Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Be more forgiving with lnd #2842
Thanks for the fix @rustyrussell @ZmnSCPxj
I've had over $700 in channels so a word of a comfort that it'll all be okay would be great :)
Since "we" closed the channel unilaterally, it is "our" delayed output, which will be returned to our onchain wallet.
The number of blocks that you end up waiting for is set by your counterparty. So if your counterparty was the one who closed, it would be your settings that are used. This is because this is a security parameter of your counterparty: it is the number of blocks they can be offline safely for, without potentially suffering theft attempt. So your funds are locked according to how paranoid your counterparty is, not according to how paranoid you are. This is a simple consequence of having to coordinate with other people. Now of course you are not going to steal from your counterparty, but your counterparty does not know that, and as they say, don't trust, verify.
We close the channel unilaterally because the BOLT specs that is what should be done if we receive an
For "outputs resolved" it is in your onchain funds. For "outputs unresolved" it is just a matter of waiting out the needed time. It will be OK, not to worry.
@NicolasDorier possibly. I shall try later to see if these can be trivially cherry-picked on some branch on top of 0.7.1.
We have very vague plans to have a release every about 4 or 5 difficulty adjustments (because this is Bitcoin, merely human concepts like "two months" do not apply), and I believe we are about two or three difficulty achievements since last release. So maybe (very maybe) we can release 0.7.2 soon... though there is only maybe a chance of a possibility of (maybe) doing so (if possible that there is a chance). Though, there are still a number of items listed in 0.7.2 milestone. If we keep to (our not particularly agreed-upon) schedule we might have a release candidate in a difficulty adjustment or so.
There’s a lot of errors that aren’t dire but which should be communicated to another implementation. Even then, you can mark the channel in an “error state”, and then let the user actually decide if they want to force close it or not. It's easier though to just force close it and then let user figure it out later.
I've also seen c-lightning users complain their c-lightning peers force closed on them. So it's normal for c-lightning to force close even on each other for no valid reason, I guess you think it's normal to see the network to be perpetually in force closing. How would you expect LN to function, let alone succeed, if users can't count on the software to be stable enough to hold their channels intact? And no I don't think LND is "normal because it's popular", but I regard it as more sane because LND doesn't do insane force closing on me all the time. I have disagreed and criticized LND much more than you know. I would have said the same if it was an LND dev that made such statements. And fwiw, I do respect and appreciate rusty's work for LN and Linux, he's a legend. I have tried to contribute to c-lightning as much as i could with testing, I am not a dev, only a user playing with Lightning the last 3 years and would like to see LN succeed. So to answer your accusation:
This is new to me. Do you have proof? Or you just want to throw mud in the dark?
Yes, please ignore me. I wasn't expecting to have to write to answer your accusation again, but now I've done it, I am done. It's your choice not to be open minded and listen to what users say, I totally respect that, and I do not expect to hear from you ever again. Thank you.