Then you have a new problem. Hash1 must contain Hash2 and the
transaction, but Hash2 must contain Hash1 and the transaction. A
On Sat, Sep 17, 2016 at 3:14 PM, Rune K. Svendsen via bitcoin-dev
> 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?
> On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo <lf-li...@mattcorallo.com>
>> (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.
>> On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev"
>> <email@example.com> 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.
>>> bitcoin-dev mailing list
> bitcoin-dev mailing list
bitcoin-dev mailing list