[bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps

As part of my recent work(1) on OpenTimestamps I've been putting some thought towards how to interpret the nTime fields in block headers, for the purpose of timestamping. I'd like to get some peer review on the following scheme I've come up with. # Motivation We want to use the Bitcoin

Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY

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

Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY

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

[bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY

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

Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY

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