IRC meeting summary for 2017-03-02

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• 0.14.0 release
• Requests for priority review and merge
• Big features for 0.15
• GetBlockTemplate behavior after segwit activation
• CreateNewBlock calling TestBlockValidity or not, and CreateNewBlock caching
• (Empty)

0.14.0 release

Background

Bitcoin Core 0.14.0’s second and third Release Candidates (RC2 and RC3) were distributed after the previous week’s meeting.

Many of the major upgrades in 0.14.0 are performance improvements.

Comments

Briefly discussed was the status of the week-old RC2 and the recently-released RC3. None of the devs was aware of any issues and one person reported seeing some positive comments from RC testers.

Conclusion

Two meeting participants suggested Tuesday March 7th for releasing the final version of Bitcoin Core 0.14.0 if no issues are found with RC3.

Requests for priority review and merge

Background

When multiple different proposed changes to a codebase each edit the same lines of code in different ways, a conflict is created that can’t be resolved by automated version control software. Instead, a developer needs to manually review each conflicting change and figure out which change to keep or whether the changes need to combined together.

Resolving these conflicts is time consuming and most developers find it quite annoying, especially since the situation can usually be avoided if the first developer’s proposed changes are merged into the codebase before any subsequent developers start work.

In addition, because the code often changes when conflicts are resolved, the changed code often needs to be re-reviewed by Bitcoin Core’s limited pool of experienced code reviewers.

For these reasons, the development team tries to prioritize the review and merging of Pull Requests (PR) that may result in many conflicting changes.

Comments

Alex Morcos opened the topic, “I’d like to briefly discuss the timing of merging #9602. Because, assuming we are going to do it, it would be nice to get it out of the way so its not a rebase/review nightmare. I also have a ton of fee estimation changes built on top.”

Matt Corallo replied, “will finish review soon, but so far [looks good to me]. [I] would agree it should merge fast.”

Suhas Daftuar add, “I’m also working on some mining tweaks that I’d rather just build on top of 9602.”

Another request for priority review was proposed by Corallo, “I imagine Luke’s dont-use-pwalletMin thing is a PITA to rebase as well. That would be #8775.”

Conclusion

“Review and merge #8775 and #9602 as soon as possible, they are prone to turning into rebase/merge nightmares,” said Wladimir van der Laan.

Big features for 0.15.0

Note: this was discussed during the preceding rebase topic.

Background

Gregory Maxwell started the discussion, “It might be useful, not in this meeting, but for people to think about what they’d like the big features of 0.15 to be and make sure we make progress early enough on those things so that they can actually be there. :) I feel like there were things that at least I personally wanted in 0.14 but didn’t give them enough attention until too late.”

Wladimir van der Laan polled to see if anyone had “large upcoming softfork projects [that would be] monopolizing everyone” but Maxwell replied, “everything like that is on hold for segwit!”, and so Wladimir suggested that “means for 0.15 we can focus on software features instead of network/consensus features.”

Discussion

Alex Morcos asked, “do we not have any suggested [soft forks] that aren’t built off segwit in the queue? lets take advantage of BIP 9!” Pieter Wuille replied: “raise minimum difficulty, optional UTXO commitments, …”.

• Raising the minimum difficulty would hopefully be the final step in removing block chain checkpoints from consensus-compatible full nodes such as Bitcoin Core. Checkpoints were added in Bitcoin 0.3.2 to “lock-in the block chain up to this point,” which reduces the effectiveness of certain attacks but also provides a mechanism that can override one of Bitcoin’s essential rules: that the network’s ledger is the valid block chain with the most proof of work (PoW).

  A raise in the minimum difficulty would make attacks more expensive (because they’d have to contain much more PoW than the same attack now) without impeding Bitcoin’s normal use of PoW to select between valid chains.

  For more background information, see discussion during the 27 October 2016 meeting as well as the IBD using chainwork (released in Bitcoin Core 0.13.2) and assumed valid blocks (released in Bitcoin Core 0.14.0).

• Optional Unspent Transaction Output (UTXO) commitments could help improve the security of lightweight wallets. This is a topic that has been researched part-time for several years by multiple contributors working mostly independently but sharing ideas. The author of this summary isn’t aware of any concrete proposals with even provisional widespread acceptance among the technical community.

Morcos also suggested, “one major feature that’s in the back of my mind, but a bit complicated so might require some discussion as to whether we want it (and when) is automated fee-bumping.” Maxwell suggested a different name, “I would replace ‘automated fee bumping’ with ‘precomputed fee bumping’”.

• Precomputed fee bumping was briefly described by Maxwell in the meeting, “when you sign, presign all the bumps, locktimed… so they don’t interfere with the wallet encryption.. and could even be handed off to someone if you go offline.”

  For example, Alice would tell Bitcoin Core that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay.

  Bitcoin Core would use its existing fee estimation feature, as well as the optional fee bumping feature being introduced in Bitcoin Core 0.14.0, to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Bitcoin Core would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…

  Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.

  Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.

  In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.

Conclusion

No explicit conclusions. Presumably the developers will focus on getting 0.14.0 released during the upcoming week and then will spend more time discussing goals for 0.15.

GetBlockTemplate behavior after segwit activation

Note: this was also discussed during the preceding rebase topic.

Background

Segwit is designed to give miners a choice after segwit activates:

1. Miners can produce old-style blocks the same as they do now, but those blocks can’t include any segwit transactions (so miners will likely receive fewer transaction fees).

2. Miners can produce segwit-style blocks and mine segwit transactions, capturing any extra fees available. To do this, solo miners and pool operators will need to update their software to a version that supports segwit.

Software for solo miners and mining pools gets a list of unconfirmed transactions and other information for mining from Bitcoin Core’s GetBlockTemplate (GBT) Remote Procedure Call (RPC).

Bitcoin Core by default currently only allows miners to signal support for segwit using BIP9 versionbits if they’ve made (or faked) the upgrade to segwit-compatible mining software using GBT. However, Bitcoin Core by default will also stop providing GBT results when segwit activates for any miners who haven’t upgraded to segwit-compatible software; the quoted meeting comments below explain why this choice was made.

Comments

Gregory Maxwell started the discussion, “[I think] we should reconsider some things around how segwit works: that we won’t mine once segwit is active without the flag set, and we don’t set the versionbit without the flag.”

Suhas Daftuar explained, “we do that so that segwit can’t activate without the miners actually mining segwit transactions. My concern (before we got to the point we’re at now) was that segwit could have activated with 0 miners mining and then mempools could be attacked with transactions that wouldn’t confirm.”

Maxwell’s reply was, “yea but I think that is an error. So what if they don’t? Then there is just less capacity for segwit transactions initially until they upgrade, and they’ll lose out on fees.”

Alex Morcos agreed and added, “as long as we know that SOME miners are mining them, which seems we’re at that point now.” Daftuar also agreed with relaxing the safety condition now, and Matt Corallo seemed to agree too.

Conclusion

No explicit conclusion, but there seemed to be general agreement among meeting participants to change Bitcoin Core to continue mining valid old-style blocks when segwit activates for miners that don’t call GBT with the segwit flag.

CreateNewBlock calling TestBlockValidity or not, and CreateNewBlock caching

Background

The main function in Bitcoin Core that assembles new blocks for miners is called CreateNewBlock (CNB). As a final step before providing the created block to miners, a TestBlockValidity (TBV) function is called that ensures the created block will be valid—accepted by other nodes—if the miner finds the required amount of proof of work.

Bitcoin miner James Hilliard (Lightsword) has opened a Pull Request (PR) that removes TBV from CNB (#9858) and an alternative PR that makes it optional (#9859), explaining: “Getting an invalid template here should never happen unless there is a bug within bitcoind, [so] this TestBlockValidity call is only an internal sanity check”.

For more background on TBV, please see discussion in the above linked issues.

Comments

Pieter Wuille suggested the topic, and Gregory Maxwell started the discussion: “We need to get TBV out of the critical path. I do not really agree with Lightsword’s view on it though– I think it’s important that we have some process that tests that blocks we’re handing out to mine. It does not need to be in the critical path.”

Alex Morcos explained more, “the downside of leaving it in the critical path is an extra 150ms of mining with an empty block.”

Pieter Wuille enumerated options: “an easy [solution] (just get rid of the test); or a hard one (background validation, caching, …)”

Technical discussion about backgrounding and caching ensued, with participants being in favor of both but not yet having a clear design so more discussion is likely needed.

Morcos suggested, “honestly I think a more important direction to go would be to start by replacing GBT [GetBlockTemplate] with a better framework.” Wuille and Maxwell replied that changing how TBV is used and a GBT replacement seemed like two independent (orthogonal) topics; Morcos agreed but added, “perhaps what I mean is we should design the better thing so it informs what we want out of CNB/TBV. And document the design so we don’t forget.. even if we don’t do it yet.”

No one was opposed to an experimental design, but no one seemed enthusiastic about it either.

Discussion turned to the possibility of validationless mining for the short period of time between when a new block is received and when that block is validated. Morcos described how this could work, “get a new block from the network -> assume valid -> mark all [of its] transactions in mempool as potentially used -> CNB from remaining -> have not yet validated new tip or TBV new template, and if we find a block, so be it.”

Maxwell pointed out, “in that case you would extend an invalid block, bad (very bad to have miners extending invalid blocks, even for relatively brief intervals, [as it] massively amplifies risk for lite clients– especially since [mining] devices may stay on old work for tens of seconds).”

Matt Corallo was thinking something similar to Morcos, “I’m more a fan of not relying on validation being fast - mine empty blocks for the 100ms it takes to get a blocktemplate, and relay blocks during validation.”

Maxwell mentioned a draft BIP he had written to reduce the harm validationless mining does to lite client security. Corallo was on board, “I think we should implement that when we go to return empty blocks :) I’m happy to go implement it in lite clients, too.”

Discussion returned to technical details at this point, focusing on how mining software would handle empty blocks returned by Bitcoin Core as well as returned by mining pool software.

Conclusion

No explicit conclusion. All developers present seemed committed to improving the situation but nobody spoke directly in favor of the solutions in #9858 or #9859. About 10 minutes after the meeting, the author of those PRs became available on IRC and began discussion with the devs about potential short-term optimizations that could be made while more significant (but longer-term work) proceeded.

Topic: (empty)

During the preceding conversation about producing empty block templates when results were needed in a hurry, Pieter Wuille reminded everyone that they only had 5 minutes left in the meeting for other topics, leading Gregory Maxwell to hurriedly suggest the topic of “empty messages”. The entirety of the discussion on this topic is relayed in the Comic Relief section below.

Comic relief

<sipa> we're running out of time
       any other topics?

<gmaxwell> quick, empty messages

<sipa>

<luke-jr>

<wumpus>

<gmaxwell>

<luke-jr> inb4 trolls use this as proof we obey gmaxwell

<gwillen>

<BlueMatt> lulwut

<wumpus> #topic

<sipa> it's "lolwut", BlueMatt.

<BlueMatt> lulzwutz

<wumpus> cleared the topic, too, now we can cleanly exit the meeting

<gmaxwell> We should appoint a subcommittee to investigate the spelling of lolwut/lulwut.

<wumpus> #endmeeting

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.