Comment by nosuchthing | Hacker News Reader

Comment by nosuchthing | Hacker News Reader

Parent Full thread

Does anyone know how Lightening Network code actually routes nodes?

The LN claim is basically decentralized BGP but much more complex and prone to race condition errors.

https://www.youtube.com/watch?v=Ug8NH67_EfE&feature=youtu.be...

The white paper doesn't even mention how LN routing works!

  8.4 Payment Routing

  It is theoretically possible to build a route map 
  implicitly from observing 2-of-2 multisigs on the 
  blockchain to build a routing table. Note, however, 
  this is not feasible with pay-to-script-hash transaction 
  outputs, which can be resolved out-of-band from the 
  bitcoin protocol via a third party routing service. 
  Building a routing table will become necessary for 
  large operators (e.g. BGP, Cjdns). Eventually, with 
  optimizations, the network will look a lot like the 
  correspondent banking network, or Tier-1 ISPs.

It seems impossible to implement true decentralized routing, so it's likely they're using some sort of hack to prioritize "masternodes" as the backbone routers instead of actual peer to peer routing.

> It seems impossible to implement true decentralized routing, so it's likely they're using some sort of hack to prioritize "masternodes" as the backbone routers instead of actual peer to peer routing.

What do you mean "impossible to implement true decentralized routing"? Many examples of decentralized distance vector and link state algorithms exist. I'm not sure what they are doing but routing isn't some mystical thing that requires a master node.

Here's a thing I did a while ago: https://github.com/jtremback/reactive-payment-routing

I was so impressed by this, I went snooping into your Github and saw you are now working on https://altheamesh.com/

Which I have to say, is a very cool project and one I would love to help spread when your protocol can handle 3G or LTE-like speeds. Keep up the good work: you're really on to something with this project!

Very interesting and impressive project, thanks for sharing!

It seems like p2p routing might work for a small network, but the complexity turns chaotic at scale very quickly. I guess time will tell how effective the LN implementation is.

just like with TSP - if you are willing to make concessions about accuracy, the problem becomes much more manageable.

LN is DOA.

Routing does not work. And it will never work.

Long live Bitcoin Cash

Yeah! Like Segwit, which now already runs 30% of all transactions (source: reddit ). Ver is like Ballmer who didn’t see the iPhone coming

SegWit will do nothing for long term scaling. Watch and see.

Expcept it does already

We're implementing a public-key based radix tree routing algorithm over here at gun, which is ranked #2 in blockchain ( https://github.com/topics/blockchain ).

Better, physical proximity (via Bluetooth or WiFi mesh networks) would provide immediate local routing. This would work with the above.

The whole thing is fishy. The lightning network is pushed by Blockstream, a company which has a large number of devs working on bitcoin core. They were responsible for all the propaganda and talking points against bumping the block size leading to the BCH fork, because they wanted the "correct" solution of their lightning network. The fact that it is so complex and ill defined is dangerous and an antithesis of decentralized system design and ethos, as it's not clear how trustless transactions are protected. How do we know that there isn't an easy backdoor that allows this network to be controlled for Blockstream's purposes?

This is pure FUD.

Satoshi himself proposed the first version of payment channels [1]. The Lightning Network paper has zero authors from Blockstream [2]. At least two other entirely independent companies are working on Lightning Network implementations [3][4]. It's well understood how trustless LN transactions work [5]. The spec [6] and code are open source, feel free to look for a "backdoor".

1. https://en.bitcoin.it/wiki/Payment_channels#Nakamoto_high-fr...

2. https://lightning.network/lightning-network-paper.pdf

3. https://github.com/lightningnetwork/lnd

4. https://github.com/ACINQ/eclair

5. https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts

6. https://github.com/lightningnetwork/lightning-rfc

Whenever I see the term "FUD" nowadays I think "ah, someone who is invested in a cryptocurrency, this will definitely be an unbiased view".

Only one of the implementation is coded by blockstream. It's a protocol, anybody else can create an implementation of it. Several other companies have created clients like LND (https://github.com/lightningnetwork/lnd) - probably more popular than clightning.

> How do we know that there isn't an easy backdoor that allows this network to be controlled for Blockstream's purposes?

The code of clightning is open source, so is the code of most known clients out there.

> The fact that it is so complex and ill defined is dangerous and an antithesis of decentralized system design and ethos

Your comment really seems like a baseless conspiracy theory full of ad hominems with no proof of what you mention: - it's not that crazy complex compared to all the intricacies / op codes and game theory of the Bitcoin base layer - it is more easily distributed than the base layer since it's easier to run a LN node by itself (albeit still relying on a bitcoin full node that may not be in your control if you wish it so).

And like other said, Blockstream doesn't have many employees working on the base protocol (3 now afaik since Luke Dash JR & G.Maxwell do not work for Blockstream anymore). The few they have actually made very useful contributions to the code base since 2011/2012 which you can easily see through and most of their code is also used in all forks of Bitcoin aka BTG, BCH etc...

> They were responsible for all the propaganda and talking points against bumping the block size leading to the BCH fork

Any proof on that? Almost no bitcoin developers (albeit none apart of maybe 1 if you count Gavin which didnt contribute for years on the code base) left to work on this particular fork. There was no scientific consensus stipulating larger blocks (than 4mb) would be safe hence why the community at large did not support BCH (and why it has a minority of market share and mining share, TX usage etc).

This is confused or wrong. They don’t have a large number of devs working on Core. They did propose and code a solution which increased the block size. Saying things are fishy and that open source solutions widely reviewed over years by a broad set of people have some secret easy supposed backdoor, seems pretty wrong to me.

what? There are 3 different implementations of the Lightning network, they all implement the same protocol and are all open source. You seem to be either very misinformed or just trying to spread FUD.

Reply on news.ycombinator.com