- cypherpunks - lists.cpunks.org

Anarchist Lev Skoryakin kidnapped in Kyrgyzstan
by professor rat 21 Oct '23

21 Oct '23

https://avtonom.org/en/news/anarchist-lev-skoryakin-kidnapped-kyrgyzstan Reposts not deputy-dog, dribble from US policing agent, Karl Semich

1 0

Freedom has a price
by zeynep＠keemail.me 20 Oct '23

20 Oct '23

https://en.m.wikipedia.org/wiki/Carlo_Caracciolo

1 1

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

On 10/17/23, Matt Corallo via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> wrote: > There appears to be some confusion about this issue and the mitigations. To > be clear, the deployed > mitigations are not expected to fix this issue, its arguable if they provide > anything more than a PR > statement. > > There are two discussed mitigations here - mempool scanning and transaction > re-signing/re-broadcasting. > > Mempool scanning relies on regularly checking the mempool of a local node to > see if we can catch the > replacement cycle mid-cycle. It only works if wee see the first transaction > before the second > transaction replaces it. > > Today, a large majority of lightning nodes run on machines with a Bitcoin > node on the same IP > address, making it very clear what the "local node" of the lightning node > is. An attacker can > trivially use this information to connect to said local node and do the > replacement quickly, > preventing the victim from seeing the replacement. > > More generally, however, similar discoverability is true for mining pools. > An attacker performing > this attack is likely to do the replacement attack on a miner's node > directly, potentially reducing > the reach of the intermediate transaction to only miners, such that the > victim can never discover it > at all. > > The second mitigation is similarly pathetic. Re-signing and re-broadcasting > the victim's transaction > in an attempt to get it to miners even if its been removed may work, if the > attacker is super lazy > and didn't finish writing their attack system. If the attacker is connected > to a large majority of > hashrate (which has historically been fairly doable), they can simply do > their replacement in a > cycle aggressively and arbitrarily reduce the probability that the victim's > transaction gets confirmed. > > Now, the above is all true in a spherical cow kinda world, and the P2P > network has plenty of slow > nodes and strange behavior. Its possible that these mitigations might, by > some stroke of luck, > happen to catch such an attack and prevent it, because something took longer > than the attacker > intended or whatever. But, that's a far cry from any kind of material "fix" > for the issue. > > Ultimately the only fix for this issue will be when miners keep a history of > transactions they've > seen and try them again after they may be able to enter the mempool because > of an attack like this. > > Matt > > On 10/16/23 12:57 PM, Antoine Riard wrote: >> (cross-posting mempool issues identified are exposing lightning chan to >> loss of funds risks, other >> multi-party bitcoin apps might be affected) >> >> Hi, >> >> End of last year (December 2022), amid technical discussions on eltoo >> payment channels and >> incentives compatibility of the mempool anti-DoS rules, a new >> transaction-relay jamming attack >> affecting lightning channels was discovered. >> >> After careful analysis, it turns out this attack is practical and >> immediately exposed lightning >> routing hops carrying HTLC traffic to loss of funds security risks, both >> legacy and anchor output >> channels. A potential exploitation plausibly happening even without >> network mempools congestion. >> >> Mitigations have been designed, implemented and deployed by all major >> lightning implementations >> during the last months. >> >> Please find attached the release numbers, where the mitigations should be >> present: >> - LDK: v0.0.118 - CVE-2023 -40231 >> - Eclair: v0.9.0 - CVE-2023-40232 >> - LND: v.0.17.0-beta - CVE-2023-40233 >> - Core-Lightning: v.23.08.01 - CVE-2023-40234 >> >> While neither replacement cycling attacks have been observed or reported >> in the wild since the last >> ~10 months or experimented in real-world conditions on bitcoin mainet, >> functional test is available >> exercising the affected lightning channel against bitcoin core mempool >> (26.0 release cycle). >> >> It is understood that a simple replacement cycling attack does not demand >> privileged capabilities >> from an attacker (e.g no low-hashrate power) and only access to basic >> bitcoin and lightning >> software. Yet I still think executing such an attack successfully requests >> a fair amount of bitcoin >> technical know-how and decent preparation. >> >> From my understanding of those issues, it is yet to be determined if the >> mitigations deployed are >> robust enough in face of advanced replacement cycling attackers, >> especially ones able to combine >> different classes of transaction-relay jamming such as pinnings or vetted >> with more privileged >> capabilities. >> >> Please find a list of potential affected bitcoin applications in this full >> disclosure report using >> bitcoin script timelocks or multi-party transactions, albeit no immediate >> security risk exposure as >> severe as the ones affecting lightning has been identified. Only cursory >> review of non-lightning >> applications has been conducted so far. >> >> There is a paper published summarizing replacement cycling attacks on the >> lightning network: >> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/r… >> >> <https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/r…> >> >> ## Problem >> >> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted >> HTLC on incoming link and >> offered HTLC on outgoing link) should settle the outgoing state with >> either a success or timeout >> before the incoming state timelock becomes final and an asymmetric >> defavorable settlement might >> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network" >> section 2.3 for a classical >> exposition of this lightning security property). >> >> Failure to satisfy this settlement requirement exposes a forwarding hop to >> a loss of fund risk where >> the offered HTLC is spent by the outgoing link counterparty's >> HTLC-preimage and the accepted HTLC is >> spent by the incoming link counterparty's HTLC-timeout. >> >> The specification mandates the incoming HTLC expiration timelock to be >> spaced out by an interval of >> `cltv_expiry_delta` from the outgoing HTLC expiration timelock, this exact >> interval value being an >> implementation and node policy setting. As a minimal value, the >> specification recommends 34 blocks >> of interval. If the timelock expiration I of the inbound HTLC is equal to >> 100 from chain tip, the >> timelock expiration O of the outbound HTLC must be equal to 66 blocks from >> chain tip, giving a >> reasonable buffer of reaction to the lightning forwarding node. >> >> In the lack of cooperative off-chain settlement of the HTLC on the >> outgoing link negotiated with the >> counterparty (either `update_fulfill_htlc` or `update_fail_htlc`) when O >> is reached, the lightning >> node should broadcast its commitment transaction. Once the commitment is >> confirmed (if anchor and >> the 1 CSV encumbrance is present), the lightning node broadcasts and >> confirms its HTLC-timeout >> before I height is reached. >> >> Here enter a replacement cycling attack. A malicious channel counterparty >> can broadcast its >> HTLC-preimage transaction with a higher absolute fee and higher feerate >> than the honest HTLC-timeout >> of the victim lightning node and triggers a replacement. Both for legacy >> and anchor output channels, >> a HTLC-preimage on a counterparty commitment transaction is malleable, i.e >> additional inputs or >> outputs can be added. The HTLC-preimage spends an unconfirmed and >> unrelated to the channel parent >> transaction M and conflicts its child. >> >> As the HTLC-preimage spends an unconfirmed input that was already included >> in the unconfirmed and >> unrelated child transaction (rule 2), pays an absolute higher fee of at >> least the sum paid by the >> HTLC-timeout and child transaction (rule 3) and the HTLC-preimage feerate >> is greater than all >> directly conflicting transactions (rule 6), the replacement is accepted. >> The honest HTLC-timeout is >> evicted out of the mempool. >> >> In an ulterior move, the malicious counterparty can replace the parent >> transaction itself with >> another candidate N satisfying the replacement rules, triggering the >> eviction of the malicious >> HTLC-preimage from the mempool as it was a child of the parent T. >> >> There is no spending candidate of the offered HTLC output for the current >> block laying in network >> mempools. >> >> This replacement cycling tricks can be repeated for each rebroadcast >> attempt of the HTLC-timeout by >> the honest lightning node until expiration of the inbound HTLC timelock I. >> Once this height is >> reached a HTLC-timeout is broadcast by the counterparty's on the incoming >> link in collusion with the >> one on the outgoing link broadcasting its own HTLC-preimage. >> >> The honest Lightning node has been "double-spent" in its HTLC forwarding. >> >> As a notable factor impacting the success of the attack, a lightning >> node's honest HTLC-timeout >> might be included in the block template of the miner winning the block >> race and therefore realizes a >> spent of the offered output. In practice, a replacement cycling attack >> might over-connect to miners' >> mempools and public reachable nodes to succeed in a fast eviction of the >> HTLC-timeout by its >> HTLC-preimage. As this latter transaction can come with a better >> ancestor-score, it should be picked >> up on the flight by economically competitive miners. >> >> A functional test exercising a simple replacement cycling of a HTLC >> transaction on bitcoin core >> mempool is available: >> https://github.com/ariard/bitcoin/commits/2023-test-mempool >> <https://github.com/ariard/bitcoin/commits/2023-test-mempool> >> >> ## Deployed LN mitigations >> >> Aggressive rebroadcasting: As the replacement cycling attacker benefits >> from the HTLC-timeout being >> usually broadcast by lightning nodes only once every block, or less the >> replacement cycling >> malicious transactions paid only equal the sum of the absolute fees paid >> by the HTLC, adjusted with >> the replacement penalty. Rebroadcasting randomly and multiple times before >> the next block increases >> the absolute fee cost for the attacker. >> >> Implemented and deployed by Eclair, Core-Lightning, LND and LDK . >> >> Local-mempool preimage monitoring: As the replacement cycling attacker in >> a simple setup broadcast >> the HTLC-preimage to all the network mempools, the honest lightning node >> is able to catch on the >> flight the unconfirmed HTLC-preimage, before its subsequent mempool >> replacement. The preimage can be >> extracted from the second-stage HTLC-preimage and used to fetch the >> off-chain inbound HTLC with a >> cooperative message or go on-chain with it to claim the accepted HTLC >> output. >> >> Implemented and deployed by Eclair and LND. >> >> CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid >> by the attacker, a risk >> of the HTLC-preimage being detected or discovered by the honest lightning >> node, or the HTLC-timeout >> to slip in a winning block template. Bumping the default CLTV delta >> hardens the odds of success of a >> simple replacement cycling attack. >> >> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72. >> >> ## Affected Bitcoin Protocols and Applications >> >> From my understanding the following list of Bitcoin protocols and >> applications could be affected by >> new denial-of-service vectors under some level of network mempools >> congestion. Neither tests or >> advanced review of specifications (when available) has been conducted for >> each of them: >> - on-chain DLCs >> - coinjoins >> - payjoins >> - wallets with time-sensitive paths >> - peerswap and submarine swaps >> - batch payouts >> - transaction "accelerators" >> >> Inviting their developers, maintainers and operators to investigate how >> replacement cycling attacks >> might disrupt their in-mempool chain of transactions, or fee-bumping flows >> at the shortest delay. >> Simple flows and non-multi-party transactions should not be affected to >> the best of my understanding. >> >> ## Open Problems: Package Malleability >> >> Pinning attacks have been known for years as a practical vector to >> compromise lightning channels >> funds safety, under different scenarios (cf. current bip331's motivation >> section). Mitigations at >> the mempool level have been designed, discussed and are under >> implementation by the community >> (ancestor package relay + nverrsion=3 policy). Ideally, they should >> constraint a pinning attacker to >> always attach a high feerate package (commitment + CPFP) to replace the >> honest package, or allow a >> honest lightning node to overbid a malicious pinning package and get its >> time-sensitive transaction >> optimistically included in the chain. >> >> Replacement cycling attack seem to offer a new way to neutralize the >> design goals of package relay >> and its companion nversion=3 policy, where an attacker package RBF a >> honest package out of the >> mempool to subsequently double-spend its own high-fee child with a >> transaction unrelated to the >> channel. As the remaining commitment transaction is pre-signed with a >> minimal relay fee, it can be >> evicted out of the mempool. >> >> A functional test exercising a simple replacement cycling of a lightning >> channel commitment >> transaction on top of the nversion=3 code branch is available: >> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 >> <https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2> >> >> ## Discovery >> >> In 2018, the issue of static fees for pre-signed lightning transactions is >> made more widely known, >> the carve-out exemption in mempool rules to mitigate in-mempool package >> limits pinning and the >> anchor output pattern are proposed. >> >> In 2019, bitcoin core 0.19 is released with carve-out support. Continued >> discussion of the anchor >> output pattern as a dynamic fee-bumping method. >> >> In 2020, draft of anchor output submitted to the bolts. Initial finding of >> economic pinning against >> lightning commitment and second-stage HTLC transactions. Subsequent >> discussions of a >> preimage-overlay network or package-relay as mitigations. Public call made >> to inquiry more on >> potential other transaction-relay jamming attacks affecting lightning. >> >> In 2021, initial work in bitcoin core 22.0 of package acceptance. >> Continued discussion of the >> pinning attacks and shortcomings of current mempool rules during >> community-wide online workshops. >> Later the year, in light of all issues for bitcoin second-layers, a >> proposal is made about killing >> the mempool. >> >> In 2022, bip proposed for package relay and new proposed v3 policy design >> proposed for a review and >> implementation. Mempoolfullrbf is supported in bitcoin core 24.0 and >> conceptual questions about >> alignment of mempool rules w.r.t miners incentives are investigated. >> >> Along this year 2022, eltoo lightning channels design are discussed, >> implemented and reviewed. In >> this context and after discussions on mempool anti-DoS rules, I discovered >> this new replacement >> cycling attack was affecting deployed lightning channels and immediately >> reported the finding to >> some bitcoin core developers and lightning maintainers. >> >> ## Timeline >> >> - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg >> Sanders and Gloria Zhao >> - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier, >> Matt Corallo and Olaoluwa >> Osuntunkun >> - 2022-12-23: Sharing to Eugene Siegel (LND) >> - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning >> potential affected projects) >> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers >> issuers) and initial >> proposal of an early public disclosure >> - 2022-01-19: Collection of analysis if other second-layers and >> multi-party applications affected. >> LN mitigations development starts. >> - 2023-05-04: Sharing to Wilmer Paulino (LDK) >> - 2023-06-20: LN mitigations implemented and progressively released. Week >> of the 16 october proposed >> for full disclosure. >> - 2023-08-10: CVEs assigned by MITRE >> - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling >> attack existence to >> security(a)bitcoincore.org <mailto:security@bitcoincore.org>. >> - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 / >> CVE-2023-40233 / CVE-2023-40234 >> and replacement cycling attacks >> >> ## Conclusion >> >> Despite the line of mitigations adopted and deployed by current major >> lightning implementations, I >> believe replacement cycling attacks are still practical for advanced >> attackers. Beyond this new >> attack might come as a way to partially or completely defeat some of the >> pinning mitigations which >> have been working for years as a community. >> >> As of today, it is uncertain to me if lightning is not affected by a more >> severe long-term package >> malleability critical security issue under current consensus rules, and if >> any other time-sensitive >> multi-party protocol, designed or deployed isn't de facto affected too >> (loss of funds or denial of >> service). >> >> Assuming analysis on package malleability is correct, it is unclear to me >> if it can be corrected by >> changes in replacement / eviction rules or mempool chain of transactions >> processing strategy. >> Inviting my technical peers and the bitcoin community to look more on this >> issue, including to >> dissent. I'll be the first one pleased if I'm fundamentally wrong on those >> issues, or if any element >> has not been weighted with the adequate technical accuracy it deserves. >> >> Do not trust, verify. All mistakes and opinions are my own. >> >> Antoine >> >> "meet with Triumph and Disaster. And treat those two impostors just the >> same" - K. >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev(a)lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev(a)lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >

1 0

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

On 10/17/23, Antoine Riard via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> wrote: > Hi Zeeman, > >> At block height 100, `B` notices the `B->C` HTLC timelock is expired > without `C` having claimed it, so `B` forces the `B====C` channel onchain. >> However, onchain feerates have risen and the commitment transaction and > HTLC-timeout transaction do not confirm. > > This is not that the HTLC-timeout does not confirm. It is replaced in > cycles by C's HTLC-preimage which is still valid after `B->C` HTLC timelock > has expired. And this HTLC-preimage is subsequently replaced itself. > > See the test here: > https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72… > >> At block height 144, `B` is still not able to claim the `A->B` HTLC, so > `A` drops the `A====B` channel onchain. >> As the fees are up-to-date, this confirms immediately and `A` is able to > recover the HTLC funds. >> However, the feerates of the `B====C` pre-signed transactions remain at > the old, uncompetitive feerates. > > This is correct that A tries to recover the HTLC funds on the `A===B` > channel. > > However, there is no need to consider the fee rates nor mempool congestion > as the exploit lays on the replacement mechanism itself (in simple > scenario). > >> At this point, `C` broadcasts an HTLC-success transaction with high > feerates that CPFPs the commitment tx. >> However, it replaces the HTLC-timeout transaction, which is at the old, > low feerate. >> `C` is thus able to get the value of the HTLC, but `B` is now no longer > able to use the knowledge of the preimage, as its own incoming HTLC was > already confirmed as claimed by `A`. > > This is correct that `C` broadcasts an HTLC-success transaction at block > height 144. > > However `C` broadcasts this high feerate transaction at _every block_ > between blocks 100 and 144 to replace B's HTLC-timeout transaction. > >> Let me also explain to non-Lightning experts why HTLC-timeout is > presigned in this case and why `B` cannot feebump it. > > Note `B` can feebump the HTLC-timeout for anchor output channels thanks to > sighash_single | anyonecanpay on C's signature. > > Le mar. 17 oct. 2023 à 11:34, ZmnSCPxj <ZmnSCPxj(a)protonmail.com> a écrit : > >> Good morning Antoine et al., >> >> Let me try to rephrase the core of the attack. >> >> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, >> `==` are channels): >> >> A ===== B ===== C >> >> `A` routes `A->B->C`. >> >> The timelocks, for example, could be: >> >> A->B timeelock = 144 >> B->C timelock = 100 >> >> The above satisfies the LN BOLT requirements, as long as `B` has a >> `cltv_expiry_delta` of 44 or lower. >> >> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the >> signed transactions --- commitment transaction and HTLC-timeout >> transactions --- are "stuck" at the feerate at the time. >> >> At block height 100, `B` notices the `B->C` HTLC timelock is expired >> without `C` having claimed it, so `B` forces the `B====C` channel >> onchain. >> However, onchain feerates have risen and the commitment transaction and >> HTLC-timeout transaction do not confirm. >> >> In the mean time, `A` is still online with `B` and updates the onchain >> fees of the `A====B` channel pre-signed transactions (commitment tx and >> HTLC-timeout tx) to the latest. >> >> At block height 144, `B` is still not able to claim the `A->B` HTLC, so >> `A` drops the `A====B` channel onchain. >> As the fees are up-to-date, this confirms immediately and `A` is able to >> recover the HTLC funds. >> However, the feerates of the `B====C` pre-signed transactions remain at >> the old, uncompetitive feerates. >> >> At this point, `C` broadcasts an HTLC-success transaction with high >> feerates that CPFPs the commitment tx. >> However, it replaces the HTLC-timeout transaction, which is at the old, >> low feerate. >> `C` is thus able to get the value of the HTLC, but `B` is now no longer >> able to use the knowledge of the preimage, as its own incoming HTLC was >> already confirmed as claimed by `A`. >> >> Is the above restatement accurate? >> >> ---- >> >> Let me also explain to non-Lightning experts why HTLC-timeout is >> presigned >> in this case and why `B` cannot feebump it. >> >> In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja >> penalty case, and are not plain HTLCs. >> >> A plain HTLC offerred by `B` to `C` would look like this: >> >> (B && OP_CLTV) || (C && OP_HASH160) >> >> However, on the commitment transaction held by `B`, it would be infected >> by the penalty case in this way: >> >> (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation) >> >> There are two changes: >> >> * The addition of a revocation branch `C && revocation`. >> * The branch claimable by `B` in the "plain" HTLC (`B && OP_CLTV`) also >> includes `C`. >> >> These are necessary in case `B` tries to cheat and this HTLC is on an >> old, >> revoked transaction. >> If the revoked transaction is *really* old, the `OP_CLTV` would already >> impose a timelock far in the past. >> This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it >> retained this very old revoked transaction. >> >> To prevent that, `C` is added to the `B && OP_CLTV` branch. >> We also introduce an HTLC-timeout transaction, which spends the `B && C >> && >> OP_CLTV` branch, and outputs to: >> >> (B && OP_CSV) || (C && revocation) >> >> Thus, even if `B` held onto a very old revoked commitment transaction and >> attempts to spend the timelock branch (because the `OP_CLTV` is for an >> old >> blockheight), it still has to contend with a new output with a *relative* >> timelock. >> >> Unfortunately, this means that the HTLC-timeout transaction is >> pre-signed, >> and has a specific feerate. >> In order to change the feerate, both `B` and `C` have to agree to re-sign >> the HTLC-timeout transaction at the higher feerate. >> >> However, the HTLC-success transaction in this case spends the plain `(C >> && >> OP_HASH160)` branch, which only involves `C`. >> This allows `C` to feebump the HTLC-success transaction arbitrarily even >> if `B` does not cooperate. >> >> While anchor outputs can be added to the HTLC-timeout transaction as >> well, >> `C` has a greater advantage here due to being able to RBF the >> HTLC-timeout >> out of the way (1 transaction), while `B` has to get both HTLC-timeout >> and >> a CPFP-RBF of the anchor output of the HTLC-timeout transaction (2 >> transactions). >> `C` thus requires a smaller fee to achieve a particular feerate due to >> having to push a smaller number of bytes compared to `B`. >> >> Regards, >> ZmnSCPxj >> >

1 0

Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

On 10/17/23, ZmnSCPxj via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> wrote: > Good morning Antoine et al., > > Let me try to rephrase the core of the attack. > > There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, > `==` are channels): > > A ===== B ===== C > > `A` routes `A->B->C`. > > The timelocks, for example, could be: > > A->B timeelock = 144 > B->C timelock = 100 > > The above satisfies the LN BOLT requirements, as long as `B` has a > `cltv_expiry_delta` of 44 or lower. > > After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the > signed transactions --- commitment transaction and HTLC-timeout transactions > --- are "stuck" at the feerate at the time. > > At block height 100, `B` notices the `B->C` HTLC timelock is expired without > `C` having claimed it, so `B` forces the `B====C` channel onchain. > However, onchain feerates have risen and the commitment transaction and > HTLC-timeout transaction do not confirm. > > In the mean time, `A` is still online with `B` and updates the onchain fees > of the `A====B` channel pre-signed transactions (commitment tx and > HTLC-timeout tx) to the latest. > > At block height 144, `B` is still not able to claim the `A->B` HTLC, so `A` > drops the `A====B` channel onchain. > As the fees are up-to-date, this confirms immediately and `A` is able to > recover the HTLC funds. > However, the feerates of the `B====C` pre-signed transactions remain at the > old, uncompetitive feerates. > > At this point, `C` broadcasts an HTLC-success transaction with high feerates > that CPFPs the commitment tx. > However, it replaces the HTLC-timeout transaction, which is at the old, low > feerate. > `C` is thus able to get the value of the HTLC, but `B` is now no longer able > to use the knowledge of the preimage, as its own incoming HTLC was already > confirmed as claimed by `A`. > > Is the above restatement accurate? > > ---- > > Let me also explain to non-Lightning experts why HTLC-timeout is presigned > in this case and why `B` cannot feebump it. > > In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja > penalty case, and are not plain HTLCs. > > A plain HTLC offerred by `B` to `C` would look like this: > > (B && OP_CLTV) || (C && OP_HASH160) > > However, on the commitment transaction held by `B`, it would be infected by > the penalty case in this way: > > (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation) > > There are two changes: > > * The addition of a revocation branch `C && revocation`. > * The branch claimable by `B` in the "plain" HTLC (`B && OP_CLTV`) also > includes `C`. > > These are necessary in case `B` tries to cheat and this HTLC is on an old, > revoked transaction. > If the revoked transaction is *really* old, the `OP_CLTV` would already > impose a timelock far in the past. > This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it > retained this very old revoked transaction. > > To prevent that, `C` is added to the `B && OP_CLTV` branch. > We also introduce an HTLC-timeout transaction, which spends the `B && C && > OP_CLTV` branch, and outputs to: > > (B && OP_CSV) || (C && revocation) > > Thus, even if `B` held onto a very old revoked commitment transaction and > attempts to spend the timelock branch (because the `OP_CLTV` is for an old > blockheight), it still has to contend with a new output with a *relative* > timelock. > > Unfortunately, this means that the HTLC-timeout transaction is pre-signed, > and has a specific feerate. > In order to change the feerate, both `B` and `C` have to agree to re-sign > the HTLC-timeout transaction at the higher feerate. > > However, the HTLC-success transaction in this case spends the plain `(C && > OP_HASH160)` branch, which only involves `C`. > This allows `C` to feebump the HTLC-success transaction arbitrarily even if > `B` does not cooperate. > > While anchor outputs can be added to the HTLC-timeout transaction as well, > `C` has a greater advantage here due to being able to RBF the HTLC-timeout > out of the way (1 transaction), while `B` has to get both HTLC-timeout and a > CPFP-RBF of the anchor output of the HTLC-timeout transaction (2 > transactions). > `C` thus requires a smaller fee to achieve a particular feerate due to > having to push a smaller number of bytes compared to `B`. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev(a)lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >

1 0

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

On 10/16/23, Matt Morehouse via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> wrote: > On Mon, Oct 16, 2023 at 7:21 PM Peter Todd via bitcoin-dev > <bitcoin-dev(a)lists.linuxfoundation.org> wrote: >> I think if you want people to understand this exploit, you need to explain >> in more detail how we have a situation where two different parties can >> spend the same HTLC txout, without the first party having the right to >> spend it via their knowledge of the HTLC-preimage. > > The two main ways of spending an "offered" HTLC txout: > 1) With a presigned multisig covenant transaction paying to the > offerer (a.k.a HTLC-timeout transaction) > 2) With a preimage and the receiver's signature > > Since option 1 uses a presigned covenant held by the offerer, only the > offerer can spend via that path. > Since option 2 requires the receiver's signature, only the receiver > can spend via that path. > > The exact script used is here: > https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-h…. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev(a)lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >

1 0

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

On 10/16/23, Antoine Riard via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> wrote: > (cross-posting mempool issues identified are exposing lightning chan to > loss of funds risks, other multi-party bitcoin apps might be affected) > > Hi, > > End of last year (December 2022), amid technical discussions on eltoo > payment channels and incentives compatibility of the mempool anti-DoS > rules, a new transaction-relay jamming attack affecting lightning channels > was discovered. > > After careful analysis, it turns out this attack is practical and > immediately exposed lightning routing hops carrying HTLC traffic to loss of > funds security risks, both legacy and anchor output channels. A potential > exploitation plausibly happening even without network mempools congestion. > > Mitigations have been designed, implemented and deployed by all major > lightning implementations during the last months. > > Please find attached the release numbers, where the mitigations should be > present: > - LDK: v0.0.118 - CVE-2023 -40231 > - Eclair: v0.9.0 - CVE-2023-40232 > - LND: v.0.17.0-beta - CVE-2023-40233 > - Core-Lightning: v.23.08.01 - CVE-2023-40234 > > While neither replacement cycling attacks have been observed or reported in > the wild since the last ~10 months or experimented in real-world conditions > on bitcoin mainet, functional test is available exercising the affected > lightning channel against bitcoin core mempool (26.0 release cycle). > > It is understood that a simple replacement cycling attack does not demand > privileged capabilities from an attacker (e.g no low-hashrate power) and > only access to basic bitcoin and lightning software. Yet I still think > executing such an attack successfully requests a fair amount of bitcoin > technical know-how and decent preparation. > > From my understanding of those issues, it is yet to be determined if the > mitigations deployed are robust enough in face of advanced replacement > cycling attackers, especially ones able to combine different classes of > transaction-relay jamming such as pinnings or vetted with more privileged > capabilities. > > Please find a list of potential affected bitcoin applications in this full > disclosure report using bitcoin script timelocks or multi-party > transactions, albeit no immediate security risk exposure as severe as the > ones affecting lightning has been identified. Only cursory review of > non-lightning applications has been conducted so far. > > There is a paper published summarizing replacement cycling attacks on the > lightning network: > https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/r… > > ## Problem > > A lightning node allows HTLCs forwarding (in bolt3's parlance accepted HTLC > on incoming link and offered HTLC on outgoing link) should settle the > outgoing state with either a success or timeout before the incoming state > timelock becomes final and an asymmetric defavorable settlement might > happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network" > section 2.3 for a classical exposition of this lightning security > property). > > Failure to satisfy this settlement requirement exposes a forwarding hop to > a loss of fund risk where the offered HTLC is spent by the outgoing link > counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming > link counterparty's HTLC-timeout. > > The specification mandates the incoming HTLC expiration timelock to be > spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC > expiration timelock, this exact interval value being an implementation and > node policy setting. As a minimal value, the specification recommends 34 > blocks of interval. If the timelock expiration I of the inbound HTLC is > equal to 100 from chain tip, the timelock expiration O of the outbound HTLC > must be equal to 66 blocks from chain tip, giving a reasonable buffer of > reaction to the lightning forwarding node. > > In the lack of cooperative off-chain settlement of the HTLC on the outgoing > link negotiated with the counterparty (either `update_fulfill_htlc` or > `update_fail_htlc`) when O is reached, the lightning node should broadcast > its commitment transaction. Once the commitment is confirmed (if anchor and > the 1 CSV encumbrance is present), the lightning node broadcasts and > confirms its HTLC-timeout before I height is reached. > > Here enter a replacement cycling attack. A malicious channel counterparty > can broadcast its HTLC-preimage transaction with a higher absolute fee and > higher feerate than the honest HTLC-timeout of the victim lightning node > and triggers a replacement. Both for legacy and anchor output channels, a > HTLC-preimage on a counterparty commitment transaction is malleable, i.e > additional inputs or outputs can be added. The HTLC-preimage spends an > unconfirmed and unrelated to the channel parent transaction M and conflicts > its child. > > As the HTLC-preimage spends an unconfirmed input that was already included > in the unconfirmed and unrelated child transaction (rule 2), pays an > absolute higher fee of at least the sum paid by the HTLC-timeout and child > transaction (rule 3) and the HTLC-preimage feerate is greater than all > directly conflicting transactions (rule 6), the replacement is accepted. > The honest HTLC-timeout is evicted out of the mempool. > > In an ulterior move, the malicious counterparty can replace the parent > transaction itself with another candidate N satisfying the replacement > rules, triggering the eviction of the malicious HTLC-preimage from the > mempool as it was a child of the parent T. > > There is no spending candidate of the offered HTLC output for the current > block laying in network mempools. > > This replacement cycling tricks can be repeated for each rebroadcast > attempt of the HTLC-timeout by the honest lightning node until expiration > of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout > is broadcast by the counterparty's on the incoming link in collusion with > the one on the outgoing link broadcasting its own HTLC-preimage. > > The honest Lightning node has been "double-spent" in its HTLC forwarding. > > As a notable factor impacting the success of the attack, a lightning node's > honest HTLC-timeout might be included in the block template of the miner > winning the block race and therefore realizes a spent of the offered > output. In practice, a replacement cycling attack might over-connect to > miners' mempools and public reachable nodes to succeed in a fast eviction > of the HTLC-timeout by its HTLC-preimage. As this latter transaction can > come with a better ancestor-score, it should be picked up on the flight by > economically competitive miners. > > A functional test exercising a simple replacement cycling of a HTLC > transaction on bitcoin core mempool is available: > https://github.com/ariard/bitcoin/commits/2023-test-mempool > > ## Deployed LN mitigations > > Aggressive rebroadcasting: As the replacement cycling attacker benefits > from the HTLC-timeout being usually broadcast by lightning nodes only once > every block, or less the replacement cycling malicious transactions paid > only equal the sum of the absolute fees paid by the HTLC, adjusted with the > replacement penalty. Rebroadcasting randomly and multiple times before the > next block increases the absolute fee cost for the attacker. > > Implemented and deployed by Eclair, Core-Lightning, LND and LDK . > > Local-mempool preimage monitoring: As the replacement cycling attacker in a > simple setup broadcast the HTLC-preimage to all the network mempools, the > honest lightning node is able to catch on the flight the unconfirmed > HTLC-preimage, before its subsequent mempool replacement. The preimage can > be extracted from the second-stage HTLC-preimage and used to fetch the > off-chain inbound HTLC with a cooperative message or go on-chain with it to > claim the accepted HTLC output. > > Implemented and deployed by Eclair and LND. > > CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid > by the attacker, a risk of the HTLC-preimage being detected or discovered > by the honest lightning node, or the HTLC-timeout to slip in a winning > block template. Bumping the default CLTV delta hardens the odds of success > of a simple replacement cycling attack. > > Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72. > > ## Affected Bitcoin Protocols and Applications > > From my understanding the following list of Bitcoin protocols and > applications could be affected by new denial-of-service vectors under some > level of network mempools congestion. Neither tests or advanced review of > specifications (when available) has been conducted for each of them: > - on-chain DLCs > - coinjoins > - payjoins > - wallets with time-sensitive paths > - peerswap and submarine swaps > - batch payouts > - transaction "accelerators" > > Inviting their developers, maintainers and operators to investigate how > replacement cycling attacks might disrupt their in-mempool chain of > transactions, or fee-bumping flows at the shortest delay. Simple flows and > non-multi-party transactions should not be affected to the best of my > understanding. > > ## Open Problems: Package Malleability > > Pinning attacks have been known for years as a practical vector to > compromise lightning channels funds safety, under different scenarios (cf. > current bip331's motivation section). Mitigations at the mempool level have > been designed, discussed and are under implementation by the community > (ancestor package relay + nverrsion=3 policy). Ideally, they should > constraint a pinning attacker to always attach a high feerate package > (commitment + CPFP) to replace the honest package, or allow a honest > lightning node to overbid a malicious pinning package and get its > time-sensitive transaction optimistically included in the chain. > > Replacement cycling attack seem to offer a new way to neutralize the design > goals of package relay and its companion nversion=3 policy, where an > attacker package RBF a honest package out of the mempool to subsequently > double-spend its own high-fee child with a transaction unrelated to the > channel. As the remaining commitment transaction is pre-signed with a > minimal relay fee, it can be evicted out of the mempool. > > A functional test exercising a simple replacement cycling of a lightning > channel commitment transaction on top of the nversion=3 code branch is > available: > https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 > > ## Discovery > > In 2018, the issue of static fees for pre-signed lightning transactions is > made more widely known, the carve-out exemption in mempool rules to > mitigate in-mempool package limits pinning and the anchor output pattern > are proposed. > > In 2019, bitcoin core 0.19 is released with carve-out support. Continued > discussion of the anchor output pattern as a dynamic fee-bumping method. > > In 2020, draft of anchor output submitted to the bolts. Initial finding of > economic pinning against lightning commitment and second-stage HTLC > transactions. Subsequent discussions of a preimage-overlay network or > package-relay as mitigations. Public call made to inquiry more on potential > other transaction-relay jamming attacks affecting lightning. > > In 2021, initial work in bitcoin core 22.0 of package acceptance. Continued > discussion of the pinning attacks and shortcomings of current mempool rules > during community-wide online workshops. Later the year, in light of all > issues for bitcoin second-layers, a proposal is made about killing the > mempool. > > In 2022, bip proposed for package relay and new proposed v3 policy design > proposed for a review and implementation. Mempoolfullrbf is supported in > bitcoin core 24.0 and conceptual questions about alignment of mempool rules > w.r.t miners incentives are investigated. > > Along this year 2022, eltoo lightning channels design are discussed, > implemented and reviewed. In this context and after discussions on mempool > anti-DoS rules, I discovered this new replacement cycling attack was > affecting deployed lightning channels and immediately reported the finding > to some bitcoin core developers and lightning maintainers. > > ## Timeline > > - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg > Sanders and Gloria Zhao > - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier, > Matt Corallo and Olaoluwa Osuntunkun > - 2022-12-23: Sharing to Eugene Siegel (LND) > - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning > potential affected projects) > - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers > issuers) and initial proposal of an early public disclosure > - 2022-01-19: Collection of analysis if other second-layers and multi-party > applications affected. LN mitigations development starts. > - 2023-05-04: Sharing to Wilmer Paulino (LDK) > - 2023-06-20: LN mitigations implemented and progressively released. Week > of the 16 october proposed for full disclosure. > - 2023-08-10: CVEs assigned by MITRE > - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling > attack existence to security(a)bitcoincore.org. > - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 / > CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks > > ## Conclusion > > Despite the line of mitigations adopted and deployed by current major > lightning implementations, I believe replacement cycling attacks are still > practical for advanced attackers. Beyond this new attack might come as a > way to partially or completely defeat some of the pinning mitigations which > have been working for years as a community. > > As of today, it is uncertain to me if lightning is not affected by a more > severe long-term package malleability critical security issue under current > consensus rules, and if any other time-sensitive multi-party protocol, > designed or deployed isn't de facto affected too (loss of funds or denial > of service). > > Assuming analysis on package malleability is correct, it is unclear to me > if it can be corrected by changes in replacement / eviction rules or > mempool chain of transactions processing strategy. Inviting my technical > peers and the bitcoin community to look more on this issue, including to > dissent. I'll be the first one pleased if I'm fundamentally wrong on those > issues, or if any element has not been weighted with the adequate technical > accuracy it deserves. > > Do not trust, verify. All mistakes and opinions are my own. > > Antoine > > "meet with Triumph and Disaster. And treat those two impostors just the > same" - K. >

1 0

Crypto Mixers as National Security Threats, Fuck Yeah!
by pro2rat＠yahoo.com.au 20 Oct '23

20 Oct '23

When cypherpunks are called terrorists we will be doing our job https://decrypt.co/news-explorer?pinned=349491&title=us-wants-to-classify-c… Reposts not yet more death threats to US protected persons ( Snork! )

2 1

Re: [bitcoin-dev] BitVM: Compute Anything on Bitcoin
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

On 10/15/23, ZmnSCPxj via bitcoin-dev <bitcoin-dev(a)lists.linuxfoundation.org> wrote: > Good morning Robin et al, > > It strikes me that it may be possible to Scriptless Script BitVM, replacing > hashes and preimages with points and scalars. > > For example, equivocation of bit commitments could be done by having the > prover put a slashable fund behind a pubkey `P` (which is a point). > This slashable fund could be a 2-of-2 between prover and verifier `P && V`. > > Then the prover provides a bit-0 point commitment `B`, which is a point. > If the prover wants to assert that this specific bit is 0, it has to provide > `b` such that `B = b * G`. > If the prover wants to instead assert that this bit is 1, it has to provide > `b + p` such that `B = b * G` and `P = p * G`. > If `b` (and therefore `B`) is chosen uniformly at random, if it makes > exactly one of these assertions (that the bit is 0, or that the bit is 1) > then it does not reveal `p`. > But if it equivocates and asserts both, it reveals `b` and `b + p` and the > verifier can get the scalar `p`, which is also the private key behind `P` > and thus can get the fund `P && V`. > > To create a logic gate commitment, we have the prover and validator provide > public keys for each input-possibility and each output-possibility, then use > MuSig to combine them. > For example, suppose we have a NAND gate with inputs I, J and output K. > We have: > > * `P[I=0]` and `V[I=0]`, which are the public keys to use if input I is 0. > * `P[I=1]` and `V[I=1]`, which are the public keys to use if input I is 1. > * ...similar for input `J` and output `K`. > > In the actual SCRIPT, we take `MuSig(P[I=0], V[I=0])` etc. > For a SCRIPT to check what the value of `I` is, we would have something > like: > > ``` > OP_DUP <MuSig(P[I=1], V[I=1])> OP_CHECKSIG > OP_IF > OP_DROP > <1> > OP_ELSE > <MuSig(P[I=0], V[I=0])> OP_CHECKSIGVERIFY > <0> > OP_ENDIF > ``` > > We would duplicate the above (with appropriate `OP_TOALTSTACK` and > `OP_FROMALTSTACK`) for input `J` and output `K`, similar to Fig.2 in the > paper. > > The verifier then provides adaptor signatures, so that for `MuSig(P[I=1], > V[I=1])` the prover can only complete the signature by revealing the `b + p` > for `I`. > Similar for `MuSig(P[I=0], V[I=0])`, the verifier provides adaptor > signatures so that the prover can only complete the signature by revealing > the `b` for `I`. > And so on. > Thus, the prover can only execute the SCRIPT by revealing the correct > commitments for `I`, `J`, and `K`, and any equivocation would reveal `p` and > let the verifier slash the fund of `P`. > > Providing the adaptor signatures replaces the "unlock" of the > challenge-response phase, instead of requiring a preimage from the > verifier. > > The internal public key that hides the Taproot tree containing the above > logic gate commitments could be `MuSig(P, V)` so that the verifier can stop > and just take the funds by a single signature once it has learned `p` due to > the prover equivocating. > > Not really sure if this is super helpful or not. > Hashes are definitely less CPU to compute. > > For example, would it be possible to have the Tapleaves be *just* the wires > between NAND gates instead of NAND gates themselves? > So to prove a NAND gate operation with inputs `I` and `J` and output `K`, > the prover would provide bit commitments `B` for `B[I]`, `B[J]`, and `B[K]`, > and each tapleaf would be just the bit commitment SCRIPT for `I`, `J`, and > `K`. > The prover would have to provide `I` and `J`, and commit to those, and then > verifier would compute `K = ~(I & J)` and provide *only* the adaptor > signature for `MuSig(P[K=<result>], V[K=<result>])`, but not the other > side. > > In that case, it may be possible to just collapse it down to `MuSig(P, V)` > and have the verifier provide individual adaptor signatures. > For example, the verifier can first challenge the prover to commit to the > value of `I` by providing two adaptor signatures for `MuSig(P, V)`, one for > the scalar behind `B[I]` and the other for the scalar behind `B[I] + P`. > The prover completes one or the other, then the verifier moves on to `B[J]` > and `B[J] + P`. > The prover completes one or the other, then the verifier now knows `I` and > `J` and can compute the supposed output `K`, and provides only the adaptor > signature for `MuSig(P, V)` for the scalar behind `B[K]` or `B[K] + P`, > depending on whether `K` is 0 or 1. > > That way, you only really actually need Schnorr signatures without having to > use Tapleaves at all. > This would make BitVM completely invisible on the blockchain, even in a > unilateral case where one of the prover or verifier stop responding. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev(a)lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >

1 0

[ot][spam][crazy] how do i make secure networks now that i've mugged all the hackers of their chains
by Undescribed Horrific Abuse, One Victim & Survivor of Many 20 Oct '23

20 Oct '23

there was a recent set of [2023-10-16 1936 ET] CVEs regarding bitcoin lightning network. i haven't more than glanced at them yet, but their discuss a vulnerability in lightning that can provide for compromise of the integrity of funds. somebody pointed out some years ago what others already knew, which is that lightning does not have the level of security of [2023-10-16 1938 ET] .... anyway, long story short, bitcoin has been stuck in a draft state for years now, likely because of the heavy addition of profit and political motives to its influences. now, i could adopt some unpleasantly affect and come in, arrogance blazing, and propose a better protocol (and i imagine many have tried to do this), but honestly i am too muddled with dissociative stuff to actually do that accurately anymore. how might you do it, if you didn't have an obsessive cryptohacker to write you beyond-classified secure constructs like used to be the norm in community research? how would you do it, if you were a crazy messed up confused person, like me? [2023-10-16 19:40] ... a little sadly, the security of these things is similar to (i happen to be playing chess these days) a chess game. you have to actually think of all the ways something can be broken, and address them. there are a few rules of thumb, too. these rules of thumb were commonly known in the 90s and 00s on lists like this one, but [obviously things are different]. but it's something like: - assume it's possible. everything can be broken: everything can be secured: -- you keep finding ways to break it and addressing them until you get so deep into how things can be broken that nobody would try to do it in your current environment -- you watch the changes in the environment and _UPDATE THE DESIGN_ to address them (bitcoin stopped updating its design.) - keep the solution simple that's ... roughly it ;P so, lightning is not simple -- [2023-10-16 19:44 ET] it fundamentally changes the security model associated with bitcoin [sending this as-is, most thoughts didn't make it at this time, [important ideas might include that among politics, security, and profit, the different focuses interact and do different things, and that the obvious solution to bitcoin's issues is to obviously to use shared distribution like bittorrent and [strong eventually-consistent cryptography that can address global consensus at a later time?]] 2023-10-23

1 0