Bitcoin Forum
May 25, 2019, 06:36:57 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: 1 second block time - what will happen ? Pros/Cons  (Read 346 times)
Rizvi91
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
September 22, 2018, 03:16:13 AM
 #1

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?
1558766217
Hero Member
*
Offline Offline

Posts: 1558766217

View Profile Personal Message (Offline)

Ignore
1558766217
Reply with quote  #2

1558766217
Report to moderator
1558766217
Hero Member
*
Offline Offline

Posts: 1558766217

View Profile Personal Message (Offline)

Ignore
1558766217
Reply with quote  #2

1558766217
Report to moderator
1558766217
Hero Member
*
Offline Offline

Posts: 1558766217

View Profile Personal Message (Offline)

Ignore
1558766217
Reply with quote  #2

1558766217
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558766217
Hero Member
*
Offline Offline

Posts: 1558766217

View Profile Personal Message (Offline)

Ignore
1558766217
Reply with quote  #2

1558766217
Report to moderator
1558766217
Hero Member
*
Offline Offline

Posts: 1558766217

View Profile Personal Message (Offline)

Ignore
1558766217
Reply with quote  #2

1558766217
Report to moderator
ranochigo
Legendary
*
Offline Offline

Activity: 1680
Merit: 1132

Somewhat inactive.


View Profile WWW
September 22, 2018, 04:39:16 AM
Merited by Foxpup (3), OgNasty (1)
 #2

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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1652
Merit: 1767

Use SegWit and enjoy lower fees.


View Profile WWW
September 22, 2018, 06:36:33 AM
 #3

Too many orphan to the point nodes confused which block is the longest/have their own longest chain (have most PoW) which makes the coins is not usable (or require extremely high confirmation to be secure in best case).
You might want to see https://www.fastcoin.ca/ which have 12s block time and see how bad is it.

Additionally, even latency, handshake and receive/sent signal between nodes can reach 1 second if one of them nodes have slow internet connection. Zero-confirmation (with checking to several nodes/explorer to see any double-spend attempt) is better option.

nc50lc
Sr. Member
****
Online Online

Activity: 602
Merit: 402


Self-proclaimed Genius ㊙️


View Profile WWW
September 22, 2018, 06:38:58 AM
 #4

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.

███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
#1
███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
BTC 
  ●
   BTC
  BTC   
.
    ▄▄▄▀▀▀▀
 ▄██▀
███        ▄▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄▄▄
▀███▄▄▄▄▀▀▀                 ▀▀▄▄
  ▀▀▀██████████████████████████▀
   ▄█▄     ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
    ▀▀██▄▄█▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀▀
      ▄  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
      ▀██▄  ▄▀▀▀▀▀▀▀▀▀▀▀▀▄
        ▀█▀██████████████▀▀
         ▀█▄▄ ▄▄▄▄▄▄▄▄▄▄
            █▀▄▄▄▄▄▄▄▄▄▄▀
             ▀▀▄▄▄▄▄▄▄
.
     BTC
  BTC   
  ●
  BTC   
███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
aleksej996
Sr. Member
****
Offline Offline

Activity: 476
Merit: 326


Do not trust the government


View Profile WWW
September 22, 2018, 12:33:17 PM
Merited by Wind_FURY (3), Foxpup (2), d5000 (1)
 #5

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
Legendary
*
Offline Offline

Activity: 1358
Merit: 1361


BtcBoss


View Profile
September 23, 2018, 02:00:12 AM
 #6

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.

.BitDice.               ▄▄███▄▄
           ▄▄██▀▀ ▄ ▀▀██▄▄
      ▄▄█ ▀▀  ▄▄█████▄▄  ▀▀ █▄▄
  ▄▄██▀▀     ▀▀ █████ ▀▀     ▀▀██▄▄
██▀▀ ▄▄██▀      ▀███▀      ▀██▄▄ ▀▀██
██  ████▄▄       ███       ▄▄████  ██
██  █▀▀████▄▄  ▄█████▄  ▄▄████▀▀█  ██
██  ▀     ▀▀▀███████████▀▀▀     ▀  ██
             ███████████
██  ▄     ▄▄▄███████████▄▄▄     ▄  ██
██  █▄▄████▀▀  ▀█████▀  ▀▀████▄▄█  ██
██  ████▀▀       ███       ▀▀████  ██
██▄▄ ▀▀██▄      ▄███▄      ▄██▀▀ ▄▄██
  ▀▀██▄▄     ▄▄ █████ ▄▄     ▄▄██▀▀
      ▀▀█ ▄▄  ▀▀█████▀▀  ▄▄ █▀▀
           ▀▀██▄▄ ▀ ▄▄██▀▀
               ▀▀███▀▀
        ▄▄███████▄▄
     ▄███████████████▄
    ████▀▀       ▀▀████
   ████▀           ▀████
   ████             ████
   ████ ▄▄▄▄▄▄▄▄▄▄▄ ████
▄█████████████████████████▄
██████████▀▀▀▀▀▀▀██████████
████                   ████
████                   ████
████                   ████
████                   ████
████                   ████
████▄                 ▄████
████████▄▄▄     ▄▄▄████████
  ▀▀▀█████████████████▀▀▀
        ▀▀▀█████▀▀▀
▄▄████████████████████████████████▄▄
██████████████████████████████████████
█████                            █████
█████                            █████
█████                            █████
█████                            █████
█████                     ▄▄▄▄▄▄▄▄▄▄
█████                   ▄█▀▀▀▀▀▀▀▀▀▀█▄
█████                   ██          ██
█████                   ██          ██
█████                   ██          ██
██████████████████▀▀███ ██          ██
 ████████████████▄  ▄██ ██          ██
   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ██          ██
             ██████████ ██          ██
           ▄███████████ ██████▀▀██████
          █████████████  ▀████▄▄████▀
[/]
DarkStar_
Legendary
*
Offline Offline

Activity: 1344
Merit: 1774



View Profile WWW
September 23, 2018, 02:41:48 AM
 #7

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
Legendary
*
Offline Offline

Activity: 1241
Merit: 1005


..like bright metal on a sullen ground.


View Profile
September 24, 2018, 06:38:44 PM
Merited by d5000 (1)
 #8

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
Legendary
*
Offline Offline

Activity: 1568
Merit: 1539


My hat is in storage. https://ibb.co/YLkPgXb


View Profile
September 24, 2018, 08:41:03 PM
Merited by HeRetiK (1), Coin-1 (1)
 #9

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.

......
.L I V E C O I N . N E T.
.
..PROFITBOX..
██  █████████████████████████
  █████████▄      ▄██████████
█████████████▄  ▄████████████
    █████████████████████████
  ██████████▀    ▀█ ▀████████
████  █████▀  ▄▄  ▀█  ▀██████
  ████████▀  ▄██▄  ▀█   ▀████
    ██████   ▀██▀   ██   ████
  █████████▄      ▄██████████
██  █████████▄  ▄████████████
  ███████████████████████████
██  █████████████████████████
  █████████████████████▀ ███
█████████████████████▀   ███
    █████████████▀     ████
  █████████████▀   ██    ████
████  █████▀     ██    ████
  ███████▀   ██    ██    ████
    █████    ██    ██    ████
  ███████    ██    ██    ████
██  █████    ██    ██    ████
  ███████████████████████████
.....
spartacusrex
Hero Member
*****
Offline Offline

Activity: 708
Merit: 524



View Profile
September 24, 2018, 10:25:31 PM
Merited by bones261 (2)
 #10

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 ).

Life is Code.
ranochigo
Legendary
*
Offline Offline

Activity: 1680
Merit: 1132

Somewhat inactive.


View Profile WWW
September 25, 2018, 01:09:27 PM
 #11

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
Legendary
*
Offline Offline

Activity: 2100
Merit: 1469


Decentralization Maximalist


View Profile
October 03, 2018, 03:41:26 AM
 #12

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
Hero Member
*****
Offline Offline

Activity: 708
Merit: 524



View Profile
October 03, 2018, 11:30:52 AM
 #13

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...

Quote
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.

Life is Code.
d5000
Legendary
*
Offline Offline

Activity: 2100
Merit: 1469


Decentralization Maximalist


View Profile
October 03, 2018, 11:56:21 AM
 #14

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
Hero Member
*****
Offline Offline

Activity: 708
Merit: 524



View Profile
October 04, 2018, 10:10:09 AM
 #15

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  Wink)

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.

Life is Code.
HeRetiK
Legendary
*
Offline Offline

Activity: 1120
Merit: 1049


the forkings will continue until morale improves


View Profile
October 04, 2018, 01:22:29 PM
 #16

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  Wink)

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
Hero Member
*****
Offline Offline

Activity: 708
Merit: 524



View Profile
October 04, 2018, 04:40:46 PM
 #17

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.

Life is Code.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!