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"

[Matt Corallo via bitcoin-dev]

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 



  ## Problem

A lightning node allows HTLCs 

Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants

[Antoine Riard via bitcoin-dev]

Hi Bastien,

> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.

It is uncertain to me if secure fee-bumping, even with future mechanisms
like package relay and nversion=3, is robust enough for multi-party
transactions and covenant-enable constructions under usual risk models.

See test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf

Appreciated expert eyes of folks understanding both lightning and core
mempool on this.
There was a lot of back and forth on nversion=3 design rules, though the
test is normally built on glozow top commit of the 3 Oct 2023.

Best,
Antoine

Le mar. 17 oct. 2023 à 14:03, Bastien TEINTURIER  a
écrit :

> Good morning list,
>
> I've been trying to design a protocol to let users withdraw funds from
> exchanges directly into their lightning wallet in an efficient way
> (with the smallest on-chain footprint possible).
>
> I've come to the conclusion that this is only possible with some form of
> covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The
> goal of this post is to explain why, and add this usecase to the list of
> useful things we could do if we had covenants (insert "wen APO?" meme).
>
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.
>
> Hence the idea of batching those into a single transaction. Since we
> don't want to introduce any intermediate transaction, we must be able
> to create one transaction that splices multiple channels at once. The
> issue is that for each of these channels, we need a signature from the
> corresponding wallet user, because we're spending the current funding
> output, which is a 2-of-2 multisig between the wallet user and the
> wallet provider. So we run into the usual availability problem: we need
> signatures from N users who may not be online at the same time, and if
> one of those users never comes online or doesn't complete the protocol,
> we must discard the whole batch.
>
> There is a workaround though: each wallet user can provide a signature
> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
> funding output to create a new funding output with the expected amount.
> This lets users sign *before* knowing the final transaction, which the
> exchange can create by batching pairs of inputs/outputs. But this has
> a fatal issue: at that point the wallet user has no way of spending the
> new funding output (since it is also a 2-of-2 between the wallet user
> and the wallet provider). The wallet provider can now blackmail the user
> and force them to pay to get their funds back.
>
> Lightning normally fixes this by exchanging signatures for a commitment
> transaction that sends the funds back to their owners *before* signing
> the parent funding/splice transaction. But here that is impossible,
> because we don't know yet the `txid` of the batch transaction (that's
> the whole point, we want to be able to sign before creating the batch)
> so we don't know the new `prevout` we should spend from. I couldn't find
> a clever way to work around that, and I don't think there is one (but
> I would be happy to be wrong).
>
> With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
> anyprevout signatures for the commitment transaction, and they will be
> valid to spend from the batch transaction. We are safe from signature
> reuse, because funding keys are rotated at each splice so we will never
> create another output that uses the same 2-of-2 script.
>
> I haven't looked at other forms of covenants, but most of them likely
> address this problem as well.
>
> Cheers,
> Bastien
> ___
> Lightning-dev mailing list
> lightning-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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"

[Antoine Riard via bitcoin-dev]

> 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  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  a
> écrit :
>
>> ## Deployed LN mitigations
>>
>> Aggressive rebroadcasting: As the 

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"

[Antoine Riard via bitcoin-dev]

Hi Zeeman,

> At block height 100, `B` notices the `B->C` HTLC timelock is expired
without `C` having claimed it, so `B` forces the `BC` 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/19d61fa8cf22a5050b51c4005603f43d72f1efcf

> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
`A` drops the `AB` 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 `BC` 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  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 `BC` 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 `AB` 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 `AB` 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 `BC` 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 && 

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"

[Antoine Riard via bitcoin-dev]

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  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 

Re: [bitcoin-dev] BitVM: Compute Anything on Bitcoin

[Russell O'Connor via bitcoin-dev]

While I haven't looked at the BitVM in detail, I would like to mention that
Simplicity's core language (excluding introspection primitives) has the
same expressivity as Boolean circuits.

A few years ago I did some experiments to compile Simplicity expressions to
a system of polynomial constraints (R1CS).  The experiments were
successful. For instance, I was able to compile our Sha256 compression
function specification written in Simplicity to a set of approximately
128,000 constraints.  Under this "circuit" interpretation, Simplicity types
represent cables, which are a bundle of wires equal to the 'bit size' of
the given type. The 'case' combinator ends up being the only "active"
component (implementing a demux).  The 'injr' and 'injr' combinators output
some fixed Boolean values. The rest of the combinations end up only
connecting, bundling and unbundling wires, and contribute no constraints at
all.

While my previous experiment was generating constraints, it is clear to me
that a similar interpretation could instead generate logic gates, and I
would expect the same order of magnitude in the number of gates generated
as the number of constraints generated above.  Thus Simplicity could be
used as a source of ready made expressions to generate useful circuits for
the BitVM, should someone be interested in pursuing this angle.

On Mon, Oct 9, 2023 at 10:05 AM Robin Linus via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin
> contracts. This requires no changes to the network’s consensus rules.
> Rather than executing computations on Bitcoin, they are merely verified,
> similarly to optimistic rollups. A prover makes a claim that a given
> function evaluates for some particular inputs to some specific output. If
> that claim is false, then the verifier can perform a succinct fraud proof
> and punish the prover. Using this mechanism, any computable function can be
> verified on Bitcoin. Committing to a large program in a Taproot address
> requires significant amounts of off-chain computation and communication,
> however the resulting on-chain footprint is minimal. As long as both
> parties collaborate, they can perform arbitrarily complex, stateful
> off-chain computation, without leaving any trace in the chain. On-chain
> execution is required only in case of a dispute.
>
> https://bitvm.org/bitvm.pdf
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

[ZmnSCPxj via bitcoin-dev]

Good morning Greg,


> > I do not know if existing splice implementations actually perform such a 
> > check.
> Unless all splice implementations do this, then any kind of batched splicing 
> is risky.
> As long as the implementation decides to splice again at some point when a 
> prior
> splice isn't confirming, it will self-resolve once any subsequent splice is 
> confirmed.

Do note that there is a risk here that the reason for "not confirming" is 
because of an unexpected increase in mempool usage.

In particular, if the attack is not being performed, it is possible for the 
previous splice tx that was not confirming for a while, to be the one that 
confirms in the end, instead of the subsequent splice.
This is admittedly an edge case, but one that could potentially be specifically 
attacked and could lead to loss of funds if the implementations naively deleted 
the signatures for commitment transactions for the previously-not-confirming 
splice transaction.

Indeed, as I understood it, part of the splice proposal is that while a channel 
is being spliced, it should not be spliced again, which your proposal seems to 
violate.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

[Greg Sanders via bitcoin-dev]

> I do not know if existing splice implementations actually perform such a
check.
Unless all splice implementations do this, then any kind of batched
splicing is risky.

As long as the implementation decides to splice again at some point when a
prior
splice isn't confirming, it will self-resolve once any subsequent splice is
confirmed.

Cheers,
Greg

On Tue, Oct 17, 2023 at 1:04 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Bastien,
>
> I have not gotten around to posting it yet, but I have a write-up in my
> computer with the title:
>
> > Batched Splicing Considered Risky
>
> The core of the risk is that if:
>
> * I have no funds right now in a channel (e.g. the LSP allowed me to have
> 0 reserve, or this is a newly-singlefunded channel from the LSP to me).
> * I have an old state (e.g. for a newly-singlefunded channel, it could
> have been `update_fee`d, so that the initial transaction is old state).
>
> Then if I participate in a batched splice, I can disrupt the batched
> splice by broadcasting the old state and somehow convincing miners to
> confirm it before the batched splice.
>
> Thus, it is important for *any* batched splicing mechanism to have a
> backout, where if the batched splice transaction can no longer be confirmed
> due to some participant disrupting it by posting an old commitment
> transaction, either a subset of the splice is re-created or the channels
> revert back to pre-splice state (with knowledge that the post-splice state
> can no longer be confirmed).
>
> I know that current splicing tech is to run both the pre-splice and
> post-splice state simultaneously until the splicing transaction is
> confirmed.
> However we need to *also* check if the splicing transaction *cannot* be
> confirmed --- by checking if the other inputs to the splice transaction
> were already consumed by transactions that have deeply confirmed, and in
> that case, to drop the post-splice state and revert to the pre-splice state.
> I do not know if existing splice implementations actually perform such a
> check.
> Unless all splice implementations do this, then any kind of batched
> splicing is risky.
>
> Regards,
> ZmnSCPxj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

[ZmnSCPxj via bitcoin-dev]

Good morning Bastien,

I have not gotten around to posting it yet, but I have a write-up in my 
computer with the title:

> Batched Splicing Considered Risky

The core of the risk is that if:

* I have no funds right now in a channel (e.g. the LSP allowed me to have 0 
reserve, or this is a newly-singlefunded channel from the LSP to me).
* I have an old state (e.g. for a newly-singlefunded channel, it could have 
been `update_fee`d, so that the initial transaction is old state).

Then if I participate in a batched splice, I can disrupt the batched splice by 
broadcasting the old state and somehow convincing miners to confirm it before 
the batched splice.

Thus, it is important for *any* batched splicing mechanism to have a backout, 
where if the batched splice transaction can no longer be confirmed due to some 
participant disrupting it by posting an old commitment transaction, either a 
subset of the splice is re-created or the channels revert back to pre-splice 
state (with knowledge that the post-splice state can no longer be confirmed).

I know that current splicing tech is to run both the pre-splice and post-splice 
state simultaneously until the splicing transaction is confirmed.
However we need to *also* check if the splicing transaction *cannot* be 
confirmed --- by checking if the other inputs to the splice transaction were 
already consumed by transactions that have deeply confirmed, and in that case, 
to drop the post-splice state and revert to the pre-splice state.
I do not know if existing splice implementations actually perform such a check.
Unless all splice implementations do this, then any kind of batched splicing is 
risky.

Regards,
ZmnSCPxj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-core-dev] Bitcoin Core 24.2 release candidate 1 available

[Michael Ford via bitcoin-core-dev]

Binaries for Bitcoin Core version v24.2rc1 are available from:

https://bitcoincore.org/bin/bitcoin-core-24.2/test.rc1/

Source code can be found in git under the signed tag

https://github.com/bitcoin/bitcoin/tree/v24.2rc1

This is a release candidate for a new minor version release.

Preliminary release notes for the release can be found here:

https://raw.githubusercontent.com/bitcoin/bitcoin/24.x/doc/release-notes.md

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as v24.2.
___
bitcoin-core-dev mailing list
bitcoin-core-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev

[bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

[Bastien TEINTURIER via bitcoin-dev]

Good morning list,

I've been trying to design a protocol to let users withdraw funds from
exchanges directly into their lightning wallet in an efficient way
(with the smallest on-chain footprint possible).

I've come to the conclusion that this is only possible with some form of
covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The
goal of this post is to explain why, and add this usecase to the list of
useful things we could do if we had covenants (insert "wen APO?" meme).

The naive way of enabling lightning withdrawals is to make the user
provide a lightning invoice that the exchange pays over lightning. The
issue is that in most cases, this simply shifts the burden of making an
on-chain transaction to the user's wallet provider: if the user doesn't
have enough inbound liquidity (which is likely), a splice transaction
will be necessary. If N users withdraw funds from an exchange, we most
likely will end up with N separate splice transactions.

Hence the idea of batching those into a single transaction. Since we
don't want to introduce any intermediate transaction, we must be able
to create one transaction that splices multiple channels at once. The
issue is that for each of these channels, we need a signature from the
corresponding wallet user, because we're spending the current funding
output, which is a 2-of-2 multisig between the wallet user and the
wallet provider. So we run into the usual availability problem: we need
signatures from N users who may not be online at the same time, and if
one of those users never comes online or doesn't complete the protocol,
we must discard the whole batch.

There is a workaround though: each wallet user can provide a signature
using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
funding output to create a new funding output with the expected amount.
This lets users sign *before* knowing the final transaction, which the
exchange can create by batching pairs of inputs/outputs. But this has
a fatal issue: at that point the wallet user has no way of spending the
new funding output (since it is also a 2-of-2 between the wallet user
and the wallet provider). The wallet provider can now blackmail the user
and force them to pay to get their funds back.

Lightning normally fixes this by exchanging signatures for a commitment
transaction that sends the funds back to their owners *before* signing
the parent funding/splice transaction. But here that is impossible,
because we don't know yet the `txid` of the batch transaction (that's
the whole point, we want to be able to sign before creating the batch)
so we don't know the new `prevout` we should spend from. I couldn't find
a clever way to work around that, and I don't think there is one (but
I would be happy to be wrong).

With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
anyprevout signatures for the commitment transaction, and they will be
valid to spend from the batch transaction. We are safe from signature
reuse, because funding keys are rotated at each splice so we will never
create another output that uses the same 2-of-2 script.

I haven't looked at other forms of covenants, but most of them likely
address this problem as well.

Cheers,
Bastien
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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"

[ziggie1984 via bitcoin-dev]

> ## 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  
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 

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"

[ZmnSCPxj via bitcoin-dev]

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 `BC` 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 `AB` 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 `AB` 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 `BC` 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev