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:
- After 1 month, the funds go back to Alice
- 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:
- After 1 month, the funds go back to Alice
- 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.
