Bitcoin Forum
December 06, 2016, 06:10:33 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Using time as a constraint to reduce the merchant wait for confirmations  (Read 817 times)
Tulkas
Sr. Member
****
Offline Offline

Activity: 350


Founder, BTCJAM


View Profile WWW
June 30, 2011, 02:34:50 PM
 #1

Hello,

Is there a way to use time constraints along with number of confirmations to calculate the probability of a transaction being legit ?

Just wait for 6, 7, 10, confirmations doesn't seems to make sense (mathematically at least), since given enough time any number of computing power will produce the confirmations needed (of course i can use 120 confirmations but no customer want to wait that long), but as I'm kind of new to bitcoins maybe i`m missing something?

Maybe will be a incentive to merchants if there is a more accurate approach on transaction confirmation.

Imagine if we calculate the time an attacker that "owns"  2/3  (btcguild + deepbit) of the hashing network will take to produce the false confirmations and set a time upper bound based on that number.

I know block finding involves luck, so 1 confirmation may never be viable, but the probability of finding, say, 3 confirmations given the attacker maximum strength seems to be calculable.

Regards,
Celso.

BTCJAM - Peer to Peer Bitcoin Lending
https://btcjam.com
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481047833
Hero Member
*
Offline Offline

Posts: 1481047833

View Profile Personal Message (Offline)

Ignore
1481047833
Reply with quote  #2

1481047833
Report to moderator
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
June 30, 2011, 02:36:45 PM
 #2

When you use the RPC API, you can choose the number of confirmations that you require yourself, depending on the perceived risk. 6 is just a convenient default.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Tulkas
Sr. Member
****
Offline Offline

Activity: 350


Founder, BTCJAM


View Profile WWW
June 30, 2011, 06:57:28 PM
 #3



Yes, I'm using 6 for the moment, but, as a newbie, I vividly remember the "fear" of my first transfer not appearing at my mtgox account.

I think the average Joe is already scared enough of using this "crypto currency", so finding a way to reduce the transfer waiting time for my customers will be very well welcomed (structural, not "insurance for a fee" based ones).

BTCJAM - Peer to Peer Bitcoin Lending
https://btcjam.com
gmaxwell
Moderator
Legendary
*
qt
Online Online

Activity: 2016



View Profile
July 01, 2011, 02:43:55 PM
 #4

Just wait for 6, 7, 10, confirmations doesn't seems to make sense (mathematically at least), since given enough time any number of computing power will produce the confirmations needed (of course i can use 120 confirmations but no customer want to wait that long), but as I'm kind of new to bitcoins maybe i`m missing something?

So— using time and delaying confirmation when things look weird would be a useful enhancement, but its less important that I think you think it is:

If, say, btcguild goes evil and starts mining a fork which reverses and respends— then yes, given enough time they will mine six blocks.  _BUT_ in that same time the rest of the network would have mined 14 and so the chain produced by the rest of the network would be much larger and your client would ignore the chain produced by btcguild.

So the only way this would matter is if they were also able to get enough control of your network connectivity that they could prevent you from hearing about the blocks produced by the rest of the network.  The fact that this isn't impossible is why some additional logic would be useful.  (Along with peer rotation, explicitly configured trusted peers, etc)  But the fact that both significant hashpower and the network attack are required is why it's less of an issue than you might guess.



Tulkas
Sr. Member
****
Offline Offline

Activity: 350


Founder, BTCJAM


View Profile WWW
July 02, 2011, 10:51:11 PM
 #5


Thanks for the explanation!

In fact I'm trying to require only the absolute minimum confirmations so the site users will have a nicer experience using the site. Just putting 6 out of the blue on my code sounded too random.

If i understood correctly any fork will only be viable if the evil persons involved have more hash power than all the network combined, because the client will ignore the shorter blocks.

So why the "standard" number of confirmations is, lets say, 2, instead of those larger numbers people out there are using?

What is the probability of some malicious attacker find 2 blocks in a row having, lets say, 40% of the total network hash on his hands ?

The mean case is easy, supposing the false blocks will not be discarded by my client because of some network tampering, the attacker will only be able to generate 4 blocks per hour, so if 2 confirmations take more than 30 minutes something is wrong and i wait more confirmations, if 2 confirmations take 15 minutes or less the transaction is legitimate.

The problem here is the "lucky" attacker who can guess 2 blocks out of luck, someone did the math or can help me calculate those odds ? I did some search and found nothing.

Thanks.


 

BTCJAM - Peer to Peer Bitcoin Lending
https://btcjam.com
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!