* [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY
@ 2016-09-17 20:45 Rune K. Svendsen
2016-09-17 21:10 ` Luke Dashjr
[not found] ` <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
0 siblings, 2 replies; 4+ messages in thread
From: Rune K. Svendsen @ 2016-09-17 20:45 UTC (permalink / raw)
To: Bitcoin
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1603 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY
2016-09-17 20:45 [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY Rune K. Svendsen
@ 2016-09-17 21:10 ` Luke Dashjr
[not found] ` <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
1 sibling, 0 replies; 4+ messages in thread
From: Luke Dashjr @ 2016-09-17 21:10 UTC (permalink / raw)
To: bitcoin-dev, Rune K. Svendsen
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY
[not found] ` <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
@ 2016-09-17 21:14 ` Rune K. Svendsen
2016-09-17 22:34 ` Nick ODell
0 siblings, 1 reply; 4+ messages in thread
From: Rune K. Svendsen @ 2016-09-17 21:14 UTC (permalink / raw)
To: Bitcoin
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
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@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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
[-- Attachment #2: Type: text/html, Size: 3467 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY
2016-09-17 21:14 ` Rune K. Svendsen
@ 2016-09-17 22:34 ` Nick ODell
0 siblings, 0 replies; 4+ messages in thread
From: Nick ODell @ 2016-09-17 22:34 UTC (permalink / raw)
To: Rune K. Svendsen, Bitcoin Protocol Discussion
Then you have a new problem. Hash1 must contain Hash2 and the
transaction, but Hash2 must contain Hash1 and the transaction. A
circular dependency.
--Nick
On Sat, Sep 17, 2016 at 3:14 PM, Rune K. Svendsen via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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@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@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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-09-17 22:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-17 20:45 [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY Rune K. Svendsen
2016-09-17 21:10 ` Luke Dashjr
[not found] ` <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
2016-09-17 21:14 ` Rune K. Svendsen
2016-09-17 22:34 ` Nick ODell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox