Bitcoin Forum
December 08, 2016, 12:35:16 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Suggestion: Introduce penalty for attempted double spend  (Read 2306 times)
jav
Sr. Member
****
Offline Offline

Activity: 249


View Profile
February 04, 2011, 03:23:25 PM
 #1

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: http://bitcointalk.org/index.php?topic=423.0 , especially this post by satoshi: http://bitcointalk.org/index.php?topic=423.msg3819#msg3819). 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! ;-)

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
1481157316
Hero Member
*
Offline Offline

Posts: 1481157316

View Profile Personal Message (Offline)

Ignore
1481157316
Reply with quote  #2

1481157316
Report to moderator
1481157316
Hero Member
*
Offline Offline

Posts: 1481157316

View Profile Personal Message (Offline)

Ignore
1481157316
Reply with quote  #2

1481157316
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 04, 2011, 03:37:45 PM
 #2

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.
jav
Sr. Member
****
Offline Offline

Activity: 249


View Profile
February 04, 2011, 04:06:41 PM
 #3

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.

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".

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
February 04, 2011, 04:31:11 PM
 #4

transactions are timestamped, aren't they?

No, they're not. And if they were, the timestamp would be provided by the attacker...

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jav
Sr. Member
****
Offline Offline

Activity: 249


View Profile
February 04, 2011, 04:42:33 PM
 #5

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.

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 04, 2011, 04:49:54 PM
 #6

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.
jav
Sr. Member
****
Offline Offline

Activity: 249


View Profile
February 04, 2011, 05:11:28 PM
 #7

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.

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
Garrett Burgwardt
Sr. Member
****
Offline Offline

Activity: 350



View Profile
February 04, 2011, 05:58:59 PM
 #8

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.
LZ
Staff
Legendary
*
Offline Offline

Activity: 1456


Satoshi everywhere!


View Profile WWW
February 04, 2011, 06:28:36 PM
 #9

No, he just want to say that it will be good if Bitcoin will reject double spend transactions before any confirmations.

"Never invest unless you can afford to lose your entire investment." © S3052
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 04, 2011, 06:29:16 PM
 #10

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.


Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 04, 2011, 06:41:23 PM
 #11

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).

How often do you get the chance to work on a potentially world-changing project?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
February 17, 2011, 07:07:56 AM
 #12

As a sophistication of jav's scheme, and with reference to http://bitcointalk.org/index.php?topic=3441.msg50075#msg50075 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    
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 17, 2011, 04:59:45 PM
 #13

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.


Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
February 17, 2011, 09:18:39 PM
 #14

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.

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!