Core Dev Peter Todd admits Lightning Network has issues

Getting your Trinity Audio player ready...

It takes a lot for a staunch advocate of a technology to question its capability. Very recently, Bitcoin Core developer Peter Todd, made an admission that Lightning Network is full of holes.

Praised by many as being the scalability fix for the Segwit chains’ scaling woes, Lightning Network has indeed come short on many fronts, and many people are beginning to question if it really is up to the task, including one prominent contributor to BTC’s code.

“Segfaults” (or Segmentation faults) are generally quite common when programming in C. But the more complex a program, the more chance of there being such instances of these bugs.

Segfaults are generally caused by a badly written program that tries to read or write to memory locations that are out of range. A common segfault for example is an out of bounds array, or a variable that has not been declared properly.

The problem with coding in C++, is that it is an extremely powerful language that gives full control of the mechanics of the application to the developer. This can be a very good thing, but it can also be terribly dangerous. The compiler assumes the developer knows what they are doing, and it will not try to ‘guide’ the user, as is the case with modern programming languages.

On one hand, Peter Todd is right. “Writing it in C, is a notoriously dangerous language”. But on the other hand, we have to question the logic both ways. If the coding language of choice was right, then why are there so many holes in the application, which are apparently very difficult to identify and resolve? If the coding language of choice was incorrect, then how much faith should we be putting in the leadership of this project?

Lightning is still far from ready on all accounts, many have already lost funds in testing Lightning Network on the main. In the same thread, Peter mentions that he’s lost funds testing “Éclair” – an android, “lightning ready Bitcoin wallet”.

He goes on to mention “As for the Lightning protocol, I’m willing to predict it’ll prove to be vulnerable to DoS attacks in its current incarnation, both at the P2P and blockchain level… While bad politics, focusing on centralized hub-and-spoke payment channels first would have been much simpler.”

Let’s ignore the ‘centralized hub-and-spoke’ comment there…

In my other life I am a business analyst and a developer. A BA role entails identifying business needs, and determining solutions. One of the most common project management methods out there is known as PRINCE2. It is used across a multitude of industries for the delivery of projects. But one interesting concept that I find myself drawn to regarding PRINCE2 is the tenet of “continuous justification”. If at any point of the project lifecycle, the outcome can no longer be justified, then the project is dropped.

As far as LN is concerned, at no point have we seen those steering the ship, reassess the viability of the project. In PRINCE2, one of the initial documents coming out of the process is the business case itself. Let’s suppose for a moment, that the Lightning Network whitepaper fills this gap. The paper identifies Bitcoin’s scalability problem, and makes a proposal for off-chain channels that can be settled on the Blockchain afterwards.

At some point after, it was then identified that it cannot scale to the desired level, and that there are some fundamental problems with the funding of channels. So then a ‘third layer’ was introduced, to scale funding capability of channels.

Another problem still open is how channel updates can be broadcast to everyone, particularly at a global adoption level. At 1 million channels, things can get very ugly.

The problem we are facing, is that this is patch work, after patch work, after patch work… At what point does project leadership, take a step back and reassess the viability and feasibility of LN as a global scalability solution?

Entities like Blockstream who are in part sponsoring the development of Lightning Network, have a lot to lose. There’s a reason that PRINCE2’s “continuous justification” principle became a thing…  there are indeed many businesses that are guilty of throwing more and more money at a project in an attempt to save it, than to go back to a drawing board. Some people just want to save face.

Eli Afram
@justicemate