📅 Original date posted:2023-01-31
🗒️ Summary of this message: Sending funds to future segwit versions may be risky, as most exchanges may not enable it, according to practical experience.
📝 Original message: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.**"
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-07 23:18:52
in reply to nevent1q…hhn4
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:18:52Event JSON
{
"id": "243d4421e098d62f3f6a18a0e61f68fbd33587f1fa830fd2b0311cbeb0e7c6a1",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179932,
"kind": 1,
"tags": [
[
"e",
"559b3155c444a292ee6c672d01973cc38f03d09aa9e17c78e9184ede4c48f5da",
"",
"root"
],
[
"e",
"94fe5a593b48fe741dd0e4b253f2372d8a85aa998aa8cb0bf1686589aef59fdb",
"",
"reply"
],
[
"p",
"937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19"
]
],
"content": "📅 Original date posted:2023-01-31\n🗒️ Summary of this message: Sending funds to future segwit versions may be risky, as most exchanges may not enable it, according to practical experience.\n📝 Original message:On 2023-01-31 04:30, Greg Sanders wrote:\n\u003e Hi David,\n\u003e \n\u003e From practical experience, I think you'll find that most exchanges\n\u003e will not enable sends to future segwit versions,\n\u003e as from a risk perspective it's likely a mistake to send funds there.\n\nHi Greg!,\n\nI thought the best practice[1] was that wallets would spend to the \noutput indicated by any valid bech32m address. You seem to implying \nthat the best practice is the opposite: that wallets should only send to \noutputs they know can be secured (i.e., which are not currently \nanyone-can-spend). The more restrictive approach seems kind of sad to \nme since any problem which can result in a user accidentally withdrawing \nto a future segwit version could even more easily result in them \nwithdrawing to a witness program for which there is no solution (i.e., \nno key or script is known to spend).\n\nIf it is a best practice, then I think there's a benefit to being able \nto test it even when other people's proprietary software is involved. A \nwallet or service likely to follow that best practice may be more likely \nto follow other best practices which cannot be as easily tested for. \nBut, if it's going to be tested, I want the testing to use the address \nleast likely to cause problems for protocol developers in the future. \nDo you (and others on this list) have any reason to believe OP_16 \nOP_PUSH2 0000 would be a problematic script, or can you think of a \nbetter script?\n\nThanks!,\n\n-Dave\n\n[1] BIP350, emphasis in original: \"[...] we emphatically recommend [...] \nensuring that your implementation supports sending to v1 **and higher \nversions.**\"",
"sig": "8e9fdb50c423cf7806b0e3037b3deb07cbd6e31ca025f618b59fb3fca67b6b54a768a893861789f73b66c1d2d956837a4d1f3a938fc7ad7d07c3ea8ca3b7dcc8"
}