Another layer sandwiched between the Blockchain and Lightning?

[References to “Blockchain” refer to the only Blockchain (PoW, which also runs Bitcoin) — TJACK]


Researchers are putting new effort into developing bitcoin’s Lightning Network.

With the Segwit2x hard fork – which looked to increase the bitcoin block size parameter to 2MB – suspended, ETH Zurich researchers Conrad Burchert and Roger Wattenhofer and Blockstream engineer Christian Decker have proposed a more scalable version of the payments channel scheme, believed by developers to be the best way to expand bitcoin to accommodate more users.

Sometimes called bitcoin’s “layer two,” Lightning hasn’t yet been pushed live onto the bitcoin blockchain, but proponents of the idea see it as a way to boost bitcoin’s transaction capacity without increasing the block size (as bitcoin cash, which forked off bitcoin in August did).

In a new paper called “Scalable Funding of Bitcoin Micropayment Channel Networks,” however, the three developers now envision even another layer, one that would be sandwiched between the bitcoin blockchain and Lightning, which they think would overcome Lightning’s existing limits.

Perhaps most notably, the researchers argue that limit is somewhat defined by the Bitcoin Blockchain itself, which, capped at 1MB, can’t support infinite Lightning channels. After all, users must complete bitcoin transactions and record them on the blockchain each time channels are opened and closed.

In this way, Decker, pointing to existing research, suggests there’s an upward bound on just how many Lightning Network transactions are feasible today.

He writes:

“It turns out, it’s not that many. It’s a few million every week, which is still a long ways from serving the full Earth’s population.”

And while this isn’t a problem right now, it could lead to issues in the future – scaling issues that continue to be a hot, and contentious topic in the crypto community.


Channel ‘factories’

To understand what the new layer would provide, it’s helpful to compare the proposed layer to the way Lightning functions currently.

Today, a user must open a new Lightning “channel” with another user through a regular blockchain transaction. Once that’s established, the two users can make as many off-blockchain transactions as they want or are able to with the initial amount of value they put into the channel.

The new proposal, which Decker called “Lightning extended,” utilizes so-called “hook transactions” to move funds into a multi-party channel capable of supporting more than just two users. The paper calls this a “channel factory.”

The method allows two people in a multi-party channel of say four or six, or as many as 15, to start a separate isolated channel within the main channel.

While it sounds a bit complex, the mechanism allows the two users in the isolated channel to close that channel and be dropped back into the multi-party channel, where they could then open another isolated channel with someone else. And all this is done without going back to the blockchain and incurring the transaction fees associated.

In this way, users could hypothetically open and close channels several times without ever making an on-chain transaction.

“The only thing the blockchain needs to know in the end is where the money ends up. So, if we have many intermediate states, we don’t have to publish them ever. Instead, we just make a transaction that everyone signs. This is the only thing that goes to the blockchain,” Buchert, the lead author of the paper, explained.

He continued, “It offers more flexibility, basically.”

According to the authors, the channel factories will lead to reductions in cost, comparable to the number of people in the multi-party channel. For instance, a 100-person group would lead to a 90 percent reduction in costs, compared to 100 traditional payment channels, the paper explains.


Still far away?

While the benefits seem attractive, the authors say there’s still a way to go before the project could see real-world use.

For one, the developers said, the technology would perform better with if another long-proposed technology, Schnorr signatures, was added to Bitcoin.

Whereas channel factories are currently limited to groups of 15 people, with Schnorr signatures, users could open up groups of an unlimited size – scaling Lightning even further.

Although there could be downsides to larger groups, in that one user could spoil the channel for everyone else by sending a transaction from the inside to the bitcoin blockchain. According to Burchert, developers and users will have to experiment to see how many members per group works in a real-world setting most effectively.

Plus, with Lightning still in the testing phase, Burchert said that channel factories can’t jump to the front of the line.

He told CoinDesk:

“There are far more important things to work on right now, like getting the Lightning Network online. We’ll need [channel factory] technology when we have millions of channels, but we’re far from that right now.”

And when that time comes, Decker said it can be integrated more easily because Lightning sits on top of the Bitcoin protocol, and so shouldn’t give rise to much conflict when upgrading.

“While we don’t plan to implement this right away, this could be a potential upgrade later on, without any disruption to the network,” Decker concluded.

Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which has an ownership stake in Blockstream.




Schnorr Signatures

[Ignore SegWit2x – it was a bad idea and is dead. This is about Schnorr Sigs — TJACK]


Bitcoin’s core developer team isn’t yet done scaling the cryptocurrency’s protocol.

Despite the fact that a years-in-the-making change called Segregated Witness (SegWit) activated on the network just over six weeks ago (with businesses and users now slowly updating and average block sizes inching upward), the upgrade has already started a chain reaction of work on other optimizations geared toward accommodating more users.

So, while businesses and miners are pushing for more aggressive scaling via the controversial Segwit2x proposal, the open-source team behind bitcoin’s most widely used software is focused on other efforts entirely. Called “Schnorr signatures,” the technology offers another signature scheme option alongside Elliptic Curve Digital Signature Algorithm (ECDSA). One benefit is that it supports “signature aggregation” on the bitcoin blockchain.

While that may sound complex, the change aims to consolidate activity that already takes place on the network with each transaction. Under the ECDSA scheme, each piece of a bitcoin transaction is signed individually, while with Schnorr signatures, all of this data can be signed once.

And doing so could improve bitcoin in a few key ways, according to developers working on the effort.

Blockstream engineer Jonas Nick told CoinDesk that this method of mashing signature data together should be considered “low-hanging fruit for helping bitcoin scale.”

First, by decreasing the number of signatures, it increases the amount of transaction data that can fit into each block. Second, by merging signatures, the technology could enhance privacy by making it harder to determine where transactions are coming from.

Third, it’s believed the change could curb “spam attacks,” where one entity sends a bunch of small bitcoin transactions that take up extra space in the blockchain, potentially making nodes more difficult to run.


Success through failure

Though the new signature technology has been an idea since at least 2013, developers have recently made some breakthroughs, bringing Schnorr signatures closer to actual implementation on bitcoin.

SegWit was the first necessary step in that the code change, which moves signature data to another part of the block, making Schnorr (or something like it) possible to implement with a backward-compatible software upgrade (soft fork), where it wasn’t previously.

Then, most recently, developers stumbled upon under-the-radar cryptography research that could help them build the algorithm faster.

According to a transcript of Bitcoin Core’s annual meeting over the summer, developers submitted a paper outlining their signature aggregation scheme to Financial Cryptography and Data Security 2017. While the conference committee rejected the paper – asserting that the security proof for the signature aggregation scheme provided in the paper was too flimsy – they also suggested another paper, which provided a stronger security proof.

Bitcoin Core contributor Bryan Bishop told CoinDesk:

“This is important and useful because it means that the cryptography has been studied in the past to a further extent than we previously thought.”

With this work already done, developers can spend less time ironing out the security signature scheme, and more time figuring out how to implement it on bitcoin.


Next steps towards reality

Blockstream’s Nick points to an in-progress bundle of code changes called “aggsig module” as the main place where Schnorr signatures are being worked on.

Code contributions – from Andrew Poelstra, Greg Maxwell, Pieter Wuille, Peter Dettman and others – date back as far as 2012, showing this module as the most advanced in terms of being worked on over the longest number of years.

While many developers there have turned their attention to optimizing the performance of the Schnorr code implementation to make sure the verification of signatures is as fast as possible, Nick said, there are still some missing pieces to the aggsig module before it can be fused into bitcoin itself.

For example, bitcoin’s OP_CHECKSIG function checks to see if someone really owns the bitcoin they’re trying to send. Currently the function does not take the new Schnorr signatures into account, meaning it can’t do the aggregating signatures, said Nick.

“There’s no public proposal yet specifying how [that] would exactly work,” he explained, adding that developers need to write up some sort of a roadmap for the new function, before it can be implemented.

Still, he was optimistic that the change will not take long to implement, calling it “relatively straightforward.”

Nick concluded:

“The right people just need to find time to focus on it.”

Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which helped organize the Segwit2x scaling proposal, and has an ownership stake in Blockstream.




Schnorr Signature on Wikipedia

“In cryptography, a Schnorr signature is a digital signature produced by the Schnorr signature algorithm. Its security is based on the intractability of certain discrete logarithm problems. The Schnorr signature is considered the simplest digital signature scheme to be provably secure in a random oracle model. It is efficient and generates short signatures. It was covered by U.S. Patent 4,995,082 which expired in February 2008.”


Bitcoin Core: Technology Roadmap with Schnorr Sigs


[29 DEC 2017 – Update on SegWit2 Fork]

Highway Robbery in other words …

… or, in less politically correct terms: even more B.S. than the first attempt.


The new SegWit2x, a revival of the original hard fork designed to help with the scalability issues of Bitcoin, was scheduled to happen at Bitcoin block number 501451. That block was mined at around 6PM UTC, Dec. 28, and the team behind the project announced its official launch:


The original SegWit2x

The SegWit2x movement has originally started in May 2017, as a direct result of the New York Agreement (NYA). The idea behind the agreement, originally signed by more than 50 leading Bitcoin companies, was to achieve a compromise on how to scale Bitcoin for a larger audience.

One of the sides, the “small blockers,” wanted to implement the second-layer solution called SegWit, which did indeed take place on Aug. 24, 2017. That was the first part of the compromise. The other part of the deal was designed to appease the “big blockers” by increasing Bitcoin’s block size limit to 2 megabytes. However, this was never followed through with, directly violating the agreement.

The fork was slated to happen on Nov. 16. However, as the developers unveiled the actual code for the hard fork, a vastly negative reaction from the Bitcoin community immediately followed. The lack of replay protection, along with general concerns about the safety of a possible hard fork, gave rise to an entire movement against SegWit2x, aptly called #no2x.

After several weeks of controversy, the fork was cancelled on Nov. 8, about a week before its scheduled arrival. The team tasked with creating the code for SegWit2x shelved the plan due to a lack of consensus.

SegWit2x 2.0

The cancellation, apparently, only lasted so long, as the fork was seemingly revived in late December by a different group of developers. A website has been set up, stating  the mission, the roadmap and the team behind the new fork that was set to take place on Bitcoin block 501451.


Reports began surfacing over the past several days that focused on several inconsistencies on the project’s home page.

First and foremost, the team behind the new fork has nothing to do with the people behind the original New York Agreement and the SegWit2x that was cancelled in November. They have even admitted it themselves in a chat with the Finance Magnates news site.

There is very little information available online about the team members listed on the official website. For example, the project’s supposed founder, Jaap Terlouw, only has a half-empty LinkedIn profile. There he claims that he is the ‘main developer’ of the new SegWit2x, with no other sources to corroborate his status as a ‘developer.’

Moreover, the project’s GitHub account is just 9 days old as of press time, which makes it even younger than some of the earlier announcements of the upcoming fork in the press.

Adding to the list of concerns, the code stored in that GitHub account indicates that the team members were planning to assign themselves 6 mln premined coins, a whopping 28% of the total supply of 21 mln:


This constitutes an incredible degree of control over the project that some would argue a scrupulous team should not have. Likewise, it represents an enormous (and instant) potential profit to the team members. This could encourage a quick pump-and-dump.

Paid-for press releases distributed to various Blockchain-related websites, such as Bitcoinist and even the Russian-language, were highlighting the tremendous increase in the value of the futures contracts of the new SegWit2x, just as some other news outlets have been voicing concerns about the intentions of the team behind the project.

Topping the list of reasons for suspicion is the bizarre promise to issue “a proportional number of Satoshi Nakamoto`s Bitcoins” to all BTC holders after the fork takes place. No indication has been offered of how would the team actually be able to access the coins that have been held by the mysterious creator of Bitcoin since the earliest days of its existence.