Bitcoin Forum
December 17, 2017, 08:17:31 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Proposal: dynamic max blocksize according to difficulty  (Read 2943 times)
stuff0577
Full Member
***
Offline Offline

Activity: 135

More stuff will come.


View Profile WWW
September 08, 2015, 03:17:43 AM
 #21

Most of the proposal are all subjective to much further discussion and test  Grin and all must agree with the one that is most reliable.

This is somehow relevant on the discussion. http://coin-vote.com/poll/55e8a33299baadff0a34acb7 you can share your thoughts in there. cheers

COINVOTE Trying to do some stuff
1513498651
Hero Member
*
Offline Offline

Posts: 1513498651

View Profile Personal Message (Offline)

Ignore
1513498651
Reply with quote  #2

1513498651
Report to moderator
1513498651
Hero Member
*
Offline Offline

Posts: 1513498651

View Profile Personal Message (Offline)

Ignore
1513498651
Reply with quote  #2

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

Activity: 190



View Profile
September 09, 2015, 03:37:16 AM
 #22

Most of the proposal are all subjective to much further discussion and test  Grin and all must agree with the one that is most reliable.

This is somehow relevant on the discussion. http://coin-vote.com/poll/55e8a33299baadff0a34acb7 you can share your thoughts in there. cheers

I hope you realize that polls of this type are of no use. For a hard fork to work it must be based on consensus. Consensus is a very dynamic process, it can change by the minute. First ideally core devs must arrive to it somehow (and even then miners have to accept the changes). If that doesn't happen, several implementations of the bitcoin core will appear (Bitcoin XT is the first). Then miners will start using them if they think they are superior without immediately causing a fork (as in Bitcoin XT that takes a super majority of 75% having mined with it). When the forking actually happens, the minority will be forced to join the majority unless they stubbornly refuse because of ideological concerns. In this case their blockchain will be supporting a weaker new altcoin (its price will plummet because the ones having funds on both coins will sell the weak one in favor of the strong one).

Thanks anyway.
noobtrader
Legendary
*
Offline Offline

Activity: 1260



View Profile
September 09, 2015, 04:55:36 AM
 #23

i dont think blockchain usage always add up at the same speed with the difficulty rise.

i think the more correct approach would be start at 2 then double when blockchain usage excess 75% of capacity, or halved when its less than 25% of capacity. minimum 1  to a max of 32.

EDIT : why max at 32, i heard there is a network limitation on blocksize that even XT or any implementation will need another hardfork to remove this limitation

"...I suspect we need a better incentive for users to run nodes instead of relying solely on altruism...",  satoshi@vistomail.com
99Percent
Full Member
***
Offline Offline

Activity: 190



View Profile
September 09, 2015, 05:06:29 AM
 #24

i dont think blockchain usage always add up at the same speed with the difficulty rise.

i think the more correct approach would be start at 2 then double when blockchain usage excess 75% of capacity, or halved when its less than 25% of capacity. minimum 1  to a max of 32.

EDIT : why max at 32, i heard there is a network limitation on blocksize that even XT or any implementation will need another hardfork to remove this limitation
Your approach is like BIP Upal. Unfortunately miners can manipulate the metrics involved: tx per block and sum(tx fees). So I think these types of proposals are of no use. We might as well go directly to BIP100 to see what miners really want.

Again, if miners can be coerced into only accepting tx that have appeared it the mempool somehow this might work, but I cannot think of a way to enforce this.
Pages: « 1 [2]  All
  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!