From: "Rune K. Svendsen" <runesvend@gmail•com>
To: Bitcoin <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY
Date: Sat, 17 Sep 2016 23:14:30 +0200 [thread overview]
Message-ID: <CAH2=CKzcNu-jWPr3AKhpTN_cyGVO67oPCMQx2hUrp=Ax_+wvCw@mail.gmail.com> (raw)
In-Reply-To: <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
[-- 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 --]
next prev parent reply other threads:[~2016-09-17 21:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-17 20:45 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 [this message]
2016-09-17 22:34 ` Nick ODell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH2=CKzcNu-jWPr3AKhpTN_cyGVO67oPCMQx2hUrp=Ax_+wvCw@mail.gmail.com' \
--to=runesvend@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox