đź“… Original date posted:2014-02-12
📝 Original message:On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen <runesvend at gmail.com> wrote:
> Instead of trying to remove the possibility of transaction
> malleability, would it make sense to define a new, "canonical
> transaction hash/ID" (cTxID), which would be a hash of the part of the
> transaction data which we know is not malleable, and have clients use
> this cTxID internally, thus making the traditional transaction hash
> irrelevant for a client to function correctly?
This is fine and good. But it only scratches the surface of the
problems created by malleability, especially for fancier transaction
protocols.
Mutation allows you to invalidate a chain of unconfirmed transaction
by mutating the parent. This breaks any protocol which depends on
creating a precomputed nlocked time refund transaction.
So a canonical ID can be used to prevent some buggy behavior it
doesn't actually fix the problem. Fortunately the non-fixed parts
aren't too critical today.
On Wed, Feb 12, 2014 at 8:22 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> I think the solution is simply to encourage Bitcoin software developers to
> design their software to use this static ID, instead of the full transaction
> hash. If MtGox had talked those IDs instead of the TX ID, their software
> would've correctly identified the mutated transactions and there would be
> no problem.
This is incorrect. MtGox was automatically issuing replacement
transactions resulting in double payments.
When you attempt to replace/reissue/cancel a transaction you __MUST__
double-spend the original transaction. If the original transaction has
not been conflicted then it is possible someone will pull the original
transaction out of a hat and both your replacement and the original
will be confirmed. It is not safe at any time to look to see if the
original has been confirmed yet, and if not reissue— not because
mutation may mean you're looking in the wrong place— but because the
state of the world could change nano-seconds after you looked.
If you do double-spend the original then there is no chance that both
will go through, you'll have atomic exclusion and only one transaction
or the other will be confirmed.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:13:31
in reply to nevent1q…7mfk
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:13:31Event JSON
{
"id": "b4b623b257d17b3932ca0fe0850205b8d5e5733832431ce9b2a14c7f98c02cf6",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686150811,
"kind": 1,
"tags": [
[
"e",
"76969a008b621e54c247029127aebdfbea1794fb79dd58e07b32a76157512d29",
"",
"root"
],
[
"e",
"8e1da77ad92146e6aed38a9b36e24a0203999f248734e023bfa8575c4ccb020e",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-02-12\n📝 Original message:On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen \u003crunesvend at gmail.com\u003e wrote:\n\u003e Instead of trying to remove the possibility of transaction\n\u003e malleability, would it make sense to define a new, \"canonical\n\u003e transaction hash/ID\" (cTxID), which would be a hash of the part of the\n\u003e transaction data which we know is not malleable, and have clients use\n\u003e this cTxID internally, thus making the traditional transaction hash\n\u003e irrelevant for a client to function correctly?\n\nThis is fine and good. But it only scratches the surface of the\nproblems created by malleability, especially for fancier transaction\nprotocols.\n\nMutation allows you to invalidate a chain of unconfirmed transaction\nby mutating the parent. This breaks any protocol which depends on\ncreating a precomputed nlocked time refund transaction.\n\nSo a canonical ID can be used to prevent some buggy behavior it\ndoesn't actually fix the problem. Fortunately the non-fixed parts\naren't too critical today.\n\nOn Wed, Feb 12, 2014 at 8:22 AM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e I think the solution is simply to encourage Bitcoin software developers to\n\u003e design their software to use this static ID, instead of the full transaction\n\u003e hash. If MtGox had talked those IDs instead of the TX ID, their software\n\u003e would've correctly identified the mutated transactions and there would be\n\u003e no problem.\n\nThis is incorrect. MtGox was automatically issuing replacement\ntransactions resulting in double payments.\n\nWhen you attempt to replace/reissue/cancel a transaction you __MUST__\ndouble-spend the original transaction. If the original transaction has\nnot been conflicted then it is possible someone will pull the original\ntransaction out of a hat and both your replacement and the original\nwill be confirmed. It is not safe at any time to look to see if the\noriginal has been confirmed yet, and if not reissue— not because\nmutation may mean you're looking in the wrong place— but because the\nstate of the world could change nano-seconds after you looked.\n\nIf you do double-spend the original then there is no chance that both\nwill go through, you'll have atomic exclusion and only one transaction\nor the other will be confirmed.",
"sig": "68b3b87b178a35568e785ff4b0032053c38a4e2a765a87e02f85d8e346d0288f4bb7f4c96a18a67bc9b1ae6b2eb242edbbf55658d968605e781ea173ce6ebfbd"
}