Coins with very short block times demonstrate incompetence

[erk]

That pool is really not that good. I was mining it for a while after launch, and I had constant disconnects. I wouldn't doubt the pool operator was doing something wrong.

I've been on Big Verns pool since then, and never had a problem.

Talk to me when this has happened on multiple, more reputable pools.

I have used several of Paul21's pools and when they work they are great, but they tend to go up and down like a yoyo, he often says he is getting DDoS, hence not a great example to use as a short block time argument.

I seriously doubt that re-org splits from shorter block targets, create longer times to arrive at consensus on block chain validity, irreversibility is a function of number of blocks, not time.

At any rate the coins are out there, WDC/DGC, we shall soon know how they perform, no need to speculate.

[1715129165]

1715129165

[jj9guy]

This is an example of why democracy doesnt work for everything. You might sit down and carefully choose the parameters for your program like the bitcoin developers did only for people to come use your source and max everything out like if designing a coin was the equivalent of using gameshark to get infinite gil.

It was made open source for the very reason that it could be improved upon, in the future, when networks and computers became better.

That, and it would be harder to shut down multiple coins.

Yeah like Firefox is open source so people could change the icon image and about:config for backspace and call it "Flamefox: the ultimate opensource browser. Way better than Firefox"

Cool story bro

Great retort. I assume you must be some type of middle school debate champ.

[DeadEyeCool]

This is an example of why democracy doesnt work for everything. You might sit down and carefully choose the parameters for your program like the bitcoin developers did only for people to come use your source and max everything out like if designing a coin was the equivalent of using gameshark to get infinite gil.

It was made open source for the very reason that it could be improved upon, in the future, when networks and computers became better.

That, and it would be harder to shut down multiple coins.

Yeah like Firefox is open source so people could change the icon image and about:config for backspace and call it "Flamefox: the ultimate opensource browser. Way better than Firefox"

Cool story bro

Great retort. I assume you must be some type of middle school debate champ.

So tell me genius, why was it made open source then? Moral support alone?

[markm]

GeistGeld has been humming along on 15 second blocks for what, years now?

So far the biggest problem was been the huge amount of RAM needed, more even than I0Coin.

I guess in a couple of years we will find out whether the RAM usage is due to the sheer number of blocks.

Or, we could update GeistGeld's code in case maybe it has a memory leak, as I0Coin is thought to have.

-MarkM-

[relm9]

That I am aware of, but hey, all of these coins are technically "experiments", so there's always time and room to do just that. Gotta start somewhere

If WorldCoin was meant to be an experiment of 'ultra-fast transactions', they should have tried a even lower block retarget time just for the hell of it.

15s has already been done several times, Geist Geld and SmallChange.

Anyway, it would be interesting to see something like satoshi DICE on 15s blocks 

[erk]

That I am aware of, but hey, all of these coins are technically "experiments", so there's always time and room to do just that. Gotta start somewhere

If WorldCoin was meant to be an experiment of 'ultra-fast transactions', they should have tried a even lower block retarget time just for the hell of it.

15s has already been done several times, Geist Geld and SmallChange.

Anyway, it would be interesting to see something like satoshi DICE on 15s blocks 

Do WDC say it's an experiment? No they don't, they expect it to be taken seriously.

[centenary]

GeistGeld has been humming along on 15 second blocks for what, years now?

So far the biggest problem was been the huge amount of RAM needed, more even than I0Coin.

I guess in a couple of years we will find out whether the RAM usage is due to the sheer number of blocks.

Or, we could update GeistGeld's code in case maybe it has a memory leak, as I0Coin is thought to have.

-MarkM-

What was the peak number of miners?

[Maged]

As I said, the block time needs to be more than several times the maximum end-to-end propagation delay.  This is needed to prevent competing nodes from generating blocks at the same time and convincing large parts of the network that their respective block is the winning block.  If competing nodes can convince large parts of the network that their respective block is the winning block, you risk fragmentation of the blockchain.  Having the block time be at least several times the maximum end-to-end propagation delays helps prevent competing nodes from convincing large parts of the network that their respective block is the winning block.

Block chain fragmentation is not the issue, an overhead for sure, but it's the "double spend attack" from competing chains that we are worried about, which BTW doesn't means "51% attack". You can try to double spend with less but you may not be successful. The more blocks generated, the smaller your chance.  The probability of success with a <50% attack depends on the number of blocks and not the amount of time. This is an advantage of shorter block times.

Yes, but like most things in life, an important balance between too much and too little exists. Shorter block times make it harder for <50% attacks to succeed, true, but by increasing the number of orphans, it decreases the effective hash rate of the network, making a >50% attack potentially much easier. Bitcoin considers the potential risks of a successful >50% attack to be very high, so Satoshi chose a long block time.

[mr_random]

GeistGeld has been humming along on 15 second blocks for what, years now?

So far the biggest problem was been the huge amount of RAM needed, more even than I0Coin.

I guess in a couple of years we will find out whether the RAM usage is due to the sheer number of blocks.

Or, we could update GeistGeld's code in case maybe it has a memory leak, as I0Coin is thought to have.

-MarkM-

+1.

[erk]

Yes, but like most things in life, an important balance between too much and too little exists. Shorter block times make it harder for <50% attacks to succeed, true, but by increasing the number of orphans, it decreases the effective hash rate of the network, making a >50% attack potentially much easier. Bitcoin considers the potential risks of a successful >50% attack to be very high, so Satoshi chose a long block time.

This seems like mathematical nonsense, please prove to me that  for example if there are 4 times more chain splits with 1/4 the block time, that there are less iterations to arrive at consensus within the same duration. I bet you can't, because the increase in chain splits is trivial compared to the increase in blocks.

LTC has certainly proven for a long time that a shorter than 10min block target is perfectly viable.

[Impaler]

I don't think anyone can credibly claim that block times must be 10 minutes, LTC and several other coins run effectively at 1-2 minutes a block. This should hardly come as a surprise, the improvement in internet latency in western countries and processor speeds in the last 4 years would give us that kind of improvement.  In other-words LTC now is likely producing orphans at about the same rate BTC did when it first launched so if those parameters were correct for BTC at the time then they are fine for LTC.

The OP is merely claiming that trying to get as the very short times around 15 seconds is unwise and unsafe and this is a legitimate concern particularly because its very very common for new coins to run even faster then target and they are certainly going to exceed propagation speed at those times and thus we get the 300 orphan blocks and other similar effects (we had some bad orphaning during FRC launch and some large orphan forks too).  If difficulty was better constrained to match network hash rates then 15 seconds might be sustainable.

Now I do not believe that LTC or other faster block chains confidence increases at a 1:1 ratio, in other words 6 LTC confirmations != 6 BTC confirmations, you do need more confirmations on the faster chain but you should NET need less TIME.  And that's what we really care about when doing commerce the time to get verification.  It's just not a linear relationship as may advocates of fast block-chains claim, their is some kind of logarithmic scaling that's yet to be really measured well, I suspect that if we did measure it we could arrive at a scientifically optimum block-time.

[Maged]

Yes, but like most things in life, an important balance between too much and too little exists. Shorter block times make it harder for <50% attacks to succeed, true, but by increasing the number of orphans, it decreases the effective hash rate of the network, making a >50% attack potentially much easier. Bitcoin considers the potential risks of a successful >50% attack to be very high, so Satoshi chose a long block time.

This seems like mathematical nonsense, please prove to me that  for example if there are 4 times more chain splits with 1/4 the block time, that there are less iterations to arrive at consensus within the same duration. I bet you can't, because the increase in chain splits is trivial compared to the increase in blocks.

LTC has certainly proven for a long time that a shorter than 10min block target is perfectly viable.

Of course a block time shorter than 10 minutes is perfectly viable! I never said that it wasn't. My point was that there exists a point where the orphan rate caused by a shorter block time ends up outweighing the benefits of a shorter block time. This starts to matter earlier than you may think because an orphan rate of just a few percent would be enough to encourage miners to centralize. However, ignoring that, here's an extrapolation of the reduction in effective hash rate as a network the size of Bitcoin reduces block time (the Bitcoin network currently sees about a 1% orphan rate):

Blocktime in seconds	Reduction in effective hashrate
600	1%
300	2%
150	4%
75	8%
37.5	16%
18.75	32%
9.375	64%

As you can see, two and a half minutes per block isn't actually all that bad in the reduction of effective hashrate, but I wouldn't want to go much lower than that.

[Impaler]

Maged:  Do you have a source for your numbers their?  Or are you just postulating that each halving of block time doubles the orphan rate?  It seems a bit too smooth to be realistic to me, miners presumably have a variety of connection speeds which should add some noise.  Do we have data on the orphan rates in LTC or Geist Geld and SmallChange which were mentioned earlier?

[erk]

Of course a block time shorter than 10 minutes is perfectly viable! I never said that it wasn't. My point was that there exists a point where the orphan rate caused by a shorter block time ends up outweighing the benefits of a shorter block time. This starts to matter earlier than you may think because an orphan rate of just a few percent would be enough to encourage miners to centralize. However, ignoring that, here's an extrapolation of the reduction in effective hash rate as a network the size of Bitcoin reduces block time (the Bitcoin network currently sees about a 1% orphan rate):

Blocktime in seconds	Reduction in effective hashrate
600	1%
300	2%
150	4%
75	8%
37.5	16%
18.75	32%
9.375	64%

As you can see, two and a half minutes per block isn't actually all that bad in the reduction of effective hashrate, but I wouldn't want to go much lower than that.

How does your table prove this? Where is the formula? What's this effective hash rate nonsense. We have block and timestamps on those block we can check to see if we are getting them at roughly one ever 15 sec.

If a 15sec block rate didn't work because of orphans my WDC mining stats would tell me this and they don't, in fact WDC is working really well, and is doing transactions faster than any other coin I have tried.

[KrLos]

i think that less tahn 2 mins is a bad proposition.

[megablue]

it is funny that all these 'pro' came out with magic numbers that 'disproof' viability of short block times.

[Maged]

Or are you just postulating that each halving of block time doubles the orphan rate?

Yes. The propagation time does not change as the block times get smaller, and the math for those values were easier. To think of it another way, at a 6 second block time, the effective hash rate is reduced by 100% - meaning that the single fastest miner will always get the next block (if you assume that blocks are produced at a constant rate). As for the 1% number, that was what someone saw as Bitcoin's orphan rate a few months ago. I'm going with that number because it is good enough for this basic analysis.

It seems a bit too smooth to be realistic to me, miners presumably have a variety of connection speeds which should add some noise.

Obviously, this is based on averages. An individual block could have a large space between blocks, allowing more propagation before the next block is found. Of course, the inverse is also true.

Do we have data on the orphan rates in LTC or Geist Geld and SmallChange which were mentioned earlier?

Doesn't matter. The Bitcoin network should dictate the absolute minimum viable block time, since it is currently the largest network.

[Tobius]

i think that less tahn 2 mins is a bad proposition.

Only thing is less than 2 minutes is what we need for these things to be viable :\ It's a battle between security and usefulness

[peacefulmind]

For all cryptocurrencies based off the Bitcoin protocol, the block time needs to be chosen carefully in order to guarantee that nearly every node in the distributed network maintains the same view of the blockchain.  The block time needs to be, at the very least, several times larger than the maximum end-to-end propagation delay across the distributed network.

Choosing a very short block time demonstrates a lack of understanding of this requirement.  If you make block times very short, then nodes will generate blocks faster than it would take for notifications to reach nodes on the opposite end of the distributed network.  This will cause nodes within the distributed network to have inconsistent views of the blockchain.

What does this mean?  1) Lots of orphans.  2) Very long orphan blockchains.  3) Significantly reduced security for the network.

Earlier today, one of the WorldCoin mining pools (http://wdc.dontmine.me) was on an orphan blockchain for more than 300 blocks.  That would never happen for any competently designed coin.

Altcoins with very short block times have no real future.  Once they reach a certain critical mass, they will inherently self-destruct due to the large percentage of inconsistency within the distributed network.  Imagine the blockchain accidentally forking into two separate blockchains.  With very short block times, that's a real possibility.  Or imagine having a transaction confirmed, only to realize hours later that the transaction was confirmed in an orphan blockchain and needs to be rolled back and reconfirmed.  No one would realistically support such an altcoin.

If you're going to release an altcoin, do the community a favor and at least release something that appears competently designed.

I agree what happened with the large pool was an example of the disaster that would occur should these new coin of the months ever reach mass adoption.

We ALREADY have the alt coin we need.

LTC.  Nothing else introduced really touched it.

Now we have Feathercoin 2.0 coming - don't get me wrong I will hop on the train and rip off BTC/LTC owners again who want to buy a bunch of FTC 2.0 just like anyone else.

This is going to continue until the rubes quit.

LTC is already the coin that is fast enough while staying 100% secure and has the history and most distributed ownership by percentage of coins outstanding.