IRC meeting summary for 2016-02-04

Logs

• link to this week logs
• Meeting minutes by meetbot

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:
- 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.

meeting comments

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.

meeting comments

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

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