IRC meeting summary for 2016-02-04
- Segwit proposed changes
- Sequence locks
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
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:
- By Pieter Wuille at the San Francisco bitcoin developer meetup (more technical)
- By Andreas Antonopoulos in the let’s talk bitcoin podcast (less technical)
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.
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.
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.
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
19:29 petertodd note that I think we're still missing transaction-level unit tests, and I'd NACK an actual soft-fork on that basis 19:29 wumpus petertodd: I think NACKing ahead of ourselves is not constructive 19:30 btcdrak wumpus: He's the Clief Naysayer, he must! 19:30 btcdrak err Chief even 19:30 petertodd btcdrak: I Naysay your speling :P