Bitcoin Forum
March 29, 2024, 05:35:22 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin bottleneck  (Read 4045 times)
alkor (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
February 03, 2011, 05:44:33 PM
 #1

The current bottleneck in the bitcoin infrastructure is the speed of confirmation of transactions. I've had to wait for up to half an hour in order to get a confirmation of a transaction that I made. Why is it taking so long to get confirmations? Are there any plans to speed up the process?
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1128


View Profile
February 03, 2011, 05:49:08 PM
 #2

It's random but averages out to 10 minutes over time.

You don't have to wait for lots of confirmations. Once your client tells you that you received or sent some coins, you can assume it's "done". Satoshis code is very conservative - it waits until the cryptographic difficulty of reversing the transactions is extremely high. For practical purposes you don't really have to worry about it.
alkor (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
February 03, 2011, 05:51:14 PM
 #3

But what determines the speed of the confirmations? Is it the number of miners that is too low?

What will happen as the difficulty increases, and there is less and less incentive for miners to operate? Will that mean that confirmations will become even slower?
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1128


View Profile
February 03, 2011, 05:52:28 PM
 #4

No, difficulty is chosen by the software automatically to target a 10 minute average. If megahash rate goes down the difficulty will go down too and the network will reconverge on 10 minutes.
alkor (OP)
Full Member
***
Offline Offline

Activity: 136
Merit: 100


View Profile
February 03, 2011, 07:00:57 PM
 #5

So if all miners were to suddenly stop mining all at once, how would this affect the bitcoin network? Will payments still go through?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 03, 2011, 07:11:13 PM
 #6

You can often speed up transaction processing by including a 0.01 BTC fee.

For practical purposes you don't really have to worry about it.

I wouldn't say that. Consider that ArtForz or slush could easily reverse a transaction with even 2 confirmations (maybe more).

So if all miners were to suddenly stop mining all at once, how would this affect the bitcoin network? Will payments still go through?

Processing would become much slower. However, transaction fees would accumulate, constantly increasing the generation incentive. Eventually someone would want to generate.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
February 03, 2011, 08:42:30 PM
 #7

I thought the clients themselves mine too, at least if they have the incoming port open?

(So all the puny clients would "confirm" transactions among themselves, until some huge mining consortium trivially creates a longer chain in moments, invalidating hours days weeks or whatever of work by the puny clients?)

(I am thinking a lot of people might not leave their client running 24/7...)

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Garrett Burgwardt
Sr. Member
****
Offline Offline

Activity: 406
Merit: 255


View Profile
February 03, 2011, 08:44:47 PM
 #8

Not by default, and it doesn't require the incoming port to be open. Once the reward from mining drops, fewer users are going to mine, lowering the difficulty, so it shouldn't be a problem.
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
February 03, 2011, 08:46:41 PM
 #9

So if the situation seems to be the case, turn on your mining in your client, duh! ?

Also maybe it would help if "get through to each other even if both are behind NAT / firewall" were included?

Usually a firewall will allow a remote machine to send packets in to you on a port you already tried to send out to them on, especially if the packets are coming from the exact port on the other box that you tried to reach... ?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Hal
VIP
Sr. Member
*
Offline Offline

Activity: 314
Merit: 3799



View Profile
February 03, 2011, 11:21:15 PM
 #10

I agree this can be a problem. Putting in a transaction fee won't help if the next block happens to take an hour to generate.

I suggested a technical solution to reduce variability:

http://bitcointalk.org/index.php?topic=2968.0

We might also consider shortening the ten minute target interval. Making it five minutes would greatly reduce the chance of a long wait.

Hal Finney
sandos
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


#SWGT CERTIK Audited


View Profile
February 04, 2011, 04:36:37 PM
 #11

We might also consider shortening the ten minute target interval. Making it five minutes would greatly reduce the chance of a long wait.


What are the drawbacks of shorter intervals? I dont see any, except maybe larger overhead in general because of more blocks, but that should be manageable.

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1128


View Profile
February 05, 2011, 10:29:02 AM
 #12

From what I understand 10 minutes was chosen as a best guess based on p2p network propagation time for very large and dense networks.
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
February 05, 2011, 05:08:24 PM
 #13

So if all miners were to suddenly stop mining all at once, how would this affect the bitcoin network? Will payments still go through?

If ALL miners quit then there would be no confirmations but YOU could turn on generation and confirm your own txn eventually. If they all quit very suddenly then it might take a fairly long time for the next difficulty adjustment to come around (something like what has recently happened on testnet). There could be a considerable period while till the next adjustment (months) that the confirmation rate would be very slow. The solution is of course to get more people back to mining. Frankly tho it seems like it would be extraordinary if all the miners quit at once. I don't think it would really happen.

If the miners quit more gradually then we would see the difficulty dropping (to keep the block rate up to 10 blocks/hour) and eventually the lower difficulty would motivate new miners to start up.
RHorning
Full Member
***
Offline Offline

Activity: 224
Merit: 141


View Profile
February 06, 2011, 02:47:53 AM
 #14

From what I understand 10 minutes was chosen as a best guess based on p2p network propagation time for very large and dense networks.

I think this is a good point, so far as the issues about how the time interval has been selected.  We really don't know how large Bitcoin is going to get, and my personal guess is that it will be considerably larger in terms of the number of people involved than is even using Bitcoin at the present time.

I know it is discouraging that ordinary folks can no longer realistically be able to mine Bitcoins using an ordinary computer, and expect to "discover" Bitcoins in a short interval.  I've expressed concerns about this very issue in the past and it went upon deaf ears then.  I've since learned a bit more about the Bitcoin architecture and realize that it is a difficult to intractable problem except for mining pools and other strategies to apportion out at least some Bitcoins to those who want to participate.

On the whole, Bitcoin does a substantially better job of verifying transactions than the Federal Reserve does for check transactions, or for that matter even ATM transactions.  While check kiting is much, much harder to do now than it was in the past, it still can be done, as can the reverse in terms of banks holding money for seemingly impossible periods of time (up to a week or more) when somebody screws up.  Knowing that a transaction will generally be "confirmed" with 5-6 blocks incorporating that transaction in a hour is to me a pretty good result, if you consider the alternatives that exist elsewhere in the banking community.

Most retailers, I would believe, would be ecstatic to know that a retail transaction was completely confirmed as theirs within an hour or less, particularly that "charge-backs" could never happen after that.  Even if you have to wait a half hour for the next block (because of random events happening) it still isn't the end of the world.

The worst part, as mentioned earlier, is what happens when mining activity drops off considerably.  I've argued that the re-adjustment algorithm needs to be modified somewhat, and that is the achilles heel of Bitcoin, as it could have some more generalized adjustment algorithm that isn't so coarse.  It does stops certain kinds of attacks by being that coarse, which I won't go into now but that is something to consider if you want to complain about the readjustment interval.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
February 07, 2011, 03:22:56 PM
 #15

I am the owner of the gambling machine and I am join in the request for the reduction 'interval' of block generation into 2 times.

Technically, this could be enabled after some block that clients have time to update the software.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
Cusipzzz
Sr. Member
****
Offline Offline

Activity: 334
Merit: 250



View Profile
February 07, 2011, 03:48:44 PM
 #16

I am the owner of the gambling machine and I am join in the request for the reduction 'interval' of block generation into 2 times.

Technically, this could be enabled after some block that clients have time to update the software.


The more efficient solution is to let players hold accounts and let them bet multiple times on a single transaction (deposit). These betting sites that create 2 transactions (deposit/withdrawal) for every bet are a  major case of unnecessary blockchain spam.

And you wouldn't need to reduce the interval, as once a user makes an initial deposit, and it is validated, will cover them for many games. They deposit, bet 20 times, withdraw. 2 transactions in the blockchain as opposed to 40! (assuming they get a payout every time).

I run a gambling site too, and while quicker confirms would be nice, i'd actually vote for longer confirms if it would cause blockchain spam sites like yours to lose business - nothing personal, do it the right way, it's not that hard.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
February 07, 2011, 04:05:10 PM
 #17

We using a different niches: users of my lottery are just passing by and decided to throw a coin.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
Cusipzzz
Sr. Member
****
Offline Offline

Activity: 334
Merit: 250



View Profile
February 07, 2011, 04:15:02 PM
 #18

fair point - but it's one way to attack the delayed confirmation issue. Make them wait once instead of multiple times for people trying it out more than once.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350
Merit: 252


probiwon.com


View Profile WWW
February 07, 2011, 04:40:11 PM
 #19

Hm... I am agree.

I think this problem needs strong mathematical modeling. It is not yet too late.

New bitcoin lottery: probiwon.com
- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
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!