8

Generally if you read BOLT 07 you will see that lightning nodes and channels can either be private or public. This is independent of the fact if they run on tor or not. The node announcment message explicitly supports announcing that it runs on tor as written in the BOLT 07 The following address descriptor types are defined: 1: ipv4; data = [4:...


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

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 ...


6

The onion routing in Lightning is based on the Sphinx Mix Format described in this paper. The situation is different from Tor We don't have entry and exit nodes in Lightning as all nodes are inside the Network. In Tor a new connection along the path is as easy as creating a TCP socket between the tor routing nodes. In Lightning a payment channel with ...


6

Tl;dr: also in lightning we have: not your keys, not your coins. More detailed explanation: I assume you mean with backup the private keys of the lightning node together with the history of the state data. Then the same would happen as in the onchain case if you loose your keys. You could not move the coins anymore. Or in a onchain 2-2 multisig wallet (...


5

Basically as fast as a regular payment. The encrypted onion is being transported from node to node and will most likely leave the TOR network pretty quickly as many connections in lightning happen with direct IP connections. The path calculation is happening locally on your node and does not need communication with your peers at the time when the payment is ...


5

The situation is less worse than you seem to assume. If node C disappears the channel A,B won't be affected. Also there is no direct need to affect the channel B, C and C, D. So most channels will stay open. The payment process is a two stage process and it depends during which stage of the process node C disappears to see what happens and how nodes react. ...


5

In lightning the receiver of the money comes up with a random secret and comits to it via the payment hash. Once all the hashed time lock contracts (htlcs) are set up along a path through the network from the sender to the receiver the recipient will release the secret preimage for the chain of htlcs to settle. The preimage can be seen as a proof of payment. ...


4

Currently it cost $0.000116736 USD (1 satoshi) fee to make a transaction on lightning. This is incorrect; there is no set price for sending a LN transaction. Each node can define its own policy for forwarding a payment through the network (base fee rate, plus a small percentage of the amount forwarded), so the fee paid will depend on the payment route ...


4

You basically answered the question already yourself. Besides the 1% channel reserve you as the funder are responsible for paying onchain fees in case you need to force close the channel by spending the commitment transaction. C Lightning (and lightning nodes in general) are rather overestimating onchain fees as they cannot rely on the fact that the fees ...


4

The Current Problem The major challenge in the current routing mechanism is finding channels with sufficient balance on one side of a node to forward an incoming payment. To be more descriptive, the channel_announcement or the channel_update messages that are broadcasted contains the short_channel_id through which lightning nodes can look up the transaction ...


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

First of all at this point in time the whitepaper is pretty outdated and should only be considered as a rough conceptual guide. The Lightning Network Protocol itself is better and more accurately described / specified in the lightning rfc That being said the situation is that even in the single-hop payment case HTLCs are being used. To set up and settle ...


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 ...


4

The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your ...


4

listpeers listpeers returns data on nodes that you have connected with OR the nodes with which you have an open channel. If you have an open channel with a node, but the connection with that node has been lost, then the node will still appear in the output, with "connected": false. If you are connected with a node but do not have open channels, then it will ...


4

Yes. Unfortunately this is true. Using push-amt means that you send over an amount to the other side wich they own. While it takes place offhand it is final in a similar way as sending Bitcoin to an address. The only way I see to get your funds back is if you talk to the owners of the nodes you opened channels with explain them the situation and ask to get ...


4

This is a very good question and I will give a quick summary of what is happening here. The longer version can be seen on my educational video on how to create payment channels starting at 33:41 (though I would recommend to watch from the beginning to review bitcoin and notation.) My understanding being the multi sig wallet is a temporary address which ...


4

The payment channel between Alice and Bob is encoded as a 2-2 multisig Adress the balance of that Adress is the capacity of the channel. A channel is opened by sending funds to that multisig Adress via a funding transaction. These funds do exist (on the Bitcoin network) and are by no means virtual. Alice and Bob each control a key of that Multisig Adress ...


3

How does TimeLockDelta affect a node? TimeLockDelta (or cltv_expiry_delta) is the minimum number of blocks a node requires to be added to the expiry of HTLCs. In other words, this value represents the required gap between the timelocks of the incoming and outgoing HTLC to this node. Once an HTLC times out, it can either be fulfilled or timed-out which means ...


3

The timelock value can be up to 14*144 = 2016 or the expected amounts of blocks to be mined with 14 days. Generally the cltv delta is a trade of: The higher you choose this value the longer your node can be offline without you rising to lose funds. However other nodes might select not to route payments through you as the routing process if hiring the chain ...


3

One reason to use HTLCs for single-hop payments in the Lightning Network would be to make them indistinguishable from multi-hop payments to the receiver. This way, the receiver does not know whether it was their direct peer who initiated the payment, or whether they are merely forwarding the payment on for somebody else. Since they look identical to the ...


3

I am sorry to write so but your understanding that the lightning network is a side chain is wrong. Thus there is not transaction with many inputs and outputs that represents the payments tat go on in the lightning network. A payment channel is encoded as a 2-2 multisig wallet. you have one key and I have one key. The capacity of the channel are the funds ...


3

The TL;DR answer is: Yes it is totally possible, but as far as I know not implemented in any lightning node software at this time. However I wish to elaborate a little bit. In your question you wrote: The reasons could be that forwarding a payment will require it to forward the htlc, fulfill it as well as compute the onion for routing to the next node ...


3

Lightning invoices are signed by the node issuing the invoice in order to verify the signature we need to know the node id. Thus it is included in the invoice. Lightning nodes provide an API to decode invoices. In c-lightning you can do (lnd below!) lightning-cli decodepay ...


3

I guess this has historical reasons. The short channel ids where there first in the onion format. C Lightning even today does not support multiple channels between 2 nodes. Lnd on the other hand does. That is why lnd developers started to switch the channel if a second channel with enough balance between the nodes existed. Later on it was agreed to add the ...


3

I am gonna need to use prude mod and began the download of the chain starting from march 2018 as recquired by lnd, my question is which bitcoin client is able to do that and how to configure it for this procedure ? I don’t believe any client can do this: how will your node know if a UTXO from before March 2018 was valid if it hast verified the full history ...


3

You can look for "last_update" field in getchaninfo output. Below I also submitted https://github.com/edouardparis/lntop console screenshot which does the same thing.


3

If you look at the channel_update message of BOLT 07 you will find that a node MAY create and send a channel_update with the disable bit set to 1, to signal a channel's temporary unavailability (e.g. due to a loss of connectivity) OR permanent unavailability (e.g. prior to an on-chain settlement). MAY sent a subsequent channel_update with ...


3

C-lightning does not save logs by default. One can ensure that the logs are saved to the drive by including log-file=<file_name>.log in the config file. When staring lightningd you can include the level of logs that the file has to capture by including --log-level=LEVEL, where LEVEL can be io, debug, info, unusual, or broken.


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