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"
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 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
Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
Hey Z-man, Antoine, Thank you for your feedback, responses inline. z-man: > 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. Correct, I didn't mention it in my post but batched splices cannot use 0-conf, the transaction must be confirmed to remove the risk of double spends using commit txs associated with the previous funding tx. But interestingly, with the protocol I drafted, the LSP can finalize and broadcast the batched splice transaction while users are offline. With a bit of luck, when the users reconnect, that transaction will already be confirmed so it will "feel 0-conf". Also, we need a mechanism like the one you describe when we detect that a splice transaction has been double-spent. But this isn't specific to batched transactions, 2-party splice transactions can also be double spent by either participant. So we need that mechanism anyway? The spec doesn't have a way of aborting a splice after exchanging signatures, but you can always do it as an RBF operation (which actually just does a completely different splice). This is what Greg mentioned in his answer. > 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. The spec doesn't require that, I'm not sure what made you think that. While a channel is being spliced, it can definitely be spliced again as an RBF attempt (this is actually a very important feature), which double spends the other unconfirmed splice attempts. ariard: > 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. I'm not entirely sure why you're bringing this up in this context... I agree that we most likely cannot use RBF on those batched transactions we will need to rely on CPFP and potentially package relay. But why is it different from non-multi-party transactions here? > See test here: > https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf I'd argue that this is quite different from the standard replacement cycling attack, because in this protocol wallet users can only unilaterally double-spend with a commit tx, on which they cannot set the feerate. The only participant that can "easily" double-spend is the exchange, and they wouldn't have an incentive to here, users are only withdrawing funds, there's no opportunity of stealing funds? Thanks, Bastien Le mar. 17 oct. 2023 à 21:10, Antoine Riard a écrit : > 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
Re: [bitcoin-dev] [Lightning-dev] Batch exchange withdrawal to lightning requires covenants
Hi Bastien,
Thanks for the answer.
If I understand correctly the protocol you're describing you're aiming to
enable batched withdrawals where a list of users are being sent funds from
an exchange directly in a list of channel funding outputs ("splice-out").
Those channels funding outputs are 2-of-2, between two lambda users or e.g
a lambda user and a LSP.
If I'm correct, two users can cooperate maliciously against the batch
withdrawal transactions by re-signing a CPFP from 2-of-2 and broadcasting
the batch withdrawal as a higher-feerate package / high fee package and
then evicting out the CPFP.
If the batch withdrawal has been signed with 0-fee thanks to the nversion=3
policy exemption, it will be evicted out of the mempool. A variant of a
replacement cycling attack.
I think this more or less matches the test I'm pointing to you which is on
non-deployed package acceptance code:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
Please correct me if I'm wrong or missing assumptions. Agree with you on
the assumptions that the exchange does not have an incentive to
double-spend its own withdrawal transactions, or if all the batched funding
outputs are shared with a LSP, malicious collusion is less plausible.
Best,
Antoine
Le mer. 18 oct. 2023 à 15:35, Bastien TEINTURIER a
écrit :
> Hey Z-man, Antoine,
>
> Thank you for your feedback, responses inline.
>
> z-man:
>
> > 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.
>
> Correct, I didn't mention it in my post but batched splices cannot use
> 0-conf, the transaction must be confirmed to remove the risk of double
> spends using commit txs associated with the previous funding tx.
>
> But interestingly, with the protocol I drafted, the LSP can finalize and
> broadcast the batched splice transaction while users are offline. With a
> bit of luck, when the users reconnect, that transaction will already be
> confirmed so it will "feel 0-conf".
>
> Also, we need a mechanism like the one you describe when we detect that
> a splice transaction has been double-spent. But this isn't specific to
> batched transactions, 2-party splice transactions can also be double
> spent by either participant. So we need that mechanism anyway? The spec
> doesn't have a way of aborting a splice after exchanging signatures, but
> you can always do it as an RBF operation (which actually just does a
> completely different splice). This is what Greg mentioned in his answer.
>
> > 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.
>
> The spec doesn't require that, I'm not sure what made you think that.
> While a channel is being spliced, it can definitely be spliced again as
> an RBF attempt (this is actually a very important feature), which double
> spends the other unconfirmed splice attempts.
>
> ariard:
>
> > 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.
>
> I'm not entirely sure why you're bringing this up in this context...
> I agree that we most likely cannot use RBF on those batched transactions
> we will need to rely on CPFP and potentially package relay. But why is
> it different from non-multi-party transactions here?
>
> > See test here:
> >
> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
>
> I'd argue that this is quite different from the standard replacement
> cycling attack, because in this protocol wallet users can only
> unilaterally double-spend with a commit tx, on which they cannot set
> the feerate. The only participant that can "easily" double-spend is
> the exchange, and they wouldn't have an incentive to here, users are
> only withdrawing funds, there's no opportunity of stealing funds?
>
> Thanks,
> Bastien
>
> Le mar. 17 oct. 2023 à 21:10, Antoine Riard a
> écrit :
>
>> 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/19d61fa8cf22a
[bitcoin-dev] Taproot Assets on Mainnet: Announcing tapd v0.3.0-alpha
I'm excited to announce tapd v0.3.0-alpha, the first software release that supports the Taproot Asset Protocol on mainnet! The deterministic+reproducible release can be found here: https://github.com/lightninglabs/taproot-assets/releases/tag/v0.3.0 Our launch blog post can be found here: https://lightning.engineering/posts/2023-10-18-taproot-assets-v0.3/ For those interested in keeping tabs on usage/activity of the protocol, we're running two Universes servers: * mainnet: https://universe.lightning.finance/v1/taproot-assets/universe/roots * testnet: https://testnet.universe.lightning.finance/v1/taproot-assets/universe/roots REST API documentation for the Universe servers can be found here: https://lightning.engineering/api-docs/api/taproot-assets/rest-endpoints. Users can also interact directly via gRPC as well. Users can run their own Universe server, and also federate with other universe servers using the relevant as of command (`tapcli universe federation`). A technical specification for the Universe/Multiverse protocol can be found here in the BIP: https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-universe.mediawiki. At a high level, a Universe server is used by clients to verify new asset issuance, archive off-chain transaction data, and transmit proof information for transfers. A Universe data structure is an authenticated merkle-sum sparse merkle tree that maps an `(outpoint, scriptKey)` tuple to proof data. A `scriptKey` is the protocol's version of the pkScript/scriptPubkey we all know and love today. In the initial version of the protocol, the `scriptKey` is actually just a normal taproot output public key. Ultimately, Bitcoin transactions are signed+verified under the hood, as we map a logical state transition to a 1-in-1-out Bitcoin transaction. The mapping from an asset state transition to a "virtual" transaction can be found here: https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-vm.mediawiki. One cool thing about reusing Bitcoin Script in the first asset script version is that higher level applications can use a familiar PSBT like structure (vPSBTs) to construct off-chain multi-party interactions. Here's an example of using PSTBs, vPSBTs, and `SIGHASH_NONE` (on the TAP layer) to construct a protocol for non-interactive, non-custodial swaps: https://github.com/lightninglabs/taproot-assets/issues/577. We look forward to experimentation and feedback for this mainnet alpha release to continue to evolve and improve the protocol! Thanks to all those that experimented with earlier versions, providing the critical feedback that made this release possible. Onwards! -- Laolu ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot Assets on Mainnet: Announcing tapd v0.3.0-alpha
On Wed, Oct 18, 2023 at 01:20:03PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote: > A technical specification for the Universe/Multiverse protocol can be found > here in the BIP: > https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-universe.mediawiki. > > At a high level, a Universe server is used by clients to verify new asset > issuance, archive off-chain transaction data, and transmit proof information > for transfers. A Universe data structure is an authenticated merkle-sum > sparse merkle tree that maps an `(outpoint, scriptKey)` tuple to proof data. > A `scriptKey` is the protocol's version of the pkScript/scriptPubkey we all > know and love today. Looks like you're missing a citation to my scalable asset transfer work from 2017: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer The key concepts in universes is very similar. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
