pull down to refresh
Hey! Thanks a lot, and welcome!
Just a follow-up: did you subscribe yet? I don't see any new subscriber around the time of your comment, and since I run the newsletter stack myself I just want to double check it's not a technical issue on my end. Thanks again!
That's a good question. Usually BIP110 node operators are quite vocal about it. I'd say if they have a public profile and don't specify it's quite safe to assume they don't run BIP110. You could also ask them if they're a public facing node.
Now that the fork happened, I guess another way would be to test sending a payment through their node: they should refuse if on the other side, since block heights don't match and hence the HTLC would be invalid to them. In LND you can specify the outgoing chan ID of a payment with the --outgoing_chan_id of the sendpayment command.
Not turning off your node is the best of precautions. If anything you want more monitoring, not less, and your Lightning node is already monitoring the chain the underlying Bitcoin node is on.
If you have a channel with a peer on the other side of the fork, the only important precaution to have is if you're on the minority chain, to check that your peer isn't stealing from you by publishing a revoked state on the majority chain.
I edited the BIP110 section to clarify that transaction validity doesn’t change during mandatory signaling, and overall LN on-chain transactions should be BIP110 compliant. It was slightly implicit in the prior version, and clarity is key in this kind of times.
I cannot edit the SN post, but you can find the edited version on Latest Strikes.
Yes. Crucially no user funds were lost, because it's all self-custodial.
As I underlined in the piece, I think it rather says something about the current asymmetry for open source software.
Apparently the Federation will be footing the bill. But I don't know where those ~600 BTC ultimately come from.
http://nitter.space/Excellion/status/2112536547115352445