I think you misunderstood me—the transaction could still be rejected when you try to get it included in a subsequent block if it’s not valid. The hash of the transaction is just to prove that the transaction is the first spend from the given address; the transaction doesn’t/can’t get checked when the hash is included in the blockchain. Miners wouldn’t be able to do it for free—the protocol addition would be that you pay (from a quantum-safe address) to include a hash of a transaction into the blockchain. You publish the actual transaction some number of blocks later.
It really only makes sense as an emergency “get your coins into an address that’s quantum computer proof” sort of addition. Hopefully the problem is solved and everyone moves their funds before it becomes an emergency.
Suppose you publish hash HT1 of a transaction T1 spending address A, and then several blocks later when you publish T1 itself, someone hacks your pubkey and publishes transaction T2 also spending address A. Miners would hypothetically prefer T1 to T2, because there’s proof that T1 was made earlier.
In the case where someone had even earlier published hash HT0 of transaction T0 also spending address A, but never bothers to publish T0 (perhaps because their steal bot—which was watching for spends from A—crashed), well, they’re out of luck, because A no longer has funds as soon as T1 is included in the blockchain.
The pre-published hashes would be used only to break ties among transactions not yet included in any blocks.
Also, in this hypothetical scenario, the steal-bot from above means you shouldn’t trust funds that haven’t yet been moved into a quantum-computer-safe address; you wouldn’t know who all might have a old hash published with a bot just waiting to spend your funds as soon as you try to move them.
I see. I understand your proposal now at least. The downside is that it requires infinitely increasing storage for validating nodes, although you could get around that by having a hash commitment have a time limit associated with it.
Infinitely is a bit of an overstatement, especially if there’s a fee to store a hash. I agree it might still be prudent to have a time limit, though. Miners can forget the hash once it’s been referenced by a transaction.
The ability to pay to store a hash in the blockchain could be interesting for other reasons, like proving knowledge at a particular point in the past. There’s some hacky ways to do it now that involve sending tiny amounts of BTC to a number of addresses, or I suppose you could also hash your data as if it were a pubkey and send 1e-8 btc to that hash—but that’s destructive.
If you make it part of the validation process, then every validating node needs to keep the full list of seen hashes. Nodes would never be allowed to forget hashes that they haven’t seen make it onto the block chain, meaning that anyone could DoS bitcoin itself by registering endless streams of hashes. Perhaps this isn’t obvious, but note that fully validating nodes do not need to store the entire block chain history, currently, just the set of unspent transaction outputs, and there are proposals to eliminate the need for validators to store even that. If it’s just a gentleman’s agreement then it would be doable but wouldn’t really have any teeth against a motivated attacker.
You certainly don’t want to store data on the block chain by sending bitcoins to fake addresses, sacrificing coins, or other nonsense. That is inefficient and hurts the entire network, not just you. Please don’t do it.
There are already mechanisms to store hashes on the block chain which require no changes to the bitcoin protocol. You simply store the root hash of a Merkle list or prefix tree to the coinbase string, or an RETURN output of any transaction. An output can have zero value assigned to it, and if prefixed by the RETURN scripting opcode, is kept out of the unspent transaction output set entirely. I proposed one such structure for storing arbitrary data here:
Just stick the root hash in a coinbase string or the PUSHDATA of a RETURN output, then provide the path to the transaction containing it and the path through the structure as proof.
Perhaps this isn’t obvious, but note that fully validating nodes do not need to store the entire block chain history, currently, just the set of unspent transaction outputs, and there are proposals to eliminate the need for validators to store even that. If it’s just a gentleman’s agreement then it would be doable but wouldn’t really have any teeth against a motivated attacker.
That’s a good point. To make this work, it’d probably make the most sense to treat the pre-published hash the same as unspent outputs. It can’t be free to make these or you could indeed DoS bitcoin.
I did not know you could have zero value outputs. I’ll look into that. (And don’t worry, I wasn’t planning on destroying any coins!)
There’s nothing wrong with sacrificing coins (there are in fact, legitimate uses of that—see the Identity Protocol for example). The problem is creating outputs which you know to be unspendable, but can’t be proven by the deterministic algorithm the rest of the network uses (prefixing with RETURN).
I think you misunderstood me—the transaction could still be rejected when you try to get it included in a subsequent block if it’s not valid. The hash of the transaction is just to prove that the transaction is the first spend from the given address; the transaction doesn’t/can’t get checked when the hash is included in the blockchain. Miners wouldn’t be able to do it for free—the protocol addition would be that you pay (from a quantum-safe address) to include a hash of a transaction into the blockchain. You publish the actual transaction some number of blocks later.
It really only makes sense as an emergency “get your coins into an address that’s quantum computer proof” sort of addition. Hopefully the problem is solved and everyone moves their funds before it becomes an emergency.
How does the miner know that there is no other conflicting transaction whose hash appeared earlier?
They don’t.
Suppose you publish hash HT1 of a transaction T1 spending address A, and then several blocks later when you publish T1 itself, someone hacks your pubkey and publishes transaction T2 also spending address A. Miners would hypothetically prefer T1 to T2, because there’s proof that T1 was made earlier.
In the case where someone had even earlier published hash HT0 of transaction T0 also spending address A, but never bothers to publish T0 (perhaps because their steal bot—which was watching for spends from A—crashed), well, they’re out of luck, because A no longer has funds as soon as T1 is included in the blockchain.
The pre-published hashes would be used only to break ties among transactions not yet included in any blocks.
Also, in this hypothetical scenario, the steal-bot from above means you shouldn’t trust funds that haven’t yet been moved into a quantum-computer-safe address; you wouldn’t know who all might have a old hash published with a bot just waiting to spend your funds as soon as you try to move them.
I see. I understand your proposal now at least. The downside is that it requires infinitely increasing storage for validating nodes, although you could get around that by having a hash commitment have a time limit associated with it.
Infinitely is a bit of an overstatement, especially if there’s a fee to store a hash. I agree it might still be prudent to have a time limit, though. Miners can forget the hash once it’s been referenced by a transaction.
The ability to pay to store a hash in the blockchain could be interesting for other reasons, like proving knowledge at a particular point in the past. There’s some hacky ways to do it now that involve sending tiny amounts of BTC to a number of addresses, or I suppose you could also hash your data as if it were a pubkey and send 1e-8 btc to that hash—but that’s destructive.
If you make it part of the validation process, then every validating node needs to keep the full list of seen hashes. Nodes would never be allowed to forget hashes that they haven’t seen make it onto the block chain, meaning that anyone could DoS bitcoin itself by registering endless streams of hashes. Perhaps this isn’t obvious, but note that fully validating nodes do not need to store the entire block chain history, currently, just the set of unspent transaction outputs, and there are proposals to eliminate the need for validators to store even that. If it’s just a gentleman’s agreement then it would be doable but wouldn’t really have any teeth against a motivated attacker.
You certainly don’t want to store data on the block chain by sending bitcoins to fake addresses, sacrificing coins, or other nonsense. That is inefficient and hurts the entire network, not just you. Please don’t do it.
There are already mechanisms to store hashes on the block chain which require no changes to the bitcoin protocol. You simply store the root hash of a Merkle list or prefix tree to the coinbase string, or an RETURN output of any transaction. An output can have zero value assigned to it, and if prefixed by the RETURN scripting opcode, is kept out of the unspent transaction output set entirely. I proposed one such structure for storing arbitrary data here:
https://github.com/maaku/bips/blob/master/drafts/auth-trie.mediawiki
Just stick the root hash in a coinbase string or the PUSHDATA of a RETURN output, then provide the path to the transaction containing it and the path through the structure as proof.
That’s a good point. To make this work, it’d probably make the most sense to treat the pre-published hash the same as unspent outputs. It can’t be free to make these or you could indeed DoS bitcoin.
I did not know you could have zero value outputs. I’ll look into that. (And don’t worry, I wasn’t planning on destroying any coins!)
There’s nothing wrong with sacrificing coins (there are in fact, legitimate uses of that—see the Identity Protocol for example). The problem is creating outputs which you know to be unspendable, but can’t be proven by the deterministic algorithm the rest of the network uses (prefixing with RETURN).