Bitcoin Forum
November 19, 2024, 01:40:17 AM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [2017-04-06]No Blocksize Increase Needed for Years, Argues Bitcoin Core Dev  (Read 491 times)
zhangswujip (OP)
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250



View Profile
April 06, 2017, 04:16:29 AM
 #1

A Reddit discussion on increasing the bitcoin block size clarified why many are opposed to the bitcoin hard fork.

A poster asked Bitcoin Core developers to explain their vision on increasing the block size. The poster claimed to be “very strongly anti-Bitcoin Unlimited (BU) but mildly in favor of bigger bitcoin blocks. BU has been proposed as a solution to scaling the bitcoin network that will hard fork the bitcoin blockchain.

“Please, educate me on your view as to if the max block size should ever change, if not why not, if yes how,” the poster asked.

Block Size Change Needed

In response, a luke-jr, a bitcoin core developer, recognized the need to eventually increase the bitcoin block size. He said people are not running nodes since the full node percentage is far below the safe 85%. “If you ask people why they don’t run a node, the reason is often tied to the block size,” luke-jr wrote.

In addition, miners are skipping the validation task due to the amount of time it now takes to verify large blocks, he added.

Core developers have conceded all possible compromises for increasing the block size, luke-jr noted. Even Segregated Witness (a solution to address the bitcoin network scalability challenge that has garnered support from many bitcoin users), is being proposed with a block size increase to as much as 3 MB, luke-jr noted.

Urgency Not Needed

Luke-jr does not think an increase in the block size is needed at the present time. A 1 MB block size is sufficient for the near term. When that size no longer suffices, the Lightning protocol (a system that allows faster transactions by doing them off of the network chain) will likely be in production, improving blockchain efficiency. It could reduce 1 MB block usage to around 10,000.

Luke-jr conceded that a block size increase will eventually be needed, but this is several years if not decades away. The scalability problems could resolve themselves by that time.

The decision to support a hard fork, for its part, is one that the community makes, luke-jr noted, and not a niche group, be it miners, developers or anyone else. The majority of the user community has rejected hard fork proposals.

The developer further noted that he himself proposed a minimal block size increase in seven years, only to meet “significant opposition.”

Also read: The first end-to-end bitcoin micropayment test on Lightning Network is successful

No To A Hard Fork

While the Bitcoin Core team has invested significant time in research and development in a future hard fork, the solutions at the present time are unsafe.

In response to luke-r, one Reddit poster noted that they don’t run nodes on account of the hassle it requires, and that 300 KB blocks or a 1 MB block won’t change this. The greater factor in falling node count is the emergence of usable thin clients such as Electrum and MyCelium.

Another poster noted that block size is not the reason people don’t run nodes; it is the lack of incentive for doing so.

Still, another poster pointed out that incentives do exist when making regular transactions, but they were unsure that increasing the block size to as much as 5 MB would increase the node count.
link:https://www.cryptocoinsnews.com/a-hard-fork-isnt-the-only-way-to-address-bitcoin-scalability/
odolvlobo
Legendary
*
Offline Offline

Activity: 4508
Merit: 3419



View Profile
April 06, 2017, 07:15:19 AM
 #2

You can safely ignore what luke-jr believes. Nobody takes him seriously, not even other developers on Core.

Join an anti-signature campaign: Click ignore on the members of signature campaigns.
PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3080



View Profile
April 06, 2017, 08:09:10 AM
Last edit: April 06, 2017, 08:23:52 AM by Carlton Banks
 #3

I have some sympathy for Luke-jr's various positions, despite not always agreeing with him.


He's right that the current blocksize is coping with present demand, and that 1MB can serve near-term demand to some extent. We only have to look at what happens when the spam attacks stop; daily transaction volumes fall comfortably back down between 250,000 and 275,000 tx per day. Sometimes lows closer to 200,000 have been reached, although that never lasts long.

The fact is that the fee market for on-chain transactions is important. When blocks are not quite full, the miners can decide which transaction they process, and in turn the fees they are willing to accept. Today's 6.25 BTC bock reward helps the miners to decide in the users favour, but I think it's been amply demonstrated recently that miners have a penchant for taking decisions against users interests, in spite of likely damage to their own interests in the mining market (one wonders why they would choose self destruction to hurt the users' interests)

But, with permanently full blocks, the users must fight to compete for the blockspace with their fees. This creates a secondary incentive effect also; the miners lose profit margins to their competitors if they decide they don't care so much about fees. It's a positive feedback loop between user fighting for blockspace, and the miners fighting for profits.

When blocksize is so high that miners can afford to ignore transactions (because the profit margin is in the block reward, not the tiny fees they could earn), the Bitcoin system starts to lose this property of economic incentives dictating fees. Users don't need to fight for blockspace, because there's plenty of space going unused. But miners don't have to provide the space, they won't earn much from it anyway. The only reason miners might include adequate transactions in blocks under those circumstances is plain goodwill, and there's a danger a negative feedback loop of disincentives could develop. Even now, with fairly full blocks, certain pools still cynically produce entirely empty blocks, so there is evidence that maximum competition among miners is vital to the Bitcoin network's smooth running.

You can safely ignore what luke-jr believes. Nobody takes him seriously, not even other developers on Core.

Explain why, and which developers feel that way. Provide evidence, not assertions. Why should we take your unsupported proclamations as facts?

I understand why people criticised Luke-jr's 300 KB blocksize proposal.

Luke was trying to be too clever for the audience, and it backfired on him rather badly. His idea was that no-one would accept 300 KB today, but because of the effects of time on the size of blockchain, maybe people would begin to accept his point that even 1MB is too big for today, but maybe in 2 years or 4 years from now. Because in 2 or 4 years, Luke's blocksize increase schedule would have decreased to only 400-600 KB, and Luke expected the smaller decrease would become more appealing once everyone has had 2 or 4 years more to think about it. (Luke's proposal finally gives a bigger blocksize than 1MB in 2024)

So there is a lot of psychology involved in Luke's proposal, and I think that's where it unwinds. Like I say, he was simply trying to be too clever. But who knows, maybe Luke's judgement that people will begin to take his proposal more seriously once 2 years (~120 GB of full blocks) or 4 years (~240 GB of full blocks) passes will come true. That would mean a 240GB blockchain in 2019, and a 360GB blockchain in 2021 (and that's all assuming we still have a 1MB blocksize limit at that point), maybe that would motivate everyone (especially considering that Segwit will likely be activated by then, we may as well multiply those figure by 4 in which case).

Will more efficiency tweaks to the Bitcoin software, better internet infrastructure and cheaper/faster storage be enough, or will the hard limits of those factors be enough for people to consider reducing the blocksize? I guess only time will tell.

Vires in numeris
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!