Bitcoin Forum
September 23, 2018, 07:20:39 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Blocksize vs time between blocks  (Read 185 times)
yshurik
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
October 27, 2017, 09:55:32 AM
 #1

Related to a lot of discussions about the increasing of block sizes in bitcoin.
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?
1537730439
Hero Member
*
Offline Offline

Posts: 1537730439

View Profile Personal Message (Offline)

Ignore
1537730439
Reply with quote  #2

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

Posts: 1537730439

View Profile Personal Message (Offline)

Ignore
1537730439
Reply with quote  #2

1537730439
Report to moderator
1537730439
Hero Member
*
Offline Offline

Posts: 1537730439

View Profile Personal Message (Offline)

Ignore
1537730439
Reply with quote  #2

1537730439
Report to moderator
HeRetiK
Hero Member
*****
Offline Offline

Activity: 868
Merit: 718


the forkings will continue until morale improves


View Profile
October 27, 2017, 01:13:33 PM
 #2

Related to a lot of discussions about the increasing of block sizes in bitcoin.
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?

Any solution that adjusts dynamically based on the amount of transactions is likely to be exploited, as spam transactions are easily created. Dynamically adjusting block times would require dynamically adjusting network difficulty, which even in a relatively simple use case such as BCH's EDA already prove to lead to problematic side effects. Additionally you'd need to find a new metric on how to define difficulty periods based on hashrate and to dynamically adjust block rewards, as otherwise you'd unwillingly increase Bitcoin's issuance rate.

Either way, as it would require some deep changes in the current consensus it would likely require a hardfork.

The approach as you describe it sounds kinda familiar to me, but I don't think Core ever considered it.

yshurik
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
October 27, 2017, 01:23:19 PM
 #3

Related to a lot of discussions about the increasing of block sizes in bitcoin.
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?

Any solution that adjusts dynamically based on the amount of transactions is likely to be exploited, as spam transactions are easily created. Dynamically adjusting block times would require dynamically adjusting network difficulty, which even in a relatively simple use case such as BCH's EDA already prove to lead to problematic side effects. Additionally you'd need to find a new metric on how to define difficulty periods based on hashrate and to dynamically adjust block rewards, as otherwise you'd unwillingly increase Bitcoin's issuance rate.

Either way, as it would require some deep changes in the current consensus it would likely require a hardfork.

The approach as you describe it sounds kinda familiar to me, but I don't think Core ever considered it.

interesting, maybe a bit different approach, not dynamically adjusting network difficulty at all, but having an multiplier/divider like from 1 to 5, so max=5 means that pool of transactions is too high (like more 100K), so with miners will have choice - mine "standard" block in 10 minutes and get 12btc or mine "fast" block in 2 minutes but get 12/5 btc.
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!