Oddbean

this HTLC thing is gonna get more intense. but let me be very clear about something: the email on the bitcoin dev mailing list does not explain in ANY WAY how the vulnerability can be exploited it makes allusions to linux kernel vulnerabilities, which have nothing to do with anything they are saying the problem is in the mempool, but this can only affect channel closures, and will have little material effect on processing payments because they either go, or they don't, and if one of the hops in a path publishes a malicious channel close then again, the payment will just fail at most. we aren't hearing anything from actual devs who build the systems, nor the inventors, only people who are clear opponents and competitors to bitcoin. this is psychological warfare, it smells fishy af in my opinion. inflating the image of potency of something is a classic psywar technique, and we already have the word FUD for creating doubt to make people feel bad. it only makes me feel mad, and i don't want to hear another word about HTLC vulnerability until someone actually explains because what is in the email is basically so vague as to be useless, and i actually have read the paper and i understand a reasonable amount about how the atomicity of lightning payments works and anything involving the bitcoin blockchain implicitly only affects channel closure. it may well be that this vulnerability has to do with splicing. but anyone who understands how the protocol works and how splices go off on a second and Nth level beyond on-chain transaction would get it when i say that splicing is something that probably should not be widely used at this point. anyhow, FUD warning. they are coming for your zaps, people. it's not going to work, as far as i can tell this is a social engineering attack, with a thin wisp of a partial vulnerability, at best, in an uncommon aspect of LN protocol.

This attack isn't easy. Pulling it off involves: - opening two channels with the victim. - routing a payment through them. - successfully replacement-cycling the victim's htlc-timeouts for Δ blocks. - without the victim discovering the htlc-preimage transaction. jumping right on ahead to "omg, rare, extremely difficult attack that everyone knows about now means change bitcoin" is pretty ridiculous. soundbites about how bitcoin and lightning are busted are beyond ridiculous in the light of the conditions laid out above. ONLY ONE OF THEM HAS TO BE BLOCKED. Unless I'm mistaken, when it says "open two channels" this means "with one key". SNIP, straight away easy to prevent. straight away, everyone who has something at stake is already sorting through their channels and force closing everything that is suspect looking just for that minimal element. and since i know a bit about the signatures and ciphers and ECDH it smells to me like an error in the use of elliptic curves. maybe it will require a substantial, minor version bumping change that is not backwards compatible but i don't think anyone is gonna be a hard sell on a well hammered out solution. thanks nostr:nprofile1qqstm0smm0ymyk5d38v0mtctuxsdekphhtykj86e0zffqwjlmkrwylcpz9mhxue69uhkummnw3ezuamfdejj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqsuamnwvaz7tmwdaejumr0dshsuj20g3 for dropping the link, i hadn't followed that account on this new nym yet.

Well it's not a #Bitcoin problem. So I don't really care. Should be even less of a problem when we get rid of Bitcoin #transaction #fees. Bitcoin doesn't need them, and that's all that matters..⚖️👮‍♂️