Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-18 📝 Original message: Hi Rene, Thanks for ...
📅 Original date posted:2020-06-18
📝 Original message:
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 congestion and yours to lockdown in-flight fees as
funds hostage situation.
> 1. The current solution is to just not use up the max value of
htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
As of today, yes I would recommend capping commitment size both for
ensuring competitive propagation/block selection and limiting HTLC exposure.
> 2. Probably the best fix (not sure if I understand the consequences
correctly) is coming from this PR to bitcoin core (c.f.
https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it
correctly with that we could always have low fees and ask the person who
want to claim their outputs to pay fees. This excludes overpayment and
could happen at a later stage when fees are not spiked. Still the victim
who offered the htlcs would have to spend those outputs at some time.
It's a bit more complex, carve-out output, even combined with anchor output
support on the LN-side won't protect against different flavors of pinning.
I invite you to go through logs of past 2 LN dev meetings.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
future anyway
Once 2. is well-addressed we may deprecate `update_fee`.
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
value (like we do with sub dust amounts and sub satoshi amounts. This would
at least make the attack expensive as the attacker would have to bind a lot
of liquidity.
Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC
economic value, feerate of its output, feerate of HTLC-transaction, feerate
estimation of any CPFP to bump it. I think that's kind of worthy to do once
we solved 3. and 4
> 5. Somehow be able to aggregate htlc's. In a world where we use payment
points instead of preimages we might be able to do so. It would be really
cool if separate HTLC's could be combined to 1 single output. I played
around a little bit but I have not come up with a scheme that is more
compact in all cases. Thus I just threw in the idea.
Yes we may encode all HTLC in some Taproot tree in the future. There are
some wrinkles but for a high-level theoretical construction see my post on
CoinPool.
> 6. Split onchain fees differently (now the attacker would also lose fees
by conducting this attack) - No I don't want to start yet another fee
bikeshadding debate. (In particular I believe that a different split of
fees might make the Flood & Loot attack economically more viable which
relies on the same principle)
Likely a bit more of fee bikeshedding is something we have to do to make LN
secure... Switching fee from pre-committed ones to a single-party, dynamic
one.
> Independently I think we should have a hint in our readme file about
where and how people can disclose attacks and vulnerabilities.
Implementations have this but the BOLTs do not.
I 100% agree, that's exactly
https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
your feedback :)
Cheers,
Antoine
Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
>
> Good morning all,
>
> >
> > Fee futures could help against this.
> > I remember writing about this some time ago but cannot find where (not
> sure if it was in lightning-dev or bitcoin-dev).
>
> `harding` found it:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200618/4505fed3/attachment.html>;
📝 Original message:
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 congestion and yours to lockdown in-flight fees as
funds hostage situation.
> 1. The current solution is to just not use up the max value of
htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
As of today, yes I would recommend capping commitment size both for
ensuring competitive propagation/block selection and limiting HTLC exposure.
> 2. Probably the best fix (not sure if I understand the consequences
correctly) is coming from this PR to bitcoin core (c.f.
https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it
correctly with that we could always have low fees and ask the person who
want to claim their outputs to pay fees. This excludes overpayment and
could happen at a later stage when fees are not spiked. Still the victim
who offered the htlcs would have to spend those outputs at some time.
It's a bit more complex, carve-out output, even combined with anchor output
support on the LN-side won't protect against different flavors of pinning.
I invite you to go through logs of past 2 LN dev meetings.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
future anyway
Once 2. is well-addressed we may deprecate `update_fee`.
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
value (like we do with sub dust amounts and sub satoshi amounts. This would
at least make the attack expensive as the attacker would have to bind a lot
of liquidity.
Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC
economic value, feerate of its output, feerate of HTLC-transaction, feerate
estimation of any CPFP to bump it. I think that's kind of worthy to do once
we solved 3. and 4
> 5. Somehow be able to aggregate htlc's. In a world where we use payment
points instead of preimages we might be able to do so. It would be really
cool if separate HTLC's could be combined to 1 single output. I played
around a little bit but I have not come up with a scheme that is more
compact in all cases. Thus I just threw in the idea.
Yes we may encode all HTLC in some Taproot tree in the future. There are
some wrinkles but for a high-level theoretical construction see my post on
CoinPool.
> 6. Split onchain fees differently (now the attacker would also lose fees
by conducting this attack) - No I don't want to start yet another fee
bikeshadding debate. (In particular I believe that a different split of
fees might make the Flood & Loot attack economically more viable which
relies on the same principle)
Likely a bit more of fee bikeshedding is something we have to do to make LN
secure... Switching fee from pre-committed ones to a single-party, dynamic
one.
> Independently I think we should have a hint in our readme file about
where and how people can disclose attacks and vulnerabilities.
Implementations have this but the BOLTs do not.
I 100% agree, that's exactly
https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for
your feedback :)
Cheers,
Antoine
Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
>
> Good morning all,
>
> >
> > Fee futures could help against this.
> > I remember writing about this some time ago but cannot find where (not
> sure if it was in lightning-dev or bitcoin-dev).
>
> `harding` found it:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200618/4505fed3/attachment.html>;