📅 Original date posted:2019-11-13
📝 Original message:I agree on all points. The address space already brings enough confusion to
users out there. As it stands, we can use script version and program length
for address validity. Sneaking an alternate checksum into the mix for
different length programs lets us lean on our parsing libraries and not
increase cognitive load for users.
-Clark
On Sun, Nov 10, 2019 at 7:02 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Seems good to me, though I'm curious if we have any (even vaguely)
> immediate need for non-32/20-byte Segwit outputs? It seems to me this
> can be resolved by just limiting the size of bech32 outputs and calling
> it a day - adding yet another address format has very significant
> ecosystem costs, and if we don't anticipate needing it for 5 years (if
> at all)...lets not jump to pay that cost.
>
> Matt
>
> On 11/10/19 9:51 PM, Pieter Wuille via bitcoin-dev wrote:
> > On Thu, Nov 7, 2019, 18:16 David A. Harding <dave at dtrt.org
> > <mailto:dave at dtrt.org>> wrote:
> >
> > On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via
> > bitcoin-dev wrote:
> > > In the current draft, witness v1 outputs of length other
> > > than 32 remain unencumbered, which means that for now such an
> > > insertion or erasure would result in an output that can be spent by
> > > anyone. If that is considered unacceptable, it could be prevented
> by
> > > for example outlawing v1 witness outputs of length 31 and 33.
> >
> > Either a consensus rule or a standardness rule[1] would require
> anyone
> > using a bech32 library supporting v1+ segwit to upgrade their
> library.
> > Otherwise, users of old libraries will still attempt to pay v1
> witness
> > outputs of length 31 or 33, causing their transactions to get
> rejected
> > by newer nodes or get stuck on older nodes. This is basically the
> > problem #15846[2] was meant to prevent.
> >
> > If we're going to need everyone to upgrade their bech32 libraries
> > anyway, I think it's probably best that the problem is fixed in the
> > bech32 algorithm rather than at the consensus/standardness layer.
> >
> >
> > Admittedly, this affecting development of consensus or standardness
> > rules would feel unnatural. In addition, it also has the potential
> > downside of breaking batched transactions in some settings (ask an
> > exchange for a withdrawal to a invalid/nonstandard version, which they
> > batch with other outputs that then get stuck because the transaction
> > does not go through).
> >
> > So, Ideally this is indeed solved entirely on the bech32/address
> > encoding side of things. I did not initially expect the discussion here
> > to go in that direction, as that could come with all problems that
> > rolling out a new address scheme in the first place has. However, there
> > may be a way to mostly avoid those problems for the time being, while
> > also not having any impact on consensus or standardness rules.
> >
> > I believe that most new witness programs we'd want to introduce anyway
> > will be 32 bytes in the future, if the option exists. It's enough for a
> > 256-bit hash (which has up to 128-bit collision security, and more than
> > 128 bits is hard to achieve in Bitcoin anyway), or for X coordinates
> > directly. Either of those, plus a small version number to indicate the
> > commitment structure should be enough to encode any spendability
> > condition we'd want with any achievable security level.
> >
> > With that observation, I propose the following. We amend BIP173 to be
> > restricted to witness programs of length 20 or 32 (but still support
> > versions other than 0). This seems like it may be sufficient for several
> > years, until version numbers run out. I believe that some wallet
> > implementations already restrict sending to known versions only, which
> > means effectively no change for them in addition to normal deployment.
> >
> > In the mean time we develop a variant of bech32 with better
> > insertion/erasure detecting properties, which will be used for witness
> > programs of length different from 20 or 32. If we make sure that there
> > are never two distinct valid checksum algorithms for the same output, I
> > don't believe there is any need for a new address scheme or a different
> > HRP. The latter is something I'd strongly try to avoid anyway, as it
> > would mean additional cognitive load on users because of another
> > visually distinct address style, plus more logistical overhead
> > (coordination and keeping track of 2 HRPs per chain).
> >
> > I believe improving bech32 itself is preferable over changing the way
> > segwit addresses use bech32, as that can be done without making
> > addresses even longer. Furthermore, the root of the issue is in bech32,
> > and it is simplest to fix things there. The easiest solution is to
> > simply change the constant 1 that is xor'ed into the checksum before
> > encoding it to a 30-bit number. This has the advantage that a single
> > checksum is never valid for both algoritgms simultaneously. Another
> > approach is to implicitly including the length into the checksummed data.
> >
> > What do people think?
> >
> > Cheers,
> >
> > --
> > Pieter
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191112/a92d5501/attachment-0001.html>;
Clark Moody [ARCHIVE] /
npub1nr…0hypj
2023-06-07 18:21:37
in reply to nevent1q…d0ch
Author Public Key
npub1nr02dq8fsgnt758nyp29waulhwwhj6j9gmlsqsknlwjem2hu8twqp0hypjPublished at
2023-06-07 18:21:37Event JSON
{
"id": "48499ceb991c4e46689cfa9167409f7c26b254a6940662f0bc7bc2e1a61baf4b",
"pubkey": "98dea680e98226bf50f3205457779fbb9d796a4546ff0042d3fba59daafc3adc",
"created_at": 1686162097,
"kind": 1,
"tags": [
[
"e",
"264ef70035b4322705af56ece91da287e8a2ce6ab384f8f06caee3ab0450477c",
"",
"root"
],
[
"e",
"f1145f5ee047b8bc69ba21138d7d3c73ae2e1b375e51f6da3ca0fd54ecd2c45d",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2019-11-13\n📝 Original message:I agree on all points. The address space already brings enough confusion to\nusers out there. As it stands, we can use script version and program length\nfor address validity. Sneaking an alternate checksum into the mix for\ndifferent length programs lets us lean on our parsing libraries and not\nincrease cognitive load for users.\n\n\n-Clark\n\n\nOn Sun, Nov 10, 2019 at 7:02 PM Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Seems good to me, though I'm curious if we have any (even vaguely)\n\u003e immediate need for non-32/20-byte Segwit outputs? It seems to me this\n\u003e can be resolved by just limiting the size of bech32 outputs and calling\n\u003e it a day - adding yet another address format has very significant\n\u003e ecosystem costs, and if we don't anticipate needing it for 5 years (if\n\u003e at all)...lets not jump to pay that cost.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 11/10/19 9:51 PM, Pieter Wuille via bitcoin-dev wrote:\n\u003e \u003e On Thu, Nov 7, 2019, 18:16 David A. Harding \u003cdave at dtrt.org\n\u003e \u003e \u003cmailto:dave at dtrt.org\u003e\u003e wrote:\n\u003e \u003e\n\u003e \u003e On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via\n\u003e \u003e bitcoin-dev wrote:\n\u003e \u003e \u003e In the current draft, witness v1 outputs of length other\n\u003e \u003e \u003e than 32 remain unencumbered, which means that for now such an\n\u003e \u003e \u003e insertion or erasure would result in an output that can be spent by\n\u003e \u003e \u003e anyone. If that is considered unacceptable, it could be prevented\n\u003e by\n\u003e \u003e \u003e for example outlawing v1 witness outputs of length 31 and 33.\n\u003e \u003e\n\u003e \u003e Either a consensus rule or a standardness rule[1] would require\n\u003e anyone\n\u003e \u003e using a bech32 library supporting v1+ segwit to upgrade their\n\u003e library.\n\u003e \u003e Otherwise, users of old libraries will still attempt to pay v1\n\u003e witness\n\u003e \u003e outputs of length 31 or 33, causing their transactions to get\n\u003e rejected\n\u003e \u003e by newer nodes or get stuck on older nodes. This is basically the\n\u003e \u003e problem #15846[2] was meant to prevent.\n\u003e \u003e\n\u003e \u003e If we're going to need everyone to upgrade their bech32 libraries\n\u003e \u003e anyway, I think it's probably best that the problem is fixed in the\n\u003e \u003e bech32 algorithm rather than at the consensus/standardness layer.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Admittedly, this affecting development of consensus or standardness\n\u003e \u003e rules would feel unnatural. In addition, it also has the potential\n\u003e \u003e downside of breaking batched transactions in some settings (ask an\n\u003e \u003e exchange for a withdrawal to a invalid/nonstandard version, which they\n\u003e \u003e batch with other outputs that then get stuck because the transaction\n\u003e \u003e does not go through).\n\u003e \u003e\n\u003e \u003e So, Ideally this is indeed solved entirely on the bech32/address\n\u003e \u003e encoding side of things. I did not initially expect the discussion here\n\u003e \u003e to go in that direction, as that could come with all problems that\n\u003e \u003e rolling out a new address scheme in the first place has. However, there\n\u003e \u003e may be a way to mostly avoid those problems for the time being, while\n\u003e \u003e also not having any impact on consensus or standardness rules.\n\u003e \u003e\n\u003e \u003e I believe that most new witness programs we'd want to introduce anyway\n\u003e \u003e will be 32 bytes in the future, if the option exists. It's enough for a\n\u003e \u003e 256-bit hash (which has up to 128-bit collision security, and more than\n\u003e \u003e 128 bits is hard to achieve in Bitcoin anyway), or for X coordinates\n\u003e \u003e directly. Either of those, plus a small version number to indicate the\n\u003e \u003e commitment structure should be enough to encode any spendability\n\u003e \u003e condition we'd want with any achievable security level.\n\u003e \u003e\n\u003e \u003e With that observation, I propose the following. We amend BIP173 to be\n\u003e \u003e restricted to witness programs of length 20 or 32 (but still support\n\u003e \u003e versions other than 0). This seems like it may be sufficient for several\n\u003e \u003e years, until version numbers run out. I believe that some wallet\n\u003e \u003e implementations already restrict sending to known versions only, which\n\u003e \u003e means effectively no change for them in addition to normal deployment.\n\u003e \u003e\n\u003e \u003e In the mean time we develop a variant of bech32 with better\n\u003e \u003e insertion/erasure detecting properties, which will be used for witness\n\u003e \u003e programs of length different from 20 or 32. If we make sure that there\n\u003e \u003e are never two distinct valid checksum algorithms for the same output, I\n\u003e \u003e don't believe there is any need for a new address scheme or a different\n\u003e \u003e HRP. The latter is something I'd strongly try to avoid anyway, as it\n\u003e \u003e would mean additional cognitive load on users because of another\n\u003e \u003e visually distinct address style, plus more logistical overhead\n\u003e \u003e (coordination and keeping track of 2 HRPs per chain).\n\u003e \u003e\n\u003e \u003e I believe improving bech32 itself is preferable over changing the way\n\u003e \u003e segwit addresses use bech32, as that can be done without making\n\u003e \u003e addresses even longer. Furthermore, the root of the issue is in bech32,\n\u003e \u003e and it is simplest to fix things there. The easiest solution is to\n\u003e \u003e simply change the constant 1 that is xor'ed into the checksum before\n\u003e \u003e encoding it to a 30-bit number. This has the advantage that a single\n\u003e \u003e checksum is never valid for both algoritgms simultaneously. Another\n\u003e \u003e approach is to implicitly including the length into the checksummed data.\n\u003e \u003e\n\u003e \u003e What do people think?\n\u003e \u003e\n\u003e \u003e Cheers,\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e Pieter\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191112/a92d5501/attachment-0001.html\u003e",
"sig": "8c284608bb67889c282e3a08c13f9e86ba75fe17818947aba7e0f962a2c9dd3ad662d7bc0915b985d5815ea9b298fb555671ebfec5f39c261b09412e64af8d16"
}