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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
