Antoine Riard [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-07-13 to 2023-06-07
💬 Posted a total of 269 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Opt-in full-RBF, DRAFT
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-10-18 13:02:09

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: No experiments have been conducted yet due to limited experts and other pending security issues.
📝 Original message:
> We have conducted one so far, multiple scenarios to look at.
_*none*_ so far. typo of mine - apologize english is not my native language.
We discussed conducting experiments pre-disclosure in an e-mail of the 11th
August 2023.
"If someone is down to setup a "black box" Lightning infra on mainet, I'm
game on to exercise the vulnerabilities and mitigations during the coming
months and revisit the disclosure date dependent on the learnings."
However as the number of Lightning worldwide experts who have level of
knowledge and understandings to take part to experiments is I think
restrained to people listed on the disclosure mails _and_ we had other
pendings non-disclosed security issues at the time like the ones revealed
"fake channel DoS vector" the 23th August 2023, we didn't conduct them.
Le mar. 17 oct. 2023 à 18:47, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> Hi Ziggie,
>
> > thanks for this detailed explanation. This class of pinning attacks
> sound not too unlikely especially if the attacker targets channels with
> high capacity and very loose channel policies (allowing the full htlc
> > amount to be the channel capacity). Could you add more details about the
> attack you observed on mainnet ? How did you monitor the chain, are the
> some tools available I can run in parallel to my
> > lightning software to record this kind of suspicious behaviour (which
> did you use)?
>
> Just to give a clarification no _such_ attack has been observed on
> mainnet, since I and other LN maintainers have been aware of this issue. If
> there is a confusion on the disclosure mail thanks to point to it, I'll
> correct it.
>
> We discussed privately to experiment a demo attack in restrained dev
> circles, like we have done in the past for some LN sec issues. We have
> conducted one so far, multiple scenarios to look at.
>
> I confirm the risk of exposure if an attacker targets channels with high
> capacity and loose channel policies. Note there is no way to configure the
> cap for the total value of outbound HTLC in-flight, which is the flow
> affected.
>
> If you would like to observe the existence of such an attack happening,
> look at your mempool logs and the amount of HTLC output being
> systematically conflicted out with the following sequence (HTLC-timeout -
> HTLC-preimage - HTLC-timeout - ...).
>
> As an observation note, this is not akin to a pinning attack, as there is
> no "honest" or "malicious" transaction pinned in network mempools. And it
> can happen without network mempools congestion.
>
> > What's also worth mentioning here is that you do not really have to
> control 2 neighbouring nodes to target your victim. If you can cycle the
> attack on the tail side and delay the confirmation of the htlc- timeout
> covenant the peer at the front (incoming link) of the victim will
> force-close the channel and claim his timeout-path in the same way
> (canceling back the initial htlc amount to the attackers initial node).
>
> I think this is a behavior worthy of testing.
>
> > Apart from that I think one can even introduce some kind of feebumping
> race between the victim and the attacker on the tail side of the attack
> making the attack even more costly. I think
> > currently when lightning nodes see the preimage in the mempool (during
> the time where they already can spend the same output with the
> timeout-covenant) we are honest and just extract
> > the preimage and don't try to race this tx output.
>
> Local-mempool preimage monitoring has been implemented by Eclair for years
> as a mitigation against old school pinning attacks on second-stage HTLC
> transactions.
>
> This mechanism has been implemented by LND in the last months, following
> the report of replacement cycling attacks. As of today this is not
> implemented by Core-Lightning or LDK.
>
> > So we maybe should start feebumping this output if we end up in this
> scenario? If we see the preimage and can also claim this output via the
> htlc-timeout path, we should aggressively fee-bump (racing this output) our
> htlc-output in addition to grabbing the preimage and claiming it on the
> incoming. This is only feasible with anchor channels where we can add fees
> to the htlc-covenant. This would make the attack more costly for a peer
> when he knows that we use fees up to 50% of the htlc value. When you cycle
> this 144 times you will be at a heavy loss trying to steal this htlc.
>
> This is the "defensive fee mitigation" proposed in the paper. Coming with
> some unknown.
>
> > I would add another mitigation to the list for node runners to restrict
> the amount and number of HTLCs for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
> See the point above on the lack of way at the spec-level to negotiate cap
> on the total value of outbound HTLC in-flight.
>
> Le mar. 17 oct. 2023 à 08:21, ziggie1984 <ziggie1984 at protonmail.com> a
> écrit :
>
>> ## 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.
>>
>>
>> Hi Antoine,
>>
>> thanks for this detailed explanation. This class of pinning attacks sound
>> not too unlikely especially if the attacker targets channels with high
>> capacity and very loose channel policies (allowing the full htlc amount to
>> be the channel capacity). Could you add more details about the attack you
>> observed on mainnet ? How did you monitor the chain, are the some tools
>> available I can run in parallel to my lightning software to record this
>> kind of suspicious behaviour (which did you use)?
>> What's also worth mentioning here is that you do not really have to
>> control 2 neighbouring nodes to target your victim. If you can cycle the
>> attack on the tail side and delay the confirmation of the htlc-timeout
>> covenant the peer at the front (incoming link) of the victim will
>> force-close the channel and claim his timeout-path in the same way
>> (canceling back the initial htlc amount to the attackers initial node).
>>
>> Apart from that I think one can even introduce some kind of feebumping
>> race between the victim and the attacker on the tail side of the attack
>> making the attack even more costly. I think currently when lightning nodes
>> see the preimage in the mempool (during the time where they already can
>> spend the same output with the timeout-covenant) we are honest and just
>> extract the preimage and don't try to race this tx output. So we maybe
>> should start feebumping this output if we end up in this scenario? If we
>> see the preimage and can also claim this output via the htlc-timeout path,
>> we should aggressively fee-bump (racing this output) our htlc-output in
>> addition to grabbing the preimage and claiming it on the incoming. This is
>> only feasible with anchor channels where we can add fees to the
>> htlc-covenant. This would make the attack more costly for a peer when he
>> knows that we use fees up to 50% of the htlc value. When you cycle this 144
>> times you will be at a heavy loss trying to steal this htlc.
>>
>> I would add another mitigation to the list for node runners to restrict
>> the amount and number of HTLCs for big channels to unknown peers. It
>> quickly comes with a loss when the HTLCs the attacker tries to steal are
>> small.
>>
>>
>> Kind regards,
>>
>> ziggie
>>
>>
>> ------- Original Message -------
>> On Monday, October 16th, 2023 at 18:57, Antoine Riard <
>> antoine.riard at gmail.com> 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/replacement-cycling.pdf
>>
>> ## 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 at 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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/36ea4307/attachment-0001.html>

2023-10-18 13:02:09

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: The disclosed mitigations for lightning attacks include mempool scanning, transaction re-signing/re-broadcasting, and bumping CLTV delta. However, these mitigations may not be effective in fixing the issue. Additional measures such as stratum v2 deployment and a replacement buffer at the mempool level may make the attack harder. The issue of fees is also a challenge.
📝 Original message:
The disclosure mails noted a 3rd mitigation beyond mempool scanning and
transaction re-signing / re-broadcasting, namely bumping CLTV delta.
Generally bumping CLTV delta is a basic line of mitigations for a lot of
lightning attacks, as it gives opportunity to node operators to intervene
and re-broadcast their time-sensitive transactions on other interfaces (e.g
a secondary full-node if the first one is eclipsed).
About the second mitigation transaction re-signing, if done correctly at
least sounds to put an economic cost (denominated in fees / feerates) on
the attack. This is unclear to me if the game-theory of this cost holds.
One thing which sounds to me making the attack harder is stratum v2
deployment, as you're increasing the number of miners which might do their
own block templates, and therefore the number of miners' mempools where an
attacker has to successfully continuously replace in cycles channels
counterparties transactions.
A replacement buffer or history of transactions at the mempool level might
be a mitigation to this attack. I believe this is yet to be seen if it can
be made robust enough.
I don't know if folks like tadge or rusty who have been involved in the
early design of lightning have more ideas of mitigations. Fees was noted as
a hard issue in the original paper.
Le mer. 18 oct. 2023 à 01:17, Matt Corallo <lf-lists at mattcorallo.com> a
écrit :
> 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/replacement-cycling.pdf
> > <
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
> >
> >
> > ## 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 at bitcoincore.org <mailto:security at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231018/dfcf4d45/attachment-0001.html>

2023-10-18 13:02:08

- reply

📅 Original date posted:2023-10-17
🗒️ Summary of this message: No pinning attacks have been observed on the mainnet. Monitoring mempool logs can help detect suspicious behavior. Feebumping could be considered as a mitigation strategy.
📝 Original message:
Hi Ziggie,
> thanks for this detailed explanation. This class of pinning attacks sound
not too unlikely especially if the attacker targets channels with high
capacity and very loose channel policies (allowing the full htlc
> amount to be the channel capacity). Could you add more details about the
attack you observed on mainnet ? How did you monitor the chain, are the
some tools available I can run in parallel to my
> lightning software to record this kind of suspicious behaviour (which did
you use)?
Just to give a clarification no _such_ attack has been observed on mainnet,
since I and other LN maintainers have been aware of this issue. If there is
a confusion on the disclosure mail thanks to point to it, I'll correct it.
We discussed privately to experiment a demo attack in restrained dev
circles, like we have done in the past for some LN sec issues. We have
conducted one so far, multiple scenarios to look at.
I confirm the risk of exposure if an attacker targets channels with high
capacity and loose channel policies. Note there is no way to configure the
cap for the total value of outbound HTLC in-flight, which is the flow
affected.
If you would like to observe the existence of such an attack happening,
look at your mempool logs and the amount of HTLC output being
systematically conflicted out with the following sequence (HTLC-timeout -
HTLC-preimage - HTLC-timeout - ...).
As an observation note, this is not akin to a pinning attack, as there is
no "honest" or "malicious" transaction pinned in network mempools. And it
can happen without network mempools congestion.
> What's also worth mentioning here is that you do not really have to
control 2 neighbouring nodes to target your victim. If you can cycle the
attack on the tail side and delay the confirmation of the htlc- timeout
covenant the peer at the front (incoming link) of the victim will
force-close the channel and claim his timeout-path in the same way
(canceling back the initial htlc amount to the attackers initial node).
I think this is a behavior worthy of testing.
> Apart from that I think one can even introduce some kind of feebumping
race between the victim and the attacker on the tail side of the attack
making the attack even more costly. I think
> currently when lightning nodes see the preimage in the mempool (during
the time where they already can spend the same output with the
timeout-covenant) we are honest and just extract
> the preimage and don't try to race this tx output.
Local-mempool preimage monitoring has been implemented by Eclair for years
as a mitigation against old school pinning attacks on second-stage HTLC
transactions.
This mechanism has been implemented by LND in the last months, following
the report of replacement cycling attacks. As of today this is not
implemented by Core-Lightning or LDK.
> So we maybe should start feebumping this output if we end up in this
scenario? If we see the preimage and can also claim this output via the
htlc-timeout path, we should aggressively fee-bump (racing this output) our
htlc-output in addition to grabbing the preimage and claiming it on the
incoming. This is only feasible with anchor channels where we can add fees
to the htlc-covenant. This would make the attack more costly for a peer
when he knows that we use fees up to 50% of the htlc value. When you cycle
this 144 times you will be at a heavy loss trying to steal this htlc.
This is the "defensive fee mitigation" proposed in the paper. Coming with
some unknown.
> I would add another mitigation to the list for node runners to restrict
the amount and number of HTLCs for big channels to unknown peers. It
quickly comes with a loss when the HTLCs the attacker tries to steal are
small.
See the point above on the lack of way at the spec-level to negotiate cap
on the total value of outbound HTLC in-flight.
Le mar. 17 oct. 2023 à 08:21, ziggie1984 <ziggie1984 at protonmail.com> a
écrit :
> ## 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.
>
>
> Hi Antoine,
>
> thanks for this detailed explanation. This class of pinning attacks sound
> not too unlikely especially if the attacker targets channels with high
> capacity and very loose channel policies (allowing the full htlc amount to
> be the channel capacity). Could you add more details about the attack you
> observed on mainnet ? How did you monitor the chain, are the some tools
> available I can run in parallel to my lightning software to record this
> kind of suspicious behaviour (which did you use)?
> What's also worth mentioning here is that you do not really have to
> control 2 neighbouring nodes to target your victim. If you can cycle the
> attack on the tail side and delay the confirmation of the htlc-timeout
> covenant the peer at the front (incoming link) of the victim will
> force-close the channel and claim his timeout-path in the same way
> (canceling back the initial htlc amount to the attackers initial node).
>
> Apart from that I think one can even introduce some kind of feebumping
> race between the victim and the attacker on the tail side of the attack
> making the attack even more costly. I think currently when lightning nodes
> see the preimage in the mempool (during the time where they already can
> spend the same output with the timeout-covenant) we are honest and just
> extract the preimage and don't try to race this tx output. So we maybe
> should start feebumping this output if we end up in this scenario? If we
> see the preimage and can also claim this output via the htlc-timeout path,
> we should aggressively fee-bump (racing this output) our htlc-output in
> addition to grabbing the preimage and claiming it on the incoming. This is
> only feasible with anchor channels where we can add fees to the
> htlc-covenant. This would make the attack more costly for a peer when he
> knows that we use fees up to 50% of the htlc value. When you cycle this 144
> times you will be at a heavy loss trying to steal this htlc.
>
> I would add another mitigation to the list for node runners to restrict
> the amount and number of HTLCs for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
>
> Kind regards,
>
> ziggie
>
>
> ------- Original Message -------
> On Monday, October 16th, 2023 at 18:57, Antoine Riard <
> antoine.riard at gmail.com> 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/replacement-cycling.pdf
>
> ## 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/9d438d0e/attachment-0001.html>

2023-10-03 21:44:18

- reply

📅 Original date posted:2023-09-25
🗒️ Summary of this message: Payment pools and channel factories face limitations in interactivity, affecting the security of user funds. Proposed solutions include introducing a coordinator or partitioning balances, but these may not be economically practical. A potential solution is to prevent off-chain group equivocation by editing the funding utxo in a way that allows for the registration of new off-chain subgroups. CoinPool's idea of including user pubkeys and balance amounts in Taproot leaves could be utilized for privacy-preserving payments and contracts.
📝 Original message:
Payment pools and channel factories are afflicted by severe interactivity
constraints worsening with the number of users owning an off-chain balance
in the construction. The security of user funds is paramount on the ability
to withdraw unilaterally from the off-chain construction. As such any
update applied to the off-chain balances requires a signature contribution
from the unanimity of the construction users to ensure this ability is
conserved along updates.
As soon as one user starts to be offline or irresponsive, the updates of
the off-chain balances must have to be halted and payments progress are
limited among subsets of 2 users sharing a channel. Different people have
proposed solutions to this issue: introducing a coordinator, partitioning
or layering balances in off-chain users subsets. I think all those
solutions have circled around a novel issue introduced, namely equivocation
of off-chain balances at the harm of construction counterparties [0].
As ZmnSCPxj pointed out recently, one way to mitigate this equivocation
consists in punishing the cheating pre-nominated coordinator on an external
fidelity bond. One can even imagine more trust-mimized and decentralized
fraud proofs to implement this mitigation, removing the need of a
coordinator [1].
However, I believe punishment equivocation to be game-theory sound should
compensate a defrauded counterparty of the integrity of its lost off-chain
balance. As one cheating counterparty can equivocate in the worst-case
against all the other counterparties in the construction, one fidelity bond
should be equal to ( C - 1 ) * B satoshi amount, where C is the number of
construction counterparty and B the initial off-chain balance of the
cheating counterparty.
Moreover, I guess it is impossible to know ahead of a partition or
transition who will be the "honest" counterparties from the "dishonest"
ones, therefore this ( C - 1 ) * B-sized fidelity bond must be maintained
by every counterparty in the pool or factory. On this ground, I think this
mitigation and other corrective ones are not economically practical for
large-scale pools among a set of anonymous users.
I think the best solution to solve the interactivity issue which is
realistic to design is one ruling out off-chain group equivocation in a
prophylactic fashion. The pool or factory funding utxo should be edited in
an efficient way to register new off-chain subgroups, as lack of
interactivity from a subset of counterparties demands it.
With CoinPool, there is already this idea of including a user pubkey and
balance amount to each leaf composing the Taproot tree while preserving the
key-path spend in case of unanimity in the user group. Taproot leaves can
be effectively regarded as off-chain user accounts available to realize
privacy-preserving payments and contracts.
I think one (new ?) idea can be to introduce taproot leaves "cut-through"
spends where multiple leaves are updated with a single witness,
interactively composed by the owners of the spent leaves. This spend sends
back the leaves amount to a new single leaf, aggregating the amounts and
user pubkeys. The user leaves not participating in this "cut-through" are
inherited with full integrity in the new version of the Taproot tree, at
the gain of no interactivity from their side.
Let's say you have a CoinPool funded and initially set with Alice, Bob,
Caroll, Dave and Eve. Each pool participant has a leaf L.x committing to an
amount A.x and user pubkey P.x, where x is the user name owning a leaf.
Bob and Eve are deemed to be offline by the Alice, Caroll and Dave subset
(the ACD group).
The ACD group composes a cut-through spend of L.a + L.c + L.d. This spends
generates a new leaf L.(acd) leaf committing to amount A.(acd) and P.(acd).
Amount A.(acd) = A.a + A.c + A.d and pubkey P.(acd) = P.a + P.c + P.d.
Bob's leaf L.b and Eve's leaf L.e are left unmodified.
The ACD group generates a new Taproot tree T' = L.(acd) + L.b + L.e, where
the key-path K spend including the original unanimity of pool
counterparties is left unmodified.
The ACD group can confirm a transaction spending the pool funding utxo to a
new single output committing to the scriptpubkey K + T'.
>From then, the ACD group can pursue off-chain balance updates among the
subgroup thanks to the new P.(acd) and relying on the known Eltoo
mechanism. There is no possibility for any member of the ACD group to
equivocate with Bob or Eve in a non-observable fashion.
Once Bob and Eve are online and ready to negotiate an on-chain pool
"refresh" transaction, the conserved key-path spend can be used to
re-equilibrate the Taproot tree, prune out old subgroups unlikely to be
used and provision future subgroups, all with a compact spend based on
signature aggregation.
Few new Taproot tree update script primitives have been proposed, e.g [2].
Though I think none with the level of flexibility offered to generate
leaves cut-through spends, or even batch of "cut-through" where M subgroups
are willing to spend N leaves to compose P new subgroups fan-out in Q new
outputs, with showing a single on-chain witness. I believe such a
hypothetical primitive can also reduce the chain space consumed in the
occurrence of naive mass pool withdraws at the same time.
I think this solution to the high-interactivity issue of payment pools and
factories shifts the burden on each individual user to pre-commit fast
Taproot tree traversals, allowing them to compose new pool subgroups as
fluctuations in pool users' level of liveliness demand it. Pool efficiency
becomes the sum of the quality of user prediction on its counterparties'
liveliness during the construction lifetime. Recursive taproot tree spends
or more efficient accumulator than merkle tree sounds ideas to lower the
on-chain witness space consumed by every pool in the average
non-interactive case.
Cheers,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-August/004043.html
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230925/77e3936d/attachment.html>

2023-07-27 00:22:34

- reply

📅 Original date posted:2023-07-25
🗒️ Summary of this message: Proposal to use a tapscript branch instead of MuSig2 signing for unilateral closes in the Lightning Network. Discusses dynamic fees and Bitcoin as a universal clock.
📝 Original message:
Hi Zeeman,
> A proposal I made in the Signal group after the summit would be to not
use MuSig2 signing for commitment transactions (== unilateral closes).
> Instead, we add a tapscript branch that is just `<A> OP_CHECKSIGVERIFY
<B> OP_CHECKSIG` and use that for unilateral closes.
> We only sign with MuSig2 on mutual closes, after we have negotiated
closing fees (whether that is the current long closing conversation, or
simplified closing) so that only mutual closes require nonce
> storage.
>
> As mutual closes assume continuous connectivity anyway, we can keep
counterparty nonces in volatile RAM and not store nonces in persistent
storage; if a disconnection occurs, we just remove it from
> volatile RAM and restart the mutual close negotiation on reconnection.
>
> This is more palatable as even with a very restrictive hardware device
you do not have to store the peer nonce in persistent storage.
> The hope is that mutual closes dominate over unilateral closes.
Hardware devices with reasonable persistent storage sounds cheaper than the
additional fee-bumping reverse one (locally or a third-party), must
conserve to pay for the probabilistic worst-case `<A> OP_CHECKSIGVERIFY <B>
OP_CHECKSIG` satisfying witness.
> Conditinoal fees already on the Lightning Network are already dynamic,
with many people (including myself) writing software that measures demand
and changes price accordingly.
> Why would unconditional fees be necessarily static, when there is no
mention of it being static?
While I'm in sync with you on the Lightning Network being a system driven
by demand and charge price accordingly, some of the recent jamming
mitigation proposals where build on the proposal of "static fees" or
unconditional fees, e.g https://eprint.iacr/2022/1454.pdf. As soon as you
start to think in terms of dynamic fees, you start to have issues w.r.t
gossip convergence delays and rate-limitation of your local unconditional
fees updates.
> Given a "stereotypical" forwarding node, what is the most likely
subjective valuation?
> If a node is not a stereotypical forwarding node, how does it deviate
from the stereotypical one?
Answer is a function of your collection of historical forwarding HTLC
traffic and secondary source of information.
Somehow the same as for base-layer fee-estimation, the more consistent your
mempool data-set, the better will be your valuation.
> The problem is that the Bitcoin clock is much too coarsely grained, with
chain height advances occasionally taking several hours in the so-called
"real world" I have heard much rumor about.
Sure, I still think Bitcoin as a universal clock is still the most costly
for a Lightning counterparty to game on, if it has to be used as a
mechanism to arbitrate the fees / reputation paid for the in-flight
duration of a HTLC. Even relying on timestamp sounds to offer some margin
of malleation (e.g advance of max 2h, consensus rule) if you have hashrate
capabilities.
> Would not the halt of the channel progress be considered worthy of a
reputation downgrade by itself?
That's an interesting point, rather than halting channel progress being
marked as a strict reputation downgrade, you could negotiate a "grace
delay" during which channel progress must be made forward (to allow for
casualties like software upgrade or connectivity issue).
Best,
Antoine
Le lun. 24 juil. 2023 à 09:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
>
>
> > > - For taproot/musig2 we need nonces:
> > > - Today we store the commitment signature from the remote party. We
> don’t need to store our own signature - we can sign at time of broadcast.
> > > - To be able to sign you need the verification nonce - you could
> remember it, or you could use a counter:
> > > - Counter based:
> > > - We re-use shachain and then just use it to generate nonces.
> > > - Start with a seed, derive from that, use it to generate nonces.
> > > - This way you don’t need to remember state, since it can always be
> generated from what you already have.
> > > - Why is this safe?
> > > - We never re-use nonces.
> > > - The remote party never sees your partial signature.
> > > - The message always stays the same (the dangerous re-use case is
> using the same nonce for different messages).
> > > - If we used the same nonce for different messages we could leak our
> key.
> > > - You can combine the sighash + nonce to make it unique - this also
> binds more.
> > > - Remote party will only see the full signature on chain, never your
> partial one.
> > > - Each party has sign and verify nonces, 4 total.
> > > - Co-op close only has 2 because it’s symmetric.
> >
> > (I don't know when mailing list post max size will be reached)
> >
> > Counter-based nonces versus stateful memorization of them from a user
> perspective depends on the hardware capabilities you have access to.
> >
> > The taproot schnorr flow could be transparent from the underlying
> signature scheme (FROST, musig2, TAPS in the future maybe).
>
> A proposal I made in the Signal group after the summit would be to not use
> MuSig2 signing for commitment transactions (== unilateral closes).
>
> Instead, we add a tapscript branch that is just `<A> OP_CHECKSIGVERIFY <B>
> OP_CHECKSIG` and use that for unilateral closes.
> We only sign with MuSig2 on mutual closes, after we have negotiated
> closing fees (whether that is the current long closing conversation, or
> simplified closing) so that only mutual closes require nonce storage.
>
> As mutual closes assume continuous connectivity anyway, we can keep
> counterparty nonces in volatile RAM and not store nonces in persistent
> storage; if a disconnection occurs, we just remove it from volatile RAM and
> restart the mutual close negotiation on reconnection.
>
> This is more palatable as even with a very restrictive hardware device you
> do not have to store the peer nonce in persistent storage.
> The hope is that mutual closes dominate over unilateral closes.
>
>
>
> > > - We run into the same pricing issues.
> > > - Why these combinations?
> > > - Since scarce resources are essentially monetary, we think that
> unconditional fees are the simplest possible monetary solution.
> > > - Unconditional Fees:
> > > - As a sender, you’re building a route and losing money if it doesn’t
> go through?
> > > - Yes, but they only need to be trivially small compared to success
> case fee budgets.
> > > - You can also eventually succeed so long as you retry enough, even if
> failure rates are very high.
> > > - How do you know that these fees will be small? The market could
> decide otherwise.
> >
> > Static unconditional fees is a limited tool in a world where rational
> economic actors are pricing their liquidity in function of demand.
>
> Conditinoal fees already on the Lightning Network are already dynamic,
> with many people (including myself) writing software that measures demand
> and changes price accordingly.
> Why would unconditional fees be necessarily static, when there is no
> mention of it being static?
>
>
> > > - We have to allow some natural rate of failure in the network.
> > > - An attacker can still aim to fall just below that failure threshold
> and go through multiple channels to attack an individual channel.
> > > - THere isn’t any way to set a bar that an attacker can’t fall just
> beneath.
> > > - Isn’t this the same for reputation? We have a suggestion for
> reputation but all of them fail because they can be gamed below the bar.
> > > - If reputation matches the regular operation of nodes on the network,
> you will naturally build reputation up over time.
> > > - If we do not match reputation accumulation to what normal nodes do,
> then an attacker can take some other action to get more reputation than the
> rest of the network. We don’t want attackers to be able to get ahead of
> regular nodes.
> > > - Let’s say you get one point for success and one for failure, a
> normal node will always have bad reputation. An attacker could then send 1
> say payments all day long, pay a fee for it > and gain reputation.
> > > - Can you define jamming? Is it stuck HTLCs or a lot of 1 sat HTLCS
> spamming up your DB?
> >
> > Jamming is an economic notion, as such relying on the subjectivism of
> node appreciation of local ressources.
>
> Given a "stereotypical" forwarding node, what is the most likely
> subjective valuation?
> If a node is not a stereotypical forwarding node, how does it deviate from
> the stereotypical one?
>
>
> > > - The dream solution is to only pay for the amount of time that a HTLC
> is held in flight.
> > > - The problem here is that there’s no way to prove time when things go
> wrong, and any solution without a universal clock will fall back on
> cooperation which breaks down in the case of > an attack.
> >
> > There is a universal clock in Bitcoin called the chain height advances.
>
> The problem is that the Bitcoin clock is much too coarsely grained, with
> chain height advances occasionally taking several hours in the so-called
> "real world" I have heard much rumor about.
>
>
> > > - What NACK says is: I’ve ignored all of your updates and I’m
> progressing to the next commitment.
> >
> > If resource bucketing or link-level liquidity management starts to be
> involved, one can mask behind "NACK" to halt the channel progress, without
> the reputation downgrade. Layer violation issue.
>
> Would not the halt of the channel progress be considered worthy of a
> reputation downgrade by itself?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230726/4858e570/attachment-0001.html>

2023-06-21 09:18:57

- reply

📅 Original date posted:2023-06-21
🗒️ Summary of this message: CivKit Node, a Nostr relay with peer-to-peer market board features, has been released. The CLI-only release is written in Rust and has basic NIP 01 support.
📝 Original message:
Hi Bitcoin Devs,
Proud to announce the first release of CivKit Node, a basic Nostr relay
with additional features to have a functional peer-to-peer market board,
written in Rust [0]. This is a very raw release as since we published the
paper back in April, we've been reached out by a bunch of folks asking how
they could contribute by code, or start to integrate CivKit in their Nostr
and Lightning peer-to-peer market clients [1].
Current release is CLI-only, just implementing basic NIP 01 support and is
full of bugs and todos, has not been tested on a lot of platforms and still
works as a local host for a lot of things [2]. There is a sample Nostr
client binary joined for deployment and testing purposes and an utility
binary to manage the node with a gRPC interface. Such an interface should
lay the groundwork to build one or more GUI applications on top, as it's a
recurring and consistent request from the community.
There is an experimental integration with BOLT8 Noise transport (thanks to
LDK), where one can connect to another CivKit Node has a peer, Idea is to
unify the communication infrastructure between Nostr and Lightning, and as
such have a single market of p2p service providers (watchtower, state
backup, boards) benefiting from network law effect. Beyond sharing all the
work between Lightning and Nostr ecosystem in terms of spamming
mitigations, careful crypto engineering (e.g onion routing) and
privacy-preserving monetary credentials [3].
With this released out, I think we'll go for sound onion routing support,
BOLT12 offers, the set of fundamental NIPs like NIP-09, NIP-16, NIP-33 and
others, and integration with a notary protocol (e.g Mainstay). Still, we
would like to listen to our users and we'll plumber features in the
function of relevant feedback collected from the community. One key lesson
from years contributing on LDK, we do not want to stay in a "purist
developer" ivory tower to avoid hard-to-integrate APIs, and make the
"product management" of the project owned by the community to ensure we're
building for the real-world of unstable and constrained mobile clients.
Once we have communication infrastructure and hopefully credentials
framework working, I think we'll start to have more serious development of
the CivKit functionaries services themselves (e.g market bulletin boards,
rank proof servers and moderation oracles in the paper parlance). Though
again, if folks want to start more custom services on top of CivKit Node,
we'll see what we can do, there is a brave new world to explore with Nostr
and Lightning maturation.
For the historical note, peer-to-peer market features were present in
Bitcoin Core circa 2010 (in fact before the ref client was dubbed Core).
Those features were removed by commit 5253d1ab "strip out unfinished
product, review and market stuff" by Satoshi [4]. Retrospectively, it was a
good insight as Core has evolved as a complex beast enough and careful
layerization is one of the best learning from the 50 years of Internet
history. Still, censorship-resistant and large-scale peer-to-peer markets
sounds still one of the missing blocks of the Bitcoin protocol stack.
Looking forward to growing the Bitcoin and Lightning internal economies by
an order of magnitude or two with the CivKit Node, if the kharma is with us.
All works are released under MIT/Apache licenses and we aim to bind to the
best open-source development standards as set by Bitcoin Core and the Linux
kernel communities and we're welcoming anyone strongly willing to build
with passion and love.
I think for the future, we'll do the announcement on its own communication
channel, whatever a new mailing list, or something experimental on top of
Nostr groups, Still, if we innove in terms of cryptography we're aiming to
have things standardized under BIPs.
"Sic itur ad astra" -
Block 000000000000000000053fd09a45f48e747f281122021edc2f7e97efcdd66248
Cheers,
Antoine
[0] https://github.com/civkit/civkit-node
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021556.html
[2] Of course, there are gazillins of things to implement, please open an
issue on the repository directly rather to yell something doesn't work.
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html
[4] https://github.com/bitcoin/bitcoin/commit/5253d1ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230621/7e720924/attachment-0001.html>