Bitcoin Forum

This paper suggests to leave out input scripts in the tx hashes, so that a tx can not be duplicated with a nonce.
It seems a good idea, can we lobby for discuss this with the core developers?

http://eprint.iacr.org/2013/837.pdf

1) Is there a reason that the hashes of transactions currently depend on the input scripts? Wondering if the modification of section [3.2] has any drawbacks.  

>>We propose to compute those hashes over the transaction without its input scripts...

is a quickly presented essential prerequisite for this proposal.

2) I was immediately concerned with "simultaneous" as used in the introduction, which leads me to section 4 in the preconditions box, #6.  Is max_BB a time corresponding to the expected time required for the next block to be mined, or something else?

Given the recent interest in transaction malleability, I'd like to bump this old thread.

The suggestion in this paper (section 3.2) is to get rid completely of TXID in the Bitcoin protocol itself, and use only NTXID to reference a transaction (i.e. hash of the simplified transaction without the input scripts).

I'm trying to understand what are the problems with this simple suggestion.
What I can see is that we would lose some of the expressive power that Bitcoin scripts currently allow. For example, Suppose that Alice can redeem an unspent output whose script is of the form (if w1 then true, else if w2 then true, else false), meaning that there can be two different witnesses w1 and w2 (for example preimages of hashed values H(w1),H(w2)) that Alice can provide to redeem the coins. So when Alice broadcasts a transaction that redeems that unspent output, and her transaction is added to the blockchain, the blockchain NTXID hash wouldn't express whether Alice revealed w1 or w2. Therefore, if Bob and Carol have some contract that says "if Alice knows w1 then Bob gets 5 BTC from Carol, and if Alice knows w2 then Carol gets 5 BTC from Bob", then Bob and Carol wouldn't be able to rely on the NTXID in the blockchain in order to settle their contract (there would be plausible deniability that Alice broadcasted the other witness).

Is that the only kind of problem, or are the much more immediate/crucial problems that I failed to see? (other than making sure that generation transactions have a unique NTXID, which is mentioned in that paper). If this was discussed before, please just give me a link to the relevant info (I searched but didn't find much).


Also, a different question: would it be possible to eliminate all the mutations (like subtracting secp256k1_order from the S value of the ECDSA signature) in nonstandard scripts, or only in standard scripts? It seems to me that nonstandard scripts can always simulate NOOP operations, therefore malleability is inherent? If that's the case, maybe there should be some sort of an updated standard-v2 scripts that are still restricted more general than the current standard scripts, where these standard-v2 scripts cannot be mutated?

I'll reply to myself, because I discussed it with Bitcoin devs at #bitcoin-wizards (freenode IRC), so they shouldn't waste their time replying here too.

The issue with that simple suggestion indeed appears to be along the lines of what I suspected it to be. From the point of view of programmers who are responsible to deploying the protocol, it may still make sense to simplify and use only NTXID, i.e. to compromise and lose some of the expressive power that Bitcoin scripts allow. There could also be other options, such as attaching the signature (for the implicit message of the entire transaction) outside of the ScriptSig input-script.

Fortunately, we can indeed get rid of transaction malleability with a softfork that keeps the current scripts infrastructure in place. The thing that I missed about NOOP operations w.r.t. malleability is that the ScriptSig input-script (that doesn't get signed) doesn't really need to contain executable opcodes, only data. In other words, if the user can redeem an unspent output by providing a witness w that satisfies a circuit (script) phi(w)==true, then it's too general to require that w can be an executable circuit in itself. If I understand correctly, this sensible restriction is specified as new rule #4 at https://gist.github.com/sipa/8907691

So, a summary for the people without a 160 IQ... they are planning on implementing a change soon to prevent this?

Iddo, you are right that there are some scenarios in which we would lose some expressive power of contracts. However, we are not aware of any known contracts which would be affected this way.

On the other hand, our change has a significant advantage for the contracts over the proposed softfork, namely it allows to sign a transaction B which redeems A before A is signed. In this case we cannot compute TXID(A) (and therefore create the transaction B) because it depends on the signature on A and the sender of A is always able to create multiple valid signatures on it. Usage of NTXID would allow to create and sign a chain of transactions with input scripts, which will be determined later. We believe it substantially enhances the possibilities of designing contracts.

My suggestion:
Create a new opcode:
 PUSH_SIG <n>

Which pushes a signature on the stack, where the signature is taken as the n-th element from a vector that is appended to the transaction but it is not part of the transaction hash. So transaction inputs are left IN the transaction, but signatures are NOT.

That is a hard fork right?  If so, then using the (no inputs) signature hash instead of the full transaction hash for previous inputs seems like a better plan.