The Lightning Network FAQ

[PrimeNumber7]

People in 3rd world countries will use alts not LN.
Because LN still has the deposit and withdrawal transaction fees of BTC, which for some of those people $5 is a month's wages.

Altcoins offer faster confirmations and overall lower costs of usage than BTC's LN combo service.

 

Providing financial services to third world countries are difficult because of the very small amounts of money involved that will often not result in meaningful profits for anyone for someone in a first world country doing business.

LN may make some inroads into third world countries that are relatively wealthy, but I would see its primary user base to be those in developed world conducting high volume transactions.

Altcoins have been subject to 51%-type attacks with increasing frequency as of recently. This means that for most altcoins, waiting 60 minutes (equivalent to 6 bitcoin confirmations in terms of blocks found), when the altcoin gets the target rate of confirmations, will not give the same level of confidence that it will not be reversed. 

[1715229918]

1715229918

[d5000]

A technical question:

Is it possible to receive a BTC amount on-chain from another person and simultaneously open a LN channel for him/her for me with the same transaction, if the sender cooperates? Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

In theory (if I remember well the funding mechanism of Poon-Dryja channels) at least the first variant (opening a new channel) should not be a problem if you exchange the commitment transactions with your channel counterparty based on the transaction you got from that other person. For this to work, however, the person who has sent the transaction must cooperate and broadcast the transaction to the channel's multisig address only after this exchange took place (which could lead to "logistic" challenges but should be solvable). About the second variant (add the transaction amount to an existing channel), I don't know currently much about splice-ins, but maybe someone here does

I imagine this could be useful if exchanges offered this service. You could withdraw an amount on-chain, and instead to have to do the channel opening transaction yourself additionally, the withdraw amount is added to an existing payment channel or opens another one to a LN node.

Ah, and @Khaos77: All altcoins which reach a certain popularity will get the same transaction cost problem as Bitcoin. Even sooner or later with big blocks (if they are not gigabyte-sized ).

Edit: There was an error in the first paragraph, I corrected it.

[PrimeNumber7]

A technical question:

Is it possible to receive a BTC amount on-chain from another person and simultaneously open a LN channel for him/her with the same transaction, if the sender cooperates? Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

The on chain transition to you would need to have two (or more) outputs, 1 the 'on chain' transaction to you and 2 an output that gets 'locked' in a newly opened channel. This would work very similar to someone opening a channel valued less than the value of an input (less tx fees), and the remaining value being sent to one or more change addresses.

[Wind_FURY]

A technical question:

Is it possible to receive a BTC amount on-chain from another person and simultaneously open a LN channel for him/her for me with the same transaction, if the sender cooperates? Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

In theory (if I remember well the funding mechanism of Poon-Dryja channels) at least the first variant (opening a new channel) should not be a problem if you exchange the commitment transactions with your channel counterparty based on the transaction you got from that other person. For this to work, however, the person who has sent the transaction must cooperate and broadcast the transaction to the channel's multisig address only after this exchange took place (which could lead to "logistic" challenges but should be solvable). About the second variant (add the transaction amount to an existing channel), I don't know currently much about splice-ins, but maybe someone here does

I imagine this could be useful if exchanges offered this service. You could withdraw an amount on-chain, and instead to have to do the channel opening transaction yourself additionally, the withdraw amount is added to an existing payment channel or opens another one to a LN node.

Ah, and @Khaos77: All altcoins which reach a certain popularity will get the same transaction cost problem as Bitcoin. Even sooner or later with big blocks (if they are not gigabyte-sized ).

Edit: There was an error in the first paragraph, I corrected it.

Gigameg blocks, the miners, the pools, and the data-center-node-operators bear the cost, and also at a cost to the user because he/she cannot verify the transactions him/herself.

I know it's not convenient for most of the people to run a full node, but it shouldn't suggest that the Core developers must make design-decisions that should take away anyone's ability to run one.

[darosior]

I noticed you answered your question yourself after having written the answer, so here it is anyway (TL;DR: you are right).

A technical question:

Is it possible to receive a BTC amount on-chain from another person and simultaneously open a LN channel for him/her for me with the same transaction, if the sender cooperates?

Yes, but only if the sender effectively cooperates as otherwise your funds would be stuck in limbo.

You need to:

• Start the funding process with your peer (here you get the keys to form the 2of2 Script)
• Get the sender to create a transaction which pays to this Script and hand you the txid
• Complete the funding process with your peer by exchanging the commitment transactions refering to the txid
• Have the sender broadcast the transaction (hence trusting them to not change the transaction, which would change the txid before doing so.

FWIW, it's possible with c-lightning if you want to try this out with the (dangerous) fundchannel_start, fundchannel_complete commands.

Or even better: use a BTC amount on-chain transaction and refund an already opened channel (this would be a kind of splice-in)?

It's possible in theory but has not been spec'ed. You can find some discussions about this on the #lightning-dev ML (end of 2018 iirc).

I imagine this could be useful if exchanges offered this service. You could withdraw an amount on-chain, and instead to have to do the channel opening transaction yourself additionally, the withdraw amount is added to an existing payment channel or opens another one to a LN node.

Yes, splice-in / splice-out would be great (and a lot of people are looking forward to it) but is quite complex state-machine-wise.

[d5000]

The on chain transition to you would need to have two (or more) outputs, 1 the 'on chain' transaction to you and 2 an output that gets 'locked' in a newly opened channel. This would work very similar to someone opening a channel valued less than the value of an input (less tx fees), and the remaining value being sent to one or more change addresses.

In my post there was an error (because I had changed the wording to be clearer from active to passive but forgot to change a crucial part  ). so I think your post answers the "wrong" question correctly. What I meant was to open a channel for the receiver of the coins, not the sender. Thanks anyway

@darosior: Thanks! So it works a bit like I imagined. But your answer made it clearer for me, above all the part you highlighted about the trust which is necessary for the transaction sender. Incentive-wise, however, in the case the sender is a service like an exchange, which must be profitable and thus "just work", there is no reason for him to "cheat" changing the transaction ID, and you would also not lose anything beyond transaction fees.

Thanks also about the hint about the mailing list discussion, will see if I find it.

[darosior]

Incentive-wise, however, in the case the sender is a service like an exchange, which must be profitable and thus "just work", there is no reason for him to "cheat" changing the transaction ID,

For the general case I tend to agree, but it is too big an assumption here because of how bad it can get.

and you would also not lose anything beyond transaction fees.

No! You would loose the complete access to the utxo, as in this case you comitted to a multisig with your channel partner [which you don't trust and] which provided you with a "refund" transaction... Not valid anymore (as it spends a non-existent tx). As this "refund" transaction is actually the first commitment transaction, neither the channel can operate.
The only way out of this is to beg your channel partner to be nice and sign a new refund tx for the real tx.

Both the spender and your channel peer have a leverage on you.

[jackg]

I think bitcoin too was made overly complicated for the average person - but I don't know what the average person wants. Most currency systems could do with a mixture of government banks and private holders imo.

[LoyceV]

I think bitcoin too was made overly complicated for the average person

So is fiat money
But none of that matters to the average person: you don't need to understand the complicated details to be able to use it.

[jackg]

I think bitcoin too was made overly complicated for the average person

So is fiat money
But none of that matters to the average person: you don't need to understand the complicated details to be able to use it.

The fractional reserve systems are confusing but its better than guineas, pounds, shillings, crowns, pennies....

And yeah I do agree if you have enough tutorials and enough confidence in the concensus then you'll be able to run stuff yourself. And an ln with Central companies isn't much different than what some companies have already tired or do (I think binance has its own token deposit system for currencies).

[d5000]

No! You would loose the complete access to the utxo, as in this case you comitted to a multisig with your channel partner [which you don't trust and] which provided you with a "refund" transaction... Not valid anymore (as it spends a non-existent tx). As this "refund" transaction is actually the first commitment transaction, neither the channel can operate.

Ah! I think you're right, I didn't take into account that the receiver of the tx loses control completely over the funds as the sender is the only one signing the transaction which transfer the funds to the channel's "multisig address".

What if we organize the transaction in a different way: if you're the receiver, the sender of the transaction only signs his input, sends this information to you, and you use an additional input controlled by yourself and sign the TX? So you would have the control over the txid. This would result in a bigger transaction (in bytes) but still could have advantages over an approach with two transactions. But I don't know if Bitcoin allows that ...

For the sender this would mean less control over the transaction, but this wouldn't matter for them, for example in the case of the exchange, it would simply reduce your balance in the database.

Possible problem: If the sender knew when you exchanged the commitment transactions and he cooperates maliciously with your channel partner, however, he could try to instantly spend the output in another transaction hoping it gets confirmed first than your transaction. This would be however a relatively risky attack.

[darosior]

What if we organize the transaction in a different way: if you're the receiver, the sender of the transaction only signs his input, sends this information to you, and you use an additional input controlled by yourself and sign the TX? So you would have the control over the txid. This would result in a bigger transaction (in bytes) but still could have advantages over an approach with two transactions. But I don't know if Bitcoin allows that ...

Yes Bitcoin does allow that, and that's what is used by the channel dual funding proposal .
EDIT: (just to be explicit) you would have to have some interaction with the sender though, as they need to know about your input to sign the transaction (with sighash ALL). The other way around would be to use ANYONECANPAY, but it's not possible as it would create a malleability vector (which becomes an attack vector in this case as it would change the txid).

Possible problem: If the sender knew when you exchanged the commitment transactions and he cooperates maliciously with your channel partner, however, he could try to instantly spend the output in another transaction hoping it gets confirmed first than your transaction. This would be however a relatively risky attack.

How so ? The sender does not have a key in the multisig.

[jackg]

Possible problem: If the sender knew when you exchanged the commitment transactions and he cooperates maliciously with your channel partner, however, he could try to instantly spend the output in another transaction hoping it gets confirmed first than your transaction. This would be however a relatively risky attack.

How so ? The sender does not have a key in the multisig.

There's a time lock added to commitment transactions of whatever the dev sets it at but its normally between 24 hours and 2 weeks depending on how active the node is - so this type of attack could be mitigated.

[darosior]

There's a time lock added to commitment transactions of whatever the dev sets it at but its normally between 24 hours and 2 weeks depending on how active the node is - so this type of attack could be mitigated.

Yeah, i know about commitment transactions however i fail to see the attack.

[d5000]

Possible problem: If the sender knew when you exchanged the commitment transactions and he cooperates maliciously with your channel partner, however, he could try to instantly spend the output in another transaction hoping it gets confirmed first than your transaction. This would be however a relatively risky attack.

How so ? The sender does not have a key in the multisig.

The channel partner has a key, and in theory he could cooperate with the sender of the funding transaction. So what I meant was that the sender could send the money to the multisig address using another funding transaction which competes with the "legit" transaction which uses your input. We would arrive then at the same problem you described: the txid would have changed, invalidating the commitment transactions.

However, I don't know if this attack makes any sense - could the channel partner access these funds or could they only be mobilized again if both channel partners cooperate and provide their signatures to close the channel?

Thanks for the link about dual funding - I will have to read a bit more about sighash ALL and ANYONECANPAY (Edit: for those interested: that seems a pretty good explanation) so I can understand what you meant with the malleability attack vector.

[jackg]

The channel partner has a key, and in theory he could cooperate with the sender of the funding transaction. So what I meant was that the sender could send the money to the multisig address using another funding transaction which competes with the "legit" transaction which uses your input. We would arrive then at the same problem you described: the txid would have changed, invalidating the commitment transactions.

Afaik this has the ability to lock funds in some sort of stalemate if you're saying someone double spends the input transaction so the CT becomes invalid itself. Double spending the same funds between two different channels I think wouldn't be possible as the old CT is either already invalid or set to be when the new one is produced - so you'd have to present your new balance as being whatever the last CT said it was.

Also, I think it's generally recommended to leave a wallet open as the CT confirms as I think if you send via mainnet to a CT and something changes while it's unconfirmed - wallets might be coded to. Double spend and return the funds back to you although at the moment only one person funds a ct so I assume the other can't provide funds without both sides agreeing.

[darosior]

The channel partner has a key, and in theory he could cooperate with the sender of the funding transaction. So what I meant was that the sender could send the money to the multisig address using another funding transaction which competes with the "legit" transaction which uses your input. We would arrive then at the same problem you described: the txid would have changed, invalidating the commitment transactions.

However, I don't know if this attack makes any sense - could the channel partner access these funds or could they only be mobilized again if both channel partners cooperate and provide their signatures to close the channel?

I don't think so, but i do think that it is an interesting thought because it comes to the blurry limits of what defines a Bitcoin payment. Not the technical mean which is the transaction, but the conceptual action of transferring value.

If you hand me an address, and i do a transaction which pays to another address. Would you accept it as a payment ? No.
If we collaborate to create a transaction to pay you, and i finally broadcast a different transaction, would you accept it as a payment ? You should not. This is not an attack, just an absence of payment.

This is why I think the proof of payment feature of Bitcoin Lightning Network payments is important, and that we *must preserve it*. We can always bikeshed on the definition of an onchain Bitcoin payment, and endlessly argue if there was a transfer of value. If we use the Lightning Network, we just have a proof that the transfer occurred.

[d5000]

I don't think so, but i do think that it is an interesting thought because it comes to the blurry limits of what defines a Bitcoin payment.

Definitively. I have also had some thoughts about that. I think it depends mostly on the kind of payment which was made.

The use case I originally had in mind, as I wrote above, is an exchange or web wallet which would allow its users to "withdraw coins to a Lightning channel" with an onchain payment. Of course, if the exchange itself is connected to LN, and the channel of the user who wants this kind of payment is bidirectional, a direct LN payment is a better alternative. But there are cases where an on-chain payment could be preferrable:

- if the user wants to increase his LN capacity
- if he has only an unidirectional channel
- if the service provider (exchange, wallet etc.) isn't connected to LN, for example for regulatory reasons (I read this argument somewhen, but I dunno if it really realistic)

In these cases, for the service provider it doesn't matter to which address he pays, as long as the transaction is under control of the customer. The service provider simply "hands out control" of the used UTXOs to the customer and deducts the amount of them from the user's balance.

So in this case, if I interpret the SIGHASH variants right (according to the above linked article), I could imagine a combination of SIGHASH_ANYONECANPAY with SIGHASH_NONE (if a whole UTXO under control of the service provider is used, the service provider simply "hands it out" to the customer and deducts the amount from his balance once the tx is confirmed - no matter to what address) or SIGHASH_SINGLE (if a part of the coins has to be transferred to a change address of the service provider) could be used for this kind of withdrawals.

What I still not understand is which malleability attack could be arise from that combination. I interpret if the service provider agreed to SIGHASH_ANYONECANPAY and SIGHASH_NONE, then the customer would have complete control over the TXID. He could prepare the funding transaction, exchange commitment transactions with the "channel partner" and then broadcast it. Or am I understanding something wrong?

[darosior]

The use case I originally had in mind, as I wrote above, is an exchange or web wallet which would allow its users to "withdraw coins to a Lightning channel" with an onchain payment. Of course, if the exchange itself is connected to LN, and the channel of the user who wants this kind of payment is bidirectional, a direct LN payment is a better alternative. But there are cases where an on-chain payment could be preferrable:

- if the user wants to increase his LN capacity
- if he has only an unidirectional channel
- if the service provider (exchange, wallet etc.) isn't connected to LN, for example for regulatory reasons (I read this argument somewhen, but I dunno if it really realistic)

In a future with a more complex LN protocol wrt fees (currently the opener pays everything, which is a bad incentive for such entities to directly open a channel), the exchange could just open the channel and pay the opener through the first commitment transaction pair ?

In these cases, for the service provider it doesn't matter to which address he pays, as long as the transaction is under control of the customer. The service provider simply "hands out control" of the used UTXOs to the customer and deducts the amount of them from the user's balance.

Yet another fundamental thought . In a future where a high number of people use Bitcoin LN won't be enough and we definitely need a way to:
- Allow a shared management of utxos
- Allow to hand utxos as you describe (without an onchain tx, so maybe hand the control of a LN channel ?)

To the best of my knowledge the closest proposal to that are channel factories.

So in this case, if I interpret the SIGHASH variants right (according to the above linked article), I could imagine a combination of SIGHASH_ANYONECANPAY with SIGHASH_NONE (if a whole UTXO under control of the service provider is used, the service provider simply "hands it out" to the customer and deducts the amount from his balance once the tx is confirmed - no matter to what address) or SIGHASH_SINGLE (if a part of the coins has to be transferred to a change address of the service provider) could be used for this kind of withdrawals.

By signing a transactiono using ACP|NONE you are giving the control not only to your customer but to anyone who claims it, so basically the first miner to include the tx .

The only way to securely hand an utxo (still, that i know of) is currently to unlock it and re-lock it to the receiver through an on-chain transaction. There might exist some more complex design to hand the *control* or *part* of the utxo (re channel factories).

[d5000]

In a future with a more complex LN protocol wrt fees (currently the opener pays everything, which is a bad incentive for such entities to directly open a channel), the exchange could just open the channel and pay the opener through the first commitment transaction pair ?

Sure, as long as the exchange doesn't have any issues (regulatory etc.) to connect to LN.

By signing a transactiono using ACP|NONE you are giving the control not only to your customer but to anyone who claims it, so basically the first miner to include the tx .

Ah, uh. I may have understood something fundamentally wrong then. So SIGHASH seems to refer always to the signing of complete transactions, not just utxos? But this contradicts what I understood in Sood's blogpost ...

I quote the part of the blogpost abouth Sighash I misunderstood perhaps:

SIGHASH_NONE - This one is a bit more confusing. On the face of it, it seems like you’re burning money by not signing any outputs. Indeed, if you create a tx with just a single input and sign it with SIGHASH_NONE, the miner would be able to simply change the output to one that they control. This is mostly designed to be used in scenarios where more than one party is contributing inputs. At that point, such a signature essentially means “I agree to spend my money, provided all these other people spend their’s too”. It is expected that one of the other signers will then use SIGHASH_ALL to secure all the outputs of the transaction, and send the money to a mutually agreed output set.

I interpreted this that way, that you could send a "pre-transaction" with your UTXO as an input, signed with SIGHASH_NONE and SIGHASH_ANYONECANPAY via a secure, encrypted communication channel (so miners can't still see it) to another person and this person could add his input and sign it with SIGHASH_ALL and broadcast it. This person (the receiver) in my example from above would be the customer of the service/exchange, and the sender, the service itself. So miners would only get access to the transaction once the customer would have "completed it", and then it's late for them to "grab it" because it was already signed with SIGHASH_ALL.