6

This was answered by Christian Decker on Telegram. Just because the specification allows something doesn't mean every implementation has to implement it and support it. In c-lightning's case it is both an architectural choice (multiplexing multiple channels onto a TCP connection is not trivial) as well as a conviction (peer diversity beats doubling down on ...


5

I guess this has historical reasons. The short channel ids where there first in the onion format. C Lightning even today does not support multiple channels between 2 nodes. Lnd on the other hand does. That is why lnd developers started to switch the channel if a second channel with enough balance between the nodes existed. Later on it was agreed to add the ...


5

I seem to remember that Lightning channels could remain open indefinitely with the introduction of CLTV I think instead of "CLTV" you mean "CSV" (as in OP_CSV, BIP112). As far as I know, nobody claimed that OP_CLTV would allow HLTC-style (Lightning) payment channels to stay open indefinitely, but that was definitely a claim of OP_CSV. An additional ...


4

The payment channel between Alice and Bob is encoded as a 2-2 multisig Adress the balance of that Adress is the capacity of the channel. A channel is opened by sending funds to that multisig Adress via a funding transaction. These funds do exist (on the Bitcoin network) and are by no means virtual. Alice and Bob each control a key of that Multisig Adress ...


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

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


3

I am not aware of a clear definition for the term zombie channels. At least I don't recall the term being used in the lightning rfc. Also I didn't hear lightning devs in conversations to talk about them. Thus I think the semantics are more along your suggestion that they refer to channels which are for some reason obsolete / inactive / unusable. Disclaimet: ...


3

A funding transaction is one where some money is paid into a P2WSH transaction output, where the redeeemScript is a 2-of-2 multisig between the two participants. No other information is provided. Technically, even the redeemScript for the funding is not revealed until the funding transaction output is spent (channel closed), which makes it less obvious that ...


3

There seems to be a mix in notation. Payment channels on lightning are bidirectional by design. However that does not mean that funds can always flow on both directions. Currently channels are funded by one party an as such can not receive funds after opening. As was mentioned in the comment what you mean is called a dual funded channel. As soon as you use ...


3

Lnd itself does as far as I remember not provide an api for rebalancing channels. However there is the lndmanage repository that uses the lnd api to provide a pretty strong rebalancing tool https://github.com/bitromortac/lndmanage Such rebalancing will cost you routing fees as they are regular (circular) payments. That being said it is not clear why you ...


3

Alice and Bob jointly create a public key R for each revocable output (RSMC output script). They each privately generate r-1 and r-2, and derive public keys R-1 and R-2 from these. R is the sum of R-1 and R-2. No secrets have been exchanges, only public keys. So R is unspendable by either. However, it is spendable by r = r-1 + r-2 When a new commitment tx ...


3

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

Yes. The channels are announced with the node ID. If the ip Address changes we get a new node announcement message so it takes some time until the information is through the gossip protocol. But moving a node to a new server is no problem


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

Streaming payments is not part of the lightning network protocol yet. However you can build a lightning app that simulates exactly this. There was a demo by alekos Filini on lädt years lightning residency. Check out https://youtu.be/IlSVTir_9Ns When AMP is coming streaming payments could be stimulated with AMP by setting up more and more routes. But that ...


2

It seems to me that the field time_lock_delta in LND corresponds to what BOLT#7 refers to as cltv_expiry_delta. Which the specification explains to be "the number of blocks it will subtract from an incoming HTLC's cltv_expiry". Hence, the unit would be a count of blocks.


2

You are not required to forward htlcs and engage in routing if you join the network. A relative easy way to achieve this is by only having non public channels. However that does not guarantee you that your channel partners might not learn about your channels and still use them. Another way to achieve this is by only having a single channel (though that makes ...


1

The channel_id in 1ml seems to be the lnd encoding of the short_channel_id. Note that the short Channel ID is just 3 bytes of blockheight, 3 bytes of transaction index within the and 2 bytes for the output index within the transaction. While BOLTs recommend to serialize this as HEIGHTxINDEXxOUTPUT lnd just concatenated those 8 bytes and displays them as a ...


1

Like vincenzopalazzo commented - it never stops growing by design. Solution is to add db.bolt.auto-compact=true to the lnd config. Then the db gets "compacted" (means cleaned-up here) at lnd's startup. But take care for enough disk space. Why it sometimes grows so fast could not be revealed. The complete discussion is here: https://github.com/...


1

This seems pretty normal. When you force close a Chanel this means that your node publishes the latest presigned commitment transaction. However we have no way of knowing if is really the latest or an older one. That is why there is a timelock on your own output which gives the other party time to invoke the penalty mechanism in case you didn't vpublish the ...


1

483 because the commitment transaction might otherwise become too large if it hits the chain. Ramifications are: blackmail fee attacks (c. F. https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002735.html a similar attack is known as flood and loot) possible congestion of channels (right now only if conducted by an attacker but later ...


1

I've been running a c-lightning node over Tor with 2 open channel for a few months and it still hasn't forwarded any payment. With two channels that's not surprising. but I noticed my channels status shows this log: CHANNELD_NORMAL:Funding transaction locked. They need our announcement signatures. The announcement signatures are retransmitted upon ...


1

When the channel is opened the opening side of the channel chooses if the channel should be private or announced. Well actually the other side can also choose not to accept public channels. Maybe that has happened with both of your channels. From the information you have we can only guess / speculate. If you want to you can try to open a channel with my ...


1

Channel funding (and the distribution of funds) is determined at the time of channel opening. Once opened, a party cannot ‘add funds’ to the channel, this would require opening a new channel. If you opened the channel and did not specify that some number of sats should be pushed to the remote node at the time of opening, then the channel will open with the ...


1

Everything but the last Comand looks correct. There is no command channel in c-lightning. In order to open a channel you need to execute cli/lightning-cli fundchannel id satoshi [feerate] [announce] [minconf] Fund channel with {id} using {satoshi} (or 'all') satoshis, at optional {feerate}. Only use outputs that have {minconf} confirmations. The thing ...


1

What is happening when a channel is pending when opened? How long does it usually take? A node establishes a channel by sending an open_channel message to its desired peer. This message specifies the parameters under which the channel will operate (e.g. the number of bitcoin the channel will be funded with and the cost to route payments through the channel)....


1

Opening a channel involves sending an on-chain transaction (with a multisig output controlled by the channel’s participants), so when the channel is ‘pending’ it simply means this transaction is not yet confirmed. How long it takes the transaction to confirm depends on the same factors as any other transaction. Further, the participants will often wait for ...


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