Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
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 ...


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

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

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

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

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

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.


3

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


2

there is an issue out discussing the strategies for the autopilot (c.f.: https://github.com/lightningnetwork/lnd/issues/677 ) there it is stated that it currently uses a constrained barabasi albert model or preferential attachment ( https://en.wikipedia.org/wiki/Barab%C3%A1si%E2%80%93Albert_model ) this means that it will look at the topology of the network ...


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


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