IRC meeting summary for 2016-09-08
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.
- segwit-compact blocks BIP
- picking a segwit rollout date
- rpc sync assumptions
segwit-compact blocks BIP
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
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.
- Discuss all options further after the meeting
picking a segwit rollout date
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.
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.
- Don’t introduce a schedule unless we’re confident
- Don’t backport segwit to 0.12
rpc sync assumptions
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.
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.
- 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
|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.