Tag Info

How will the lightning network handle lightweight clients? Most steps during the payment process in an LN channel don't actually require full knowledge of the blockchain or even the unconfirmed (mempool) transactions. This is because the transactions involved deal with 2-of-2 multisig scripts, where both parties have to sign off on each transaction to make ...

The lightning network is comprised of bi-directional payment channels between two nodes. This means that either one of those nodes should be able to initialize a transaction at any time. These transactions require both parties to be actively participating in updating the smart contracts that keep the channel alive. If one party fails to respond, they are ...

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

Short answer: no (unless you control all nodes on that path) However the problem about uncertainty is part of the routing anyway. You know the topology of the network with the cltv deltas, routingfees and capacity of ech channel. Yet you never know how the capacity is split into balance of a channel. so once your lightning nodes computed a potential path ...

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

This is a tricky question as it tackles the difference between what the protocol supports and what implementations provider as an API. On a protocol level channels are enabled / disabled via an update message on the gossip Protocol. Nodes SHOULD set the disabled flag and send such a message if they are shutting down or turning (shortly) off for maintenance....

I suppose that when you refer to "third-party watchers" you mean watchtowers. I do agree that 'trustless' is probably an ambiguous word in this context. At the time of writing, the only actual proposal with a protocol that I am aware of is PISA, by Andrew Miller et al. PISA allows users to select a custodian that will be incentivised in publishing. Users pay ...

A Lightning Channel does not have any requirement as to when to close the channel, as specified by BOLT. It is entirely decided by the user, and the implementation. For the case of lnd, whenever the user wants to close the channel, he will call closechannel trying first to perform a cooperative close, unless specified otherwise: Name: "closechannel", ...

If the transaction cannot resolve before the CLTV value of the HTLC runs out the peers will be refunded (the pending HTLCs cancelled) and the transaction will be cancelled. If C is not there to receive R funds will not move so there is no need for force closures, but the funds will be stuck on the online channels as well for that period of time. The online ...

Unless I have misunderstood the LN, the R value gets disclosed publicly when D accepts the payment, allowing the entire backchain to claim their parts.

This sounds like a web wallet, where the keys were managed for you and you simply interact through a website. You'd have to trust the third party, but as we've seen on the main network, this is acceptable to a great number of people. Just like with the existing Bitcoin network, you have to run things yourself to be trustless, but there are more convenient ...