path: root/0b/b92ad4781b683f2385eaae3c0189684e043eb9

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7F726C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 14:30:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4D855416DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 14:30:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4D855416DB
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=SiZ8N5zY
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id um15jJeHyBD3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 14:30:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 73C90416C9
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [IPv6:2a00:1450:4864:20::633])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 73C90416C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 14:30:48 +0000 (UTC)
Received: by mail-ej1-x633.google.com with SMTP id bk15so42098550ejb.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 06:30:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=83oeDvjl3Tsnq60cpkNBGrnXqOhuEo+bK/N3kzN05sY=;
 b=SiZ8N5zYnXujiA6yTAei6W46qc7H8PaociuJcToNyNrPlAm8mbyJZOVlWdE/hCvMMZ
 mX9vEhjDF6k9opg8k8t7rtg5iQ3SiW3ugNYjPfe+oxRdMu+F1Dgu3UxkgL3+sVq7KwTW
 8iaPK7TEJfDwMdE8bImsl6lWd/QVrKmSL1xowO1JlyWftiU9M/Gd/Bn4CRalwgYSRFks
 YvDhz51xb8/vZ4zcz4gPAiAOkWqrcKjHPrBAL+duw2sNkHiF/sL7VCWbEGj3DEX8P0Ax
 Yk9QmD49sCfdTGgprPZoEunoZEP/F80Ht4GM2sfl3/R/1s0su8IFmd+7BPbcaM1cNj2/
 ubEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=83oeDvjl3Tsnq60cpkNBGrnXqOhuEo+bK/N3kzN05sY=;
 b=e1WCxMBalKFQ0pMxcvnySh37mouJzSvsXdkif7M7grXJ/0FdEqwlvuluIEwj9UI59B
 Zc67X/H02CfaRkI1J83w0KmILFIpGCfhQwmMZpf0mZMx3Ugn4W3LBXZH4R3Jv9b8ET1P
 5y6LLa03v9oymghPW7B6TGd676hZXQzczr88K6txXjTD8j6DiFv58XeKvuMYfoiQiHET
 qLdd96C+xmPMn7vUzJrNwNg093UsHBFaIT26HIPmHpDjFBHx4uyw2kR6pr+eli7Vh5P7
 JwFGQHyN1h+Hfo6uoXSZzROA/3NircdY5WIah2KGHmZEK0ouMsZ29GyumhIshcwA9438
 Ib4Q==
X-Gm-Message-State: AO0yUKU1hf3Y34cIoN7wbF4STATtGSt1Q2psZlMYNsUAJt+Cktg9a4ml
 8PM1YmtiJJYlw61hFxQnLJj/a2KDr+A8trrMG6+7ARTf
X-Google-Smtp-Source: AK7set8MGOySj4BH+B+Mx3VIrw2JQvNCrHjJHdbJU12ydwxsZHzuy5UPQhEJ+fquF+deexY/akZNPXQ59yPkrA5MoOM=
X-Received: by 2002:a17:906:b858:b0:878:5dec:1bc3 with SMTP id
 ga24-20020a170906b85800b008785dec1bc3mr5914282ejb.134.1675175446135; Tue, 31
 Jan 2023 06:30:46 -0800 (PST)
MIME-Version: 1.0
References: <e6da74da025355472a81e613fe7683b9@dtrt.org>
In-Reply-To: <e6da74da025355472a81e613fe7683b9@dtrt.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 31 Jan 2023 09:30:34 -0500
Message-ID: <CAB3F3Dtfu+kaJ8jgi-qRiZBXvuYaEVEa32q_UPkwA5MLAP9RSg@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000674cfd05f3902d07"
Subject: Re: [bitcoin-dev] Reference example bech32m address for future
	segwit versions
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: Tue, 31 Jan 2023 14:30:50 -0000

--000000000000674cfd05f3902d07
Content-Type: text/plain; charset="UTF-8"

Hi David,

From practical experience, I think you'll find that most exchanges will not
enable sends to future segwit versions,
as from a risk perspective it's likely a mistake to send funds there. That
said, as long as we don't change
the checksum again(!), updating to new versions should be fairly straight
forward. Every update will be a matter
of allowing a new version and a new length instead of requiring
library updates. Making sure the most popular
open source libraries support it is probably the best way to spend energy
ensuring that future upgrades go smoothly.

Best,
Greg

On Mon, Jan 30, 2023 at 8:25 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi y'all!,
>
> One of the benefits proposed for bech32 (and, by extension, bech32m) is
> that spender wallets shouldn't need to be upgraded to pay segwit outputs
> defined in future soft forks.  For example, Bitcoin Core today can pay a
> bech32m address for a segwit v2 output, even though no meaning has been
> assigned to output scripts matching a segwit v2 template.
>
> However, testing this behavior in production[1] can create an annoyance
> for developers of future soft forks.  They will need to deal with any
> existing outputs paid to the templates used in that proposed soft fork.
> See, for example, some discussion by developer 0xB10C about payments to
> segwit v1 addresses before activation of the taproot soft fork:
> https://b10c.me/blog/007-spending-p2tr-pre-activation/
>
> I was wondering if it would be useful to have a canonical examples of
> future segwit addresses that are designed to be very unlikely to
> interfere with future soft forks but which would still reasonably
> exercise wallets supporting bech32m.  I think of this as the rough
> equivalent of the RFC2606 domain "example.com" which has been reserved
> for examples in documentation.
>
> Specifically, I'm thinking of the following addresses, one each for
> mainnet and testnet:
>
> - HRP: bc for mainnet; tb for testent
> - Witness version: 16 (the last segwit version)
> - Witness program: 0x0000.  Two bytes is the minimum allowed
>    by BIP141, but it's far too small to make any sort of secure
> commitment,
>    so I'm hoping it won't conflict with any future use
>
> I think we should try to start with just one reserved address per
> network, but if that isn't enough, I think we could allow any two-byte
> witness program with witness version 16.
>
> Outputs paid to reserved addresses will still be anyone-can-spend, so
> there's no change required to Bitcoin Core or other software and those
> outputs can still be cleaned out of the UTXO set.  Additionally, if we
> ever *really* need that address space for a soft fork, it will be
> available.
>
> Are there any objections to this idea, or suggestions for a better way
> to go about it?
>
> Thanks!,
>
> -Dave
>
> [1] Testing in production should be avoided because it uses block space
> that could otherwise be used by actual value transfers.  Also, it costs
> money and pollutes the UTXO set (at least temporarily).  However, when
> testing whether proprietary third-party software, such as an exchange,
> supports payments to future segwit versions, sometimes the only
> convenient method is to actually pay the address for a future segwit
> version.  Additionally, my specific use case is just to write
> documentation
> about bech32m---but I worry that people will pay my example of a future
> segwit
> version address.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000674cfd05f3902d07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi David,<div><br></div><div>From practical experience, I =
think you&#39;ll find that most exchanges will not enable sends to future s=
egwit versions,</div><div>as from a risk perspective it&#39;s likely a mist=
ake to send funds there. That said, as long as we don&#39;t change</div><di=
v>the checksum again(!), updating to new versions should be fairly straight=
 forward. Every update will be a matter</div><div>of allowing a new version=
 and a new length instead of requiring library=C2=A0updates. Making sure th=
e most popular</div><div>open source libraries support it is probably the b=
est way to spend energy ensuring that future upgrades go smoothly.</div><di=
v><br></div><div>Best,</div><div>Greg</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 30, 2023 at 8:25 PM =
David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">Hi y&#39;all!,<br>
<br>
One of the benefits proposed for bech32 (and, by extension, bech32m) is<br>
that spender wallets shouldn&#39;t need to be upgraded to pay segwit output=
s<br>
defined in future soft forks.=C2=A0 For example, Bitcoin Core today can pay=
 a<br>
bech32m address for a segwit v2 output, even though no meaning has been<br>
assigned to output scripts matching a segwit v2 template.<br>
<br>
However, testing this behavior in production[1] can create an annoyance<br>
for developers of future soft forks.=C2=A0 They will need to deal with any<=
br>
existing outputs paid to the templates used in that proposed soft fork.<br>
See, for example, some discussion by developer 0xB10C about payments to<br>
segwit v1 addresses before activation of the taproot soft fork:<br>
<a href=3D"https://b10c.me/blog/007-spending-p2tr-pre-activation/" rel=3D"n=
oreferrer" target=3D"_blank">https://b10c.me/blog/007-spending-p2tr-pre-act=
ivation/</a><br>
<br>
I was wondering if it would be useful to have a canonical examples of<br>
future segwit addresses that are designed to be very unlikely to<br>
interfere with future soft forks but which would still reasonably<br>
exercise wallets supporting bech32m.=C2=A0 I think of this as the rough<br>
equivalent of the RFC2606 domain &quot;<a href=3D"http://example.com" rel=
=3D"noreferrer" target=3D"_blank">example.com</a>&quot; which has been rese=
rved<br>
for examples in documentation.<br>
<br>
Specifically, I&#39;m thinking of the following addresses, one each for<br>
mainnet and testnet:<br>
<br>
- HRP: bc for mainnet; tb for testent<br>
- Witness version: 16 (the last segwit version)<br>
- Witness program: 0x0000.=C2=A0 Two bytes is the minimum allowed<br>
=C2=A0 =C2=A0by BIP141, but it&#39;s far too small to make any sort of secu=
re <br>
commitment,<br>
=C2=A0 =C2=A0so I&#39;m hoping it won&#39;t conflict with any future use<br=
>
<br>
I think we should try to start with just one reserved address per<br>
network, but if that isn&#39;t enough, I think we could allow any two-byte<=
br>
witness program with witness version 16.<br>
<br>
Outputs paid to reserved addresses will still be anyone-can-spend, so<br>
there&#39;s no change required to Bitcoin Core or other software and those<=
br>
outputs can still be cleaned out of the UTXO set.=C2=A0 Additionally, if we=
<br>
ever *really* need that address space for a soft fork, it will be<br>
available.<br>
<br>
Are there any objections to this idea, or suggestions for a better way<br>
to go about it?<br>
<br>
Thanks!,<br>
<br>
-Dave<br>
<br>
[1] Testing in production should be avoided because it uses block space<br>
that could otherwise be used by actual value transfers.=C2=A0 Also, it cost=
s<br>
money and pollutes the UTXO set (at least temporarily).=C2=A0 However, when=
<br>
testing whether proprietary third-party software, such as an exchange,<br>
supports payments to future segwit versions, sometimes the only<br>
convenient method is to actually pay the address for a future segwit<br>
version.=C2=A0 Additionally, my specific use case is just to write <br>
documentation<br>
about bech32m---but I worry that people will pay my example of a future <br=
>
segwit<br>
version address.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000674cfd05f3902d07--