<p>This is a creative idea, but I see one massive issue with it: </p>

<p>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.</p>

<p>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. </p>

<p>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.</p>

<p>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. </p>

<p>Any wallet implementing this would have to <strong>strictly</strong> 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.  </p>

<hr>

<p>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?</p>

<p>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, <em>you will have to wait for a confirmation!</em> So now we are still stuck waiting for a confirmation anyways. </p>

<p>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 <em>ad infinitum</em> is clearly not a good solution. </p>

<p>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?</p>

<hr>

<p>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. </p>

CC BY-SA 4.0
2020-05-28T06:56:52.680Z
For the 'One try or die' problem, I've added the nLocktime check. Yes, if the 0.1 btc transaction failed (fees too low), you will not be able to use that UTXO until the nLocktime expires, but this shouldn't be a problem if you have lots of unconsolidated utxos. Just use another one.
Users will not like the higher fees, but services could demand this if the user doesn't want to wait for enough block confirmations (ATMs, gas stations, TOGO services, etc.).
Oren
CC BY-SA 4.0
2020-05-28T07:06:08.113Z
The user could create the insurance UTXO in advance, without knowing what it will be used for (which ATM...). Nothing prevents the user from double-spending the insurance UTXO, but to do so he has to publish two signatures of the 0.1btc UTXO, and others could use these two hashes to build a transaction that takes the 10btc for themselves.
Oren
CC BY-SA 4.0
2020-05-28T07:08:23.427Z
Basically, if I the user sends 0.1btc to an ATM, takes the cash, then tries his luck in double spending the 0.1btc (send it back to himself), he's now risking losing 10btc. If the original double-spending succeeds, the ATM lost 0.1btc worth of cash, but the user may lose 10btc to some clever node/miner.
Oren
CC BY-SA 4.0
2020-05-28T02:17:44.283Z
2020-05-28T02:17:44.283Z
chytrik
<p>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 <em>pubKey1</em>, and 10 bitcoins that I would send to an output script that would do something like:</p>

<ol>
<li><p>If nLocktime is greater than X, verify that the stack contains a signature that matches some <em>pubKeyHash2</em>.</p></li>
<li><p>Otherwise, verify that the stack contains: <code>&lt;sig1&gt;</code> <code>&lt;payload1&gt;</code> <code>&lt;sig2&gt;</code> <code>&lt;payload2&gt;</code>, such that <code>&lt;payload1&gt;</code> != <code>&lt;payload2&gt;</code>, and <code>&lt;sig1&gt;</code> matches <em>pubKey1</em> + <code>&lt;payload1&gt;</code>, and <code>&lt;sig2&gt;</code> matches <em>pubKey1</em> + <code>&lt;payload2&gt;</code>.</p></li>
</ol>

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

<p>This will create a huge incentive for me to never sign two transactions (or any two payloads) with the private key of <em>pubKey1</em>. 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).</p>

<p>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.</p>

<p>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.</p>

<script><doublespend>
Could it be possible to secure transactions against double-spending with other utxos?
Oren
# Could it be possible to secure transactions against double-spending with other utxos?

(Asked by: username_0 on 2020-05-28)

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.

**Tags:** script, doublespend


---

## 1 answers

### Answer by username_1 on 2020-05-28. Score: 0 | Accepted answer

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.

> **Comments:**
> **username_0**: For the 'One try or die' problem, I've added the nLocktime check. Yes, if the 0.1 btc transaction failed (fees too low), you will not be able to use that UTXO until the nLocktime expires, but this shouldn't be a problem if you have lots of unconsolidated utxos. Just use another one. Users will not like the higher fees, but services could demand this if the user doesn't want to wait for enough block confirmations (ATMs, gas stations, TOGO services, etc.).  
> **username_0**: The user could create the insurance UTXO in advance, without knowing what it will be used for (which ATM...). Nothing prevents the user from double-spending the insurance UTXO, but to do so he has to publish two signatures of the 0.1btc UTXO, and others could use these two hashes to build a transaction that takes the 10btc for themselves.  
> **username_0**: Basically, if I the user sends 0.1btc to an ATM, takes the cash, then tries his luck in double spending the 0.1btc (send it back to himself), he's now risking losing 10btc. If the original double-spending succeeds, the ATM lost 0.1btc worth of cash, but the user may lose 10btc to some clever node/miner.  

---

