A newly introduced proposal for how the bitcoin network can be scaled to handle greater transaction volumes is gaining traction in its once divided development community.
Called segregated witness, the proposal was debuted by Blockstream co-founder Pieter Wuille at Scaling Bitcoin Hong Kong on 7th December. Arriving to general acclaim, it has already been hailed as a “turning point” by technologist Andreas Antonopoulos and positioned by Bitcoin Core developer Greg Maxwell as a solution that could provide a fourfold increase in capacity to the network in a “short time frame”.
Most notable about segregated witness is that, unlike other proposed bitcoin improvements, it can be introduced to the network as a soft fork, meaning that it would avoid forcing all those running the bitcoin software to upgrade their clients in near-unison, thereby reducing the risk an upgrade splits the bitcoin blockchain.
That this could be accomplished has come as a surprise to many in the community, which has been embroiled in debate on how to scale the network in line with the ambitions of a startup sector which has attracted nearly $1bn in investments in 2015.
Wuille himself said in his talk that he had dismissed segregated witness as “non-viable” until recently, when it was revealed that it can be implemented as either a hard or soft fork, and there is growing consensus in the community that a soft fork is a preferred path to a solution.
Even more objective observers such as Digital Asset Holdings senior developer Miron Cuperman told CoinDesk:
“There’s consensus that a soft fork is better. You can deploy it much sooner, because you just need the large majority, and in a hard fork you have to upgrade everyone. It’s a straightforward idea, the concept is not that risky or complicated.”
At an open developer meetup hosted at Cyberport in Hong Kong today, the solution was widely seen positively, though a certain minority expressed their concern that it would delay a hard fork – a process they believe will eventually be needed for later scaling solutions.
Others, such as developer and hosted mining service provider Jonathan Toomim, argued that the segregated witness proposal was perhaps best implemented via a hard fork to improve its design and overall functionality.
“My attitude is it’s ugly and awkward and that this is not a way that’s intuitive. I just see that they’re putting segregated witness here because it will be a soft fork, but that is better off as a hard fork, where it will be more elegant and safer,” he told CoinDesk.
The segregated witness code has already been introduced as a hard fork in Sidechain Elements, a sandbox in which developers can experiment with its proposed sidechains functionality and features.
Nonetheless, Wuille said he will move forward with formalizing the idea as a bitcoin improvement protocol (BIP) so it can be more widely discussed by the larger bitcoin community.
He told CoinDesk expects this to be completed in a “number of weeks”, though the exact timeline is not yet clear.
The segregated witness solution
Segregated witness is perhaps best described as a novel workaround to the block size issue that affects how certain network variables are counted toward block size.
In bitcoin, transactions include one or more input fields showing where the funds come from, one or more output fields indicating where they’re going and a signature that validates that the owner had the ability to execute the transaction.
“Now signatures go into the ‘from’ field,” Lightning Network developer Tadge Dryja explained. “[In segregated witness] the signature is separate.”
More specifically, segregated witness takes the signature out of the transaction and puts the data into a Merkle tree in the coinbase component of the transaction, or the input of a generated transaction. This change would make transactions appear smaller to current nodes on the network, so that more could be included in a bitcoin block, even if blocks are still limited to 1MB by protocol rules.
“If the signatures would add 0.75MB [of capacity] to a block to a 1MB block, it would now be equivalent to 4MB,” developer Doug Roark said, echoing the description put forth by Maxwell and Wuille.
Dryja noted that a soft fork would mean parties running older versions of Bitcoin Core could still use bitcoin, even if it would appear to them as if users were sending money without signatures.
“Nodes today only see the transaction Merkle root and the transaction data, which today includes the signature,” David Vorick, CEO of distributed storage startup Nebulous, explained. “If segregated witness were to be implemented, today’s nodes would not see the transaction signature data, because it would be in a storage area that they don’t recognize.”
Older nodes that have not updated their software would still however be able to monitor the network, though it would appear as if certain parties are behaving abnormally.
“[In a soft fork] nothing changes, my coins are still the same, which is different than everyone must upgrade their software or it stops working,” Dryja said. “Things start looking really weird, but they can ignore these transactions.”
Tangential benefits
Another proposed benefit to segregated witness was that it would allow for other scaling proposals to be more effectively implemented.
Dryja, for example, told CoinDesk that segregated witness would allow his proposed version of payment channels to reach their maximum efficiency based on projections he presented on day two of the event.
Segregated witness would also fix transaction malleability, a longstanding issue on the network whereby when transactions are signed, the signature does not cover all the data in the transaction.
“Without segregated witness, if one of us puts money into the address, the other party can resign the transaction, changing the transaction ID,” Dryja indicated. “When you resign in segregated witness, the signatures are not in the transactions.”
Transaction malleability is perhaps most widely known as the source of controversy during the collapse of bitcoin exchange Mt Gox, which sought to claim the issue was the cause of withdrawal issues before its collapse.
Mining problems
However, fixing transaction malleability this way could have the side effect of at least temporarily destabilizing other parts of the network.
Toomim was the most vocal in his concerns that the design of segregated witness could have an impact on the mining community that has perhaps not been properly evaluated.
Of issue, Toomim said, is that miners use coinbase messages in blocks to include vital information for their business. This includes votes on various BIP proposals and bookkeeping details such as the fact they mined the block in which the coins were included.
“It’s co-opting a resource that is already being used for a lot of things, and that resource was not designed for that,” he argued.
Since the coinbase is also the first part of data blocks compiled by miners today, Toomim said that adding signatures to this field would make it dependent on other information in the block, which could potentially complicate mining software.
Overall, he said he was excited about the idea, but that these effects could be averted if segregated witness was implemented as a hard fork.
With this design, he explained, block headers could contain merkle roots wherein one side of the tree would contain transactions, and the other would contain signature data, creating a mirrored structure that would be more easily scaled. By comparison, as a soft fork, the merkle tree containing transactions would be added to the coinbase.
While a minority view, the comments could gain relevance given the emphasis developers at the event put on seeking solutions for a block size that would not affect mining profitability.
Political football
But while segregated witness has attracted enthusiasm, there is some suggestion it could become the focal point for a larger discussion on whether the community needs to solve its scalability issues with a hard fork for academic reasons.
Such a view was most loudly voiced by Core developer Jeff Garzik in his talk on BIP proposals on day one of Scaling Bitcoin. There, he made the argument that there is a lack of data on how a distributed economic system like bitcoin would react when faced with this challenge.
Under any proposal, changing the cap on block size would require a hard fork, meaning that such instances are likely to occur, perhaps regularly, as bitcoin scales. Given this, some were more blunt in their criticism of the reluctance to pursue this path.
“The Core devs haven’t done a hard fork. They’re afraid of it. They need to get over it. I don’t think the hard fork-soft fork is really an issue,” Toomim said.
Dryja’s opinion represented the more moderate view that any chosen scaling initiative should provide additional necessary technical fixes to the network.
“They’ve wanted to fix malleability for years,” he said. “We want to have more capacity. If we’re gonna make this change, why don’t we also fix a bunch of other stuff?”
For more information on segregated witness, read Wuille’s full slideshow below:
Magic image via Shutterstock