IRC meeting summary for 2016-09-29

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• Gmaxwell mentioned the idea of having a cron mode for the daemon where it just syncs up and shuts down after, to more easily keep your copy of the blockchain up to date.
• Next weeks meeting is unlikely to happen (or have very few participants) as most developers are travelling to Scaling Bitcoin Milan

Main topics

• Pruning and blockrelay
• Removing checkpoints
• Segwit against uncompressed keys?

Pruning and blockrelay

background

With the introduction of segwit it’s expected blocks will be bigger, thus adding a bigger pressure on full node diskspace. There’s been several ideas around adding a service flag to indicate the blockchain is pruned and will not relay historical blocks.

meeting comments

The easiest solution is to just add a flag that says you relay valid blocks and transactions, but not historical blocks. It becomes harder when you want multiple ranges so nodes can host only a part of the old blocks. It becomes even more harder when you want to support sharding in an efficient way.

Sipa has been running some statistics on what block depths are being requested from nodes. He noticed 4 meaningful ranges:

• The top 2 blocks (just relay, 100 000 out of 7 000 000 requests)
• up to +/- 2500 blocks deep (requested very often, around 200-2000 requests per block)
• up to +/- 10000 blocks deep (requested a few times more than the next range)
• the rest (around 20 requests per block)

Sipa notes 4 ranges can be done with 2 service bit flags. Wumpus thinks there should be one service flag, and indicate the ranges via query so the number of ranges can be variable.

Adding node ranges over the ‘addr’ message is more difficult, gmaxwell notes ‘addr’ needs some redo relatively soon anyway, since the messages are not compatible with Tor’s new hidden service standard.

Gmaxwell was previously working on a proposal where nodes could signal a small seed from which everyone would know what parts of the history they would store, but so far he’s unable to make it both computational efficient and make it so there’s never a peer fetching a block which it had previously deleted.

Petertodd notes blocks are being downloaded linearly, so we could take advantage of that and make sure nodes with one range keep track of nodes with adjacent ranges.

If the service bit is used to indicate serving last X blocks, it should be consistent with the maximum pruning. Sipa’s data suggests there’s a lot of requests for blocks up to 2000 blocks deep, while pruned nodes have a minimum history of 288 blocks.

Morcos suggests to have preferential download from pruned peers whenever you are behind less than 288 blocks, hereby taking load off of full history peers.

meeting conclusion

• Start with a service bit indicating only relaying blocks 288 deep, maybe later add another one to indicate larger ranges.

Removing checkpoints

background

Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. These checkpoints are currently used for 3 use-cases:

• Preventing header flooding with low difficulty headers
• Skipping signatures in earlier blocks
• estimate progress

meeting comments

Gmaxwell proposes to remove checkpoints completely. Since only a very small percentage of transactions are below the checkpoint and since libsecp256k1 the signature checking only adds 15-20 minutes to the sync time.

For preventing header flooding gmaxwell proposes to perpetually increase the minimum difficulty (with a checkpoint-like bypass of that rule, if existing blocks break the minimum rule).

Estimating progress can be done in many different ways.

Sipa is not convinced and would like to see a replacement for signature skipping which could significantly improve things. Gmaxwell would like it to be something good, because otherwise imprudent attempts might be adopted, for example bitcoin classic currently ignores signatures more than 24 hours old by the local clock which can easily be exploited.

meeting conclusion

• Work on a proposal to remove checkpoints and replace it with other solutions

Segwit against uncompressed keys?

background

Public keys can be serialized in two ways: compressed (33 bytes) or uncompressed (65 bytes). Since Bitcoin QT 0.6 the compressed version is used.

meeting comments

The proposal is to make uncompressed keys non-standard in segwit transactions. Sipa noted uncompressed keys accounted for 0.7% of used keys on the network for the past 2 hours.

Armory still uses uncompressed keys. If segwit is enforcing compressed keys it would delay segwit adoption for Armory users. They plan to have a new wallet structure anyway, with BIP32 and compressed keys and segwit support. Gmaxwell thinks compressed key support can be done entirely inside the process the serializes the segwit scriptpubkey.

We should encourage all wallets to use compressed keys and help where needed.

meeting conclusion

• Make uncompressed keys non-standard in segwit
• Encourage wallets to move to compressed keys

Comic relief

wumpus          otoh bittorrent has a fixed block size :)
sipa            wumpus: so do we *ducks*
btcdrak         inb4 Bittorrent XT
petertodd       btcdrak: I use Bittorrent Unlimited myself

gmaxwell        Might as well fit a cubic spline to the height vs txn count... and store the parameters.
sipa now remembers a song our student organization wrote to the melody of staying alive, called 'cubic spline'

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.