path: root/fc/d3b38688bb41ffa89946ecf04e51ca2a0f4a23

Return-Path: <bitcoin-dev@wuille.net>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E37D3C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Oct 2020 21:09:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id C961F88549
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Oct 2020 21:09:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4tBycXHTTHTc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Oct 2020 21:09:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id A61F587097
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Oct 2020 21:09:14 +0000 (UTC)
Date: Fri, 16 Oct 2020 21:09:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net;
 s=protonmail2; t=1602882551;
 bh=n7cO7uFfhuB2jAEKEkQAd/uNgHB2nkGcBs48aJRWPQ8=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=mxF2UY6kvPAXRTlwZLSBqidilWKOf9zylL56cs8e45Xoyxn/ANAczY9NiX0EHSgWr
 UYUhHtdg9KwgFLqF1orkcjt3oYwGBkk241mrGkQzoYrT5qJ8WraGnDUCY3jfoHKc6t
 Oe5Jg8GO4SNoDemQ+C7S7wg/gZ9wD+y3Ui0/7F4d52V9ixStnjnFfReA8l+XYcxdUD
 MTihsjbVRKbgA9ZCfian83r3RU+w+D3oS9zLPOjMg2k0NIpvncXRagrLG+j+aYF3ep
 l/6G0HuXV5fuKK5peI6Hf7pVS/HTh3fobbYkKkMKZFGqQqnNhdRBrSuWMXyiJGwkqF
 ARCWr/FLY80Rg==
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Reply-To: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <sYf9B0e3UaSdMfdBfChon1Vr7BRFdH_6mgzuXIt_xbtlKtdqns9JJp90dRlNfvwBoRq57YEVrKbKX-dHDWz7TE0gobU4u8dGGJTcFFz2n60=@wuille.net>
In-Reply-To: <87r1q0e06p.fsf@rustcorp.com.au>
References: <87imblmutl.fsf@rustcorp.com.au>
 <20201008145938.vrmm33f6sugdc7qm@ganymede> <87r1q0e06p.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 16 Oct 2020 23:34:55 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2020 21:09:22 -0000

Hi Rusty,

thanks for starting this thread. We definitely should make a decision aroun=
d
this soon.


On Wednesday, October 14, 2020 6:40 PM, Rusty Russell via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:
> > > Here's a summary of each proposal:
> > > Length restrictions (future segwits must be 10, 13, 16, 20, 23, 26, 2=
9,
> > > 32, 36, or 40 bytes)
> > >
> > > 1.  Backwards compatible for v1 etc; old code it still works.
> > > 2.  Restricts future segwit versions, may require new encoding if we
> > >     want a diff length (or waste chainspace if we need to have a padd=
ed
> > >     version for compat).
> > >
> > > Checksum change based on first byte:
> > >
> > > 1.  Backwards incompatible for v1 etc; only succeeds 1 in a billion.
> > > 2.  Weakens guarantees against typos in first two data-part letters t=
o
> > >     1 in a billion.[1]
> > >

> If we go for option 2, v1 (generated from bitcoin core) will simply fail
> the first time you try test it. So it will force an upgrade. There
> are fewer places generating addresses than accepting them, so this
> seems the most likely scenario.
>
> OTOH, with option 1, anyone accepting v1 addresses today is going to
> become a liability once v1 addresses start being generated.

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.

Does anyone have an up-to-date overview of where to-future-witness sending
is supported? I know Bitcoin Core does.

> > It took a lot of community effort to get widespread support for bech32
> > addresses. Rather than go through that again, I'd prefer we use the
> > backwards compatible proposal from BIPs PR#945 and, if we want to
> > maximize safety, consensus restrict v1 witness program size, e.g. rejec=
t
> > transactions with scriptPubKeys paying v1 witness programs that aren't
> > exactly 32 bytes.
>
> Yes, I too wish we weren't 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 adoptio=
n
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 c=
ode
to be replaced.

As for how long: new witness version/length combinations are only rarely ne=
eded,
and there are 14 length=3D32 ones left to pick. We'll likely want to use th=
ose
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.

> 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.

TL;DR: what codebases/services/infrastructure exists today that supports
sending to witness v1 BIP173 addresses?

Cheers,

--
Pieter