<p>I was wondering if the following could be implemented on Bitcoin or other cryptos, or maybe in the future with additional opcodes.</p>
<p>Suppose Alice wants to send small transactions to others, without the lightning network (because the recipients might not support it). She puts 5 BTC in a special transaction with the following logic:</p>
<ol>
<li>After 1 month, the funds go back to Alice</li>
<li>Given a list of UTXOs (that Alice controls), if the top of the stack contains two different signatures of the same UTXO, the 5 BTC can go immediately to anyone (and will probably go to the miner).</li>
</ol>
<p>Now Alice meets Bob to buy some product and sends him a low-fee 0.01 BTC transaction that may take hours or even days to be added to the Blockchain, from one of the UTXOs in the last list. Bob publishes the transaction to all the miners, and they will confirm that the transaction is “insured” by 5 BTC. They may even offer a bounty to anyone that gives them another transaction from the same UTXO.</p>
<p>Bob can let Alice leave with the product, knowing that if she tries to double-spend the 0.1 BTC, she’s risking a loss of 5 BTC. Bob won’t earn anything if Alice decides to do so, but he can assume that she is rational.</p>
<p>One problem could be that Alice is a miner herself, and might try to mine the double-spending transaction herself (without publishing that second transaction to the other miners). We could solve this by saying that the 5 BTC transaction won’t go to the miner that mined it, but to whoever mines the later 100th block. Alice must be a really big miner if she can take the risk that she will also successfully mine that 100th block.</p>
<p>What do you think?</p>
<p>-- edit --</p>
<p>Since modern wallets don't reuse addresses, another solution for the &quot;collateral contract&quot; could be:</p>
<ol>
<li>After 1 month, the funds go back to Alice</li>
<li>Given a list of addresses (that Alice controls), if this contract is used against a redeem-script that has two different signatures made by a private key of a single address from the list - the 5 BTC can go immediately to anyone (and will probably go to the miner).</li>
</ol>
<p>It is Alice's responsibility not to publish two transactions that use the same address, or any two pieces of information signed by the same private key - or else, she might lose 5 BTC to some random miner.</p>
<p>For privacy and saving space, instead of the contract containing the entire list of addresses, it can contain a merkel-tree root, and when Alice pays Bob she could also publish the paths from each of the relevant addresses to the root.</p>
<p>The disadvantage is that Alice must be careful not to sign two messages (transactions) with the same private key (that its address is in the contract). Not even to fix anything in the payment to Bob, or to increase fees. She could, however, add some extra payment to Bob, and make it a zero-fee transaction, leaving Bob with the responsibility to attach it to another transaction with whatever fee that he chooses (For example, once a week Bob could consolidate many zero-fee transactions to a single address).</p>
<p>-- edit --</p>
<p>A typical use case could be &quot;mid range&quot; transactions. For large transactions, even a $10 fee is insignificant. For small transactions, lightning can be used. But for mid-range transactions, which lightning's inbound capacity problem might disallow, you wouldn't want to pay high fees and you also wouldn't want to wait hours for the transaction to complete.</p>

CC BY-SA 4.0
2021-06-28T13:38:49.227Z
In general I think there are definitely ways to move forward with zero confirmation transactions, especially when you compare to traditional payment fraud. But I don't understand 2 things. " two different signatures of the same UTXO"? and how does the 5btc insure the transaction? you mean like a way to release the 5btc to a miner, if a transaction comes up short because it was double spent?
noone392
CC BY-SA 4.0
2021-06-28T14:41:12.577Z
Yes, if Alice tries to double spend the 0.01 btc, it will have to publish two different transactions with the same UTXO (assuming she is not a miner herself). Any miner that sees these two signatures could “punish” Alice and claim the 5 BTC to himself.
Oren
CC BY-SA 4.0
2021-06-28T14:52:15.233Z
0.01 BTC is quite a lot for zero confirmations (~$340) and why pay a $2 fee for a $340 transaction to be added quickly to the blockchain, if the merchant is ok with receiving the payment in a delay of 48 hours. This could work for ATMs as well.
Oren
CC BY-SA 4.0
2021-06-28T16:11:06.677Z
I like where this is going, but I think there are a lot of different things you would have to figure out how to solve. 1) when the person puts up btc as collateral, how do you relate future transaction that are insured with that particular collateral?
noone392
CC BY-SA 4.0
2021-06-28T17:18:02.143Z
What's the "top of the stack"? Transactions are immutable and don't expire, so Alice will never be able to issue a second transaction spending the same UTXO, i.e. if fees stay high for a long time, Alice is forced to do a CPFP instead of an RBF transaction and just wastes more blockspace.
Murch
CC BY-SA 4.0
2021-06-28T18:52:02.420Z
@noone392 The future transactions must come from pre-known UTXOs or pre-known addresses, that are specified in the collateral-smart-contract. A merkle-tree could be used here.
Oren
CC BY-SA 4.0
2021-06-28T19:00:03.637Z
@Murch I'm not familiar enough with Bitcoin's technical terms. The idea is similar to lightning's HTLC - once the transaction is on the blockchain for all to see, it can reused with a redeem script that adds two params to the stack. In this case, the two params will be two signatures made by Alice.
Oren
CC BY-SA 4.0
2021-06-28T19:07:29.583Z
@Oren so lets say there is some sort of contract that has some btc as collateral. There are 1 or more public keys/addresses listed that can be used for 0 confirmation transactions. The user sends one of the insured transactions, referencing the collateral transaction id. Then lets say we find there isn't enough to cover that transaction. How would you unlock the collateral? I mean maybe it would be possible to rely on policy if you could prove to future nodes that at that time there was not enough funds...
noone392
CC BY-SA 4.0
2021-06-28T19:29:40.953Z
@noone392 What do you mean by "not enough funds"? Not enough fees for the transaction to be added to the Blockchain at all? Then in my case Alice is not allowed to publish another transaction from the same addresses (and same UTXOs). Yes, this is a disadvantage. On the other hand, she could add 20 cents to the transaction output (Bob's address) and tell Bob "I'm publishing this zero-fee transaction and added 20 cents to the price - it is now your responsibility to chain it to another transaction sometime in the following month".
Oren
CC BY-SA 4.0
2021-06-28T21:51:13.470Z
Ignoring technical implementation details, I'm not sure I see much benefit here. This idea might help stop intentional double-spends (low fee tx spends coins to victim, and then soon after a higher fee tx double spends those coins back to the attacker), but it does nothing to stop low fee txs simply not confirming (which could be seen as another form of zero-conf attack). Worse: it gives less options to a legitimate sender, as they can no longer RBF a stuck tx!
chytrik
CC BY-SA 4.0
2021-06-28T22:08:53.960Z
@chytrik The receiver (Bob) could always chain another transaction to himself, with increased fees, if he sees that the transaction takes a huge amount of time. It allows a trusted to "pay and go", leaving the fee optimization to be handled by the receiver. The receiver doesn't even have to run a lightning-node, knowing that the miners operate as "watchtowers", and will punish Alice if she tries to cheat. The receiver can recheck the transaction after a week, and in case it wasn't added, chain it to another transaction with high fee to himself.
Oren
CC BY-SA 4.0
2021-06-28T22:14:56.277Z
By chaining I mean that if we have a low-fee transaction A -> B1 (or even a zero-fee transaction), and the receiver wants it to be added to the blockchain, the receiver can create a high fee transaction to himself B1 -> B2, and the miners now have incentive to add both A -> B1 and B1 -> B2. This is without RBF. There must be a more official term for this practice but I haven't finished "Mastering Bitcoin" yet :)
Oren
CC BY-SA 4.0
2021-06-28T22:25:05.503Z
@Oren yes, it allows child-pays-for-parent (CPFP) to still work, but I think RBF is more preferable in most real-world payment flows, and this proposal would render it unusable. Consider: if I'm receiving money, I just want finality, I don't want to have to pay (potentially unknown) fees in order to receive the payment. ie, *"Here is a zero-fee tx, you can CPFP it to get a confirmation if you want"* is a terrible UX (and incurs even more fees than just a single tx with a competitive feerate!).
chytrik
CC BY-SA 4.0
2021-06-28T22:53:14.453Z
@chytrik I don't think merchants care about immediate finality that much, otherwise we wouldn't live in a credit-card world... If something could guarantee that the money will eventually pass for a low fee, even after a week or two, why not? I agree that RBF is better than CPFP because it takes less blockchain space overall. Another possibility is to have the collateral contract require 3 signatures by the same address instead of 2, and Alice will send Bob two transaction: one with a low fee, and one with high fee but where Bob gets less. For example, the second transaction could have
Oren
CC BY-SA 4.0
2021-06-28T22:55:31.153Z
@Oren its probably best to discuss this further in this site's chatroom, comments aren't well-suited to extended discussions https://chat.stackexchange.com/rooms/8089/mempool
chytrik
CC BY-SA 4.0
2021-06-28T22:56:59.203Z
additional $5 fee, where Alice gets $2.5 less to her change-address and Bob gets $2.5 less to his address. The second "RBF" transaction will be sent from Alice to Bob and not published to the miners. If Bob sees that the first transaction takes too long, he can use the second transaction. If Alice tries to cheat with a third transaction to herself, Bob will publish all 3 transactions to the miners and make Alice lose 5 BTC.
Oren
<transaction-fees><unconfirmed-transactions><zero-confirmation>
Idea for zero confirmations transactions using “proof of risk”
Oren
# Idea for zero confirmations transactions using “proof of risk”

(Asked by: username_0 on 2021-06-28)

I was wondering if the following could be implemented on Bitcoin or other cryptos, or maybe in the future with additional opcodes.

Suppose Alice wants to send small transactions to others, without the lightning network (because the recipients might not support it). She puts 5 BTC in a special transaction with the following logic:

1. After 1 month, the funds go back to Alice
2. Given a list of UTXOs (that Alice controls), if the top of the stack contains two different signatures of the same UTXO, the 5 BTC can go immediately to anyone (and will probably go to the miner).

Now Alice meets Bob to buy some product and sends him a low-fee 0.01 BTC transaction that may take hours or even days to be added to the Blockchain, from one of the UTXOs in the last list. Bob publishes the transaction to all the miners, and they will confirm that the transaction is “insured” by 5 BTC. They may even offer a bounty to anyone that gives them another transaction from the same UTXO.

Bob can let Alice leave with the product, knowing that if she tries to double-spend the 0.1 BTC, she’s risking a loss of 5 BTC. Bob won’t earn anything if Alice decides to do so, but he can assume that she is rational.

One problem could be that Alice is a miner herself, and might try to mine the double-spending transaction herself (without publishing that second transaction to the other miners). We could solve this by saying that the 5 BTC transaction won’t go to the miner that mined it, but to whoever mines the later 100th block. Alice must be a really big miner if she can take the risk that she will also successfully mine that 100th block.

What do you think?

-- edit --

Since modern wallets don't reuse addresses, another solution for the "collateral contract" could be:

1. After 1 month, the funds go back to Alice
2. Given a list of addresses (that Alice controls), if this contract is used against a redeem-script that has two different signatures made by a private key of a single address from the list - the 5 BTC can go immediately to anyone (and will probably go to the miner).

It is Alice's responsibility not to publish two transactions that use the same address, or any two pieces of information signed by the same private key - or else, she might lose 5 BTC to some random miner.

For privacy and saving space, instead of the contract containing the entire list of addresses, it can contain a merkel-tree root, and when Alice pays Bob she could also publish the paths from each of the relevant addresses to the root.

The disadvantage is that Alice must be careful not to sign two messages (transactions) with the same private key (that its address is in the contract). Not even to fix anything in the payment to Bob, or to increase fees. She could, however, add some extra payment to Bob, and make it a zero-fee transaction, leaving Bob with the responsibility to attach it to another transaction with whatever fee that he chooses (For example, once a week Bob could consolidate many zero-fee transactions to a single address).

-- edit --

A typical use case could be "mid range" transactions. For large transactions, even a $10 fee is insignificant. For small transactions, lightning can be used. But for mid-range transactions, which lightning's inbound capacity problem might disallow, you wouldn't want to pay high fees and you also wouldn't want to wait hours for the transaction to complete.

**Tags:** transaction-fees, unconfirmed-transactions, zero-confirmation

> **Comments:**
> **username_1**: In general I think there are definitely ways to move forward with zero confirmation transactions, especially when you compare to traditional payment fraud. But I don't understand 2 things. " two different signatures of the same UTXO"? and how does the 5btc insure the transaction? you mean like a way to release the 5btc to a miner, if a transaction comes up short because it was double spent?  
> **username_0**: Yes, if Alice tries to double spend the 0.01 btc, it will have to publish two different transactions with the same UTXO (assuming she is not a miner herself). Any miner that sees these two signatures could “punish” Alice and claim the 5 BTC to himself.  
> **username_0**: 0.01 BTC is quite a lot for zero confirmations (~$340) and why pay a $2 fee for a $340 transaction to be added quickly to the blockchain, if the merchant is ok with receiving the payment in a delay of 48 hours. This could work for ATMs as well.  
> **username_1**: I like where this is going, but I think there are a lot of different things you would have to figure out how to solve. 1) when the person puts up btc as collateral, how do you relate future transaction that are insured with that particular collateral?  
> **username_2**: What's the "top of the stack"? Transactions are immutable and don't expire, so Alice will never be able to issue a second transaction spending the same UTXO, i.e. if fees stay high for a long time, Alice is forced to do a CPFP instead of an RBF transaction and just wastes more blockspace.  
> **username_0**: @username_1 The future transactions must come from pre-known UTXOs or pre-known addresses, that are specified in the collateral-smart-contract. A merkle-tree could be used here.  
> **username_0**: @username_2 I'm not familiar enough with Bitcoin's technical terms. The idea is similar to lightning's HTLC - once the transaction is on the blockchain for all to see, it can reused with a redeem script that adds two params to the stack. In this case, the two params will be two signatures made by Alice.  
> **username_1**: @username_0 so lets say there is some sort of contract that has some btc as collateral. There are 1 or more public keys/addresses listed that can be used for 0 confirmation transactions. The user sends one of the insured transactions, referencing the collateral transaction id. Then lets say we find there isn't enough to cover that transaction. How would you unlock the collateral? I mean maybe it would be possible to rely on policy if you could prove to future nodes that at that time there was not enough funds...  
> **username_0**: @username_1 What do you mean by "not enough funds"? Not enough fees for the transaction to be added to the Blockchain at all? Then in my case Alice is not allowed to publish another transaction from the same addresses (and same UTXOs). Yes, this is a disadvantage. On the other hand, she could add 20 cents to the transaction output (Bob's address) and tell Bob "I'm publishing this zero-fee transaction and added 20 cents to the price - it is now your responsibility to chain it to another transaction sometime in the following month".  
> **username_3**: Ignoring technical implementation details, I'm not sure I see much benefit here. This idea might help stop intentional double-spends (low fee tx spends coins to victim, and then soon after a higher fee tx double spends those coins back to the attacker), but it does nothing to stop low fee txs simply not confirming (which could be seen as another form of zero-conf attack). Worse: it gives less options to a legitimate sender, as they can no longer RBF a stuck tx!  
> **username_0**: @username_3 The receiver (Bob) could always chain another transaction to himself, with increased fees, if he sees that the transaction takes a huge amount of time. It allows a trusted to "pay and go", leaving the fee optimization to be handled by the receiver. The receiver doesn't even have to run a lightning-node, knowing that the miners operate as "watchtowers", and will punish Alice if she tries to cheat. The receiver can recheck the transaction after a week, and in case it wasn't added, chain it to another transaction with high fee to himself.  
> **username_0**: By chaining I mean that if we have a low-fee transaction A -> B1 (or even a zero-fee transaction), and the receiver wants it to be added to the blockchain, the receiver can create a high fee transaction to himself B1 -> B2, and the miners now have incentive to add both A -> B1 and B1 -> B2. This is without RBF. There must be a more official term for this practice but I haven't finished "Mastering Bitcoin" yet :)  
> **username_3**: @username_0 yes, it allows child-pays-for-parent (CPFP) to still work, but I think RBF is more preferable in most real-world payment flows, and this proposal would render it unusable. Consider: if I'm receiving money, I just want finality, I don't want to have to pay (potentially unknown) fees in order to receive the payment. ie, *"Here is a zero-fee tx, you can CPFP it to get a confirmation if you want"* is a terrible UX (and incurs even more fees than just a single tx with a competitive feerate!).  
> **username_0**: @username_3 I don't think merchants care about immediate finality that much, otherwise we wouldn't live in a credit-card world... If something could guarantee that the money will eventually pass for a low fee, even after a week or two, why not? I agree that RBF is better than CPFP because it takes less blockchain space overall. Another possibility is to have the collateral contract require 3 signatures by the same address instead of 2, and Alice will send Bob two transaction: one with a low fee, and one with high fee but where Bob gets less. For example, the second transaction could have  
> **username_3**: @username_0 its probably best to discuss this further in this site's chatroom, comments aren't well-suited to extended discussions https://chat.stackexchange.com/rooms/8089/mempool  
> **username_0**: additional $5 fee, where Alice gets $2.5 less to her change-address and Bob gets $2.5 less to his address. The second "RBF" transaction will be sent from Alice to Bob and not published to the miners. If Bob sees that the first transaction takes too long, he can use the second transaction. If Alice tries to cheat with a third transaction to herself, Bob will publish all 3 transactions to the miners and make Alice lose 5 BTC.  

---

## 0 answers

