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

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.

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.

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.

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.

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.

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.

If I got it correctly payments are still limited to 0.0429 4967 295 BTC (2^32-1 msat).

From BOLT #2, update_add_htlc

With the standard, I know to ask on github.
Has anyone had an issue after installing 0.11 of random 100% cpu utilization?
My node just stops and goes to 100% for minutes on end. Then everything goes back to normal.
No funds in it at the moment so I'll probably roll back to 0.10

-Dave