1

One of the main reasons it's not safe to accept Bitcoin with 0 confirmations is due to the possibility of a double spend (where Mr. Scammer first sends 1 BTC to Alice and then creates an identical transaction in which he sends the same 1 BTC to Bob or to another address controlled by himself. If the network ends up including the second transaction in the blockchain only Bob (or Mr. Scammer himself) will be viewed as the rightful owner of the coins and Alice will be left with nothing).

However, being that it is impossible to hide a double spend forever, and everyone on the network will eventually discover that Mr. Scammer double spent his coins, why is it not possible to penalize the double spender in order to reduce the economical incentives of doing so in the first place? For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we "burn" (or destroy) the locked up BTC.

Wouldn't this significantly reduce the likelihood of a double spend occurring in the first place?

Improve this question
1
  • Some people have actually created gambling games where a double-spend is deliberately created, and then they wait to see who the lucky winner is depending on which transaction is validated and which is rejected.. Its juvenile, but deliberate and (vaguely) fun. Punishment is not necessary or appropriate for that.
    – abelenky
    Commented Jan 20, 2021 at 21:59

2 Answers 2

Reset to default
3

Given two transactions that spend the same input, there is no way to know which one 'came first' or is the 'rightful' transaction. Because of this, it is very difficult to enforce a 'no double spend' policy in this way. How can you guarantee that you have the transactions ordered correctly? What happens if some nodes on the network see the transactions arrive in a different order? Or what if a scammer sends a payment, but then claims that a transaction that pays those same coins back to themselves is actually the 'first' transaction? Etc.

This is why the blockchain exists in the first place: to give an explicit order to the transactions which occur on the network. Attempts to make 'zero-confirmation transactions' as reliable as confirmed transactions will never succeed, and if they could, then we could just do away with the whole blockchain! Perhaps there are ways to make double-spend attempts less likely to be successful, but ultimately if you are accepting zero-confirmation transactions, then you are incurring some risk of being double spent against.

For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we "burn" (or destroy) the locked up BTC.

You have more or less described an escrow system, in which a third party is employed to ensure that the transaction in question proceed smoothly. This is possible today, and indeed some markets provide access to this sort of protocol.

Keep in mind: if you are requiring that the user lock up some coins on-chain as collateral... that will require a bitcoin transaction to create this 'locked up UTXO'. To create that UTXO you will have to wait for an on-chain transaction to confirm... and at that point you might as well just wait for the payment to confirm in the first place! If you don't wait for it to confirm then you're just back at square one in regards to double-spend risk.

Attempting to automate this doesn't seem viable, for reasons similar to those I mentioned in the first paragraph above.

Improve this answer
5
  • My thinking is that the locked up funds would be sent to a custom type of address that is specifically designed to hold funds as collateral (it can be created by any individual just like a normal BTC address). The point is that no node/miner would accept a transaction from this address unless the address maintains at least an equivalent amount of collateral compared to amount being spent
    – S.O.S
    Commented Jan 19, 2021 at 4:43
  • It is true that it would require a bitcoin transaction to lock up the UTXO (funds) initially but my thinking is that if a user knows they will need to performa transaction with quick confirmation time in the future transaction they could lock up some of their funds in advance in this kind of address. When this is no longer needed they can move funds to a normal address. It is not like a centralized escrow system as everyone on the network can easily know when a user attempts to double spend.
    – S.O.S
    Commented Jan 19, 2021 at 4:45
  • Perhaps the only flaw I can see with this system is in the event that Mr. Scammer tries to send the same Bitcoin not to one but to several individuals and each one of those individuals believes his transaction is the only one that exists. In this case the only way to mitigate a "triple" or "quadruple" spend would be to lock up 300% - 400% of the amount being sent but since the attacker could conceivably trick an unlimited number of individuals we would need to lock up an infinite amount of funds to fully protect against a double (multi) spend..
    – S.O.S
    Commented Jan 19, 2021 at 4:48
  • To be clear, I'm not saying this strategy should replace PoW. I'm saying it can work in harmony with PoW with the added benefit of be able to accept 0 confirmation transaction
    – S.O.S
    Commented Jan 19, 2021 at 4:51
  • 2
    You're going to need to be more clear about the specific technical mechanism that decides to burn the funds if a double spend attempt was found to exist. I don't think it is possible to build such a thing with bitcoin script, without using some sort of trusted oracle.
    – chytrik
    Commented Jan 19, 2021 at 4:58
3

This wouldn't be effective.

Say I want to transfer value worth $100. How much is it reasonable to ask me to lock up and for how long? Maybe we could tolerate forcing me to lock up $200 for an hour.

But I don't just have to do a double-spend. I can do a quintuple-spend. I can get $500 worth of value for my $100 payment and then, even if I forfeit an extra $200, I'm still well ahead. And now you've made payments far more painful for everyone since they need to have three times as much as the amount they want to pay just sitting around.

Improve this answer
3
  • @_David Schwartz I did mention the issue of quintuple-spend as a comment to @chytrik answer. I don't see a way around this because even if we locked up 500% of the original transaction he could do a sextuple-spend (although I would be interested in knowing if it is significantly less likely to perform a sextuple-spend vs. a double spend) (continued)
    – S.O.S
    Commented Jan 20, 2021 at 17:27
  • However, I don't agree that this makes "payments painful for everyone since they need to have three times as much as the amount.." bec the idea is that this type of transaction would be tied to a specific type of address (say address starting with letter e). If a person knows in advance he will require instant confirmation (say buying something at the grocery or paying for gas in his car) he can transfer the required funds before hand. The network will apply these rules only to this kind of address. When quick confirmation is no longer required he can move the funds back to a normal address..
    – S.O.S
    Commented Jan 20, 2021 at 17:34
  • 1
    @S.O.S I don't follow the point then. Is it to allow a special type of very expensive transaction just to provide rapid confirmation for low-value payments that are a tiny fraction of a person's balance? If so, I would say that's just an awful match for the way the bitcoin blockchain works because it doesn't have balances. If you're proposing an entirely new and radically different system, why make it slow for any payments?
    – David Schwartz
    Commented Jan 20, 2021 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.