Make 0-conf double spend uneconomical by fixing the r value ahead of time

[dskloet]

I'm proposing a new kind of transaction that would make double spending 0-conf transactions uneconomical, and thus reducing the risk of double spending for the recipient.

Theory
Creating an ECDSA signature involves choosing a random number k. From this number, a value r is derived that is revealed as part of the signature. Quoting from Wikipedia:

As the standard notes, it is crucial to select different k for different signatures, otherwise the equation in step 6 can be solved for d_A, the private key

This is how a while back, coins were stolen from blockchain.info wallets because a bug in their random number generation caused the same k to be used, revealing the private key.

But we can use this to our advantage to discourage double spending. What if embedded in the unspent output is already determined what r value must be used to sign the transaction that spends those coins? That means that signing 2 different transactions that both spend the same output means revealing the private key and putting the coins up for grabs by anyone (effectively the next miner to mine a block).

This does not guarantee the recipient of a 0-conf transaction will receive their coins but it does make double spending uneconomical as the attacker would not get the coins back for themselves. This should reduce the risk of double spending for the recipient.

Implementation
We could introduce a new operation to the Bitcoin scripting language, similar to OP_CHECKSIG, but with one more input: the r value. When a transaction is created that spends such an output, the specified r must be used in the signature or the transaction is invalid.

One problem is that r must be determine by the recipient of the output while the output is created by the sender. I see 3 potential solutions for this

1. Use a P2SH address that has the r value embedded. The problem with this is that each output spent to this address would have to use the same r. So it is crucial that coins are spent to this address no more than once.
2. When accepting coins, specify the r together with the address that you want to receive the coins to. For example by using the payment protocol BIP 70.
3. When planning to do a 0-conf transaction, the sender should first move their coins into a new output that fixes the value of r in advance.

To me (2) seems the most promising.

Note: I'm no crypto expert so it would be great if someone could verify and confirm that this would work.