Hacker News new | ask | show | jobs
by mike_hearn 3824 days ago
The design has always designed around wallet-wallet topologies from the beginning (try doing a Find for the word "hub" in the paper).

This is very clearly not true, and you don't do yourself any favours by saying such things. The paper discusses hubs that need to provide various guarantees, like being continuously online and routing payments for arbitrary third parties. This is not at all the same thing as a wallet and Chris is right to point out the distinction.

With respect to your point about becoming a punching bag, I'm afraid I am not particularly sympathetic. When Blockstream started floating LN as an alternative to raising the block size (which is what they have consistently done) you should have condemned that and them right away, loudly and clearly, as it was obviously an absurd suggestion and not going to happen anywhere near in time.

LN is a highly theoretical system that doesn't have any implementation that ordinary people could actually use. There is no practical experience with running such a network. It doesn't even have answers to basic design questions, like how routing and addressing would work. The chance of project failure is therefore quite high, as is always the case for research projects.

Thus to imply LN is some sort of dead-cert thing is hubris. Academics have been producing e-cash white papers for decades. Almost none of them actually turned into real-world systems. Nobody will know if LN actually works better than Bitcoin does (or did) until it's built and has competitive usability, which is a very long time away.

> There is a clear obvious misunderstanding of core principles in computer science, wishful thinking does not solve real problems

That's not very charitable is it?

I can assure you, the CS understanding of the people who disagree with you (like Chris, Gavin, myself and Satoshi) is just fine, but I have to question your understanding of engineering. The calculations were done years ago that showed for typical payment network loads that global broadcast could work just fine. Computer science doesn't mean "some algorithms never work and some always work". It just gives us the tools to analyse costs. By simply ignoring complexity and engineering costs of LN, as well as some rather tricky algorithmic costs around pathfinding in global non-suspended networks, you can obviously make any actually existing system look bad in favour of a theoretical proposal.

3 comments

The paper never refers to hubs, the necessity of a handful of entities routing payments a-la Visa has never been part of the design. There are certainly more connected nodes, but that's true in any P2P system (as well as nodes with higher uptime). Additionally the paper refers to larger blocks, LN doesn't resolve underlying block capacity issues alone, it could help mitigate its problems significantly -- much like how a switched network helps resolve bandwidth (but you still might want faster connections).

I've never argued that it is a dead certainty, certainly less so than you have argued that arbitrarily large blocksizes are the only solution.

Quite frankly, I don't understand why you're so butthurt with my comment, I've stated that I think multiple solutions are best, and have explicitly avoided the politicization with this community.

> I can assure you, the CS understanding of the people who disagree with you (like Chris, Gavin, myself and Satoshi) is just fine

I'm pretty sure your comments don't accurately represents Gavin's view (AFAIK, he also thinks we need to explore many technical approaches), nor do you speak for Satoshi (current understanding of bitcoin's risks is significantly different than 2011).

Engineering costs are one thing, technical impossibilities are another. It's not credibly possible for bitcoin to exist in its current form while also being able to make a $0.0001 payment. I agree there are some aspects to consider, esp with maximizing the social value of the network and testing it out, though. Certainly, for all we know there may be unaccounted issues, but that's the case for bitcoin as well (51% risks are still unknown).

For those who are not paying attention to the bitcoin discussions, I have always stated many transactions will still be on-chain (e.g. large directional flows, but paying $0.001 has not been feasible for a very long time in Bitcoin, LN enables those payments to exist using Bitcoin again).

> It's not credibly possible for bitcoin to exist in its current form while also being able to make a $0.0001 payment.

Of course it is. I've made such payments many times over the years. The only reason it's not currently possible is because the Bitcoin Core developers have deliberately forced the network to run out of capacity instead of doing what the community wanted and raising the block size limit. So now the fees are huge, payments are flaky and users are rightly complaining that the system they rather liked appears to be losing any advantages it had over the competition.

Saying "it isn't feasible" or "not credibly possible" when it was repeatedly done right up until very recently is ... not great.

The proposed Lightning Network has received some very strong technical criticism, such as Chris Pacia's article. I wrote a similar one months ago that touched on different issues. I have not seen much in the way of answers to these criticisms.

> The only reason it's not currently possible is because the Bitcoin Core developers have deliberately forced the network to run out of capacity

The Bitcoin developers suspect that there is nearly unlimited demand for $0.000000000000000000001 bitcoin transactions (micropayments). "Unlimited demand" is another way of saying "denial-of-service vulnerability".

I think that "forced the network" is tiresome allegation-making. The developers did not force the network to have an asymmetric bandwidth graph, but they definitely have an interest in countering centralization pressure (such as the increase in resource requirements derived from increasing transaction rate directly through the block size parameter). ....

I know you have long-standing disagreements with Bitcoin Core developers, but this does not seem like good reason to gloss over their reasoning.

> Saying "it isn't feasible" or "not credibly possible" when it was repeatedly done right up until very recently is ... not great.

"What they call a 'centralization pressure' was working fine right up until some limitations on that 'centralization pressure' were implemented!"

> instead of doing what the community wanted and raising the block size limit

Btw "what the community wants" is irrelevant when trying to determine feasibility; sum of community-desire-weight does not make community-desired options more/less feasible.

> The paper never refers to hubs, the necessity of a handful of entities routing payments a-la Visa has never been part of the design.

Yet in person the opposite is true. I've heard Tadje refer to large hubs plenty of times.

As for your comment about CS understanding, curious to know, what are your credentials? What's your background in algorithms, networks and software engineering? There is no biographical data on the Lightning network website.

> I can assure you, the CS understanding of the people who disagree with you (like Chris, Gavin, myself and Satoshi) is just fine

Speaking for Satoshi is a bit presumptuous, yes? It does make me question who else you're supposedly representing.

Go read Satoshi's first announcement of Bitcoin on the crypography list. The very first question ever is about scalability and he states quite clearly that he thought about it extensively and it would never be an issue in practice. He uses Visa as an example to illustrate his point.

Now go read the Lightning white paper. They also use Visa as an example and state that Bitcoin cannot scale. They directly contradict Satoshi on literally the first Bitcoin topic ever discussed.

So I am not speaking for Satoshi in my post above: I am pointing out that he strongly disagreed with Poon & Dryja's reasoning right from day one.

As you can see above, Joseph uses the same language some of the other Bitcoin Core folks use ... they like to say "our understanding is much better now". They do not like to explain exactly what this "better understanding" actually is, given that computers haven't got any slower. They just assert that it could never work. That's unfortunate.

> They do not like to explain exactly what this "better understanding" actually is, given that computers haven't got any slower.

Scalability isn't only about going fast/slow. Scalability is about growth in performance, reliability, guarantees, etc. What counts as better (or worse)? And what are the tradeoffs? And which tradeoffs can we reliably make without breaking the system's guarantees, if indeed it makes any guarantees at all? It's easy to see how Satoshi may not have been omnipotent. Indeed many programmers don't always know all performance characteristics of all the software they write; too, we see programmers taking up opinions on system performance even when their opinion is wrong (some are even known to recognize when they are wrong and update their opinions based on new better knowledge).

> The paper discusses hubs that need to provide various guarantees, like being continuously online and routing payments for arbitrary third parties.

Can you quote the paper on that?

The article attached to this thread discusses it.