12

There is no substitute in terms of security and trust for running a full node. There are different "lightweight client" concepts. Some of them are... BIP37 (bloom filter): [minus] With current used false-positive rates, peers may learn all wallet addresses [minus] Usually done over an unencrypted channel (p2p 8333), ISPs, etc. learn also all your ...


12

It takes about 200 vbytes to spend from a Lightning Network (LN) Hashed Time-Locked Contract (HTLC) output used for routing a payment. At the default minimum feerate of 10 nBTC/vbyte, that makes it uneconomical to attempt to claim a routed micropayment below about 2,000 nBTC ($0.008 USD at $4,000 USD/BTC). As fees rise, larger and larger micropayments ...


9

A very low value output in Bitcoin (or any similar system) has zero actual value because the cost in fees to spend it would be equal to or greater than the coins it provides. Like someone writing you a check for $0.01, you'd be best off throwing it out because the time it takes to handle it (much less the tiny risk that it bounces and causes you a bounced ...


8

TCP and other stream based protocols do not have a 1-to-1 correlation of application level messages and IP packets. If you call send() 3 times, it might result in sending a single IP packet over the wire (eg, due to Nagle's algorithm which is enabled by default), it might get sent individually as 3 packets, as you would expect from a packet oriented protocol ...


7

Millisatoshi's are the unit in which channel balances are accounted for. They are a necessary accounting unit, if the aim is to enable very small lightning payments amounts, which represents a protocol design choice. If I wish to send, let's say, 1 satoshi on lightning, the routing fee should necessarily be denominated in a sub-satoshi unit, or else fees ...


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


6

Is lightning running on the bitcoin protocol or another blockchain? The Lightning Network operates on the Bitcoin blockchain. However it has its own network protocols and protocols with transactions. It merely uses Bitcoin transactions. The Lightning Network can be ported to different blockchains so long as they support a similar feature set to the Bitcoin ...


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


6

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


5

There is no known way to do this with the current consensus rules nor does it seem likely except via computationally expensive general ZKP. The normal way to make compact proofs of non-membership is to have a hash tree which is ordered by the key you're looking to prove non-membership on. The proof is just the two neighbors that are greater and lesser than ...


5

Yes, but just running a lightning node is not enough. In order for your node to be able to earn fees, it has to have payments passing through it. For this you need to have a routing node, which has at least 2 open channels (where is payment coming from, where is payment going). The more open channels your node has, the more it will be chosen by the routing ...


5

When two channel participants open a channel or update it, they exchange commitment transactions. Each of these commitment transactions allows one party to unilaterally close the channel. The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's ...


5

First of all welcome to the lightning network and keep asking excellent questions! the important information is within the result of the listfunds command. For example here: "channel_sat": 500000, "channel_total_sat": 500000, The channel_total_sat says that the capacity of your channel is 500k satoshi. Whereas the channel_sat says that you own 500k ...


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

Plugins can be written in any language as long as a client library for that language exists. The command line API and the Plugins communicate with lightningd over a unix domain socket using JSON RPC 2.0. As far as I know no Java / Scala lib exists. I have started creating one at this pull request: https://github.com/ElementsProject/lightning/pull/2223 ...


5

The bolt 11 which specifies invoices does not give a rational for this design choice therefor - unless one of the people who build it come along - I can only give an educated guess: So first of all if invoices were valid for an arbitrary time the recipient would have to keep an arbitrary amount of preimages running eventually into memory / Harddisk issues. ...


5

As far as I know It can and did happen. On a protocol level 2 seperate nodes (or the same node) can construct two different (or the same) onions and initiate the routing process. On a protocol level I am not aware of any mechanics to prevent two htlcs on the same channel with the same payment hash and on different channels this is obviously not encoded to ...


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

You are correct. It is not possible to get Diana into the Channel Factory without a transaction that closes and reopens with Diana. Splicing-in and splicing-out as explained by Decker et al. in the paper you mention is not secure. Imagine the following situation: Alice, Bob and Carol spliced out Dave by creating a new Allocation within the same factory, ...


4

The first three scenarios are indeed possible, the last one is identical to the second. This is called a collaborative close. It has the advantage of using a lower on-chain fee since the transactions are not time critical and the users get their coins back immediately (no dispute time). If the other node is unresponsive (offline or doesn't sign a ...


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

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

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

Android Lightning Network wallets https://github.com/ACINQ/eclair-mobile https://lightning-wallet.com


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

As far as I understand this is not needed. Let us assume we have an congested mempool and someone publishes an old channel state. This transaction will not be mined directly as the mempool is congested. The timelock during which this transaction can be revoked via the penalty mechanism is a relative one and starts as soon as the transaction is mined. So, ...


4

What is so special about chacha20 stream cipher along with poly1305 for message authentication codes? There is nothing special about the combination. It's just a combination of two constructions (ChaCha20 for the stream cipher, Poly1305 for MAC) that are designed with similar goals in mind: Easy to write a correct implementation in software Optimized for ...


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

Pretty much everything would stay the same. If you look at the relevant messages channel_announcement and channel_update we have the following formats: channel_announcement type: 256 (channel_announcement) data: [64:node_signature_1] [64:node_signature_2] [64:bitcoin_signature_1] [64:bitcoin_signature_2] [2:len] [len:features] [...


4

First of all: it is in fact not possible at this time to sort a stuck payment. The htlcs are a contract in which you agree to fulfill a payment if the routing node provides a preimage within a time window (the timelock). Assume you would be allowed to remove an htlc before the timelock, not only would this be a breach to the contract but it could easily ...


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