Bitcoin Forum
May 26, 2024, 11:29:12 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Bitcoin transaction times  (Read 1111 times)
QuestionAuthority
Legendary
*
Offline Offline

Activity: 2156
Merit: 1393


You lead and I'll watch you walk away.


View Profile
June 23, 2014, 05:37:21 PM
 #21

lol do you seriously want to know.

anyway AceWallen, got to love bitpay for that, instant speed transaction, me likes.

Yeah, I think she should link to a bucket pic somewhere. Tits or gtfo.

BitPay and other companies are getting rich by taking on the risk of instant transactions. I wonder what their losses actually are? I bet it's petty small.

railzand
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250

Lux e tenebris


View Profile
June 23, 2014, 08:14:06 PM
 #22

Hello,

I've been doing a lot of research on bitcoin and its weaknesses. I realize that bitcoin is software and that anything about it can be changed. After using it for a few months, I think the greatest annoyance is the long transaction times. For large purchases such as transferring money or purchasing a house, the transaction times are fine, but if bitcoin is to really take off in day to day life, it needs much faster transaction times. No one will want to wait around for 15 minutes for confirmations.

My question is, since bitcoin is software, will the transaction times be decreased in the future? I think they absolutely must be or else another cryptocurrency will come along and do it.

No, satoshi himself said about transaction times that they are perfect like this. Shorter times would be more vurnerable to attacks.

Also, for reasonably small transactions like groceries it's not needed to wait for conformations, as the hassle of double spending (which is not as easy as many people make believe) is not worth it for small transactions.

I've had similar questions and I'd like to see this. Do you have a link to where satoshi said that?

I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate.  When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first.  If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example:
1         0
4         1
16        4
64        16
80%      20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes.  When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends.  If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad.  A double-spent transaction wouldn't get very far without one of the listeners hearing it.  The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.


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