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

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


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

Yes, a channel opening involves creating and signing 3 transactions, and broadcasting just one. The transaction to be broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel. When this funding tx receives sufficient confirmation, the channel is considered open. This multisig output is spent by two ...


3

First of all we should understand the difference between capacity of a channel and its balance. The capacity is the amount of Bitcoin provided to that channel. The balance encodes the amount of bitcoin which each channel partner owns in the channel. so the sum of the balances will always be the total capacity of the channel. Second we currently do not ...


3

In your scenario you would like to create a payment channel with user 1 and 2 contributing (on-chain) and receiving (off-chain, in the payment channel) the following amounts: User 1: 2 btc User 2: 1 btc To open and fund the channel accordingly, you therefore create the following funding transaction: Input 0: 2 btc from user 1 Input 1: 1 btc from user 2 ...


3

Stuff like this can usually be found in the lightning-rfc aka BOLT (basics of lightning technologies) which is the formal protocol specification. Currently channel capacity can't succeed 1/6 of a Bitcoin. However for BOLT1.1 (the next version of the protocol) it was agreed that this limit should be dropped (if both nodes of a channel agree to do so). Single ...


3

A lightning funding transaction is a P2WSH transaction, which appears on chain as paying to some random-looking script hash, but the redeemScript which can unlock and spend the money is not revealed on chain until the transaction gets spent (which is when the channel gets closed in Lightning's case). You can recreate the redeemScript if you know the funding ...


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

Whether you run a full node or a lightweight node is a first layer question. It is a question about how you keep track about what happens on the blockchain. And even though this is important for you, the Lightning nodes that are communicating with your Lightning node do actually not care about it and in fact they don't even (have to) know about your Bitcoin ...


3

Are these two problems effectively solved with segregated witness? One is; one is not. Specifically: (1) The anchor transation id required for the commitment input will only be known once the anchor is signed. Segwit fixes this. If the anchor transaction contains only segwit inputs, then its transaction identify (txid) does not change when signatures ...


2

Because a fee is part of a transaction, the fee must be paid by whichever party creates the funding transaction. Don't think of it as paying a fee to open a channel, think of it as funding a channel with a transaction. The fee just happens to be part of the transaction. I believe the current spec has just a single party funding a transaction, but I see no ...


2

The current protocol implementations only allow one party to fund a channel. If only one party funds the channel, then the first payments can only be sent from the funding party to the counterparty. After that, subsequent payments could go both directions (until the entire channel balance rests with one party, at that point transactions could again only ...


2

So in the first step you make a regular transaction from your address A to our common 2-2 address C, and I make a regular transaction from my address B to our common 2-2 address C? Yes, although in the current lightning spec and implementation, only one party funds the channel. However it could certainly be both parties that fund it. I have one key of ...


2

Does opening a channel mean that a 2-to-2 multisig address (3xxxx) is created? Yes. But it's not always a 3... address. Such addresses must be segwit, and there are two types: nested (3... address) and native (bech32 addresses, bc1..). And then both parties put money into the address? For now, only one party puts money into the address. But ideally both ...


2

When you start using lightning, the minimum bitcoin you need is the cost of opening the channel + anything else you want in the channel. The cost of opening the channel is equal to the fees you pay to send a transaction. So as a minimum you will need: the lowest fees you can get away with to send a transaction + the amount you want to put in the channel. ...


2

They can only be detected when force closed and there are still pending htlcs otherwise they look like a spend from a 2-2 multisig wallet. I've been told some people try to do chain analysis and machine learning to predict private channels. I highly doubt that this is reasonably possible. Although there is one thing to consider. If a node has public and ...


2

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


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

lncli pendingchannels gives a pendingChannelRespnse which might have the pending_open_channels parameter. This contains an array of PendingOpenChannel objects. According to the documentation they should have a parameter confirmation_height which is the height of the blockchain at which the funding TX has enough confirmations (the max of your and your ...


1

Not all implementations support multiple channels between two nodes. That is why I would advise against that practice. Also I do not really see an advantage of having two channels. We don't have Atomic multipath routing yet so in general it makes more sense to have larger channels. Only counter argument I see is that one channel can only have 483 htlcs ...


1

Here there are some properties: Node reliability: On-line connected 24/7. History: when the node came online for first time. Routing: How many channels has the node. Capacity: How much capacity can the handle through channels


1

I will only give the answer for a mutual close. The situation for unilateral (forced) channel close should be similar only that you have too look in the commitment transactions and that you have to look for local_delayedpubkey instead of localpubkey. You can look at BOLT 03: Transactions where it is specified. In particular the section closing transaction. ...


1

Is there a minimum limit of bitcoin that can be added into a channel during the initialization? According to the Lightning Network Specifications: "The amounts for each output MUST be rounded down to whole satoshis. If this amount, minus the fees for the HTLC transaction, is less than the dust_limit_satoshis set by the owner of the commitment ...


1

It seems you're having technical issues with the app. I would recommend to bring this issue to the devs on their forum: https://gitter.im/ACINQ/eclair. Also, please prepare to have all info such as the version of the app, your OS, mainnet or testnet.


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


1

When opening a lightning channel, is there any data immediately written to the blockchain? I mean, the channel is not considered opened until the data is on the blockchain. The data may be the funding transaction, or may be some sort of 2-to-2 multisignature script, I don't know. The channel has a funding transaction which must be included in the blockchain ...


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