Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-20 📝 Original message: I am not steeped enough ...
📅 Original date posted:2020-06-20
📝 Original message:
I am not steeped enough in Lightning Protocol issues to get the full design
space, but I'm fairly certain BIP-119 Congestion Control trees would help
with this issue.
You can bucket a tree by doing a histogram of HTLC size, so that all small
HTLCs live in a common CTV subtree and don't interfere with higher value
HTLCs. You can also play with sequencing to prevent those HTLCs from
getting longchains in the mempool until they're above a certain value.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> 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
>>
> _______________________________________________
> 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/20200620/3c0b6b52/attachment.html>;
📝 Original message:
I am not steeped enough in Lightning Protocol issues to get the full design
space, but I'm fairly certain BIP-119 Congestion Control trees would help
with this issue.
You can bucket a tree by doing a histogram of HTLC size, so that all small
HTLCs live in a common CTV subtree and don't interfere with higher value
HTLCs. You can also play with sequencing to prevent those HTLCs from
getting longchains in the mempool until they're above a certain value.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> 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
>>
> _______________________________________________
> 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/20200620/3c0b6b52/attachment.html>;