1 second block time - what will happen ? Pros/Cons

[Rizvi91]

Hey,
Let's say there's a coin which has 60 seconds block time and 6 coins reward per block with 15 confirmations. What will happen if we change the block time time 1 second and block reward to 0.1 coins and make the number of confirmations same. What will happen now? I you guys please post the advantages / disadvantages of this scenario?

[1714849267]

1714849267

[1714849267]

1714849267

[1714849267]

1714849267

[ranochigo]

Much more orphans. If you're using POW, the delay in the block relays would be much more significant than the block interval.

If the number of required confirmations remains the same, the security of the merchant accepting the transactions would decreases significantly. As compared to before, less resources is required to attack the chain and double spend your own transaction. I can't think of any significant advantage to lowering the block time to that amount.

[nc50lc]

The "block time" which can be adjusted by tweaking the target difficulty isn't all based from the target constant supply and the maximum coins limit like you presented.
It's more of a security feature, adjusting it to 1 sec average is purely filled with disadvantages.

One advantage though: Seconds to instant transaction propagation in exchange for...
Disadvantages: ronochigo's reply (more chain splits which will cause chaos to the market) and also for POS coins
Nodes will have to dedicate more storage space not because of the number of blocks per hour but because of more blocks without a transaction.

[aleksej996]

1 second on average means a lot of times it will take just a fraction of the second.

On top of all of this, anyone who is willing to mine this coin would have to have fiber-optic Internet connection in order to have low latency.
Of course, routing your connections over something like Tor or VPN would be ridiculous.
So no privacy for the miners, more centralization to only miners that have access to fiber-optic and overall lower security for the network.

[seoincorporation]

I can see two things in this scenario...

1.- An enormous blockchain... at that block rate after one year we will have a big number of blocks, that mean a heavy blockchain:

Code:

60*60*24*365
31536000

2.- A massive processing... blocks each second mean the miners have to solve them fast... and transmit the information about the new block onthe network each second is another important fact.

At start could be simple, but with time could get really heavy.

[DarkStar_]

I can see two things in this scenario...

1.- An enormous blockchain... at that block rate after one year we will have a big number of blocks, that mean a heavy blockchain:

Code:

60*60*24*365
31536000

Not sure what a 'heavy' blockchain means, but the blockchain's file size would rapidly get faster. A coinbase transaction that claims the reward and states the pool and any other data is around 230 bytes. In 10 minutes worth of blocks, we'd be adding over 13 MB to the blockchain from block rewards alone.

[monsanto]

Much more orphans. If you're using POW, the delay in the block relays would be much more significant than the block interval.

If the number of required confirmations remains the same, the security of the merchant accepting the transactions would decreases significantly. As compared to before, less resources is required to attack the chain and double spend your own transaction. I can't think of any significant advantage to lowering the block time to that amount.

Instead of a strict targeted block time, would it be possible to adjust difficulty partly based on orphan rate? So that as orphan rate increases, difficulty would also adjust upward, increasing block time (and lowering orphan rate).

[bones261]

Much more orphans. If you're using POW, the delay in the block relays would be much more significant than the block interval.

If the number of required confirmations remains the same, the security of the merchant accepting the transactions would decreases significantly. As compared to before, less resources is required to attack the chain and double spend your own transaction. I can't think of any significant advantage to lowering the block time to that amount.

Instead of a strict targeted block time, would it be possible to adjust difficulty partly based on orphan rate? So that as orphan rate increases, difficulty would also adjust upward, increasing block time (and lowering orphan rate).

I'm not certain that all of the mining nodes are going to agree on exactly what the orphan rate will be. It is quite possible that some orphan blocks are never relayed to the whole network. This may cause the mining nodes that are not aware of a particular ophan block to mine at a lower difficulty than other mining nodes. And these miners that never had this information would end up getting their block orphaned because their new chain would have less accumulated work than a miner who found a block at the higher difficulty rate.

[spartacusrex]

Much more orphans. If you're using POW, the delay in the block relays would be much more significant than the block interval.

If the number of required confirmations remains the same, the security of the merchant accepting the transactions would decreases significantly. As compared to before, less resources is required to attack the chain and double spend your own transaction. I can't think of any significant advantage to lowering the block time to that amount.

Instead of a strict targeted block time, would it be possible to adjust difficulty partly based on orphan rate? So that as orphan rate increases, difficulty would also adjust upward, increasing block time (and lowering orphan rate).

I've always liked this idea.

A fully endogenous solution to block time.

I'm not certain that all of the mining nodes are going to agree on exactly what the orphan rate will be. It is quite possible that some orphan blocks are never relayed to the whole network. This may cause the mining nodes that are not aware of a particular ophan block to mine at a lower difficulty than other mining nodes. And these miners that never had this information would end up getting their block orphaned because their new chain would have less accumulated work than a miner who found a block at the higher difficulty rate.

All the data required to determine the orphan rate would need to be in the longest chain - so all the uncles would need to be referenced. No other data would be taken into account when calculating consensus. So those uncles that did exist but weren't referenced would be ignored, until added to the longest chain.

This way it would always be possible to independently calculate the correct required difficulty from the parent block (and the chain up from there ).

[ranochigo]

Instead of a strict targeted block time, would it be possible to adjust difficulty partly based on orphan rate? So that as orphan rate increases, difficulty would also adjust upward, increasing block time (and lowering orphan rate).

Likely not. Other than the need for perfect information, an implementation like this would require each node to allocate more resources and validate more blocks that are relayed to them and has a valid POW. By changing the block intervals, you would have to consider the supply limit of the coin. The block halving rate could potentially occur much sooner.

It's more of a hassle to implement a mechanism like this than to just determine the equilibrium of the orphan rate and the block interval and to put a fixed interval to it. 1 second blocks would not be viable for now.

[d5000]

Keeping the "required confirmations" at 15 would be stupid (anyway, nobody can tell a merchant or exchange how many confirmations he should require).

If a cryptocurrency with a 60-second block interval changes to one second, and all other parameters (reward rate per minute [not per block!], coin price, difficulty) remain the same, then you would need about 60 1-second-onfirmations to achieve a similar security than with one 60-second-confirmation before. This is because the security of a transaction isn't bound to the number of confirmations alone, but also to the "attack cost". This is the cost to revert the confirmations for a malicious miner. And the attack cost to revert a 1-second-block would be approximately 1/60 of the cost to revert a 60-second-block.

There is only one scenario in which a 1-second-confirmation would make sense: for micropayments. Because even an 1-second-confirmation is still better than no confirmation at all, as the act to "add a transaction to a block in the blockchain" is providing already a minimal double-spend protection. And I guess nobody would try to 51% Bitcoin for a coffee (you may be unlucky, however, if the attacker tries to scam several merchants at once). But for larger transactions, you would have to require a sufficient number of confirmations to ensure an "attack cost" high enough to disincentive an attack on your transaction.

Low block intervals are cool for sidechains, and regarding PoS coins the math is a bit different as the attack cost doesn't depend on hashrate - however, they have the Nothing-at-stake problem.

[spartacusrex]

Keeping the "required confirmations" at 15 would be stupid (anyway, nobody can tell a merchant or exchange how many confirmations he should require).

If a cryptocurrency with a 60-second block interval changes to one second, and all other parameters (reward rate per minute [not per block!], coin price, difficulty) remain the same, then you would need about 60 1-second-onfirmations to achieve a similar security than with one 60-second-confirmation before. This is because the security of a transaction isn't bound to the number of confirmations alone, but also to the "attack cost". This is the cost to revert the confirmations for a malicious miner. And the attack cost to revert a 1-second-block would be approximately 1/60 of the cost to revert a 60-second-block.

There is only one scenario in which a 1-second-confirmation would make sense: for micropayments. Because even an 1-second-confirmation is still better than no confirmation at all, as the act to "add a transaction to a block in the blockchain" is providing already a minimal double-spend protection. And I guess nobody would try to 51% Bitcoin for a coffee (you may be unlucky, however, if the attacker tries to scam several merchants at once). But for larger transactions, you would have to require a sufficient number of confirmations to ensure an "attack cost" high enough to disincentive an attack on your transaction.

Low block intervals are cool for sidechains, and regarding PoS coins the math is a bit different as the attack cost doesn't depend on hashrate - however, they have the Nothing-at-stake problem.

https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/

And if I may simply quote Vitalik's conclusion...

The conclusion of all this is simple: faster block times are good because they provide more granularity of information. In the BFT security models, this granularity ensures that the system can more quickly converge on the "correct" fork over an incorrect fork, and in an economic security model this means that the system can more quickly give notification to users of when an acceptable security margin has been reached.

Of course, faster block times do have their costs; stale rates are perhaps the largest, and it is of course necessary to balance the two - a balance which will require ongoing research, and perhaps even novel approaches to solving centralization problems arising from networking lag. Some developers may have the opinion that the user convenience provided by faster block times is not worth the risks to centralization, and the point at which this becomes a problem differs for different people, and can be pushed closer toward zero by introducing novel mechanisms. What I am hoping to disprove here is simply the claim, repeated by some, that fast block times provide no benefit whatsoever because if each block is fifty times faster then each block is fifty times less secure.

[d5000]

OK, thanks for the link (I didn't know it before). After having read it, at a first glance, I think Vitalik is at the same time right and not.

The problem I have with his conclusion is that both risks of short block intervals he mentions - stale blocks and mining centralization - are decreasing security (more precisely: stale blocks decrease the needed "attack cost" at similar hashrate, while added centralization risks are very difficult to measure, but should be clearly negative).

That means that the "security per minute" equation becomes less favourable with shorter block intervals, but at the same time, "finality" can be determined earlier, at least in "normal" conditions where not too many attackers are threatening the network.

My view on the subject is, thus, not really changing - smaller block times are good for chains where smaller payments are dominating - coins where single transactions should be used like "cash". In these cases, attack costs after a few confirmations are much higher than the typical amount that can be "scammed" by a double-spend. But for chains which are more used as a "settlement layer" with big amounts being transferred, I would still prefer longer block times - even if they have an additional "micropayment layer" such as LN, or a short-interval sidechain.

[spartacusrex]

I think the point of a dynamic block time, is that at some point our global network should effectively be operating at light speed with near limitless capacity. 

So if it takes light 0.1 seconds (let's say) to travel around the world.. The fastest time you could possibly send a message through the network would be 0.1s. (Let's ignore quantum entanglement for now  )

A 1 second block time with 0.1s relay delay would cause 10% stales - perfectly acceptable. That would be the target number of stales for the algorithm.

If you could have your coin ready - without needing to hard fork it in - I think it's the logical conclusion of where block time ends up - why not?

All the while, as we reach this nexus point, speeding up block times to add that granularity of information Vitalik mentions without really sacrificing security (since it is strongly linked to the network topology, and whether the network can handle it). Win win.

[HeRetiK]

I think the point of a dynamic block time, is that at some point our global network should effectively be operating at light speed with near limitless capacity. 

So if it takes light 0.1 seconds (let's say) to travel around the world.. The fastest time you could possibly send a message through the network would be 0.1s. (Let's ignore quantum entanglement for now  )

A 1 second block time with 0.1s relay delay would cause 10% stales - perfectly acceptable. That would be the target number of stales for the algorithm.

If you could have your coin ready - without needing to hard fork it in - I think it's the logical conclusion of where block time ends up - why not?

All the while, as we reach this nexus point, speeding up block times to add that granularity of information Vitalik mentions without really sacrificing security (since it is strongly linked to the network topology, and whether the network can handle it). Win win.

Quantumentanglementcantbeusedtotransferinformation!!!111one

On a more serious note though, keep in mind that decreasing block time does not necessarily mean an increase of capacity, unless you sacrifice even more decentralization (that is, on top of latency concerns) to rapid blockchain growth.

[spartacusrex]

Quantumentanglementcantbeusedtotransferinformation!!!111one

Ifyousayso!!!

On a more serious note though, keep in mind that decreasing block time does not necessarily mean an increase of capacity, unless you sacrifice even more decentralization (that is, on top of latency concerns) to rapid blockchain growth.

Absolutely.

Decreasing block time given a constant stale rate is used so that consensus convergence is reached sooner.