IRC meeting summary for 2016-06-02

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• Segwit review
• Compactblock testing
• CPFP status & other pending pull requests

Notes / short topics

There aren’t a lot of people interested in doing the softfork backports for 0.11 and there isn’t a lot of user interest for it either. The backport of BIP68 is particularly complex and might be more dangerous than not doing a release at all. The software life cycle page still promises to maintain the previous version but also 0.13 is near so it may be less of an issue.

Segwit review

background

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

meeting comments

Sipa’s planning to make the BIP9/GBT changes, remove segnet and the positive witness flag and then create a parallel rebase with a clear history, but which leads to the same tree. The positive witness flag was a flag to indicate you want to serialize the witnesses. Since you almost always want to serialize the witnesses outside of a few exceptions it’s better to have a negative witness flag. Another reason is that a failure of setting the positive flag will not usually be detected, but a failure to set a negative flag will. Having both flags is also an option, but would result in more code changes shattered all over the place.

Since you don’t want users to have segwit addresses before the roll-out, the new wallet code can be introduced behind a hidden configuration option that tests could use.

jl2012 brought up the issue that our witness program definition is limited to 16 versions, which is not easily extended without introducing a new witness storage. The easy solution to allow witness programs to be slightly larger is a hard fork change compared to the current code, which would result in a testnet fork, since segwit is already activated there. Since the worst thing that can happen is a reindex for testnet nodes and 16 is too few sipa will change the version limit.

meeting conclusion

• Review #7749 (Enforce expected outbound services) and #8083 (Add support for dnsseeds with option to filter by servicebits)
• Extend the max witness program length

Compactblock testing

background

BIP152: “Compact block relay” is a proposed idea by BlueMatt for decreasing the bandwidth used during block relay by using short transaction IDs for transactions that should be in the mempool of the node. As a side-effect this also results in reducing the block transfer latency for the p2p network.

meeting comments

BlueMatt has built a parallel relay network that uses compact blocks and the UDP network block coding stuff and sipa has rebased TheblueMatt’s PR on top of the shared_ptr mempool change (available here). A number of people, including some large miners, are running both on public nodes. Everything seems to work as expected with the data collected.

Gmaxwell notes he should take an action to setup a couple of published addresses too, for people to connect to without asking.

meeting conclusion

Review PR #8126 (std:shared_ptr based CTransaction storage in mempool).

CPFP status & other pending pull requests

background

Suhas Daftuar has a pull request (#7600) 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 for 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).

meeting comments

PR #7598 which refactors CreateNewBlock is needed for CPFP

There are a lot of PRs in the queue that are decent, but not quite finished. Which makes it hard to maintain a good overview and hard to test multiple PRs, as many touch the same parts. Wumpus asks if there are any PR’s that are close to being able to merge.

Jonasschnelli thinks #7957 (RPC: Add support for sequence number) can be merged and asks for some review on #7946 (Reduce cs_main locks during ConnectTip/SyncWithWallets). He also asks for permission to merge [docs] and [tools] PR’s. He’ll try and focus on the more trivial docs PRs.

Sipa asks for review of #7948 (RPC: augment getblockchaininfo bip9_softforks data), #7967 (RPC: add feerate option to fundrawtransaction) and #7997 (replace mapNextTx with slimmer setSpends)

Luke-jr thinks #7935 (Versionbits: GBT support) is ready.

meeting conclusion

Review PR #7598 (Refactor CreateNewBlock to be a method of the BlockAssembler class)

Comic relief

sipa         i have another question
gmaxwell     sipa: what is the meaning of life?
sipa         42
gmaxwell     thats an answer, not a question!
luke-jr      he has both the answer and a question
gmaxwell     we're going to need to build a bigger computer...

gmaxwell     Yes, though they may get DDOS attacked, which is harmless but would waste time sorting out the issue. :)
wumpus       gmaxwell: you mean thoroughly stress-tested :)

Participants

Disclaimer

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.