Bitcoin Forum
December 08, 2016, 06:02:02 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] 2  All
  Print  
Author Topic: Two Bitcoins at the Price of One  (Read 11878 times)
meanig
Hero Member
*****
Offline Offline

Activity: 527


View Profile
May 03, 2012, 03:04:19 PM
 #1

I came across this paper on Twitter

"Two Bitcoins at (sic) the Price of One? Double Spending attacks on Fast Payments in Bitcoin."

http://eprint.iacr.org/2012/248.pdf

Their strategy is to cheaply double spend a coin by using friendly hosts to spread the malicious transaction. They've shown it to work without being detected for approximately 10 seconds, enough time they believe for you to run away from Starbucks with your coffee.

Is this really a problem for fast transactions? I've used fast transactions (Bit-Pay, Coindl and Bitcointorrentz) and they already cautiously wait for around 10 seconds before confirming payment.
1481176922
Hero Member
*
Offline Offline

Posts: 1481176922

View Profile Personal Message (Offline)

Ignore
1481176922
Reply with quote  #2

1481176922
Report to moderator
1481176922
Hero Member
*
Offline Offline

Posts: 1481176922

View Profile Personal Message (Offline)

Ignore
1481176922
Reply with quote  #2

1481176922
Report to moderator
1481176922
Hero Member
*
Offline Offline

Posts: 1481176922

View Profile Personal Message (Offline)

Ignore
1481176922
Reply with quote  #2

1481176922
Report to moderator
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481176922
Hero Member
*
Offline Offline

Posts: 1481176922

View Profile Personal Message (Offline)

Ignore
1481176922
Reply with quote  #2

1481176922
Report to moderator
1481176922
Hero Member
*
Offline Offline

Posts: 1481176922

View Profile Personal Message (Offline)

Ignore
1481176922
Reply with quote  #2

1481176922
Report to moderator
1481176922
Hero Member
*
Offline Offline

Posts: 1481176922

View Profile Personal Message (Offline)

Ignore
1481176922
Reply with quote  #2

1481176922
Report to moderator
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
May 03, 2012, 03:24:52 PM
 #2

Any service that uses 0-conf is usually for cheap, low-dollar goods.  Businesses take the same risk when they sell goods that might potentially be bought with counterfeit dollars, a stolen credit card, or a bad check.  Bad funds received are just a part of doing business.

It's not likely that many people will go through the trouble of doing a 0-conf double spend, and those that do will need to cover their tracks well.  It can be days before a business knows that they received a bad check - 10 seconds means the criminal needs to get out of a physical location quickly!  For digital downloads and such, if enough people do it, then they'll simply wait a bit longer to give away the download link, or whatever it is they are waiting on.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 03, 2012, 03:31:49 PM
 #3

The 0-confirm double spend is something which has been known and studies for some time.

That being said a 10 sec window for real world face to face transactions is just asinine.

Counter experiment.
Go to starbucks, order, swipe your credit card.
START STOPWATCH
wait for coffee ... wait .... wait ... get coffee ... walk to door ... get in car ... drive out of line of site.
STOP STOP WATCH

I am 99% certain the elapsed time is going to be >10 sec.

There are methods to reduce (but likely never eliminate) the fraud risk of 0-confirm double spends.  That being said no payment system is without risk.

Cash:  counterfeit bills, theft, bank processing fees (which is why stores "generously" allow cashback)
Credit cards: stolen cards, friendly fraud,  never ending cut to VISA/MC.

The goal isn't to reduce fraud/theft/loss to 0%.  Doing that likely will drive away consumers.  The goal is to reduce the COST OF PROCESSING transactions which includes everything from employee training to fraud to bank fees to infrastructure/logistics.  
Blazr
Hero Member
*****
Offline Offline

Activity: 882



View Profile
May 03, 2012, 03:54:43 PM
 #4

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.

Busy ATM.
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
May 03, 2012, 05:02:16 PM
 #5

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.
And there you go!  An intermediary processor that takes the risk of double-spends in exchange for a fee.
Fuzzy
Hero Member
*****
Offline Offline

Activity: 560



View Profile
May 03, 2012, 08:30:57 PM
 #6

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.
And there you go!  An intermediary processor that takes the risk of double-spends in exchange for a fee.

Gotta love bitcoin  Cool
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 03, 2012, 10:59:36 PM
 #7

I'm still reading it but it was already a recommendation that the merchant not allow incoming network traffic (and disable UPnP) and to explicitly connect only to well-known nodes, preferably the mining pools.

I don't see anything in the report yet that indicates they tested using this configuration.

giszmo
Legendary
*
Offline Offline

Activity: 1568


¡ɥɔʇɐʍ ʇsnɾ &#7


View Profile WWW
May 03, 2012, 11:19:12 PM
 #8

The suggested double spend alert would be hard to do as it would open doors for DOS attacks.

I see only green addresses or to a degree well connected clients to do instant payment for now.

In the end I wouldn't worry too much about brick and mortar fraud as here the client has a face to loose within 10s. It would just be too risky to actually see my double spend attempt being identified as such even within 10s.

SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
May 03, 2012, 11:29:03 PM
 #9

The suggested double spend alert would be hard to do as it would open doors for DOS attacks.

I see only green addresses or to a degree well connected clients to do instant payment for now.

In the end I wouldn't worry too much about brick and mortar fraud as here the client has a face to loose within 10s. It would just be too risky to actually see my double spend attempt being identified as such even within 10s.
Exactly.  You may as well just run out of the establishment with the goods in hand.  It'd be the same result either way.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 03, 2012, 11:32:48 PM
 #10

Here were recommendations for merchants not considered by these researchers:

Quote
A merchant can lessen the risk of being defrauded in a race attack (on 0/unconfirmed) by:

- Using an explicit list of peers to connect to (with most of the known IP addresses of miners)
- Not allowing incoming connections (turn off uPnP)

this still leaves the merchant vulnerable to a 51% attack that all transactions below 6 confirmations are subject to but also to the Finney attack and another type of attack even where 2 confirmations is required

 - http://bitcoin.stackexchange.com/questions/2622#2625


Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 03, 2012, 11:35:22 PM
 #11

Here were recommendations for merchants not considered by these researchers:

Quote
A merchant can lessen the risk of being defrauded in a race attack (on 0/unconfirmed) by:

- Using an explicit list of peers to connect to (with most of the known IP addresses of miners)
- Not allowing incoming connections (turn off uPnP)

this still leaves the merchant vulnerable to a 51% attack that all transactions below 6 confirmations are subject to but also to the Finney attack and another type of attack even where 2 confirmations is required

 - http://bitcoin.stackexchange.com/questions/2622#2625

The method used in the research paper relied on the ability to know the IP address for the vendor and to directly connect to that vendor's node.  (which presumes that the vendor's firewall has UPnP enabled and/or the port for Bitcoin is accessible from the outside, such as when the network's firewall has port forwarding enabled and is routing that traffic to the host that the Bitcoin node runs from.)

And shock of all shocks, a race attack was successful in nearly every attempt.

REF
Hero Member
*****
Offline Offline

Activity: 526


View Profile
May 04, 2012, 02:42:40 AM
 #12

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.
so many great bitcoin start ups Iv never heard of. thanks for the link
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
May 04, 2012, 06:04:22 AM
 #13

I came across this paper on Twitter

I doubt you'll come across it in a peer-reviewed venue.

Is this really a problem for fast transactions?

No.  It's a problem for 0-confirm transactions, which has been obvious since the original Bitcoin paper.

"Fast" transactions can mean lots of things.  Sounds like the "researchers" who wrote this paper concocted the new term so they could flaunt the problems it has.  Pointing out the flaws in "I didn't wait for confirmations and got hacked" doesn't have quite the same ring to it.

The authors need to re-title their paper "here is yet another reason you shouldn't accept 0-confirmation payment for non-recourse transactions".

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
May 04, 2012, 06:10:00 AM
 #14

I came across this paper on Twitter

I doubt you'll come across it in a peer-reviewed venue.

Is this really a problem for fast transactions?

No.  It's a problem for 0-confirm transactions, which has been obvious since the original Bitcoin paper.

"Fast" transactions can mean lots of things.  Sounds like the "researchers" who wrote this paper concocted the new term so they could flaunt the problems it has.  Pointing out the flaws in "I didn't wait for confirmations and got hacked" doesn't have quite the same ring to it.

The authors need to re-title their paper "here is yet another reason you shouldn't accept 0-confirmation payment for non-recourse transactions".

I didn't read it all, but I'd suggest a title of "wait 30 seconds and you're in the clear"

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
May 04, 2012, 06:20:09 AM
 #15

I didn't read it all, but I'd suggest a title of "wait 30 seconds and you're in the clear"

Yes, waiting 29.9 seconds is terribly dangerous.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
May 04, 2012, 06:45:59 AM
 #16

The ten second window has been (intuitively) known among most of the old salts of this forum for two or three years.  This might be the first time that it was confirmed with any kind of experiment, or perhaps not.  Many methods of reducing exposure risk to a 0/conf race attack have been proposed, but none yet implimented simply because they don't have any current demand in the marketplace.  I've personally suggested more than one method, myself.  Furthermore, since there are so many different tactics at reducing said exposure, there is no practical way that an attacker could know in advance which method, if any, his mark may be employing.  The simplest method of all would be to simply delay the completion of the transaction for ten seconds.  How often have you seen an electronic check or a cc transaction take longer than that?

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
PawShaker
Full Member
***
Offline Offline

Activity: 140



View Profile
May 04, 2012, 06:50:22 AM
 #17

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful. The only problem I can see, is that overspending a coin N times may generate O(N^2) alerts. Hence generation and propagation of alerts must be a little bit smarter than authors of the paper envisioned. Before rising or propagating and alert, nodes must search their cache of alerts not only for an exact match, but also for any other alert that contains transactions with the same inputs.

Over all, it is a valuable food for thought.

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
May 04, 2012, 07:08:03 AM
 #18

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful.

I read the suggestions presented in the paper, and I've personally proposed both over a year ago.  Looks to me like someone has been lurking the forum and turned that into a school project.  The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate.  Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all.  So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet.  Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network.  If they match & are good, then a (successful) race attack is very unlikely.  If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved.

This method doesn't require that a special service or a distant node owned by the vendor exist.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
May 04, 2012, 07:41:06 AM
 #19

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful.

I read the suggestions presented in the paper, and I've personally proposed both over a year ago.  Looks to me like someone has been lurking the forum and turned that into a school project.  The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate.  Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all.  So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet.  Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network.  If they match & are good, then a (successful) race attack is very unlikely.  If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved.

This method doesn't require that a special service or a distant node owned by the vendor exist.

Seems obvious now but I'd completely overlooked it. I was thinking that you could wait and see if you hear another with the same inputs.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
PawShaker
Full Member
***
Offline Offline

Activity: 140



View Profile
May 04, 2012, 10:36:05 AM
 #20

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful.

I read the suggestions presented in the paper, and I've personally proposed both over a year ago.  Looks to me like someone has been lurking the forum and turned that into a school project.  The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate.  Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all.  So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet.  Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network.  If they match & are good, then a (successful) race attack is very unlikely.  If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved.

This method doesn't require that a special service or a distant node owned by the vendor exist.

Why not to take it a step further and simply do not propagate a transaction message if receiving address belongs to the vendor/owner of the node. This effectively turns all vendor’s peers into listening posts.

It is also hard to judge which node is the farthest. On internet distance can be quite tricky: ping time, trace hoops, BitCoin hoops, geographic distance. While it is hard to find farthest one, it is quite easy to locate peers which are close to each other, the difference in timing of messages from two close nodes will have low variation.

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
Pages: [1] 2  All
  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!