MIME-Version: 1.0
Date: Mon, 30 Jan 2023 14:02:51 -1000
From: "David A. Harding" <dave@dtrt.org>
To: bitcoin-dev@lists.linuxfoundation.org
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <e6da74da025355472a81e613fe7683b9@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: [bitcoin-dev] Reference example bech32m address for future segwit
	versions
Precedence: list

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.