IRC meeting summary for 2016-05-26
- Segwit priority
Notes / short topics
- The logs for the coredev hacking event last week can be found here and a summary of these notes here.
- BIP 151
Developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet. Segregated witness (segwit) allows transaction signature data to be stored outside of the data hashed to produce transaction identifiers, removing all known forms of third-party malleability, allowing full nodes to compile the current UTXO set without downloading all signatures, and laying the groundwork for fraud proofs that can allow lightweight (SPV) clients to help enforce more of the consensus rules. The segwit soft fork also allows miners to substitute 1 byte of block space with 4 bytes of segwit data, increasing transaction capacity for wallets that use segwit. segregated witness BIPs: BIP141, BIP142, BIP143, BIP144 and BIP145
Both the network stack refactoring as the libconsensus refactoring are long-term important, but conflict with code from segregated witness. Although the net refactors hurt compact blocks more than segwit, as the network changes for segwit are at a higher level than the network refactors.
Libconsensus refactoring worked well in 0.10 because there was a clear goal and a clear way to do it, whereas further efforts have mostly been one-person shows and it makes sense to agree on a plan if we want those changes to happen.
The feature freeze for 0.13 is on 2016-06-16 and compact blocks would be good to have in 0.13 to alleviate the extra replay latency. We could merge segwit with no softfork defined to just have the code in which makes testing on testnet easier and let’s further development happen on top so other work isn’t held up by segwit.
Since segwit has activated on testnet, segnet will be dropped.
- Merge segwit as code only
The Bitcoin network does not encrypt communication between peers today. This opens up security issues and allows for mass surveillance / analysis of bitcoin users. For SPV nodes this can have significant privacy impacts and could reduce the censorship-resistance of a peer.
Encrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is. Today it’s trivial for a network provider or any other men-in-the-middle to identify a Bitcoin user and its controlled addresses/keys as a newly broadcasted transactions will reveal the amount and the payee to the network provider.
This BIP also describes a way that data manipulation (blocking commands by an intercepting TCP/IP node) would be identifiable by the communicating peers.
Analyzing the type of p2p communication would still be possible because of the characteristics of the encrypted messages.
Petertodd got some feedback from cryptographers who where concerned about BIP 151 not being an off-the-shelf standard. BIP151 uses the openssh’s chacha20-poly1305 exactly, so it might need to be made more prominent in the BIP.
- make it more clear in the BIP text BIP151 uses the chacha20-poly1305 standard.
Suhas Daftuar has a pull request that helps miners create more profitable blocks by considering the combined fee rate of unconfirmed transactions plus their child transactions. This is useful not just or improving miner profitability but also for allowing users to effectively add fees to transactions that are already in miner memory pools by creating child transactions with high fee rates, which is commonly called Child Pays For Parent (CPFP).
The needed refactors for CreateNewBlock conflict with segwit, so it might miss 0.13. There hasn’t been much review / testing although everyone wants to have it in sooner than later, as this is a feature long talked about.
- Review PR #7600
|wumpus||Wladimir van der Laan|
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.