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


5

It is possible to run Lightning (both LND and c-lightning) with bitcoind pruned mode. There is a lot of conflicting information online, because it became possible only recently in Bitcoin Core 0.16.0. The change that enabled txid lookups in pruned mode is BIP159. There are already packages turning the pruned mode on when disk space is limited: Lightning ...


5

Usually a merchant will generate a (psuedo)random 32-byte value and hash it. This becomes the payment_hash which identifies the payment in the network and is transferred to the purchaser in an invoice. When the user makes the payment, they send this payment_hash with an onion packet, as a conditional payment which will complete if the preimage of the hash is ...


5

As you mentioned your question is almost a duplicate of Why does my c-lightning node pay more than the invoice plus routing fees? But you asked if there is a way of knowing how much you will overpay before you pay. There are two ways : You can configure lightningd with a maximum allowed fee for a payment. In that case your node won't use a route with ...


4

The money now belongs to the counterparty in the channel you opened. In every one of your channels, whether you opened them or they were opened to you, "local balance" refers to your spendable/forwardable balance and "remote balance" refers to the counterparty's. Don't worry though, if your node stays online reliably, then others will open channels with you,...


4

The flags field (2 bytes) has been split into two different (1 byte) fields, the message_flags (most significant bits) and the channel_flags field (least significant bits). Hence the flags value displayed in lnd has the message_flags byte set to 0x00 and the message_flags set to 0x01. message_flags indicates that this channel_update has some optional fields ...


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

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

The time_lock_delta is the minimum difference in the number of blocks between the CLTV of an incoming HTLC and the forwarded HTLC. Full details are described in BOLT2 # CLTV expiry delta.


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


3

It is bidirectional by default. In fact LND does not even allow for single-directional channels. What you're experiencing though, is the drawback of having created a single-funded channel. That means, that all of the funds in your newly created channel are sitting on your side, which means that for now, you can only send money but not receive any money. Or ...


3

As far as I know, this is not possible. lnd and bitcoind are two separate daemons, that interact with the bitcoin network in different ways. The only way I could think of doing this would be to import keys from one daemon to the other, but exploring the help command of lnd I'm not currently seeing any options to import or export private keys. In any case, ...


3

Will a bitcoin lightning node run on a raspberry pi zero? This probably depends on what you are doing on the node, how much traffic it gets, etc. I have one running on a Raspberry Pi 3B with basically no traffic and its currently utilizing virtually no CPU and 0.8% memory. Does it have to have the full Bitcoin blockchain synced or can it connect to a ...


3

Many! If you look at the BOLTs ( lightning RFC) you will find many situations in which nodes must fail a channel (meaning a force close) if something happens in an unexpected way while communicating with a channel partner. This could be even as easy as an unresponsive channel partner while settling an htlc in which case you have to settle the htlc onchain. ...


3

I think the problem is that you are trying to pass the file name as an argument instead of the content of the file. Try passing the json through the standard input instead: cat routes.json | lncli --network=testnet sendtoroute --payment_hash=...


3

The short_channel_id points to the funding transaction of the payment channel by the format blockheightxtransaction_indexxoutput where the x is used to seperate the 3 values and the three values are depicted in decimal. This is at least the BOLT 1.1 agreed format for the short channel id. Previously the shortchannel id might have been encoded and depicted ...


3

Lnd itself does not provide the betweeness centrality of your or any nodes. However you access the network with the graph api call and compute the centrality yourself. You can either implement it yourself by following the instructions from the Wikipedia article or you can use a graph lib like networkx that does it with one api call after you passed the ...


3

Currently, no. The receiver will reject an attempt for less than the requested amount and fail with incorrect_or_unknown_payment_details. Each invoice has a payment_hash which a payment corresponds to, and the payment hash is generated from a random payment_preimage. This preimage must be unique for each payment, else it may be possible for any party along ...


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

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

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.


2

I think is not possible. They are still working on it. https://github.com/lightningnetwork/lnd/issues/732


2

that depends on the locktime that is configured for your channels. taken from c lightning (c.f.: https://github.com/ElementsProject/lightning/blob/97118c558e84e0b3a12a8cbe60528ad5cfcb2fd6/doc/lightningd-config.5.txt ) watchtime-blocks='BLOCKS':: How long we need to spot an outdated close attempt: on opening a channel we tell our peer that this ...


2

I have to fill in these values in the config: bitcoind.rpcuser=bitcoind_rpc_user_string bitcoind.rpcpass=bitcoind_rpc_password_string These are user defined, and used to authenticate and communicate with your full node. There is no authentication to the network, anyone is free to join. You’ll want to define a username and password in your bitcoind ...


2

The specification of the short_channel_id describes the format as follows: The short_channel_id is the unique description of the funding transaction. It is constructed as follows: the most significant 3 bytes: indicating the block height the next 3 bytes: indicating the transaction index within the block the least significant 2 bytes: ...


2

https://github.com/lightningnetwork/lnd/blob/8379bbaa9b259544c2c8591782a78d7384680b2a/lnwire/short_channel_id.go#L25-L43 // NewShortChanIDFromInt returns a new ShortChannelID which is the decoded // version of the compact channel ID encoded within the uint64. The format of // the compact channel ID is as follows: 3 bytes for the block height, 3 bytes // for ...


2

After some searching through the BOLT documents and talking with the lnd slack community, I found an answer: B->C. If B were to send 4,999,999 millisatoshi directly to C, it would neither charge itself a fee nor add its own cltv_expiry_delta, so it would use C's requested min_final_cltv_expiry of 9. Presumably it would also add a shadow route to ...


2

I haven't received any fee payments. (...) Any ideas? Or is this expected? Running a LN node does not guarantee you will collect fees. Fees are collected iff you route a payment for another user, so at this time it appears that no users have routed a payment through your node. Factors that could affect this: which nodes you are connected to, the liquidity ...


2

You can secure an LND node in the same way how you would secure any host on the internet. You can for example use ufw to set up a firewall. You could also have a physical firewall in front of you node. Also a big step towards security would be to run no other software on the node. As for backups it is a little bit more tricky. The seedwords will not ...


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