IRC meeting summary for 2016-02-25
- BIP 68/112/113 rollout
- Forthcoming OpenSSL releases
PR #7542 Implement “feefilter” P2P message hasn’t been reviewed yet.
BIP 68/112/113 rollout
BIP 68 Consensus-enforced
transaction replacement signaled via sequence numbers.
BIP 112 CHECKSEQUENCEVERIFY.
BIP 113 Median time-past as endpoint for lock-time calculations.
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. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions.
BIP 9 Version bits with timeout and delay.
Currently softforks have been done by the IsSuperMajority mechanism, meaning when 95% of the last 1000 blocks have a version number higher than X the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
A nontrivial amount of hashrate is voting using block version numbers for BIP 109, which complicates deployment using IsSuperMajority. This could also delay Segregated Witness deployment. Therefore versionbits are likely to be used.
BIP 68 requires v2 transactions, which aren’t currently relayed.
A significant portion of the hashrate had signaled readiness to enforce CLTV (BIP 65) before any released software supported it.
PR #7561 will need to be converted to versionbits.
Review PR #7575.
The relay policy will likely be changed before softfork deployment.
Talk to the btcd developers about BIPs 9/68/112/113 for feedback.
Send an email to the mailing list about BIP 68/112/113 deployment for any objections.
To prevent premature activation a “start time” will be defined for BIP 9 softforks. A 1-2 month start time after the expected release date is suggested.
Forthcoming OpenSSL releases
There’s a new OpenSSL release which fixes some security issues.
Since 0.12 Bitcoin Core uses their own libsecp256k1 for ECDSA signature verification instead of OpenSSL.
OpenSSL should be out of the software to the greatest extent possible.
OpenSSL is only really needed for the payment protocol which is virtually unused. It is suggested to disable it by default and listen for feedback.
For the time being emergency updates for serious OpenSSL vulnerabilities will need to be rolled.
petertodd Peter Todd gmaxwell Gregory Maxwell btcdrak btcdrak morcos Alex Morcos sipa Pieter Wuille CodeShark Eric Lombrozo jonasschnelli Jonas Schnelli sdaftuar Suhas Daftuar warren Warren Togami
19:25:30 <btcdrak> wumpus: I would caution any merging consensus refactoring PRs until we get the sf code emerged. It will make backporting to 0.12 easier and easier to verify (basically an easy cherrypick). 19:26:28 <petertodd> btcdrak: I suggest we buy jtimom a time machine so he can do his refactors in the past :) 19:26:40 <petertodd> *jtimon