📅 Original date posted:2015-04-24
📝 Original message:On Fri, Apr 24, 2015 at 7:58 PM, William Swanson <swansontec at gmail.com> wrote:
> On Thu, Apr 16, 2015 at 9:12 AM, s7r <s7r at sky-ip.org> wrote:
>> Thanks for your reply. I agree. Allen has a good point in the previous
>> email too, so the suggestion might not fix anything and complicate things.
>
> The BIP 62 approach to malleability isn't the only option. Another
> approach is to sign the transaction in such a way that the input
> txid's are allowed to change without invalidating the signatures. That
> way, if malleability happens, you just adjust you transaction to match
> and re-broadcast. That proposal is here:
This is not a free choice. There are several concerns, from mild to
severe, that arise when you do not sign enough.
In particular not covering the ID allows for transaction replay which
can result in monetary losses far more severe than any possible
mishandling of malleability could result in. Byzantine attackers can
costlessly replay your old transactions any time anyone reuses an
address, even accidentally (which cannot be easily prevented since
they can race).
Other fun effects also show up like being able to backwards compute
signatures to result in a kind of limited covenant- coins which can
only be spent a particular way which has some implications for
fungibility. (See here for a discussion in general of covenants:
https://bitcointalk.org/index.php?topic=278122.0)
There are no free lunches; the proposal linked to there is itself a
game of wack-a-mole with assorted masking flags; many of which we have
no notion of if they're useful for any particular application(s); and
it doesn't provide tools to address the replay issue; and in order to
'improve' malleability via that mechanism you must always mask out the
inputs completely; meaning you'd always be exposed to replay and not
just in specialized 'contract' applications where "there won't be
address reuse" could be a strong assumption enforced by the
application.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:32:32
in reply to nevent1q…ks38
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:32:32Event JSON
{
"id": "783f74b0b397f828a211d769fe5c6093c9b399ddf68f87edebb0329b57bad60d",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151952,
"kind": 1,
"tags": [
[
"e",
"8b8a2347eb8a1165154b18f1aa6b1f8a0b99712f1e1f9461e574d86e0b7c9986",
"",
"root"
],
[
"e",
"4555a6f492eb0b4b315736cd71ea5f2f5199965984dd02fcaf94e24c1d01bc1f",
"",
"reply"
],
[
"p",
"a178a4d8dc03df766d640bbff9f4a535decb16c595ad471cabee59e7f78f439d"
]
],
"content": "📅 Original date posted:2015-04-24\n📝 Original message:On Fri, Apr 24, 2015 at 7:58 PM, William Swanson \u003cswansontec at gmail.com\u003e wrote:\n\u003e On Thu, Apr 16, 2015 at 9:12 AM, s7r \u003cs7r at sky-ip.org\u003e wrote:\n\u003e\u003e Thanks for your reply. I agree. Allen has a good point in the previous\n\u003e\u003e email too, so the suggestion might not fix anything and complicate things.\n\u003e\n\u003e The BIP 62 approach to malleability isn't the only option. Another\n\u003e approach is to sign the transaction in such a way that the input\n\u003e txid's are allowed to change without invalidating the signatures. That\n\u003e way, if malleability happens, you just adjust you transaction to match\n\u003e and re-broadcast. That proposal is here:\n\nThis is not a free choice. There are several concerns, from mild to\nsevere, that arise when you do not sign enough.\n\nIn particular not covering the ID allows for transaction replay which\ncan result in monetary losses far more severe than any possible\nmishandling of malleability could result in. Byzantine attackers can\ncostlessly replay your old transactions any time anyone reuses an\naddress, even accidentally (which cannot be easily prevented since\nthey can race).\n\nOther fun effects also show up like being able to backwards compute\nsignatures to result in a kind of limited covenant- coins which can\nonly be spent a particular way which has some implications for\nfungibility. (See here for a discussion in general of covenants:\nhttps://bitcointalk.org/index.php?topic=278122.0)\n\nThere are no free lunches; the proposal linked to there is itself a\ngame of wack-a-mole with assorted masking flags; many of which we have\nno notion of if they're useful for any particular application(s); and\nit doesn't provide tools to address the replay issue; and in order to\n'improve' malleability via that mechanism you must always mask out the\ninputs completely; meaning you'd always be exposed to replay and not\njust in specialized 'contract' applications where \"there won't be\naddress reuse\" could be a strong assumption enforced by the\napplication.",
"sig": "dd5bfe9097a17fdd0ff6248dc18836602831f65d675e432490477d3e6b72ad59e8a6a8d56a6169aa2d0b5860ef0b41eacf13680c449c2f942e4a259f55e38192"
}