Topic: The Lightning Network FAQ - page 59. (Read 33287 times)

All major implementations now support "wumbo". It allows node operators to create and accept channels larger than 0.16777215 BTC and payments larger than 0.04294967 BTC. While the vast majority of users won't "go wumbo", operators of large nodes might benefit from it by having to rebalance their channels less often.

Instructions on how to enable "wumbo": LND, c-lightning, Eclair

I'm trying it with 15p because theoretically it could work and may do so I want to try it... My thought is that for a while therell only be one person funding a channel so it might just be credited but it's unlikely - I'm still just curious though.

I'll post my results if it works but even if it does it might just rely on individual configurations.

---

Edit: not entirely sure what happened to t, I woke up with about 200 notifications overnight so I don't remember what it said but it said something like "suspicious activity noticed" as a notification from elcair - I think it might have gone through on the other side and my side just refused to sign for it as a security measure.

No, this is called splice-in (or out - same but decrease channel capacity). See above, it's theoretically possible but not yet spec'ed.

As far as I know, this isn't possible.
A way around this is to use a custodial wallet. This this morning I asked someone to pay to a Bech32-address that goes straight into my BlueWallet LN balance, and by creating a new LN wallet each time, I can use different addresses for this.
Custodial isn't perfect, but for small amounts I don't mind.

Again I am with a question.
When I open a channel, I only use the coins that are in the channel to move them back and forth. If I want to take out some of the coins that have gathered in the channel, I have to close it and open a new one, right?
Can anyone else fund my channel? For example, Bob and Alice have a channel that is 0.001BTC, can Jack transfer 0.0001 coins to Bob and Alice's channel outside the LN and thus increase the channel volume to 0.0011?
The idea is if someone has to send me BTC he can directly fund my channel.

When you are sending a payment via LN, you will not need to deal with any type of change output, therefore you will not need to pay anything to consolidate change outputs, ever. When you spend coin on-chain, you will receive a change output, and eventually you will need to pay to consolidate two or more change outputs. If you have enough other coin, you can send a tx to yourself with a low fee, and hope the txn will eventually confirm (it may not). Or you can pay an increased fee (in terms of blockspace) for a txn that has two inputs and two outputs for something you would normally buy, and in this case you generally need to pay a 'market' fee. In both cases, you are incurring costs in addition to what you would 'normally' incur when dealing with on-chain txns.

You don't even have to time it, you can just wait for fees to drop, and then make a transaction. I know this doesn't guarantee anything for the future, but my counter argument would be fees can rise right after broadcasting any Bitcoin transaction.

Do you consider consolidating UTXOs at 1 sat/byte as the same then? If you can save even more money and enjoy instant payments at the same time just by opening your channel at the right moment then I don't see any problem. It appears to me to be as clever as consolidating inputs.

I would not try to time fee rates when deciding the costs/benefits to opening a LN channel. This would be like saying you have a guaranteed way to make money that is you will 'buy low and sell high'. BTC fee rates may rise and fall over time that follow patterns, but these patterns can end or change at any time.

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?