Logs

Main topics

Segwit proposed changes

Sequence locks

Short topics

Bitcoin core 0.12 is at release candidate 3 https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

The end-of-life policy as discussed in a previous meeting is published.

Segwit proposed changes

background

Segregated witness changes the structure of transactions so that the signatures can be separated from the rest of the transactions. This allows for bandwidth savings for relay, pruning of old signatures, softforking all future script changes by introducing script versions and solves all unintentional forms of malleability. During the last scaling bitcoin conference Pieter Wuille presented a way of doing this via a softfork, and proposed increasing the maximum amount of transactions in a block by discounting signature data towards the total blocksize.

Segregated witness is part of the capacity increase roadmap for bitcoin-core.

More detailed explanations:

Peter Todd proposed two ideas for segregated witness:

unvalidated block extension data which would make future consensus-data-adding softforks easier to deploy.

Miners should prove they, or a trusted 3rd party, have a copy of the previous block’s data to be able to create a new block, as a way of not further incentivizing validationless mining.

The discussion about unvalidated block extension data is ongoing.

Petertodd is working on the prev-block-proof and he’ll likely have it ready for review in a few days.

This idea can be used to stop SPV mining entirely, whether we do this or not is an implementation decision.

It’s also possible to enforce that the block must be empty to validationless mine.

The problem with SPV-mining is that it breaks the SPV-wallet’s security model.

meeting conclusion

As the discussion moves to more long-term ideas of what bitcoin should become, it’s redirected off-meeting, as the meeting is for short-term development.

Sequence locks

background

BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers.

BIP 112 CHECKSEQUENCEVERIFY.

In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system.

The BIP68 implementation is done and gathering ACKs, same for the BIP112 implementation

Ajtowns has written some test scripts, for which you need to merge both PR’s together. btcdrak did so at https://github.com/btcdrak/bitcoin/tree/sequenceandcsv

Downstream consumers have done extensive testing and found the code useful for their cases.

All the BIP texts are merged and final.

Petertodd notes he thinks we’re still missing transaction-level unit tests for an actual soft-fork.

meeting conclusion

Review and ACK #7184 and #6564

Participants

petertodd Peter Todd wumpus Wladimir J. van der Laan btcdrak btcdrak jtimon Jorge Timón sipa Pieter Wuille Tasoshi Tasoshi phantomcircuit Patrick Strateman cfields Cory Fields gmaxwell Gregory Maxwell shea256 Ryan Shea

Comic relief