IRC meeting summary for 2016-06-09

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• compile-time / memory usage
• segwit update
• Compactblock testing

Notes / short topics

• The feature freeze for Bitcoin Core is scheduled next week, all the features that need to be merged should be merged before that time. Cfields has 2 p2p refactor PR’s he’d like to get in, which can be done after the freeze as those aren’t new features.
• After last meetings comment about the software life cycle page Btcdrak and David Harding have been working to update that page to make it more clear and representative here and further here, this needs review.

compile-time / memory usage

background

Issue 6658 (Building requires >1GB memory) and 7471 (Not a lot of headroom for building with 512 MB RAM) talk about the increasing need for RAM while compiling.

meeting comments

Gmaxwell notes we can no longer compile on hosts with only 2GB of RAM with default settings, while we have documentation that says 1.5GB.

TheBlueMatt has a patch ready that moves all the mempool stuff out of it, which apparently gets it back to 1.5GB. He hasn’t made the pull request yet though.

Wumpus notes building with Clang usually uses a lot less memory at the same compile settings.

The compile time probably correlates with the memory usage as disk seek/read access is negligible.

Adding binary builds for ARM and AARCH64 would reduce the amount of complaints about memory problems. Cfields is working on this. Users can currently use cross-compilation, however gmaxwell notes a lot of people using raspberry pi-like systems do not have another linux host.

meeting conclusion

Cfields plans to add ARM binaries without GUI for 0.13 (Done after the meeting in PR #8188)

Segwit update

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

There are still some bugs that need to be fixed before the code minus the softfork can go into 0.13. Sipa notes everything will be addressed in the next batch of patches.

Luke-jr would like the maximum witness program length to be 75 bytes as opposed to the 40 bytes it is now. He argues there’s no point in limiting (below 75, as above 75 would require more changes and additional testing) and smaller limits could very well prevent future softforks. Expanding the limit later on would require a hardfork. Sipa argues there should be no need for more than 256-bit hash + some versioning metadata, setting it to more would give the impression that there is, or as petertodd elaborates: would give the impression bitcoin is more broken than that. Gmaxwell chimes in and thinks the biggest harm he sees is that allowing a larger size potentially limits the ability to make UTXO entries limited in size in the future. However further limiting can happen later on. He also notes it is possible to expand this in the future by using a different version type signaling, however that would require a new commitment in addition to the current one.

meeting conclusion

Discussion kept going and was deferred to off-meeting.

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.

meeting comments

There are a number of nodes running compactblocks on the public network and everything seems to be working well. Instagibbs made a chart of it. Gmaxwell has been running tests with a modified version that reduces the hash size to 16 bits to test rare corner cases surrounding collisions by making them more common. Two large mining pools have been running it, one of which is behind the great firewall of china.

Cfields wonders if there’s been discussion about a servicebit for compact blocks. The argument brought up before was that service bits should only be used for critically required services. Since it’s likely to become sufficiently ubiquitous fast enough it won’t be needed. Only the miners would really need it, but they should be curating their connections manually anyway.

meeting conclusion

• The interaction with block fetching logic needs more review.
• Reviewers should stop using sipa’s branch, as PR #8068 has been rebased on top of the shared_ptr work.
• Review PR #8084 (Add recently accepted blocks and txn to AttemptToEvictConnection)

Comic relief

wumpus       #link https://github.com/bitcoin/bitcoin/issues/7471
cfields_     wumpus: thanks
wumpus       eeh that's the wrong one
gmaxwell     wumpus: unthanks

Lightsword   maybe we should just have a service bit for flagging fast relay nodes/miners in general for preferential peering rather than making it flag compact blocks specifically
sipa         Lightsword: we should also have an evil bit that abusive nodes should set

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.