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
wrote:
> I hadn't thought of that... There is a solution, I think, but it m
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 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 mu
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
defi
