1

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.

17
  • 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
    Jun 28 at 13:38
  • 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
    Jun 28 at 14:41
  • 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
    Jun 28 at 14:52
  • 1
    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
    Jun 28 at 17:18
  • 1
    @Oren its probably best to discuss this further in this site's chatroom, comments aren't well-suited to extended discussions chat.stackexchange.com/rooms/8089/mempool
    – chytrik
    Jun 28 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.