Date: Mon, 19 Oct 2020 22:55:50 +0000
To: Rusty Russell <rusty@rustcorp.com.au>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Reply-To: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <S6FCoLsmwaQUhrtSURemcTcG8tUWTXYkBf-0Q0hxCpObfJQ0TXNcmJrQhoqy7ttWwtGnvyS-bJ5RSXJoPizAgjuMognzVnu3SM3wMujKy88=@wuille.net>
In-Reply-To: <877drn2g6q.fsf@rustcorp.com.au>
References: <87imblmutl.fsf@rustcorp.com.au>
 <20201008145938.vrmm33f6sugdc7qm@ganymede> <87r1q0e06p.fsf@rustcorp.com.au>
 <sYf9B0e3UaSdMfdBfChon1Vr7BRFdH_6mgzuXIt_xbtlKtdqns9JJp90dRlNfvwBoRq57YEVrKbKX-dHDWz7TE0gobU4u8dGGJTcFFz2n60=@wuille.net>
 <877drn2g6q.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 John Barboza <johnbarboza@gmail.com>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions
	(BIP-173)
Precedence: list

On Sunday, October 18, 2020 5:49 PM, Rusty Russell <rusty@rustcorp.com.au> =
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