Topic: The Lightning Network FAQ - page 60. (Read 33714 times)

I can think of a different scenario: you can open a LN-channel when fees are low, and make a low-fee transaction when you need it at a later moment. Especially when paying for a time-sensitive service this could save you money.
It can fail though: I've had a channel that didn't open because my low-fee transaction took to long to confirm, and when it was closed it did CPFP which lead to a much higher fee.

In order to realize cost benefits of using LN, you must make at least three LN payments, assuming consistent fees, at least 66.67% cost savings per/tx and a non-zero cost of making a LN transaction. If you don't plan on making at least 3 txns, you are probably better off using on-chain txns.

LN channels are really designed to be kept open near infinitely. The cost savings for using LN will increase exponentially as you keep channels open longer, specifically, how many txns you send on a channel (the exponent is very small).

It's a little bit more complicated than I thought at first. I will have to read more.
I found it interesting because I want to buy bitcoin to use every day for various small things, as I asked here . There are various places around me that accept cryptocurrencies, which is great.
I think this is the future of finance and I decided to start using it now.
Seems that the LN thing is way out of my league, yet.

@btcduster: For relatively small amounts, I used to prefer an exchange that accepts LN-payments instead of dealing with channels. But my favourite (CoinPlaza.it) has largely increased the fees for doing so (probably because of on-chain fees). There are similar exchanges around so you might find a better deal again.

However, if you're looking to sell just something, and to instantly convert your LN Bitcoin to on-chain Bitcoin, you're better off just asking for a Bitcoin payment. LN only has benefits if you make multiple transactions to enjoy the low fees.

No, Lightning Network does not use addresses for payments. Instead, you need to create an invoice. Some implementations already support invoiceless payments, but those are not available in most LN wallets and I am not sure if they are cross-compatible between implementations since this feature is still not a part of the official specifications. Keep in mind that you can't start receiving payments right after you open a channel. I have described it in detail in the FAQ.


In order to move your coins off-chain, you need to open a channel with some node. That requires you to send an on-chain transaction to a 2-of-2 multisig address controlled by you and the other node. The transaction will be created automatically by your wallet. The channel will become active after the transaction reaches a few confirmations. In order to move the coins back on-chain, you need to close the channel. If the other node is online, the closure should happen instantly and your on-chain address should receive your remaining LN balance minus the closing transaction fee. If the other node is offline, you will have to wait some time before you can broadcast your closing transaction. It's a cheating countermeasure. As you can see, you will pay only for two on-chain transactions and you will be able to make an indefinite number of off-chain transactions.

By the way, if you are interested in using Electrum's implementation of the Lightning Network, check out this thread.

I found this wonderful thread after checking the size of the fees that are paid for transactions.
This may be the solution for small transactions, but I have a question.
If I decide to sell something with LN payment, can I use an address that is outside the LN wallet?
In other words, do I pay fees to transfer bitcoins from LN network to,let's  say, my Electrum wallet? If it is an off-chain transaction, how to I go back on-chain?

Ah, ok, I think I understand now. So Sighash flags are only valid for the inputs and outputs you sign, and any person who has access to the unconfirmed transaction can try to "steal" inputs which are only signed with the SIGHASH_NONE flag and get it confirmed earlier as your transaction, even if someone has signed it with SIGHASH_ALL.

In this case it seems SIGHASH_NONE in its current iteration is pretty pointless or flawed, as it is basically always a "donation to the miner".

What would be needed instead is a way where one party could give out a signed output to another person to include it in a transaction, with the condition to sign it in a way it can't be stolen (e.g. with SIGHASH_ALL), and if I understand your posts the right way, this is not possible currently (at least not easily).

(If this is correct it's not necessary to answer me, as I think this sub-thread has already become a bit long and it is not totally LN-specific I'll look if I find more info about that by myself. Thank you for your explanations!)

No, the signature is valid for an input but signs what the sighash mode tells it to sign. What i mean is that if you have a 2-input transaction with one NONE-signed input and one ALL-signed input, someone can just malleate the transaction by removing the ALL-signed input and creating an output paying them.

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

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

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 ?

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.

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

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?

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.

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.

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.

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

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.

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

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

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.

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

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.