On January 24, the Bitcoin blockchain transaction queue was significantly backed up with unconfirmed transactions. At the peak of the backlog, the mempool showed over 67,000 unconfirmed transactions. Following this event Bitcoin developer Lukejr has revealed his latest Github BIP proposal asking to lower the block size even more.
Bitcoin Developer Lukejr Proposes to Decrease the Block Size
Over the past couple of years, debate and controversy has been thick concerning the Bitcoin block size cap of 1MB per block. There have been many disagreements on whether or not the block size should be increased. The argument has divided the community significantly where one side looks to scale Bitcoin off-chain, and the other side believes an on-chain solution with a removal the block size cap is necessary. Throughout this period the backlog within the Bitcoin mempool has grown considerably having people waiting hours if not days for one confirmation.
On January 24 the backlog once again grew significantly with over 60 thousand unconfirmed transactions according to blockchain explorers. Now as the topic of debate becomes more ferocious as Bitcoin developer and Blockstream contractor Lukejr has proposed to shrink the block size to 300 kilobytes. Lukejr states via Github that the block size should be reduced to a “safe value, and gradually increased over time, eventually expanding beyond the current limits.”
“The current rate of blockchain growth is demonstrably too high for many users,” explains Lukejr’s BIP proposal. “Full node count and percentage continues to drop (with the most-cited reason being blockchain-size related); miners are de-facto skipping validity checking of blocks before mining on top of them; and the total cost to sync a new node for the first time is growing significantly faster than technology improvements to reduce such costs.”
Blockchain Size Too Difficult for Full Node Operators Says Lukejr
The primary motivation for the new proposal is because of the Bitcoin blockchain’s vast size. Currently, the blockchain is getting close to reaching 100 gigabytes, and Lukejr and others believe that full node operators will have difficulty maintaining its size increase. There are roughly 5,000 nodes that are accounted for, and the full node count has decreased over time. However, not all nodes make themselves known, and the official node number may be higher than many perceive.
Of course, the new proposal has rustled the crowd quite a bit, and many community members across social media seemed very surprised. One Reddit user writes:
Setting the block size to 300 KB will have huge market consequences! Lightning is not ready yet! We need to push for Segwit and Lightning. This should be the priority. Without Lightning and Segwit, 1MB blocks are not enough even TODAY.
Lightning Believed to Be the Solution, but Segwit Adoption Remains Stagnant
Within the Github proposal, Lukejr’s main rationale to implement a block size decrease is the Lightning Network’s speculative abilities. “Once Lightning is widely implemented as well-tested, at least microtransactions are likely to gain a huge improvement in efficiency, reducing legitimate usage of block sizes well below 300k naturally – that is frankly when I first expect this proposal to be seriously considered for activation,” details Lukejr’s latest BIP.
As reported by the Lightning Labs developers a few weeks ago, Segregated Witness (Segwit) is important for Lightning implementation. However currently, only 24 percent of the network so far has signaled support for Segwit and alternate client adoption such as the Bitcoin Unlimited node count has been steadily increasing. A version of the Lightning Network Daemon has been released but is in its earliest stages and mainly for developers. A Lightning implementation may not happen for a very long time as Segwit adoption is still having trouble gaining consensus.
What do you think about Lukejr’s BIP proposal to decrease the block size? Let us know in the comments below.
Images via Blockchain.info, Twitter, and Shutterstock.