Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Antoine Riard
I've been informed by Mitre, the correct CVE assignment: * c-lightning : CVE-2021-41592 * lnd: CVE-2021-41593 Not the assignement disclosed in the initial mail. Le lun. 4 oct. 2021 à 11:09, Antoine Riard a écrit : > Hi, > > I'm writing a report to disclose specification-level vulner

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Antoine Riard
13.3+ (CVE-2021-41592) > > * LDK: v0.0.102 (not released as production software yet) > > * C-lightning v0.10.2 (CVE-2021-41593) > > > Lisa > > On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard > wrote: > >> Hi, >> >> I'm writing a repo

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Antoine Riard
ink we're already making that kind of social or economic assumption on the user behavior w.r.t to full-node design. Blocks and transactions are relayed for "free" today, not satoshis are received in exchange. Le lun. 4 oct. 2021 à 12:28, Luke Dashjr a écrit : > On Monday 04 October 2021

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Antoine Riard
sadly that's going to increase with Lightning growth and deployment of other L2s. Maybe we could dry-up some policy rules in consensus like the dust limit one :) Le lun. 4 oct. 2021 à 11:57, Luke Dashjr a écrit : > On Monday 04 October 2021 15:09:28 Antoine Riard wrote: > > St

[Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread Antoine Riard
Hi, I'm writing a report to disclose specification-level vulnerabilities affecting the Lightning implementations. The vulnerabilities are expected to be patched in: * Eclair: v0.6.2+ (CVE-2021-41591) * LND: v0.13.3+ (CVE-2021-41592) * LDK: v0.0.102 (not released as production software yet) The

Re: [Lightning-dev] Removing the Dust Limit

2021-08-10 Thread Antoine Riard
m/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2=1#slide=id.g85f425098 Thanks to bringing to the surface probabilistic payments, yes that's a worthy alternative approach for low-value payments to keep in mind. Le mar. 10 août 2021 à 02:15, David A. Harding a écrit : > On Mon, Aug 09, 2021 at 09:22:

Re: [Lightning-dev] Removing the Dust Limit

2021-08-09 Thread Antoine Riard
I'm pretty conservative about increasing the standard dust limit in any way. This would convert a higher percentage of LN channels capacity into dust, which is coming with a lowering of funds safety [0]. Of course, we can adjust the LN security model around dust handling to mitigate the safety

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-07-02 Thread Antoine Riard
Hi Ryan, Thanks for starting this discussion, I agree it's a good time for the Lightning development community to start this self-introspection on its own specification process :) First and foremost, maybe we could take a minute off to celebrate the success of the BOLT process and the road

Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-24 Thread Antoine Riard
nds full with their own > implementations. > > I think we can get the balance right by making progress on this > (important) discussion whilst also maintaining humility that we don't > know exact timelines and that getting things merged into Core relies > on a number of people who

[Lightning-dev] On the recent softforks survey, forget to fulfill my answer!

2021-06-21 Thread Antoine Riard
Hi, I was super glad to see the recent survey on potential softforks for the near-future of Bitcoin! I didn't have time to answer this one but will do so for the future. I wanna to salute the grassroots involvement in bitcoin protocol development, that's cool to see :) Though softforks are what

Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-21 Thread Antoine Riard
ub.com/bitcoin/bitcoin/issues/14895 [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html Le sam. 19 juin 2021 à 09:38, David A. Harding a écrit : > On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote: > > 2) Solving the Pre-Signed Feerate problem

Re: [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-18 Thread Antoine Riard
> That's a question I hope we'll gather feedback during next Thursday's transaction relay workshops. As someone kindly pointed out to me, workshop is happening Tuesday, June 22th. Not Thursday, mistake of mine :/ Le ven. 18 juin 2021 à 18:11, Antoine Riard a écrit : > Hi, > >

[Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

2021-06-18 Thread Antoine Riard
Hi, It's a big chunk, so if you don't have time browse parts 1 and 2 and share your 2 sats on the deployment timeline :p This post recalls some unsolved safety holes about Lightning, how package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool hardening can solve the second

[Lightning-dev] Reminder: Transaction relay workshop on IRC Libera - Tuesday 15th June 19:00 UTC

2021-06-14 Thread Antoine Riard
Hi, A short reminder about the 1st transaction relay workshop happening tomorrow on #l2-onchain-support Libera chat (!), Tuesday 15th June, from 19:00 UTC to 20:30 UTC Scheduled topics are: * "Guidelines about L2 protocols onchain security design" * "Coordinated cross-layers security

[Lightning-dev] On Mempool Funny Games against Multi-Party Funded Transactions

2021-05-06 Thread Antoine Riard
Hi, In this post I would like to highlight some DoS attacks against multi-party Bitcoin protocols during their funding phases. Recent discussions around DLC funding flow [0] and dual-funding of LN channel [1] remind me that some timevalue DoS/fee inflation issues are common to any multi-party

Re: [Lightning-dev] L2s Onchain Support IRC Workshop

2021-04-23 Thread Antoine Riard
0 block lock > on spending a sponsoring tx which would hopefully make less controversial, > this would be a great place to discuss those tradeoffs. > > On Fri, Apr 23, 2021, 8:17 AM Antoine Riard > wrote: > >> Hi, >> >> During the lastest years, tx-relay and mempool

[Lightning-dev] L2s Onchain Support IRC Workshop

2021-04-23 Thread Antoine Riard
Hi, During the lastest years, tx-relay and mempool acceptances rules of the base layer have been sources of major security and operational concerns for Lightning and other Bitcoin second-layers [0]. I think those areas require significant improvements to ease design and deployment of higher

Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)

2021-02-15 Thread Antoine Riard
a first attempt at projecting this idea onto the existing spec: > https://github.com/lightningnetwork/lightning-rfc/pull/843. This may also > clarify some of the questions that haven't been answered yet. > > Joost > > On Fri, Feb 12, 2021 at 2:29 PM Antoine Riard > wro

Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)

2021-02-12 Thread Antoine Riard
Hi Joost, Thanks for working on this and keeping raising awareness about channel jamming. > In this post I'd like to present a variation of bidirectional upfront payments that uses a time-proportional hold fee rate to address the limitation above. I also tried to come up with a system that aims

[Lightning-dev] Full Disclosure: CVE-2020-26895 LND "Hodl my Shitsig"

2020-10-20 Thread Antoine Riard
# Problem A lightning node must verify that its channel transactions are not only consensus-valid but also tx-relay standard. The counterparty signatures are part of the local txn (commitment/HTLC) as provided in the `commitment_signed`. Verifying consensus-validity of these signatures but not

[Lightning-dev] Full Disclosure: CVE-2020-26895 LND "Hodl my Shitsig"

2020-10-20 Thread Antoine Riard
# Problem A lightning node must verify that its channel transactions are not only consensus-valid but also tx-relay standard. The counterparty signatures are part of the local txn (commitment/HTLC) as provided in the `commitment_signed`. Verifying consensus-validity of these signatures but not

[Lightning-dev] Full Disclosure: CVE-2020-26896 LND "The (un)covert channel"

2020-10-20 Thread Antoine Riard
# Problem In case of a relayed HTLC hash-and-amount collision with an expected payment HTLC on the same channel, LND was releasing the preimage for the later while claiming onchain the former. A malicious peer could have deliberately intercepted a HTLC intended for the victim node, probe the

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

2020-10-15 Thread Antoine Riard
Hi Joost, Thanks for your proposal, please find my following opinion which is deliberately on a high-level as IMO defining better threats model and agreeing on expected network dynamics resulting from any solution trade-offs sounds required before to work on any solution. > We've looked at all

Re: [Lightning-dev] Incremental Routing (Was: Making (some) channel limits dynamic)

2020-10-08 Thread Antoine Riard
Hi Zeeman, > * It requires a lot more communication rounds and (symmetric, at least) cryptographic operations. At first sight, it sounds similar to HORNET/rendez-vous, at least in the goal of achieving bidirectional communications. * Intermediate nodes can guess the distance from the source by

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-08 Thread Antoine Riard
> There is no need to stop the channel's operations while you're updating these parameters, since they can be updated unilaterally anyway I think it's just how you defne channel's operations, either emptying out all pending HTLCs or more a `update_fee` alike semantic. You're right that the latter

Re: [Lightning-dev] Why should funders always pay on-chain fees?

2020-10-06 Thread Antoine Riard
Hello Bastien, I'm all in for a model where channel transactions are pre-signed with a reasonable minimal relay fee and the adjustment is done by the closer. The channel initiator shouldn't have to pay for channel-closing as it's somehow a liquidity allocation decision ("My balance could be

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-06 Thread Antoine Riard
Hello Bastien, As a first note , I was thinking dynamic policy adjustment would be covered by the dynamic commitment mechanism proposed by Laolu as it presents the same trade-offs, you need to stop channel HTLC processing before upgrading, otherwise it might falsify your whole in-flight HTLC

Re: [Lightning-dev] SIGHASH_SINGLE + update_fee Considered Harmful

2020-09-13 Thread Antoine Riard
h can potentially cascade. > > > > In lnd today, anchors is still behind a build flag, but we plan to enable > > it by default for our upcoming 0.12 release. The blockers on our end > were to > > add support for towers, and add basic deadline aware bumping, both of >

Re: [Lightning-dev] SIGHASH_SINGLE + update_fee Considered Harmful

2020-09-13 Thread Antoine Riard
ll now also look into setting clamps on the > receiver end to just not accept unreasonable values for the fee rate of a > commitment, as this ends up eating into the true HTLC values for both > sides. > > -- Laolu > > > On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard > w

[Lightning-dev] SIGHASH_SINGLE + update_fee Considered Harmful

2020-09-10 Thread Antoine Riard
Hi, In this post, I would like to expose a potential vulnerability introduced by the recent anchor output spec update related to the new usage of SIGHASH_SINGLE for HTLC transactions. This new malleability combined with the currently deployed mechanism of `update_fee` is likely harmful for funds

Re: [Lightning-dev] Proposal for skip channel confirmation.

2020-08-25 Thread Antoine Riard
Hi Zeeman, > i.e. I send my high-fee RBF-enabled channel funding to you, at the same time I send a conflicting low-fee RBF-disabled transaction (that pays the entire channel amount to myself) to all the miners I can find. Mapping miners mempools will be a cost in spying infrastructure and thus

Re: [Lightning-dev] Proposal for skip channel confirmation.

2020-08-24 Thread Antoine Riard
Hi Roei, You might have a mechanism to lower trust in zero-conf channel opener. Actually the local party can be in charge of broadcasting the funding transaction, thus ensuring it's well-propagated across network mempools and then start to accept incoming payment on the zero-conf channel. Per BIP

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Antoine Riard
Hi Laolu, I think that's a must before we introduce a bunch of new features and the number of channels explodes. The de-synchronized side could be underscored more as any scheduled, automatic, massive upgrade for security forcing chain writes can be exploited to launch mempool-congestion

[Lightning-dev] Pinning : The Good, The Bad, The Ugly

2020-06-28 Thread Antoine Riard
(tl;dr Ideally network mempools should be an efficient marketplace leading to discovery of best-feerate blockspace demand by miners. It's not due to current anti-DoS rules assumptions and it's quite harmful for shared-utxo protocols like LN) Hello all, Lightning security model relies on the

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

2020-06-18 Thread Antoine Riard
Hi Rene, Thanks for disclosing this vulnerability, I think this blackmail scenario holds but sadly there is a lower scenario. Both "Flood & Loot" and your blackmail attack rely on `update_fee` mechanism and unbounded commitment transaction size inflation. Though the first to provoke block

Re: [Lightning-dev] Miners Dust Inflation attacks on Lightning Network

2020-05-19 Thread Antoine Riard
Hi ZmnSCPxj, As of today, you can setup a `htlc_minimum_msat` higher than remote's `dust_limit_satoshis`, but you don't necessarily know it before announcing your channel parameters if you're initiator. In practice, assuming you can do so, with fees going higher and HTLC outputs being encumbered,

[Lightning-dev] Miners Dust Inflation attacks on Lightning Network

2020-05-18 Thread Antoine Riard
Lightning protocol supports a floating dust output selection at channel creation, where each party declares a dust parameter applying to its local transactions. The current spec doesn't enforce or recommend any bound on this value, beyond the requirement of being lower that

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-16 Thread Antoine Riard
> * At the same time, it retains your-keys-your-coins noncustodiality, because every update of a Lightning channel requires your keys to sign off on it. Yes I agree, I can foresee an easier step where managing low-value channel and get your familiar with smooth key management maybe a first step

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-13 Thread Antoine Riard
dev wrote: > > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < > > bitcoin-...@lists.linuxfoundation.org> wrote: > > > >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > >>> Trust-minimization of Bitcoin security

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-09 Thread Antoine Riard
Hi Christopher, Thanks for Blockchain Commons and Learning Bitcoin from the Command Line! > If there are people interested in coordinating some proposals on how to defining different sets of wallet functionality, Blockchain Commons would be interested in hosting that collaboration. This could

Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-09 Thread Antoine Riard
Africans and > Europeans serving the Asians in kind. By plugging in our phones and going > to sleep we could blanket the whole world in (somewhat) full nodes! > > Cheers, > Igor > > [1] https://icota.github.io/ > > On Tue, 5 May 2020 at 12:18, Antoine Riard > wrot

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard
out miners. > > Keagan > > On Wed, May 6, 2020 at 3:06 AM Antoine Riard > wrote: > >> I do see the consensus capture argument by miners but in reality isn't >> this attack scenario have a lot of assumptions on topology an deployment ? >> >> For such attack

Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard
ess to a single header/filter, a range of them in the past, or N headers > past the known chain tip, etc, etc. > > -- Laolu > > [1]: https://lsat.tech/ > [2]: https://lightning.engineering/posts/2020-03-30-lsat/ > > > On Tue, May 5, 2020 at 3:17 AM Antoine Riard > wrote: > >

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard
> The choice between whether we offer them a light client technology that is better or worse for privacy and scalability. And offer them a solution which would scale in the long-term. Again it's not an argumentation against BIP 157 protocol in itself, the problem I'm interested in is how

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard
foster node adoption as much as we can. Le mar. 5 mai 2020 à 09:01, Luke Dashjr a écrit : > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > Trust-minimization of Bitcoin security model has always relied first and > > above on running a full-node. This curre

Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-06 Thread Antoine Riard
I didn't trust myself and verify. In fact the [3] is the real [2]. Le mar. 5 mai 2020 à 06:28, Andrés G. Aragoneses a écrit : > Hey Antoine, just a small note, [3] is missing in your footnotes, can you > add it? Thanks > > On Tue, 5 May 2020 at 18:17, Antoine Riard >

[Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Antoine Riard
Hi, (cross-posting as it's really both layers concerned) Ongoing advancement of BIP 157 implementation in Core maybe the opportunity to reflect on the future of light client protocols and use this knowledge to make better-informed decisions about what kind of infrastructure is needed to support

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Antoine Riard
Personally, I would have wait a bit before to go public on this, like letting some implementations increasing their CLTV deltas, but anyway, it's here now. Mempool-pinning attacks were already discussed on this list [0], but what we found is you can _reverse_ the scenario, where it's not the

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-30 Thread Antoine Riard
Darosior ( i'll stick with my pseudo, first names definitely don't have > enough entropy :-) ) > Original Message ---- > On Jan 30, 2020, 19:09, Antoine Riard < antoine.ri...@gmail.com> wrote: > > > Hey Darosior, > > You don't need a strict synchronization bet

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-30 Thread Antoine Riard
ei) > > > Antoine > > > ---- Original Message > On Jan 30, 2020, 01:21, Antoine Riard < antoine.ri...@gmail.com> wrote: > > > Hey thanks for this proposal! > > 2 high-level questions: > > What about multi-party tx constructi

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-29 Thread Antoine Riard
Hi Max, Sorry by transaction format I didn't mean a binary transaction format, but format like we use in BOLT3 : https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md My concern is, e.g LN implementations setting nLocktime to 0x, Coinjoin wallets always

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-29 Thread Antoine Riard
Hey thanks for this proposal! 2 high-level questions: What about multi-party tx construction ? By multi-party, let's define Alice initiate a tx construction to Bob and then Bob announce a construction to Caroll and "bridge" all inputs/outputs additions/substractions in both directions. I think

Re: [Lightning-dev] Speculations on hardware wallet support for Lightning

2020-01-16 Thread Antoine Riard
Hey Zeeman, tl;dr A LN node paired with an external signer can be distrusted and LN funds be safe in any case if signer is connected to a N-set of watchtowers and at least one of them is non-compromised. Thanks for this interesting post, I was thinking about LN hardware wallets support for a

Re: [Lightning-dev] Pay-to-Open and UX improvements

2019-12-17 Thread Antoine Riard
Hi Bastien, The use case you're describing strikes me as similar to a slashing protocol for a LN node and a watchtower, i.e punishing a lazy watchtower for not broadcasting a penalty tx on remote revoked state. In both case you want "if A don't do X unlock some funds for B". Here a rough

Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols

2019-12-16 Thread Antoine Riard
do a fallback is > nontrivial, especially if you are concerned with user privacy. > > Matt > > On 12/16/19 9:10 AM, David A. Harding wrote: > > On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote: > >> If well executed, attacks described stay stealth un

Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols

2019-12-15 Thread Antoine Riard
54:19 CET, "David A. Harding" > wrote: >> >> On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote: >> >>> Time-Dilation Attacks on Offchain Protocols >>> -- >>> >> >> What is the advantag

[Lightning-dev] Time-Dilation Attacks on Offchain Protocols

2019-12-09 Thread Antoine Riard
Time-Dilation Attacks on Offchain Protocols === Lightning works on reversing the double-spend problem to a private state between parties instead of being a public issue verified by every network peer. The security model is based on revocation of previous states and

Re: [Lightning-dev] [DRAFT] BOLT 13(?): WatchTower protocol

2019-11-28 Thread Antoine Riard
Thanks for working on this, a bunch of interesting ideas! I think it could be noted in the motivation, that's having an interoperable watchtower protocol is really cool, because every watchtower you add is a liveness reliability increase (modulo privacy loss), specially if these watchtowers are

Re: [Lightning-dev] Rendez-vous on a Trampoline

2019-10-27 Thread Antoine Riard
Hi, Design reason of trampoline routing was to avoid lite nodes having to store the whole network graph and compute long-hop route. Trick lays in getting away from source-base routing, which has the nice property to hide hop position along the payment route (if we forget payment hash

Re: [Lightning-dev] eltoo implementation in Bitcoin functional test framework

2019-09-04 Thread Antoine Riard
Hello all, Didn't listen to Pieter Wuille interview, so don't know how he was thinking to use miniscript for lightning. But currently in lightning all our scripts are templates, a use of a miniscript compiler would be to find optimized bitcoin scripts for a given policy which model the channel

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-16 Thread Antoine Riard
Hi ZmnSCPxj, Awesome resume, it's better lay-out than I did myself !! > Thus, I would like to thank you for your tolerance and continued attention. Personally, it's a pleasure to read your weird but always thoughtful proposals in other threads :) "We have identified two requirements: 1. We

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-16 Thread Antoine Riard
Hi ZmnSCPxj, > Just a minor correction here: your own commitment transactions are not > being signed until we want to release them. Therefore having access to > your DB doesn't give an attacker the ability to frame the user with an > old version, since that'd still require access to the keys to

[Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-12 Thread Antoine Riard
Hi all, Eltoo has been criticized to lower the cost for a malicious party to test your monitoring of the chain. If we're able to reintroduce some form of punishment without breaking transaction symmetry that would be great. Transaction symmetry implies that we can't deduce from observing txid