IRC meeting summary for 2016-03-10

• Link to this week logs
• Meeting minutes by meetbot

Segregated witness (segwit) coordination

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.

Pieter Wuille started, “my plan was to rebase segwit on top of BIP9 [versionbits], add the BIP9 rewind logic to continue after a post-softfork upgrade, and do a new segnet [segwit testnet].”

Conversation from here discussed both standardness policy and new Bitcoin address types:

Standardness policy

[Editor’s note: BIP9 uses the word “active” to mean “enforced for all newly-created blocks”. Older soft forks used “active” with a different meaning, but for consistency the text below uses the BIP9 meaning in all cases.]

Suhas Daftuar asked for discussion about standardness policy, the optional policy that nodes follow by default to decide which transaction types to relay or mine. The segwit soft fork will create a new type of transaction the same way the BIP16 soft fork created the P2SH transaction type, and just as it was the case that anyone who spent a P2SH output before the P2SH soft fork activated (and people did) could have the bitcoins in that output stolen so again will it be the case that anyone who spends a segwit output before the segwit soft fork activates could have the bitcoins in that output stolen if the spending transaction is sent outside of a block or if the block that contains it is forked off the best blockchain.

“I believe we decided to advise wallet authors to wait some time after segwit activates before using [it]”, said Daftuar with the agreement of Alex Morcos, describing a policy that leaves the decision up to wallet authors and their users. Pieter Wuille described alternatives that would use the standardness rules, “one possibility is not enabling relay/mempool logic for segwit transactions until 2 [retarget periods] after activation.” That’s about one month after activation. “Another possibility is to just be cautious and not enable the functionality in wallets until a post-segwit release.” Wuille neither endorsed nor rejected these alternatives; he only described them as options.

Gregory Maxwell did not comment on whether a standardness policy should be used, but for Bitcoin Core’s own wallet he suggested, “I would recommend that we would switch to using segwit as default in a subsequent release after the soft fork activates. I recommend using a [subsequent] release [because] automatic behavior is not needed here. Also—it’s a pretty big behavioral change to use it, e.g. you’d be issuing other address styles in response. Having that [user interface change] triggered by invisible-to-the-user network behavior isn’t great.”

Action items: Discussion seemed to revolve around leaving the decision to wallet authors rather than creating a temporary standardness policy, but no concrete decision was reached and Eric Lombrozo suggested discussion move onto other topics, “this is something that can be decided once segwit has already been deployed and is awaiting activation”.

Segwit address type

Background: the initial announcement of segwit called for two ways segwit-capable wallets could request payment, one way uses the well-established P2SH address style; another would provide a new address style that was fully optimized for segwit. BIP142 is a proposal for that new address style, but support for it was dropped from the plan for the initial segwit implementation due to concerns from both inside and outside the project.

Wuille began the discussion, “I wish we had an address style for segwit as part of the standard.” Morcos agreed, “I think we should do that, otherwise everyone is going to embed [segwit] in P2SH, which is kind of silly.”

Lombrozo explained why it isn’t part of the initial standard, “we haven’t been pushing BIP142 because of concerns regarding scary ‘new addresses’. Internally [to the project] some people hate base58; externally some people are still grandstanding with the ‘segwit is too hard’ crap. I think it’s a battle not worth fighting right now.” BtcDrak indicated agreement with that final sentence.

Maxwell explained why he objects to BIP142’s address style: “[the] continued use of base58 is awful.” Less seriously (as indicated by an emoticon) he continued, “I am going to refuse to discuss address encodings with anyone who hasn’t read an address to me over the phone.”

Matt Corallo added, “It is not up to us here to figure out addressing for segwit – that is something wallets need to be involved in – people who actually have some UX experience, which does not exist here.” (Emphasis in original.) Maxwell agreed, “Yes, indeed, but that’s also why taking on a new address type at the same time [as releasing segwit] is not a good idea, it would get in the way of that kind of collaboration.”

Wuille remained unconvinced, “I think it’s the opposite.” Maxwell pointed out that there’s another reason to postpone creating a new address style for the moment, “[Wuille] was raising the concern that if something weren’t done sooner, we’d be stuck with [the] 80-bit security [of current addresses] forever; I reminded him […] that we have an upcoming checksig improvement to reduce transaction sizes by 30%, which would be a nice time to do a new address type too.” The OP_CHECKSIG improvement he alludes to is allowing the use of the Schnorr digital signature algorithm, which is supported already in Bitcoin Core’s signing and verification library, libsecp256k1.

Action items: none. [Editor’s note: as Corallo and Maxwell suggested, I think it would be good if the wallet authors reading this began discussing what they want to see in a new address style and how (and when) they think it should be deployed.]

Initial Block Download (IBD) with pre-generated signed UTXOs

Background: each Bitcoin Core full node downloads and processes every block on the best blockchain in order to create a database of current Unspent Transaction Outputs (UTXOs). This is the list of spendable bitcoins and the conditions under which they may be spent (such as what public key the spending signature must match). Processing all those blocks is what takes Bitcoin Core two or more hours to become fully ready the first time you start it. Jonas Schnelli proposed providing users with a pre-generated copy of the UTXO set at a certain fairly recent block height, with that set being signed by highly regarded community members, to allow users to skip downloading and processing all but the most recent blocks.

Jonas Schnelli started, “what do you think about my approach of [performing the Initial Block Download (IBD)] with a pre-generated signed UTXO set?”

Feedback was entirely negative:

• Luke Dashjr: “Sounds like a waste of time at best, to be frank. [I’d] much prefer to see [Bitcoin Core start in an] SPV mode until IBD completes.”

• Morcos: “I think that’s a bad idea. Core devs (or anybody for that matter) should not be authorizing the state of the ledger at any time.”

• Wladimir van der Laan: “It’s risky, it brings trust into the system. Who would you trust to sign something like that?”

• Wuille: “That’s not reducing block serving; it’s changing the trust model instead.”

Action item: Schnelli accepted the feedback gracefully, providing a positive emoticon and saying, “okay… so then let me not implement it.”

Backports to Bitcoin Core 0.11

Background: Bitcoin Core’s software life cycle document says, “We maintain the major versions until their ‘Maintenance End’. We generally maintain the current and previous major release. So if the current release is 0.12, then 0.11 is also considered maintained. Once 0.13 is released, then 0.11 would be considered at it’s ‘Maintenance End’.”

Morcos started, “We also need to backport all these soft forks [BIPs 9, 68, 112, 113] to 0.11; is that correct?”

Maxwell, van der Laan, and Wuille agreed, “I think backporting to 0.11 is fairly necessary; that’s only one release back”, said van der Laan.

Dashjr wanted to see backports to 0.10 if they weren’t too difficult: “0.11 is necessary; 0.10 would be ideal; but I’ll deal with 0.10 later I guess.”

Morcos replied, “0.10? I’d hoped you guys would be willing to skip 0.11. I’m worried about how well tested these major [backported soft forks] would be.” BtcDrak seemed to agree: “I would skip 0.11”.

Action item: Morcos and BtcDrak discussed dividing up the work and everyone seemed in agreement to backport all of the BIPs to the Bitcoin Core 0.11 series. Wuille concluded, “I think we can do [BIPs] 9/68/112/113 soon”. Morcos, van der Laan, and BtcDrak all agreed, with BtcDrak saying “68/112/113 are done from my side; Morcos wants to add more RPC tests, which is fine.”

VersionBits default block version

Background: VersionBits BIP9 allows using the block header version field as a bit array so that miners can indicate readiness for up to 29 soft forks simultaneously. According to the current code and proposal, a miner that isn’t signaling readiness for any soft forks will create ‘version 4 blocks’, that is blocks with the same version as used to trigger and enforce the BIP65 CLTV soft fork.

Daftuar started, “Right now [pull request] #7575 will revert back to version 4 blocks after the first soft fork activates, if no other soft forks are in the queue; I assume that is unintentional?”

Wuille replied that was actually intentional, “That [behavior] seems correct to me; the old version [4] is used to indicate ‘no versionbits’.”

Morcos wasn’t sure that the right way to do it, “all prior soft forks required miners to upgrade. What I would like to do is, with this first soft fork, require [the block header] version be greater than 4. Then we can warn on anything that is not [a bitfield whose top bits are] 001 unless it is less than or equal to 4, which we know are invalid.”

The bitfield with top bits 001000 was proposed as a good option with Maxwell saying, “I like 001000 in that it would encourage visualization tools to parse the bitfield instead of just displaying an integer.” That’s because setting the top three bits to 001 would be equivalent to a version number of 536,870,912 in the original system, which would look very odd in any blockchain explorer that displayed it that way.

Action items: none explicitly mentioned, but it seemed likely that the default version bitfield would have its top bits set to 001000.

Whether a new VersionBits default version should be required

After the preceding discussion seemed to conclude with setting the default version bitfield top bits to 001000, Pieter Wuille wanted to know whether making the the default version greater than or equal to 5 should be a “consensus [rule] or not? I prefer not introducing new consensus logic, especially when the only argument for it is better guarantees for warnings.”

Morcos replied, “I suppose it doesn’t have to be a consensus rule, but I think it’s more clear to me that it doesn’t have problems if it is a consensus rule because that’s how the [previous version-increase soft forks] worked. If it’s not a consensus rule, you can’t be sure that old nodes will be warned that the rules have changed [but] perhaps that’s not worth worrying about.” (Emphesis in original.)

Wuille asked, “are we worried that [miners] can bypass a warning mechanism?” Soft forks are different from hard forks in that a majority of hash rate can begin enforcing a soft fork at any time without creating a persistent chain split. Both versionbits and the older method of managing soft forks allow miners to use their hash rate to signal their readiness to enforce a soft fork to other miners so that they can all enforce it at the same time, but there is nothing that directly prevents the miners from agreeing to a soft fork privately. That means a soft fork warning mechanism depends upon the cooperation of the miners and attempting to design it to prevent some form of bypass might be wasted effort.

Morcos seemed agreeable to not making it a consensus rule, although it “just seems weird to me: I feel like we’re transitioning from and old system to a new system, and the transition should conform to the old system – but as long as we make the default 00100, then I think it’s just theoretical concerns.”

Action items: none.

Conclusion

The meeting concluded at its scheduled end time with discussion continuing about how warnings and alerts should be changed for versionbits-managed soft forks.

Comic relief

wumpus: it's risky, it brings trust into the system
wumpus: who would you trust to sign something like that?
sipa:   Bob.
wumpus: yes, definitely Bob
Luke-Jr: XD
CodeShark: :p

Participants

Disclaimers

Quotes taken from the discussion had their capitalization, punctuation, and spelling modified to produce consistent sentences. Bracketed words and fragments, as well as background narratives and explanatory exposition, were added by the author of this summary and may have accidentally changed the meaning of some sentences; if you believe any quote was taken out of context, please contact us and the mistake will be rectified.

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.