6

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


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

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


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

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


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

It is possible to run Lightning (both LND and c-lightning) with bitcoind pruned mode. There are already packages turning the pruned mode on when disk space is limited: Lightning Power Node Launcher (works with LND) and BTCPayServer docker (works with c-lightnig). There is a lot of conflicting information online, because it became possible only after ...


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

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


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


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

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


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

Yes this is theoretically possible as described in this video https://youtu.be/bihYeAeNi0g The idea is to have a deterministic way of generating preimages and entangling the lightning node with the point of sale device. This idea originated from stepan snigirev who went down further and refined it to this idea: https://lists.linuxfoundation.org/pipermail/...


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

In each of your channels, you have a local balance. This is the balance that is yours in that channel. The counterparty of the channel has the remote balance. All lightning transactions change these balances with each one resulting in their sum being the same and matching the channel capacity. As all transactions in that channel just end up changing the ...


4

Walletbalance is showing your on-chain balance of a lightning wallet. Regarding channel balances (locked on layer 2 and not available onchain): local balance is your local balance that you can spend on lightning network remote balance is balance in your channels but it's being owned by the other party in the channel, this is the amount you are able to ...


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

You are correct in that you cannot run a LND node with a pruned bitcoind server. Pruning isn't compatible with transaction indexing because the index would point to transactions which have been pruned (no longer in store). Each lightning node requires transaction indexing, because it will be looking for specific txid's on-chain throughout the lifetime of ...


3

The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each channel_announcement contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a channel_announcement non-free, and binds some resources ...


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

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


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

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

Generally when paying an invoice a chain of htlcs from the sender via some path on the network to the recipient is set up. The htlcs lock in by exchanging signatures on every local channel. Now there is a min timelock which is the amount of time the payment can take. Or the time frame in which the htlcs must settle by releasing a preimage to have a ...


3

The Problem here is the channel reserve. If you fund a channel all the bitcoin are on your side. At this point you can only pay. However let us assume you make a really small payment (below 1% of the channel capacity) your channel partner can't pay you back on that channel. After establishment lightning channels are required to keep at least 1% of the ...


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