Topic: Bitcoin bottleneck (Read 4077 times)

Hm... I am agree.

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

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.

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

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.

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.

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.

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.

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

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.

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:

https://bitcointalksearch.org/topic/reducing-block-time-variability-2968

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

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-

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.

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-

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


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


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

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

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.

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?

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.

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?