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
Precedence: list

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