📅 Original date posted:2016-09-17
📝 Original message:I hadn't thought of that... There is a solution, I think, but it makes the
operation less simple.
If a transaction contains at least two OP_TXHASHVERIFY-protected inputs,
signed without ANYONECANPAY, their signatures would cover the other
input's OP_TXHASHVERIFY hash, right?
/Rune
On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> (removing the list)
>
> Because the tx hash in your construction is not signed, someone wishing to
> maleate a transaction may do so by also updating the hash in the scriptSig.
>
> Matt
>
> On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> 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.
>>
>>
>>
>> /Rune
>>
>> ------------------------------
>>
>> 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/20160917/c90dd12a/attachment.html>;
Rune K. Svendsen [ARCHIVE] /
npub1vh…dq8h9
2023-06-07 17:53:21
in reply to nevent1q…nn4a
Author Public Key
npub1vhrurz53pdk9wyzr3dxhm05xx3ea4n8cxd8qw77nw79wxpwexq5scdq8h9Published at
2023-06-07 17:53:21Event JSON
{
"id": "5d047135c4e56ff63ecc6599d507690cf86dba24d40af137ce3452c4e863d43e",
"pubkey": "65c7c18a910b6c5710438b4d7dbe863473daccf8334e077bd3778ae305d93029",
"created_at": 1686160401,
"kind": 1,
"tags": [
[
"e",
"7f10f0f48b0d563b85776363e04d42d7024eadb5120e5cb44dfed28391cd316b",
"",
"root"
],
[
"e",
"83cda7ece127623bd95c8c918d5313fcaf29544f8839a909b6fffd00c853e05d",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-09-17\n📝 Original message:I hadn't thought of that... There is a solution, I think, but it makes the\noperation less simple.\n\nIf a transaction contains at least two OP_TXHASHVERIFY-protected inputs,\nsigned without ANYONECANPAY, their signatures would cover the other\ninput's OP_TXHASHVERIFY hash, right?\n\n\n /Rune\n\n\nOn Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e (removing the list)\n\u003e\n\u003e Because the tx hash in your construction is not signed, someone wishing to\n\u003e maleate a transaction may do so by also updating the hash in the scriptSig.\n\u003e\n\u003e Matt\n\u003e\n\u003e On September 17, 2016 4:45:17 PM EDT, \"Rune K. Svendsen via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I would really like to be able to create transactions that are immune to\n\u003e\u003e transaction ID malleability now, so I have been thinking of the simplest\n\u003e\u003e solution possible, in order to get a BIP through without too much trouble.\n\u003e\u003e\n\u003e\u003e An opcode we could call OP_TXHASHVERIFY could be introduced. It would be\n\u003e\u003e defined to work only if added to a scriptSig as the very first operation,\n\u003e\u003e and would abort if the hash of the transaction **with all OP_TXHASHVERIFY\n\u003e\u003e operations (including stack push) removed** does not match what has been\n\u003e\u003e pushed on the stack.\n\u003e\u003e\n\u003e\u003e So, in order to produce a transaction with one or more inputs protected\n\u003e\u003e against tx ID malleability, one would:\n\u003e\u003e\n\u003e\u003e 1. Calculate tx ID of the tx: TX_HASH\n\u003e\u003e 2. For each input you wish to protect, add \"0x32 $TX_HASH\n\u003e\u003e OP_TXHASHVERIFY\" to the beginning of the scriptSig\n\u003e\u003e\n\u003e\u003e When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question,\n\u003e\u003e and remove the \"0x32 \u003c32 bytes\u003e OP_TXHASHVERIFY\" sequence from the\n\u003e\u003e beginning of all scriptSigs (if present), and abort if the tx copy hash\n\u003e\u003e does not match the top stack item.\n\u003e\u003e\n\u003e\u003e This is a very simple solution that only adds 34 bytes per input, and\n\u003e\u003e when something better becomes available (eg. Segwit), we will stop using\n\u003e\u003e this. But in the meantime it's very valuable to be able to not worry about\n\u003e\u003e tx ID malleability.\n\u003e\u003e\n\u003e\u003e Please let me know what you think.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e /Rune\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160917/c90dd12a/attachment.html\u003e",
"sig": "f411661d2359213fdb8469bfb71ad8040ed5426012c6ec58db718005b9d150aefc540a4c836a8f4db0cfb84f246bd719adee530db09101da79e2141bcf4510d8"
}