* [bitcoin-dev] Reference example bech32m address for future segwit versions
@ 2023-01-31 0:02 David A. Harding
2023-01-31 14:30 ` Greg Sanders
0 siblings, 1 reply; 5+ messages in thread
From: David A. Harding @ 2023-01-31 0:02 UTC (permalink / raw)
To: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
2023-01-31 0:02 [bitcoin-dev] Reference example bech32m address for future segwit versions David A. Harding
@ 2023-01-31 14:30 ` Greg Sanders
2023-01-31 23:33 ` David A. Harding
0 siblings, 1 reply; 5+ messages in thread
From: Greg Sanders @ 2023-01-31 14:30 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4685 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
2023-01-31 14:30 ` Greg Sanders
@ 2023-01-31 23:33 ` David A. Harding
2023-02-01 0:37 ` Greg Sanders
2023-02-01 1:13 ` Anthony Towns
0 siblings, 2 replies; 5+ messages in thread
From: David A. Harding @ 2023-01-31 23:33 UTC (permalink / raw)
To: Greg Sanders; +Cc: Bitcoin Protocol Discussion
On 2023-01-31 04:30, Greg Sanders wrote:
> 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.
Hi Greg!,
I thought the best practice[1] was that wallets would spend to the
output indicated by any valid bech32m address. You seem to implying
that the best practice is the opposite: that wallets should only send to
outputs they know can be secured (i.e., which are not currently
anyone-can-spend). The more restrictive approach seems kind of sad to
me since any problem which can result in a user accidentally withdrawing
to a future segwit version could even more easily result in them
withdrawing to a witness program for which there is no solution (i.e.,
no key or script is known to spend).
If it is a best practice, then I think there's a benefit to being able
to test it even when other people's proprietary software is involved. A
wallet or service likely to follow that best practice may be more likely
to follow other best practices which cannot be as easily tested for.
But, if it's going to be tested, I want the testing to use the address
least likely to cause problems for protocol developers in the future.
Do you (and others on this list) have any reason to believe OP_16
OP_PUSH2 0000 would be a problematic script, or can you think of a
better script?
Thanks!,
-Dave
[1] BIP350, emphasis in original: "[...] we emphatically recommend [...]
ensuring that your implementation supports sending to v1 **and higher
versions.**"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
2023-01-31 23:33 ` David A. Harding
@ 2023-02-01 0:37 ` Greg Sanders
2023-02-01 1:13 ` Anthony Towns
1 sibling, 0 replies; 5+ messages in thread
From: Greg Sanders @ 2023-02-01 0:37 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]
David,
I'm merely speaking in a descriptive sense. I predict that most custodians
are reluctant to whitelist
a witness version they know is insecure.
I'm not sure what's best for not colliding with future versions, I'll let
other wiser folks weigh in.
Cheers,
Greg
On Tue, Jan 31, 2023 at 6:33 PM David A. Harding <dave@dtrt•org> wrote:
> On 2023-01-31 04:30, Greg Sanders wrote:
> > 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.
>
> Hi Greg!,
>
> I thought the best practice[1] was that wallets would spend to the
> output indicated by any valid bech32m address. You seem to implying
> that the best practice is the opposite: that wallets should only send to
> outputs they know can be secured (i.e., which are not currently
> anyone-can-spend). The more restrictive approach seems kind of sad to
> me since any problem which can result in a user accidentally withdrawing
> to a future segwit version could even more easily result in them
> withdrawing to a witness program for which there is no solution (i.e.,
> no key or script is known to spend).
>
> If it is a best practice, then I think there's a benefit to being able
> to test it even when other people's proprietary software is involved. A
> wallet or service likely to follow that best practice may be more likely
> to follow other best practices which cannot be as easily tested for.
> But, if it's going to be tested, I want the testing to use the address
> least likely to cause problems for protocol developers in the future.
> Do you (and others on this list) have any reason to believe OP_16
> OP_PUSH2 0000 would be a problematic script, or can you think of a
> better script?
>
> Thanks!,
>
> -Dave
>
> [1] BIP350, emphasis in original: "[...] we emphatically recommend [...]
> ensuring that your implementation supports sending to v1 **and higher
> versions.**"
>
[-- Attachment #2: Type: text/html, Size: 2573 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
2023-01-31 23:33 ` David A. Harding
2023-02-01 0:37 ` Greg Sanders
@ 2023-02-01 1:13 ` Anthony Towns
1 sibling, 0 replies; 5+ messages in thread
From: Anthony Towns @ 2023-02-01 1:13 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion; +Cc: Greg Sanders
On Tue, Jan 31, 2023 at 01:33:13PM -1000, David A. Harding via bitcoin-dev wrote:
> I thought the best practice[1] was that wallets would spend to the output
> indicated by any valid bech32m address.
I think it depends -- if the wallet in question is non-custodial and
might not be upgraded by the time witness v2 addresses are in use, then
being able to send to such addresses now makes sense.
If it's a custodial wallet where the nominal owner of the coins isn't
the one signing the tx, then I could see a pretty strong argument to not
allowing sending to such addresses until they're in use: (a) nobody will
be running the old software, since the custodian can just force everyone
to upgrade (eg, by deploying a new version of their own website), and (b)
signing a tx to send the bitcoins you're holding on Bob's behalf to an
address that will just get them stolen could be considered as negligence,
and you might end up forced to make Bob whole again.
So maybe the argument is:
* is this a custodial wallet? then what's the point of testing a
scenario that's likely years away -- the custodian will probably have
changed their system entirely by then anyway
* is it a non-custodial wallet? then it's worth testing -- you might
not be able to find compatible software in future to move your
private keys and have to dig up the current software and use it. will
it still work? but in that case, you ought to be able to capture the
tx it generates before broadcasting it, and don't need to publish it
on chain, and then it doesn't matter what script you use?
(For libraries and non-wallet software like block explorers or alternate
node implementations, it's a different matter)
Cheers,
aj
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-02-01 1:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-31 0:02 [bitcoin-dev] Reference example bech32m address for future segwit versions David A. Harding
2023-01-31 14:30 ` Greg Sanders
2023-01-31 23:33 ` David A. Harding
2023-02-01 0:37 ` Greg Sanders
2023-02-01 1:13 ` Anthony Towns
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox