We’re rewarding the question askers & reputations are being recalculated! Read more.
22

Note: This answer was written in Spring 2016 and has since been overtaken by an actual spec and multiple implementations. I'm hoping to update this answer shortly. Summarizing mostly from r/bitcoin: How are paths found in Lightning Network?, the currently suggested routing would be similar to the Border Gateway Protocol. At intervals, the following process ...


15

“Centralization” is now a word constantly repeated but is one that, generally speaking, no one tries to define accurately. ---Alexis de Tocqueville, Democracy in America, Vol.1, Part 1, ch.5. Lightning Network channels will naturally tend to form along the paths of economic activity. If you assume (as I do) that most economic activity in Bitcoin ...


15

Lightning forwards payments using a construction called a "hashed timelock contract" (HTLC), which allows the payee to redeem the transaction if they know the preimage to a given hash, or allows the payer to redeem the transaction after a given timeout. So eg if I'm selling you something for $2 over lightning, I might say "I'll tell you the sha256 preimage ...


7

I agree with Alex Bosworth and I have pointed this out about one year ago when I have filed an issue about the strategy used by the LND autopilot which basically looks for nodes with a high channel count. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning. There are several kind of information we ...


7

If you want to route a lightning payment via your node, your channel(s) must hold at least a balance of the to-be-routed amount, right? If not, your node by definition cannot be chosen as a potential routing path. yes this is true. If you don't have enough bitcoin to forward you cannot forward a payment. So, in the future, when we dream about mass ...


7

I don't think there is a Public dataset online with an answer to your question. This would also be extremely hard to create as the results could change a lot depending on which node is doing the experiment. I know people are probing payment channels you could do the same. Just do payments to random payment hashes and collect the data for your node. You will ...


6

There's no fundamental reason why you couldn't use a non-bidirectional link. The onion routing protocol of lightning is ignorant of the channel between two nodes. Hypothetically, if two lightning nodes were right next to one another, you could have robotic arms pass pennies back and forth in lieu of a lightning channel. That said, would a non-two-party ...


6

With the current specification it is not possible to make a spontaneous payment to somebody on the network. However, this will likely change very soon, as it is one of the features on the roadmap and will be discussed in the specification group in November. There are tricks on how to do a payment by delivering a large fee at the destination and continue ...


6

There's no document explaining step-by-step, because the routing decisions are not part of the protocol (the BOLTs). It is purely client-side decision making about how to find a route through the graph, and any client can choose to implement their own mechanisms. There is no compatibility issues because only the payer makes routing decisions, and ...


5

Whoever made that example doesn't seem to understand how the lightning network works. I think the creator of this scenario is confusing how the lightning network functions with how traditional deferred net settlement functions. With the LN, you don't hold accounts with the people you have open channels with. Instead, you have money tied up in the channel ...


5

In fact, it's worse: payment channels can only transfer the balance that belongs to the sender in it. So, if David and Rob each paid 25BTC into the channel, David can at most send 25 BTC to Rob.— However, there could actually be multiple paths from Alice to Rob which could in parallel allocate 100BTC to Rob. There's an interesting trade-off here: the ...


5

I didn't attend the conference but here is my take on Hodl invoices. In a normal Lightning payment, the sender pays an invoice which contains the payment hash and the payee releases the pre-image to that payment hash for the successful resolution of the payment. In a hodl invoice the sender pays an invoice to the receiver, but the receiver does not release ...


4

Everything is described in detailed in the corresponding BOLT specifications: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md BOLT #7: P2P Node and Channel Discovery This specification describes simple node discovery, channel discovery, and channel update mechanisms that do not rely on a third-party to disseminate the ...


4

No, there is no work around for this. If a channel's balance is completely allocated to one side, the channel can only be used to move funds in one direction. Additionally, a channel whose balance is shifted completely to one side is vulnerable to the broadcast of a previous channel state as there are no funds to be lost for the attacker. This does not apply ...


4

Since 1ml is closed source I obviously cannot be 100% sure how it calculates the capacity of your node. But from my experience I can say that it does it in the same way as any other lightning node do it. It takes the capacity of all payment channels which have been broadcast by the gossip protocol and have been received by the node in question and adds ...


4

No as this algorithm introduced in the paper is not very efficient. As far as I understood the paper when it came out basically everyone needs to be involved in finding the path for a single payment. I want to say a few more things that always get mixed up when talking about decentralization: Path discovery and building a censorship resistant ...


4

TL;DR. You need to specify --final_cltv_delta=144 option in the lncli queryroutes command. Longer answer... When payment is routed through Lightning Network, each intermediate node has a potential ability to steal the funds being transferred. To prevent this from happening, intermediate nodes cannot move the money immediately, but only after a certain ...


4

Natively c-lightning does not support paying invoices to yourself. But I have provided a trick described in this video: https://www.youtube.com/watch?v=Dwl-0cY6KkU&t=1s: The trick is to create an invoice and then use getroute to find a route to some node and then go back (possible over another route with another getroute call). once you have such a ...


4

I am sorry to say but your understanding is wrong. When you send x btc to Bluewallet you don't open a channel. You just give them your Bitcoin. Bluewallet and other custodial wallets run one (or possibly several) lightning nodes and allow you to use it with up to the amount of btc you have sent to them before. So as long as Bluewallet users send each other ...


4

I am not sure if scale is the term you are looking for when discussing potential problems with routing. But I will try to focus on scaling when giving the answer. That being said my answer would probably differ quite a lot if the question was asked differently. The current routing algorithm is onion routing. The onions contain a path from sender to the ...


4

Obviously for questions like this I can't give a 100% certain answer as I would have to look at your nodes logfiles and configuration / state. However I can make some (hopefully) educated guesses and we can see if that helps you. First of all it seems like you kept the standard base fee and fee rate. Following my analysis and video it seems pretty unlikely ...


4

Yes, there are basically two ways to avoid becoming a forwarding node: Do not announce your channels, and keep them private Reject any incoming HTLC that is not destined for you The first is supported by the protocol itself, and is a proactive measure against forwarding any payment that is not destined for you, while the latter is a reactive measure and ...


4

Running lightning node over TOR is no different than running it over normal IP connection. Sending payment, fulfilling incoming payment, sending error messages etc. would happen in the exact same way in both cases. The only difference is that the above messages that you send to your peer will now happen over TOR network rather than a direct IP package. If ...


3

Channels do not publicly announce their balance for several obvious reasons It would be a huge privacy concern if balances could be viewed live on the network. People could monitor large parts of the network and aggregate data about how balances change over time, which could then be used to trace payments through the network and deanonymize users. If every ...


3

When I set up a lightning channel with a node, have I need to put some bitcoins in it? Generally, yes. The person who initiates the channel creation process (i.e. the person that says "I want to open a channel with you") is the one who funds the channel. Then, if I wanted to buy something using lightning network (for example, a sticker from Blockstream), ...


3

As far as I understand the process the channel is constructed between two peers. For privacy reasons one of the two peers could decide to keep the channel private. Bolt7 uses the following quote with a reference to the open message of Bolt2 The willingness of the initiating node to announce the channel is signaled during channel opening by setting the ...


3

The preimage R is the same throughout the entire route, so Bob/Dave would know what R is (from lnd Overview). However if Bob were to broadcast his commitment transaction for the Bob -> Carol channel, it would have to either be an old commitment without the HTLC-offered output or be the current commitment transaction with the HTLC-offered output. In the ...


3

Even if you did find such a route successfully, what guarantees that B WILL use its payment channel? B can deny at any moment, because decentralization. Also, from routing recommendations: When calculating a route for an HTLC, the cltv_expiry_delta and the fee both need to be considered: the cltv_expiry_delta contributes to the time that funds will ...


3

Yes, a hardware wallet could be designed for use on the Lighting Network, but no, there's no such thing as eliminating risk of theft. There is always risk of theft, no matter what you do. A hardware wallet could be made to sign the transactions needed to construct the smart contracts for lightning channels, and could even be made to communicate with them. ...


3

The "centralization" that most people talk about is really about limiting who can effectively (and profitably) participate. If we're talking about the blocksize debate, the idea is that larger block sizes require faster internet connections to remain competitive and at a certain point this might make it infeasible for any but a few large companies to be ...


Only top voted, non community-wiki answers of a minimum length are eligible