shopify analytics tool

Bitcoin Casino

0 Members and 1 Guest are viewing this topic.



Segregated Witness: The Right Answer to the Wrong Question
« on: December 30, 2015, 07:02:49 AM »
Segregated Witness: The Right Answer to the Wrong Question

Segregated Witness, the proposal put forth by Blockstream developer Dr. Pieter Wuille, has been trumpeted as a block size scaling solution that gets around the difficult scenarios associated with increasing the block size utilizing a hard fork.

But the problem is that, while Segregated Witness does provide benefit to the code, it misses one of the fundamental problems bitcoin has been experiencing: there are no true, long-term solutions on how to scale Bitcoin for mass-adoption. Instead, the focus has been on developing solutions on top of bitcoin. Further, the stigma associated with a hard fork acts as a hindrance to further development.

Segregated Witness 101

When looking at the block size problem, it helps to think of it as a bucket of marbles. The 1MB block size can carry a certain number of transactions the same as a bucket can only carry so many marbles. As more transactions try to fit in the block, naturally some are unable; they fall out.

What Segregated Witness does is remove the signature from the transaction and stores it in a separate data structure. By removing the signature from the transaction, the size of the that transaction decreases.

In his blog post about Segreated Witness, Gavin Andresen said:

for example, the simplest possible one-input, one-output segregated witness transaction would be about 90 bytes of transaction data plus 80 or so bytes of signature—only those 90 bytes need to squeeze into the one megabyte block, instead of 170 bytes. More complicated multi-signature transactions save even more.”

Using our marble analogy, in this most basic of examples, each marble is shrunk down by approximately 47%. In essence, we find that we can have 47% more one-to-one transactions in the block size.

But at its core, Segregated Witness is compression and optimization of the code; it’s not a true scaling feature. There remains only 1MB of block space and when that fills, the problems that the network are currently experiencing come back again.

The Hard Fork Stigma

Bitcoin is at a crossroads right now. On one hand, there is a significant push to keep the blocksize at the arbitrary 1MB size—there has been no data presented suggesting this is the optimal size. And on the other hand, there is the need to prove that bitcoin can be scaled to a point where it can handle transactions from a growing user base.

The problem has to do with a stigma associated with implementing a change via a hard fork.

The concern with a hard fork is that it results in two parallel chains where the winner takes all and the losers are harmed. It can result in double spends and uncertainty as to which chain is going to win. When dealing with a market cap of over $6 billion, concern about that is certainly warranted.

But the problem is that inaction—or a decision not to act—results in the same outcome. The inability for the community to get behind a hard fork to scale bitcoin even to 2MB, as proposed by Jeff Garzik in BIP 102, can create an event as chaotic as a hard fork.

In an email to the Bitcoin Core Dev team, Garzik postulated that by not scaling bitcoin and instead pushing for higher transaction fees, it would create an economic change event, which “is a period of market chaos, where large changes to prices and sets of economic actors occurs over a short time period.”

Both are problematic and can cause significant damage to the community. However, what a proposal like BIP 102 does is get past the stigma of a hard fork and allow the developers to do what they’re good at: analyze data and make decisions based on it.

There is no doubt that there is a need to scale bitcoin. While Segregated Witness is, fundamentally, a great move, it doesn’t solve the problem that there is a stigma associated with hard forking the code, which will be an inevitable necessity to further scale the protocol.

Segregated Witness Should Hard Fork

In a series of Tweets, BitGo Engineer Jameson Lopp argued that node operators have a responsibility to keep current with software that is responsible for securing people’s money. In essence, if you’re going to run a node that is securing the Bitcoin network, which inherently is securing people’s money, the tech needs to be upgraded.

To offer the necessary data that developers need, Segregated Witness should be pushed through as a hard fork, where those that do not upgrade are left behind. Segregated Witness is not controversial; it’s exactly what Bitcoin needs. Therefore, it would show what a hard fork is like and shake out some of the nodes that are not going to update their software.

There’s no doubt that scaling Bitcoin is a difficult conversation; however, it is going to continue coming up. Even with Segregated Witness, the network will reach a point where it needs to scale again. Compressing data can only work so much. At some point, you can’t make the marbles any smaller and you have to go find a bigger bucket.

The post Segregated Witness: The Right Answer to the Wrong Question appeared first on Bitcoin Magazine.

Source: Segregated Witness: The Right Answer to the Wrong Question