Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
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 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 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.**" > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
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 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.**" ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reference example bech32m address for future segwit versions
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: 0x. 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
[bitcoin-dev] Reference example bech32m address for future segwit versions
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: 0x. 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
