I'm wondering if the split is technically possible at all since the attacker is signing the transaction with his private key, and changing the amount transferred would effectively invalidate the signature. My guess is that blacklisting the "change" is a lot easier, but also easier to trick.
A double spending attack can only be detected over time, since we need a consistent view of the state the network is in. Blocks are used to synchronize and recreate consistency.
Topic: Suggestion: Introduce penalty for attempted double spend (Read 2571 times)
If the customer wishes to buy from the merchant without waiting for confirmation then he creates a transaction with a total value much larger than the value of the goods he wishes to buy from the merchant. Say the merchant's goods are worth 10BTC then the customer creates a transaction for 100BTC. 10BTC goes to the merchant's address and the remaining 90BTC "change" which would normally go to a new address generated by the customer actually goes to one of the customer's addresses listed as an input to the transaction. This signals to the world that the transaction is meant to be consummated immediately and that if the inputs are double spent in another "immediate transaction" elsewhere then the change is forfeit.
This would also come at an incremental expense of everyone else's anonymity: one more factor that helps obscure the transaction history just becomes clearer, it tells the world which part of every transaction was spent and which was change.
As a sophistication of jav's scheme, and with reference to https://bitcointalksearch.org/topic/m.50075 I propose the following.
If the customer wishes to buy from the merchant without waiting for confirmation then he creates a transaction with a total value much larger than the value of the goods he wishes to buy from the merchant. Say the merchant's goods are worth 10BTC then the customer creates a transaction for 100BTC. 10BTC goes to the merchant's address and the remaining 90BTC "change" which would normally go to a new address generated by the customer actually goes to one of the customer's addresses listed as an input to the transaction. This signals to the world that the transaction is meant to be consummated immediately and that if the inputs are double spent in another "immediate transaction" elsewhere then the change is forfeit.
The ratio of the amount "at stake" and the price of the goods can be mutually agreed beforehand by the merchant and customer. In the event of a double spend of the same inputs then the merchants are credited in order of decreasing ratio until the value of the inputs expires and any change is lost. Enabling the network to make financial sense of honouring the double spending of inputs in this fashion would be fraught with problems however. The idea does have merit though. Suppose the customer makes three immediate transactions using a total of 100BTC for 30BTC, 40BTC and 50BTC. The network could allow the payees of the first two transactions to be credited. The last merchant could probably be credited 30BTC out of the 50BTC owed although further analysis of strategies where the customer colludes with one or more merchants might decide it's more wise to burn the remaining 30BTC instead.
Gavin's worry about "honest" double spending mistakes by buggy clients can be ameliorated by agreeing that transactions which don't route the "change" back to one of the crediting addresses should never be accepted before being confirmed and therefore the "attempt" at double spending is doomed to fail, is therefore harmless and should go unpunished.
ByteCoin
If the customer wishes to buy from the merchant without waiting for confirmation then he creates a transaction with a total value much larger than the value of the goods he wishes to buy from the merchant. Say the merchant's goods are worth 10BTC then the customer creates a transaction for 100BTC. 10BTC goes to the merchant's address and the remaining 90BTC "change" which would normally go to a new address generated by the customer actually goes to one of the customer's addresses listed as an input to the transaction. This signals to the world that the transaction is meant to be consummated immediately and that if the inputs are double spent in another "immediate transaction" elsewhere then the change is forfeit.
The ratio of the amount "at stake" and the price of the goods can be mutually agreed beforehand by the merchant and customer. In the event of a double spend of the same inputs then the merchants are credited in order of decreasing ratio until the value of the inputs expires and any change is lost. Enabling the network to make financial sense of honouring the double spending of inputs in this fashion would be fraught with problems however. The idea does have merit though. Suppose the customer makes three immediate transactions using a total of 100BTC for 30BTC, 40BTC and 50BTC. The network could allow the payees of the first two transactions to be credited. The last merchant could probably be credited 30BTC out of the 50BTC owed although further analysis of strategies where the customer colludes with one or more merchants might decide it's more wise to burn the remaining 30BTC instead.
Gavin's worry about "honest" double spending mistakes by buggy clients can be ameliorated by agreeing that transactions which don't route the "change" back to one of the crediting addresses should never be accepted before being confirmed and therefore the "attempt" at double spending is doomed to fail, is therefore harmless and should go unpunished.
ByteCoin
So as a merchant, you would then receive a transaction, broadcast it and wait - let's say 5 seconds - whether you see any conflicting transactions. If not, you accept it. If the attacker still manages to pull of a well-timed double spend, you know at least, that when the next few confirmation blocks come around, the fraud will be punished.
So if the merchant sees an attempted double-spend within 5 seconds they accept the bitcoins but don't give the merchandise/service/whatever.
That sounds like a good idea to me. Maybe instead of 5 seconds it aught to be "before the transaction is fully confirmed."
The only drawback I see is buggy clients that might have bugs that cause 'honest' double-spending mistakes.
Oh, and merchants would have to explain to customers whey they kept their double-spent coins (although the merchants could easily produce both transaction IDs to show the world that it WAS a double-spend, so they shouldn't have to worry about their reputation being sullied).
You're still missing the product you sold and YOU are missing the point that people could abuse this to get coins back easily. This is a terrible idea.
Typically the product you sold wasn't worth much. If it was a brand new car, you probably had a few minutes to wait for block confirmation.
So, someone rips you off for a candy bar and a drink, or a pair of pants. That's something they could have already done a dozen other ways. The risk of loss is grossly smaller than the intangible cost of protection from the risk.
It's the same reason Wendy's restaurant doesn't make me sign the credit card slip for $8 worth of food. Sure, I could charge it back and say it wasn't me, and get back my $8. I could do this every day. Eventually though, my reputation would decline, I'd have to drive farther away for food, and my bank might close my credit card account. At some point, that's not worth while for me, and in Wendy's view nor a worthwhile reason to require signatures for every burger on a credit card.
No, he just want to say that it will be good if Bitcoin will reject double spend transactions before any confirmations.
You're still missing the product you sold and YOU are missing the point that people could abuse this to get coins back easily. This is a terrible idea.
So the problem is not to know about it, but to know which of they two transactions is the "second spend".
Bitcoin's answer is that the "second spend" is the one that doesn't make it into the block chain accepted by the majority. Read Satoshi's paper to see how this works.
Yes, I know, I read the paper. But that requires to wait for one or more confirmation blocks.
I'm more interested in how to quickly (in a matter of seconds) sort-of-confirm a transaction and manage the risk that is associated with that. That's why I wanted to discuss the possibility of such a penalty, to shift the risk further in favor of a merchant using such a fast-track payment system.
So as a merchant, you would then receive a transaction, broadcast it and wait - let's say 5 seconds - whether you see any conflicting transactions. If not, you accept it. If the attacker still manages to pull of a well-timed double spend, you know at least, that when the next few confirmation blocks come around, the fraud will be punished.
So the problem is not to know about it, but to know which of they two transactions is the "second spend".
Bitcoin's answer is that the "second spend" is the one that doesn't make it into the block chain accepted by the majority. Read Satoshi's paper to see how this works.
transactions are timestamped, aren't they?
No, they're not. And if they were, the timestamp would be provided by the attacker...
Ok, I see. Either way, a node can keep track on how much time passes between receiving the two transactions.
transactions are timestamped, aren't they?
No, they're not. And if they were, the timestamp would be provided by the attacker...
Splitting the payment 50:50? So if I pay someone some bitcoins, any time I want I can take 50% of them back by spending them again?
Destroying the coins? If someone has already spent the coins twice, the spender is the one laughing and only the recipients lose if the coins are destroyed.
Destroying the coins? If someone has already spent the coins twice, the spender is the one laughing and only the recipients lose if the coins are destroyed.
Thx for pointing that out. It should indeed only apply to transactions that a very close to each other in their timestamps (transactions are timestamped, aren't they?). If you attempt a double spend sometime 'later' it should just be rejected as invalid like it would now, without a penalty.
In any case I doubt there's a practical way to implement it. If the majority of the network knows about the double-spend attempt, it has rejected the second spend anyway. If the majority of the network doesn't know about the double-spend attempt, it can't do anything in response to it.
A double spend attack is usually a race. So the problem is not to know about it, but to know which of they two transactions is the "second spend".
There are lots of things wrong with this.
Splitting the payment 50:50? So if I pay someone some bitcoins, any time I want I can take 50% of them back by spending them again?
Destroying the coins? If someone has already spent the coins twice, the spender is the one laughing and only the recipients lose if the coins are destroyed.
In any case I doubt there's a practical way to implement it. If the majority of the network knows about the double-spend attempt, it has rejected the second spend anyway. If the majority of the network doesn't know about the double-spend attempt, it can't do anything in response to it.
Splitting the payment 50:50? So if I pay someone some bitcoins, any time I want I can take 50% of them back by spending them again?
Destroying the coins? If someone has already spent the coins twice, the spender is the one laughing and only the recipients lose if the coins are destroyed.
In any case I doubt there's a practical way to implement it. If the majority of the network knows about the double-spend attempt, it has rejected the second spend anyway. If the majority of the network doesn't know about the double-spend attempt, it can't do anything in response to it.
I have been doing some thinking about double spending and would like to hear your thoughts regarding the following idea: If I understand this correctly, a double spend attempt of a coin can only be done by the person who is in possession of it. So how about introducing penalties for doing so?
Right now when two conflicting transactions appear, the network eventually decides which one is valid and discards the other one. Instead, nodes could react in a special way to these attempts in one of the following ways:
1) Decide that the result of the two conflicting transactions is a 50:50 split of the double spend. So a merchant that has been tricked with a double spend would get a least half of the payment
2) or more radical, but maybe even better: simply destroy the bitcoins involved in the double spend completely
Obviously such a penalty would have to be agreed upon among nodes, so the same proof-of-work backing would be necessary to decide whether the network really saw an attempted double spend and destroy the bitcoins as an result.
Such a penalty would be most useful in settings where a merchant doesn't want to wait for one or several confirmation blocks, but instead just waits a few seconds for the transaction to spread through the network. This already prevents a number of attacks (see the snack machine thread: https://bitcointalksearch.org/topic/bitcoin-snack-machine-fast-transaction-problem-423 , especially this post by satoshi: https://bitcointalksearch.org/topic/m.3819). This penalty would not make attacks impossible - a merchant could still be cheated (with an elaborated attack) into providing a service without payment. But after the dust settles, the attacker would also be left without his double spent coins, greatly reducing the incentive for such an attack (or at least prevent repeated attacks).
Discuss! ;-)
Right now when two conflicting transactions appear, the network eventually decides which one is valid and discards the other one. Instead, nodes could react in a special way to these attempts in one of the following ways:
1) Decide that the result of the two conflicting transactions is a 50:50 split of the double spend. So a merchant that has been tricked with a double spend would get a least half of the payment
2) or more radical, but maybe even better: simply destroy the bitcoins involved in the double spend completely
Obviously such a penalty would have to be agreed upon among nodes, so the same proof-of-work backing would be necessary to decide whether the network really saw an attempted double spend and destroy the bitcoins as an result.
Such a penalty would be most useful in settings where a merchant doesn't want to wait for one or several confirmation blocks, but instead just waits a few seconds for the transaction to spread through the network. This already prevents a number of attacks (see the snack machine thread: https://bitcointalksearch.org/topic/bitcoin-snack-machine-fast-transaction-problem-423 , especially this post by satoshi: https://bitcointalksearch.org/topic/m.3819). This penalty would not make attacks impossible - a merchant could still be cheated (with an elaborated attack) into providing a service without payment. But after the dust settles, the attacker would also be left without his double spent coins, greatly reducing the incentive for such an attack (or at least prevent repeated attacks).
Discuss! ;-)
Jump to: