IRC meeting summary for 2016-09-08

• Link to this week logs
• Meeting minutes by meetbot

Notes / short topics

• There will be 2 hack days on Monday 10th and Tuesday 11th of October after the scaling bitcoin conference in Milan, more info and registration will follow.
• There’s a queue of PR’s for 0.13.1, review is encouraged.

Main topics

• segwit-compact blocks BIP
• picking a segwit rollout date
• rpc sync assumptions

segwit-compact blocks BIP

background

BIP152: “Compact block relay” is a feature introduced in 0.13.0 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.

Developers are now working on version 2 of compact blocks, which is almost identical to version 1, but supports segregated witness transactions. The changes to the BIP document are proposed here

meeting comments

Gmaxwell has been doing some testing. Once he gets a bigger testing setup he’ll call for people to create more segwit transactions on testnet, as there currently aren’t many.

The latest commit to the proposed BIP document changes adds a ‘cmpctack’ message to the protocol. This has the advantage that you you could implement receiving some version of compactblocks without implementing sending that encoding, as well as simplifying the protocol slightly. This goes at the cost of complicating the implementation slightly. It is definitely not worth it if we don’t anticipate adding more than one or so more versions, however it might be worth it if we anticipate compact blocks version 4, 5, 6 at some point.

Gmaxwell notes while it’s fine to clean things up, at some point the better upgrade is to introduce a seperate mechanism and drop the old one, instead of extending it forever, as that creates a lot of technical debt.

meeting conclusion

• Discuss all options further after the meeting

picking a segwit rollout date

background

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

Segregated witness code has been introduced in 0.13.0 and is active on testnet.

meeting comments

Gmaxwell has been asking some forks about their implementation schedule around segwit, and responses were basically “after it’s deployed in the network”.

Given there are quite a few things to work on for 0.13.1 it’s hard to propose a rollout date.

Achow101 wonders wether segwit will be backported to 0.12. As been discussed in the 2016/07/14 meeting there won’t be a 0.12 backport as it has received no feedback requesting the backport.

meeting conclusion

• Don’t introduce a schedule unless we’re confident
• Don’t backport segwit to 0.12

rpc sync assumptions

background

As briefly talked about in the 2016/09/01 meeting there’s a race condition when the wallet is not yet finished dealing with transactions before getblockcount/getbestblockhash return new values, so balances might not represent the accurate state as of that block.

meeting comments

Some developers don’t see this as a bug, as unconfirmed transactions can appear at any time, unrelated to any blocks. If changing the balance while the wallet is processing transactions is regarded as a bug it should apply to all other states too, like the transaction list for example.

Other developers see this as a change in API which is going to break some RPC clients, while making wallet balance calls wait on their own until the wallet reports a height that matches chainactive height, doesn’t require all the users to audit their codebase.

In the future wallet block processing should move onto a background thread.

meeting conclusion

• Create an issue about the problem (done after the meeting).
• Merge a quick fix (#8680) to address the travis failures
• Discuss more outside of the meeting

Comic relief

BlueMatt          topic: sing morcos happy birthday
luke-jr           morcos: happy birthday https://www.youtube.com/watch?v=dQw4w9WgXcQ 

wumpus            happy birthday morcos
kanzure           wumpus: no doxxing :)
petertodd         kanzure: happy birthday to anyone who considers themselves born on this date
kanzure           much better.

btcdrak           unless you are happy with bigger blocks being relayed without it...
btcdrak           anyway. weeds.
sipa              yes, weeds
wumpus            weeds?
sipa              wumpus: "we're getting into the weeds"
wumpus            ohh
CodeShark         in the Netherlands that might have a different meaning ;)

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.