Scaling Bitcoin Hong Kong returned for day two today, with presentations showcasing the breadth of ideas for how bitcoin’s transaction processing capacity can be improved and the speed at which some have consolidated into plans of action.

Audience enthusiasm was more pronounced early in the day as proposals for longstanding ideas such as payment channels via the Lightning Network were demonstrated with renewed clarity, while developer Pieter Wuille wowed with segregated witness – a proposal for scaling the bitcoin blockchain without requiring a hard fork.

A change to the bitcoin protocol that is not backwards compatible, the hard fork has emerged as a contentious issue given what some in the community view as its potential risks. Effectively, a hard fork would require all members of bitcoin’s disparate ecosystem to upgrade their software in near unison, with the implied risk that any divisions could create two versions of the bitcoin blockchain.

Still, excitement for Wuille’s proposal to avoid a hard fork was balanced by an equally embraced appeal by Bloq founder and core developer Jeff Garzik for the bitcoin community to pursue a solution that requires a hard fork, in part to remove fear over the issue.

In a talk aimed at breaking down the pros and cons of various increases to the size of blocks on the bitcoin blockchain, Garzik voiced his belief that failure to meet the challenge head on could have a lasting negative impact on bitcoin’s perception.

Garzik said:

Garzik’s political appeal was balanced by an equally strong academic appeal in which he said that a block size increase alone would not be enough, and that the community would need to continue to drive scaling solutions forward regardless.

Still, he said he believes that leaving the network unchanged could cause bitcoin businesses to pursue paths that might split the blockchain, while noting that the tech consensus is any increase above 2MB is risky.

“I think we need a small bump [in block size] now to gather field data. You can theorize and test and simulate but the real world is the best test lab,” he continued.

Moving further along the development horizon, talks by SolidX chief scientist Bob McElrath, Hebrew University’s Yonatan Sompolinsky and National University of Singapore’s Loi Luu aimed to illustrate larger issues with the bitcoin network when viewed through the lens of distributed computing systems.

The most well-received talk of the day was given by Blockstream co-founder Pieter Wuille, in which the developer made the case that the block size could be increased with only a soft fork to the network, should changes be made to how transaction signatures are handled.

“What if we can redesign bitcoin from scratch?” Wuille asked. “What if we were designing an altcoin? There’s no way you would do it the way bitcoin did.”

Wuille began the talk by breaking down bitcoin transactions, explaining that they are the sum of inputs and outputs, and that the input contains a signature meant to prove the owner. In Wuille’s model, the witness, or signature, would be separated from the transaction so that adding it would be optional.

“Today, they are inherent in the transaction, you can’t remove it. With segregated witness this would be possible when you give to lightweight wallet or dropped from the blockchain after year. We’ll remember the transactions, but not who authorized them,” he said.

Overall, the proposal characterizes the current issues with the bitcoin network as its validation and data storage processes. By changing how the network handles signature data, it would increase the bitcoin blocksize to 1.75MB with current transactions, and to 4MB should the majority of these transactions be multisig.

"We can increase the block size with a soft fork. This is my proposal," Wuille concluded.

The statement was met with applause from the audience, excitement that was mirrored by Wuille who was sometimes unable to contain his enthusiasm onstage.

Elsewhere, an impromptu roundtable discussion between prominent bitcoin developers and members of bitcoin’s China-based mining community, held under Chatham House Rules, aimed to close the gap in conversation on display in day one’s talks.

Held over two hours and described by one participant as a "12-hour United Nations meeting", the talks were often strained by a language gap, but found both sides working toward understanding how they view issues facing the bitcoin network.

For example, bitcoin’s developers sought to determine the underlying metrics affecting miners' bottom lines in an effort to assess how any solution would affect their profitability, and by extension, their ability to secure the bitcoin network and continue processing transactions.

Metrics included orphan rates, both in optimal and stress conditions, as well as the competitive edge miners would be willing to allow their competitors in any solution.

Much of the talks focused on Peter Wuille’s segregated witness proposal, which suffered in translation but was ultimately communicated as a way to compress data on the bitcoin blockchain. Nuances such as how the block size would adjust to handle 4MB only for multisig transactions were perhaps lost in translation.

Talks were also strained as developers demonstrated a desire to craft rules into the network that would allow it to scale for global use, while the comments of miners often displayed a more practical approach that was willing to accept imperfect realities in the system.

“Don’t worry about it,” said one miner during a conversation on how rented hashing power could be used by bad actors to perform a 51% attack on the network. “Why would I spend money to buy the gun to kill myself?”

Also on display was a verbal game of hot potato in which neither miners nor developers wanted to be seen as being the primary decisionmakers for the network.

“We as developers do not want to be seen as in control of bitcoin,” said one developer, who noted that the technology is highly regulated in Western nations.

The group did ultimately decide on metrics by which a proposal could be judged, including latency between China-based nodes and global nodes and how well it levels the playing field between small and large miners.

Though the group started with the intent to declare a loose consensus to the wider global bitcoin community, it ultimately settled on less concrete goals, such as having core developers engage with the China-based community on its popular WeChat forums.

The day’s biggest winner among alternative scaling solutions that don't impact block size was perhaps the Lightning Network, as its two lead developers successfully made the case that the proposal is the most developed way to seriously scale bitcoin by orders of magnitude.

Lightning developer Tadge Dryja, for example, made a reasoned case for pushing transaction volumes off the main bitcoin blockchain while maintaining a system heavily influenced by its decentralized design architecture.

Dryja’s talk focused on presenting how the Lightning Network could be implemented on bitcoin, laying out three scenarios for how it could be deployed, and noting the features that would be available under each.

"With fairly reasonable block sizes you can get millions to hundreds of millions of users," Dryja said. "How many transactions are those users going to do? Lots. Once you have the channel open you can do hundreds of transactions a day and hour. That’s encouraging."

Lightning's Joseph Poon followed Dryja with a talk that sought to emphasize the values that underline the network and the tradeoffs its design takes to scaling.

"It's not how do you get to the optimal state, it’s what will look like if it has this design. It can be highly decentralized, if you bias the system toward decentralization," he said.

Perhaps the day’s most anticipated talk was by core developer Jeff Garzik, who was tasked with giving a dispassionate overview of various proposals that have been submitted for increasing the bitcoin block size.

Garzik took on the task with an academic tone, beginning by stating the parameters in which all the proposals are seeking to work within.

Should the block size be too small, he argued, users could be forced off the blockchain and into the "walled gardens" of bitcoin service providers, while blocks that were too large would prohibit decentralization of network nodes.

"At either end, you defeat the security and privacy of the system," he said.

Garzik also spoke out against what he characterized as the drawbacks of keeping the current block size, thus risking that transactions routinely exceeded capacity and forcing users to pay a premium for funds to be included in blocks.

"From the user's point of view," he said, "bitcoin fees are hard to understand and predict. Fees are disconnected from value."

Further, Garzik sought to define the pros and cons of proposals including BIP 100, BIP 101, BIP 103, BIP 105, BIP 106, BIP 248, and what he perhaps suggested was the best path forward, BIP 102, which would increase the blocksize to 2MB.

In the question-and-answer session, Garzik was also keen to stress that a block size increase is not a silver bullet solution, emphasizing that the community’s emphasis on growth through conferences and conversation needs to continue.

He concluded:

Disclaimer: CoinDesk received a subsidy to attend Scaling Bitcoin Hong Kong from the event's organizers.

Images via Pete Rizzo for CoinDesk