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 07E10C0051 for ; Mon, 19 Oct 2020 22:56:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id DC1612E160 for ; Mon, 19 Oct 2020 22:56:05 +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 O98hMI9i6sHF for ; Mon, 19 Oct 2020 22:56:02 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by silver.osuosl.org (Postfix) with ESMTPS id BE6ED20113 for ; Mon, 19 Oct 2020 22:56:01 +0000 (UTC) Date: Mon, 19 Oct 2020 22:55:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail2; t=1603148158; bh=k/A00TGYeZGH9/C/4y6t1IQ8pPOOTriKDkKPb+hQYrU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=bT5Ya+WzyYZnJ8Mj45frSicSaDUmk1WfvlkgQzdWJdyAYvm2FtqeDJpvXUOq6MyRt atpI9I6c6Dv+O6fjwibOMA7BqGdQrU72gOp2Cf+RKpOh8sYP0dQA3B9RKPaauHELd7 x8mOR6dTqr6Tg7N72zoQgAdY4fh5SSSBfOUUtnTMyd43Oz1q5Q1UtkkXBZVaKNPxBG aGDgoDfE/JvXfykN/klZBB0DI8FL6a1jp4dq3lTZeCrRDdCl6IlHJnq0kB+a8NosGu N7CUYJ14sB6Lf3BsEkF45Rlzq/NJa8zKvyFDytnBJiNsORB7j/WwBxXMbZWzTn/55B p08cPx8G2vIcg== To: Rusty Russell From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: <877drn2g6q.fsf@rustcorp.com.au> References: <87imblmutl.fsf@rustcorp.com.au> <20201008145938.vrmm33f6sugdc7qm@ganymede> <87r1q0e06p.fsf@rustcorp.com.au> <877drn2g6q.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 19 Oct 2020 22:58:55 +0000 Cc: Bitcoin Protocol Discussion , 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 22:56:06 -0000 On Sunday, October 18, 2020 5:49 PM, Rusty Russell = wrote: > Pieter Wuille bitcoin-dev@wuille.net writes: > > > Today, no witness v1 receivers exist. So it seems to me the only questi= on > > is what software/infrastructure exist that supports sending to witness = v1, > > and whether they (and their userbase) are more or less likely to upgrad= e > > 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. It depends. As is, they'd be relayed even as sending to future witness vers= ions or lengths is standard. If option 1 is chosen there may be reasons to add safeguards using relay policy, though. > 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). Possibly, but it's also possible that it won't get fixed at all, and instea= d receiver software just has to wait a few years longer before being able to = start giving out v1 addresses and have a reasonable chance the sender supports it= . You're right though that protecting old sender software from being protecte= d against the insertion bug is a good argument in favor of Option 2. Strictly speaking it also has an issue, as the error detection properties a= ren't guaranteed for new-scheme-address + intended-detected-error interpreted as old-scheme-address (in particular, you can make 4 substitution errors in a new-scheme address and have it be a valid old-scheme address). This is mu= ch less of an issue than the insertion bug that remains present with Option 1 = in old senders. > > As for how long: new witness version/length combinations are only rarel= y needed, > > and there are 14 length=3D32 ones left to pick. We'll likely want to us= e those > > first anyway, as it's the cheapest option with 128-bit collision resist= ance. > > Assuming future constructions have something like BIP341's leaf version= ing, new > > witness version/length combinations are only required for: > > > > - Changes to the commitment structure of script execution (e.g. Graft= root, > > 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 s= ighash > > modes for the keypath in BIP341, or cross-input aggregation for the= m). > > > > > > and in general, not for things like new script opcodes, or even for fai= rly > > 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. Of course, our thinking here may change significantly over time - still, I = expect it'll be years before something other than 32-byte addresses is desired. > > TL;DR: what codebases/services/infrastructure exists today that support= s > > 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 :) Here is a BIP341 witness v1 address, corresponding to just the generator as inner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP)= : bc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY ptwy6lm87= hf5ss52r5n8 Cheers, -- Pieter