IRC meeting summary for 2016-03-31

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• segregated witness update
• softfork backports
• bad chain alerts
• child-Pays-For-parent mining

Short topics

Update for the median time-past violation check talked about last week: there are currently no violations being mined. Gmaxwell will start generating MTP violating transactions to check for this again.

Update for network-stack refactors: cfields pushed an up-to-date version to his net-refactor10 branch which is ready for testing and review. It still needs a bunch of unit tests for which cfields is building a framework for as well as documentation.

Jonasschnelli asked if people are still interested in the p2p encryption and authentication BIP he’s been working on. Whether we need our own solution or adapt already available solutions. Sipa proposes to copy the crypto code from openssh, which is 300 lines for chacha20 - poly1305. Everyone seems in favor of continuing to write the BIP as it allows simple setups for wallets (spv) to increase privacy.

Segregated witness update

background

several developers are working on a soft fork to introduce segregated witness onto Bitcoin mainnet, with initial testing being performed on a special testnet. 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.

meeting comments

Sipa, the main contributor/maintainer of the segwit code, notes:

• segwit code progressed a lot the past few days; it now passes all preexisting rpc tests and unit tests, and many bugs were fixed in the process
• it’s rebased on top of the bip68/112/113 backport, and a new segnet (segnet4) is up and running with bip9 activation logic
• I have significantly reorganized the commits in the branch to 1) define segnet 2) add consensus/node logic 3) add wallet logic 4) add tests. This so that upgrade tests from pre-segwit code post fork can be tested and so the consensus critical part can be reviewed separately.
• I’ll write write script unit tests, as we are not testing all possible witness validation failures
• code changes can be viewed here

meeting conclusion

• Sipa will make a list of things he’d like other people to work on in order to move segwit forward.

softfork backports

background

As described in the software life cycle document Bitcoin Core developers aim to maintain the latest and previous major release, which currently are 0.12 and 0.11.

meeting comments

Relevant backports are #7716(0.11) and #7543(0.12). #7543 got 5 tested ACKs and should be ready for merge.

Morcos voiced some concerns shared by multiple developers: “I know this may be controversial, but I’d argue that it is worse to provide backports for 0.11 than not. It’s very difficult to provide sufficient enough review. You could have backported those soft forks to 0.11 in a way that passed both the existing unit tests and was broken if you didn’t know you needed to change both. I think we are doing our “customers” a better service by not putting our stamp of approval on something we can’t give as high a degree of safety to. Just a though, given that segwit will also likely be difficult to get properly tested in 0.11 … we seem to have set a requirement for ourselves that we will backport 2 major versions, and so we waste a lot of development resources doing that for a questionable quality product.”

Gmaxwell also notes there isn’t any feedback nor requests from users of 0.11 for a backport and given the performance difference between 0.11 and 0.12 there are many reasons not to run 0.11.

meeting conclusion

• People that want a backport to 0.11 should review #7716
• 0.11 backports should not delay 0.12.1

bad chain alerts

background

Services are using -alertnotify to be notified of critical problems. Some have pagers connected, or even shut off the service automatically.

Some of the messages based on heuristics, such as the “abnormally high number of blocks” one seem to appear a lot despite there being no real issue: https://www.reddit.com/r/Bitcoin/comments/3ydwg2/warning_abnormally_high_number_of_blocks/

As well as wasting time and resources, after the zillionth time users start ignoring the messages completely, and thus miss a serious problem.

Another issue is that some of the warnings don’t go away when the (temporary) problem goes away, the only way to turn them off is to restart bitcoind.

meeting comments

There doesn’t seem to be a final conclusion of what is causing the false positives and more research should go into that.
dgenr8’s pull #7568 fixes some, but possibly not all issues.

meeting conclusion

• Disable warnings for now, try to fix it in master and backport to 0.12.2/0.13 if it succeeds.

child-Pays-For-parent mining

background

Suhas Daftuar has an Work-In-Progress (WIP) 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).

meeting comments

first step is for people to give concept feedback for #7598, refactor of CreateNewBlock. The original goal of the design was to separate priority filling from feerate filling, but i think the overall goal should be to make it more modular to figure out how to assemble a block.

Given the feature freeze for 0.13 isn’t that far off (2016/05/15) and some changes need to be made on top of segwit Morcos is wondering whether to continue in parallel or focus efforts on segwit first.

Comic relief

<gmaxwell> is that bad "chain alerts" or "bad chain" alerts? :)  
<jonasschnelli> second.  
<wumpus> hehe both  
<sipa> (bad ((bad chain) alerts))  
<gmaxwell> I think it's actually more the first.

Participants

Disclaimers

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.