📅 Original date posted:2016-09-17
📝 Original message:On Saturday, September 17, 2016 8:45:17 PM Rune K. Svendsen via bitcoin-dev
wrote:
> I would really like to be able to create transactions that are immune to
> transaction ID malleability now, so I have been thinking of the simplest
> solution possible, in order to get a BIP through without too much trouble.
>
> An opcode we could call OP_TXHASHVERIFY could be introduced. It would be
> defined to work only if added to a scriptSig as the very first operation,
> and would abort if the hash of the transaction **with all OP_TXHASHVERIFY
> operations (including stack push) removed** does not match what has been
> pushed on the stack.
>
> So, in order to produce a transaction with one or more inputs protected
> against tx ID malleability, one would:
>
> 1. Calculate tx ID of the tx: TX_HASH
> 2. For each input you wish to protect, add "0x32 $TX_HASH OP_TXHASHVERIFY"
> to the beginning of the scriptSig
>
> When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question, and
> remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the beginning of
> all scriptSigs (if present), and abort if the tx copy hash does not match
> the top stack item.
>
> This is a very simple solution that only adds 34 bytes per input, and when
> something better becomes available (eg. Segwit), we will stop using this.
> But in the meantime it's very valuable to be able to not worry about tx ID
> malleability.
>
> Please let me know what you think.
First of all, this is likely to be more trouble than segwit to deploy (mainly
just because SegWit is already implemented and tested).
Secondly, it wouldn't fix your problem: anyone malleating the transaction
would simply update the hash before this opcode...
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:53:21
in reply to nevent1q…3z7k
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:53:21Event JSON
{
"id": "83cda7ece127623bd95c8c918d5313fcaf29544f8839a909b6fffd00c853e05d",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160401,
"kind": 1,
"tags": [
[
"e",
"7f10f0f48b0d563b85776363e04d42d7024eadb5120e5cb44dfed28391cd316b",
"",
"root"
],
[
"e",
"363f95361349e04512cd3b9d3c9e756d833a5b473eb8326fe5eca0cc484099ca",
"",
"reply"
],
[
"p",
"65c7c18a910b6c5710438b4d7dbe863473daccf8334e077bd3778ae305d93029"
]
],
"content": "📅 Original date posted:2016-09-17\n📝 Original message:On Saturday, September 17, 2016 8:45:17 PM Rune K. Svendsen via bitcoin-dev \nwrote:\n\u003e I would really like to be able to create transactions that are immune to\n\u003e transaction ID malleability now, so I have been thinking of the simplest\n\u003e solution possible, in order to get a BIP through without too much trouble.\n\u003e \n\u003e An opcode we could call OP_TXHASHVERIFY could be introduced. It would be\n\u003e defined to work only if added to a scriptSig as the very first operation,\n\u003e and would abort if the hash of the transaction **with all OP_TXHASHVERIFY\n\u003e operations (including stack push) removed** does not match what has been\n\u003e pushed on the stack.\n\u003e \n\u003e So, in order to produce a transaction with one or more inputs protected\n\u003e against tx ID malleability, one would:\n\u003e \n\u003e 1. Calculate tx ID of the tx: TX_HASH\n\u003e 2. For each input you wish to protect, add \"0x32 $TX_HASH OP_TXHASHVERIFY\"\n\u003e to the beginning of the scriptSig\n\u003e \n\u003e When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question, and\n\u003e remove the \"0x32 \u003c32 bytes\u003e OP_TXHASHVERIFY\" sequence from the beginning of\n\u003e all scriptSigs (if present), and abort if the tx copy hash does not match\n\u003e the top stack item.\n\u003e \n\u003e This is a very simple solution that only adds 34 bytes per input, and when\n\u003e something better becomes available (eg. Segwit), we will stop using this.\n\u003e But in the meantime it's very valuable to be able to not worry about tx ID\n\u003e malleability.\n\u003e \n\u003e Please let me know what you think.\n\nFirst of all, this is likely to be more trouble than segwit to deploy (mainly \njust because SegWit is already implemented and tested).\n\nSecondly, it wouldn't fix your problem: anyone malleating the transaction \nwould simply update the hash before this opcode...\n\nLuke",
"sig": "40c286d2ad875b37430827ce5971673ff639f716626627b379df47e3537eb9cf99131bbc15d3c6df8574c45e2bbc859f31fdbef68c23e618fd5cb38de90e60a0"
}