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 blockchai
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