From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id DCAFBC0051 for ; Mon, 19 Oct 2020 01:57:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 8BF40232D2 for ; Mon, 19 Oct 2020 01:57:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6jvNeyvXFGg for ; Mon, 19 Oct 2020 01:57:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) by silver.osuosl.org (Postfix) with ESMTPS id F3CC620134 for ; Mon, 19 Oct 2020 01:57:03 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 4CF0Hd5z3fz9sSf; Mon, 19 Oct 2020 12:57:01 +1100 (AEDT) From: Rusty Russell To: Pieter Wuille , Bitcoin Protocol Discussion In-Reply-To: References: <87imblmutl.fsf@rustcorp.com.au> <20201008145938.vrmm33f6sugdc7qm@ganymede> <87r1q0e06p.fsf@rustcorp.com.au> Date: Mon, 19 Oct 2020 11:19:17 +1030 Message-ID: <877drn2g6q.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Cc: John Barboza Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 01:57:07 -0000 Pieter Wuille writes: > Today, no witness v1 receivers exist. So it seems to me the only question > is what software/infrastructure exist that supports sending to witness v1, > and whether they (and their userbase) are more or less likely to upgrade > before receivers appear than those that don't. > > Clearly if only actively developed software currently supports sending to > v1 right now, then the question of forward compatibility is moot, and I'd > agree the cleanliness of option 2 is preferable. If software supports v1 today and doesn't get upgraded, and we persue option 1 then a trailing typo can make trouble. Not directly lose money (since the tx won't get propagated), but for most systems (e.g. hosted wallets) someone has to go in and figure out the error and fix it up. Option 2 means they're likely to fix their systems the first time someone tries a v1 send, not the first time someone makes a trailing typo (which might be years). > Does anyone have an up-to-date overview of where to-future-witness sending > is supported? I know Bitcoin Core does. Anecdata: c-lightning doesn't allow withdraw to segwit > 0. It seems that the contributor John Barboza (CC'd) assumed that future versions should be invalid: if (bip173) { bool witness_ok = false; if (witness_version == 0 && (witness_program_len == 20 || witness_program_len == 32)) { witness_ok = true; } /* Insert other witness versions here. */ >> Deferring a hard decision is not useful unless we expect things to be >> easier in future, and I only see it getting harder as time passes and >> userbases grow. > > Possibly, but in the past I think there has existed a pattern where adoption > of new technology is at least partially based on certain infrastructure > and codebases going out of business and/or being replaced with newer ones, > rather than improvements to existing ones. > > If that effect is significant, option 1 may be preferable: it means less > compatibility issues in the short term, and longer term all that may be > required is fixing the spec, and waiting long enough for old/unmaintained code > to be replaced. Hmm, I'd rather cleanly break zombie infra, since they're exactly the kind that won't/cant fix the case where someone trailing-typos? > As for how long: new witness version/length combinations are only rarely needed, > and there are 14 length=32 ones left to pick. We'll likely want to use those > first anyway, as it's the cheapest option with 128-bit collision resistance. > Assuming future constructions have something like BIP341's leaf versioning, new > witness version/length combinations are only required for: > > * Changes to the commitment structure of script execution (e.g. Graftroot, > different hash function for Merkle trees, ...) > * Upgrades to new signing cryptography (EC curve change, PQC, ...). > * Changes to signatures outside of a commitment structure (e.g. new sighash > modes for the keypath in BIP341, or cross-input aggregation for them). > > and in general, not for things like new script opcodes, or even for fairly > invasive redesigns of the script language itself. Hmm, good point. These can all be done with version bumps. The only use for extra bytes I can see is per-UTXO flags, but even then I can't see why you'd need to know them until their spent (in which case you stash the flag in the input, not the output). And fewer bytes seems bad for fungibility, since multisig would be dangerous. But the future keeps surprising me, so I'm still hesitant. >> The good news it that the change is fairly simple and the reference >> implementations are widely used so change is not actually that hard >> once the decision is made. > > Indeed. Whatever observations we had about adoption of base58 -> bech32 may not > apply because the change to a different checksum is fairly trivial compared to > that. Still, presence of production codebases that just don't update at all > may complicate this. > >> > Hopefully by the time we want to use segwit v2, most software will have >> > implemented length limits and so we won't need any additional consensus >> > restrictions from then on forward. >> >> If we are prepared to commit to restrictions on future addresses. >> >> We don't know enough to do that, however, so I'm reluctant; I worry that >> a future scheme where we could save (e.g.) 2 bytes will impractical due >> to our encoding restrictions, resulting in unnecessary onchain bloat. > > I'm opposed to consensus-invalidating certain length/version combinations, if > that's what you're suggesting, and I don't think there is a need for it. This *seems* to leave the option of later removing size restrictions, but I think this is an illusion. Upgrading will only get harder over time: we would instead opt for some kind of backward compatiblity hack (i.e. 33 byte address, but you can optionally add 3 zero pad bytes) which *will* have consensus effect. > TL;DR: what codebases/services/infrastructure exists today that supports > sending to witness v1 BIP173 addresses? OK, time to waste some money! Can you provide a mainnet v1 address, and I'll try to spam it from as many things as I can find. If we're really lucky, you can collect it post-fork and donate it to charity. Or a miner can steal it pre-fork :) Thanks! Rusty.