Bitcoin Forum
October 31, 2024, 08:10:32 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Quick and safe confirmation for merchants and in client-side code  (Read 1571 times)
WiW (OP)
Sr. Member
****
Offline Offline

Activity: 277
Merit: 250


"The public is stupid, hence the public will pay"


View Profile
May 28, 2013, 03:45:38 PM
 #1

I've seen too many software (and merchants using such software) waiting way too long for too many confirmations. Even 1 confirmation is too much for most transactions.

End users hate waiting for confirmations, especially if it's on their phones. As a user, why do I need to wait 3 confirmations when buying something for $10??
Programmers want to cover their asses when transactions need to be confirmed. What if the merchant thought he was paid $5000 but was double spended?

Network propagation

My understanding is that miners take the first transaction they receive, and henceforth throw out any conflicting transaction received after that one. What does this mean? If my transaction propagated throughout 90% of the network, a fraudster would need to either convince the miners to dump that transaction and take a new one (the double spend) or to transmit the new double spend transaction to the remaining 10% and hope they will find the next block.

In other words, the confirmation process is as follows:
- the buyer transmits the signed transaction (good for the smallest transactions)
- this transaction reaches most miners before any other conflicting transaction (good for most transactions)
- it enters a block (good for large transactions)
- buried deeper under more blocks (good for the most high-value transactions)
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1026



View Profile
May 28, 2013, 06:42:28 PM
 #2

My understanding is that miners take the first transaction they receive, and henceforth throw out any conflicting transaction received after that one. What does this mean? If my transaction propagated throughout 90% of the network, a fraudster would need to either convince the miners to dump that transaction and take a new one (the double spend) or to transmit the new double spend transaction to the remaining 10% and hope they will find the next block.

Virtually all of this is assumption.  No one can force miners to pick one transaction over another for inclusion in a block.  No one can force nodes to relay one transaction over another.

We think that your assumptions are mostly correct, for now.  But nothing is sure until it is confirmed.  Rely on good intentions at your own peril.  Different people in different situations will have different levels of acceptable peril.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
WiW (OP)
Sr. Member
****
Offline Offline

Activity: 277
Merit: 250


"The public is stupid, hence the public will pay"


View Profile
May 28, 2013, 10:22:09 PM
 #3

But nothing is sure until it is confirmed.
Neither are bitcoin "confirmations".

Rely on good intentions at your own peril.  Different people in different situations will have different levels of acceptable peril.
Everyone does a risk-cost analysis, and even 6 confirmations has risk. 3 confirmations as well and even no confirmations.

My point is to note that network propagation can and should be used as a parameter in software developers cost-risk analysis - because for the reasons stated above it offers less cost (time) per risk (chance of fraud).

We think that your assumptions are mostly correct, for now.
These things may of course change over time, but that doesn't mean the network (or in this case, just the client software) can't adapt.


EDIT: It's worth noting that such behaviour of miner's preference for transactions can be monitored easily and quickly. By simply trying to double spend on yourself (send a transaction to address A, wait for 95% network propagation, then send a transaction to address B), a general trend can be recognized.
kodo
Newbie
*
Offline Offline

Activity: 42
Merit: 0



View Profile
May 29, 2013, 01:59:53 AM
 #4

This is really cool, thanks!
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!