Bitcoin Forum
June 26, 2019, 11:21:29 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Will the new dust rule 0.8.2 make it trivial to double spend 0-conf?  (Read 1707 times)
apetersson
Hero Member
*****
Offline Offline

Activity: 667
Merit: 500



View Profile
May 06, 2013, 03:10:17 PM
 #1

lets assume the following scenario:

attacker connects to all miners directly.
constructs transaction with very healthy fee (0.01 btc) and 1 dust input + multiple fat inputs. outputs all back to him.
now he sends those directly to all miners. they may or may not relay it. but they will propably accept it to their memory pool to collect the fee on the next block.

now Mr. Attacker goes and pays at a merchant or digital download / vending machine.
-------
the merchants sees the 0-conf TX and thinks it is ok. but in fact the inputs are conflicting with the 1st transaction.
previously this fact would be known quite fast because the original transaction would have flooded the network already and all merchants would have rejected it instantly. but now, he has no way of knowing that the conflicting transaction is already sitting in all miners memorypools and on the next block he will have a bad surprise!
Bitcoin Poker 3.0
The Largest Bitcoin Poker Site
Bad Beat Jackpot Available
No Limit Texas Hold'em Cash Games And Tournaments
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1561548089
Hero Member
*
Offline Offline

Posts: 1561548089

View Profile Personal Message (Offline)

Ignore
1561548089
Reply with quote  #2

1561548089
Report to moderator
1561548089
Hero Member
*
Offline Offline

Posts: 1561548089

View Profile Personal Message (Offline)

Ignore
1561548089
Reply with quote  #2

1561548089
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2758
Merit: 2315



View Profile
May 06, 2013, 03:16:39 PM
 #2

No change from current behavior: We already have IsStandard and there are an infinitude of transactions which do not qualify as standard already.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1008


View Profile
May 06, 2013, 03:17:09 PM
 #3

The default code will not accept transactions into the memory pool if it would not relay them. So this is not an issue unless miners change how Bitcoin works en-masse, and yes obviously if all miners deliberately change their behaviour to make double-spending of unconfirmed transactions easier than people will stop relying on them and usage of Bitcoin will go down (along with its value, I'd imagine).
apetersson
Hero Member
*****
Offline Offline

Activity: 667
Merit: 500



View Profile
May 06, 2013, 04:05:04 PM
 #4

in my understanding the fee/dust setting will be configurable by users and miners.
so from the outside it is not obvious if a miner will treat a transaction as nonstandard or not.

how exactly is a merchant supposed to find out about a TX that is non-standard to SOME nodes that may be conflicting with his freshly-received transaction? - this question applies to other forms of nonstandard tx as well.

if the transaction is non-standard to ALL nodes the problem is not as severe, because the probability of a miner including it in the next block is within manageable limits.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1013


View Profile
May 06, 2013, 04:27:12 PM
 #5

Considered this scenario:

1) Get Bitcoin address for payment from double-spend vulnerable merchant

2) Broadcast payment, and a double spend, at the same time

3) ~50% of nodes get your payment, %50 get your double-spend, each thinking the other is the double spend

4) If merchant's node gets payment transaction, run with the goods; 50:50 chance you'll have wound up paying for them.


Blockchain.info's shared-send mixer guards against this because they have a huge network of nodes watching the network and can detect double-spends; the solution for your average merchant is to either not accept zero-conf (highly recommended) or get double-spend propagation so nodes propagate the first double-spend they see as well as the initial transaction implemented in the Bitcoin reference client.

tl;dr: Making dust outputs non-standard is just one of a huge variety of ways to pull off a zero-conf double-spend.

kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1001



View Profile
May 06, 2013, 07:57:47 PM
 #6

This is not a change.  Zero-confirmations means "not confirmed" today, just like it did yesterday.  Confirmations are what make transactions safe.  No confirmations, no safety.

Maybe this will finally wake people up.  People have been operating for too long under the delusion that their wishes for someone to confirm a transaction someday in the future were equivalent to having trillions of hashes already done in the past.

The sooner everyone accepts reality as it is, the better off we'll all be.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2758
Merit: 2315



View Profile
May 06, 2013, 11:37:21 PM
 #7

in my understanding the fee/dust setting will be configurable by users and miners.
Nonstandardness enforcement has never been consistent.

Quote
so from the outside it is not obvious if a miner will treat a transaction as nonstandard or not.
Never has been.

Quote
how exactly is a merchant supposed to find out about a TX that is non-standard to SOME nodes that may be conflicting with his freshly-received transaction? - this question applies to other forms of nonstandard tx as well.
By seeing it get confirmations.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1001


View Profile
June 28, 2013, 02:47:02 AM
 #8

We already have IsStandard and there are an infinitude of transactions which do not qualify as standard already.

I'ld like to see an entry added to the Double Spending article on the wiki for this category of attack.
 -  - http://en.bitcoin.it/wiki/Double_spending#Attack_vectors

I don't know that each specific tactic needs to be described, but something to the effect of how exploiting differences in the rules between versions (or from custom modifications) introduces an increased attack vector.   What would be a good name for this category?

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


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!