2 minutes between the blocks?

Technical discussions related to CryptoNote repository and the forking process

2 minutes between the blocks?

Postby O.S.G. » Wed Apr 02, 2014 11:42 am

It seems like you, guys, tried to make everything best.

I think that 2 minutes between blocks (against 10 in bitcoin) is an improvement, but not an ideal decision. Do you know that DogeCoin has 1 minute and Quark has 30 seconds?
O.S.G.
 
Posts: 9
Joined: Fri Mar 28, 2014 9:41 am

Re: 2 minutes between the blocks?

Postby Maurice.P » Wed Apr 02, 2014 5:41 pm

O.S.G. wrote:It seems like you, guys, tried to make everything best.

I think that 2 minutes between blocks (against 10 in bitcoin) is an improvement, but not an ideal decision. Do you know that DogeCoin has 1 minute and Quark has 30 seconds?


I can continue your list: Fastcoin has 12 seconds timespan, Quickcoin had 5 seconds. I don't remember the name of the altcoin with 1 second (it was created just as an experiment).

However, smaller timespans are not necessarily better. There are certain downsides of a smaller interval between blocks:

1. Orphan rate.

Suppose you have a constant time of block propagation across the network (e.g. 10 seconds). When you find the block, you immediately send it to all your peers, so that they can work on the next block. Meanwhile, the "remote" areas of the network are still working on the previous block chain height. This implies that those nodes can produce their own blocks before getting to know yours exist.

In this situation a block chain fork appears; at least one of the blocks will be orphaned. So, the faster the chain grows, the more orphans it produces and the more work is wasted. It results in money loss (only one block is rewarded) and, more importantly, in security threats, since the real network hashrate decreases.

2. Space/power requirements.

The faster you generate blocks, the more block headers you need to store for the same period of time. Of course the size of a header is insignificant comparing to the size of the transactions it contains. But it does matter for light/SPV clients that store only the headers of the block chain. 30 second instead of 120 will force those clients to spend four times more space (e.g. 100 MB/year instead of 25) and four times more time to verify the headers. This might be a serious problem for a pocket device.

The bottom line: decreasing time interval between blocks is not always the best choice.
Maurice.P
 
Posts: 63
Joined: Wed Mar 26, 2014 3:26 pm

Re: 2 minutes between the blocks?

Postby O.S.G. » Thu Apr 03, 2014 1:41 pm

Maurice.P wrote:1. Orphan rate.

Suppose you have a constant time of block propagation across the network (e.g. 10 seconds). When you find the block, you immediately send it to all your peers, so that they can work on the next block. Meanwhile, the "remote" areas of the network are still working on the previous block chain height. This implies that those nodes can produce their own blocks before getting to know yours exist.

In this situation a block chain fork appears; at least one of the blocks will be orphaned. So, the faster the chain grows, the more orphans it produces and the more work is wasted. It results in money loss (only one block is rewarded) and, more importantly, in security threats, since the real network hashrate decreases.


I know about orphans, thanks. You didn't need to explain this in detail. But I also know that Doge and Quark don't suffer from orphans that much, so 30-60 seconds might be a good option.

O.S.G. wrote:2. Space/power requirements.

The faster you generate blocks, the more block headers you need to store for the same period of time. Of course the size of a header is insignificant comparing to the size of the transactions it contains. But it does matter for light/SPV clients that store only the headers of the block chain. 30 second instead of 120 will force those clients to spend four times more space (e.g. 100 MB/year instead of 25) and four times more time to verify the headers. This might be a serious problem for a pocket device.


I think 100 MB is not a big problem. My HTC has 2 GB onboard, not counting external SDHC.
O.S.G.
 
Posts: 9
Joined: Fri Mar 28, 2014 9:41 am

Re: 2 minutes between the blocks?

Postby Maurice.P » Thu Apr 03, 2014 6:03 pm

If we take merchant and point-of-sale perspective, there is hardly any difference between 30 and 120 seconds. If you're standing in front of a snack machine, you won't be satisfied to wait any longer than a few seconds. Instant payment confirmation is impossible in contemporary cryptocurrencies. At least without new levels of abstraction and specific protocols. How much should the time span be for a point-of-sales interaction? I'd say less than 10 seconds, but as I've shown above this should be rather disadvantageous.

If there's no point in trying to reach the lower bound, why should be pursue it at all? Actually, there was quite an argument among us on that issue. Original proposal was to make the block rate at about 5-10 minutes. Current 2 mins consensus was a result of very long disputes.

I think 100 MB is not a big problem. My HTC has 2 GB onboard, not counting external SDHC.


Your HTC is also likely to verify each header for a significant amount of time. This is mostly due to our proof-of-work function tailored to modern CP CPUs. So mobile processors are still suitable for this, but not as much as their "elder brothers".

So, choosing 2 min interval we did concern mobile devices' speed of verification of a several-year-old block chain.
Maurice.P
 
Posts: 63
Joined: Wed Mar 26, 2014 3:26 pm

Re: 2 minutes between the blocks?

Postby ochtend » Fri Apr 11, 2014 3:47 pm

Did you read this paper: https://eprint.iacr.org/2013/881.pdf ?

It claims that time interval can be lowered to a few seconds.
ochtend
 
Posts: 3
Joined: Fri Mar 28, 2014 9:49 am

Re: 2 minutes between the blocks?

Postby SpainDev » Tue May 20, 2014 4:09 pm

Bytecoin was started before this paper was published. But the main message of the article (from our point of view) is not about 1-second blocks. It is still impossible due to the storage/verification costs. The advantage of the protocol proposed is in eliminating the wasted work, done by the nodes which haven't received the newest block. It is a very helpful feature indeed, but mainly for the point-of-sale issue.
SpainDev
 
Posts: 2
Joined: Wed Mar 26, 2014 3:47 pm


Return to Reference Code & Forking

Who is online

Users browsing this forum: No registered users and 1 guest