Bitcoin Forum
May 06, 2024, 05:57:22 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Blocksize vs time between blocks  (Read 258 times)
yshurik (OP)
Newbie
*
Offline Offline

Activity: 9
Merit: 4


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?
BitcoinCleanup.com: Learn why Bitcoin isn't bad for the environment
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715018242
Hero Member
*
Offline Offline

Posts: 1715018242

View Profile Personal Message (Offline)

Ignore
1715018242
Reply with quote  #2

1715018242
Report to moderator
HeRetiK
Legendary
*
Offline Offline

Activity: 2926
Merit: 2091


Cashback 15%


View Profile
October 27, 2017, 01:13:33 PM
Merited by ABCbits (1)
 #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.

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
yshurik (OP)
Newbie
*
Offline Offline

Activity: 9
Merit: 4


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:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!