Could it be possible to secure transactions against double-spending with other utxos?

Question

I'm new to Bitcoin Script, and I was wondering if it is possible to use funds from one utxo to "insure" that other utxo will not be double-spent (until the Lightning Network will save us all). Suppose I have 0.1 bitcoin in a utxo with pubkey pubKey1, and 10 bitcoins that I would send to an output script that would do something like:

1. If nLocktime is greater than X, verify that the stack contains a signature that matches some pubKeyHash2.

2. Otherwise, verify that the stack contains: <sig1> <payload1> <sig2> <payload2>, such that <payload1> != <payload2>, and <sig1> matches pubKey1 + <payload1>, and <sig2> matches pubKey1 + <payload2>.

i.e. until nLocktime passes, anyone who can find 2 different signatures of pubKey1 (of two different payloads) can win the 10 btc prize.

This will create a huge incentive for me to never sign two transactions (or any two payloads) with the private key of pubKey1. I could obviously take the risk, double-spend the 0.1 btc by publishing two transactions, and immediately try to claim the 10 btc prize myself, but once I published the two double-spending transactions, the miners would try to take all the 10 btc to themselves (and probably ignore any transaction that tries to take even a small portion of the prize without offering them 100% fee).

I don't see how the current op-codes allow this kind of script - I couldn't even find an "OP_CHECKLOCKTIME" (found only "OP_CHECKLOCKTIMEVERIFY"), and "OP_CHECKSIG" operates on data from the transaction and not on arbitrary payloads in the stack.

What do you think? Could this be implemented in the future? Could this be implemented in other cryptocurrencies? This could be useful when you don't want to wait for even a single block confirmation, for example in ATMs.

Answer 1

This is a creative idea, but I see one massive issue with it:

While it works to stop malicious double spends, it does so by making participating transactions 'One try or die'. Malicious double-spends are punished, but so are normal transaction failures.

Consider what would happen if a user used this technique to make a payment, but for whatever reason, they set the fee-rate too low. Now their transaction will not confirm for a long time, in fact it may never confirm if there is a sufficient volume of transactions paying higher fee-rates.

So now the poor user that owns any UTXO used in that transaction may never be able to attempt to spend it again, since doing so would put their other 'insurance' UTXO at risk of being claimed. This is a obviously a massive issue.

I think that it may also even create incentives for other nodes and miners to censor transaction propagation/confirmation, in hopes of seeing conflicting transactions published at a later date.

Any wallet implementing this would have to strictly enforce a policy of no address reuse. Otherwise, after successfully completing the 'insured against a double spend' transaction, the user's BTC stored at the insurance address will still be at risk! An attacker could send a small amount of BTC to the address that the original payment was sent from, and then a naive wallet implementation might use that new UTXO as input to a new payment. This would create a second valid signature, that could be used to claim the insurance UTXO.

---

Another issue: we should expect that services receiving payments would want to use this, but users would not (doing so would just cost them more tx fees, after all). Why is this an issue?

Consider what would happen if you arrived at a retailer that required such a transaction: you would have to create an 'insurance' UTXO that relates to some other UTXO you own. In order for that insurance UTXO to take effect, you will have to wait for a confirmation! So now we are still stuck waiting for a confirmation anyways.

I don't think building off of an unconfirmed insurance UTXO makes much sense, what is to stop someone from double spending the insurance UTXO? It is the same 'issue' we had in the first place. Creating insurance UTXOs ad infinitum is clearly not a good solution.

Alternatively, the user could prepare and get confirmation for insurance UTXOs in advance, but what is their incentive? To appease a retailer, at risk of losing the insurance UTXO if something goes wrong?

---

Perhaps I am missing something in my critique, so I'm interested to see if someone smarter can see ways it could work (or not). Neat idea, anyways.