Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-21 📝 Original message: Hi ZmnSCPxj, My ...
📅 Original date posted:2020-06-21
📝 Original message:
Hi ZmnSCPxj,
My understanding is that you can use the CTV deferral to also get
independent HTLC relative timelocks start points per output. This would
help with this sort of issue right?
And you're correct that there's overhead of indirection, but it's not super
large (minimally complicated something like an extra 100 bytes per output,
if you were to have a flat array where each entry is a CTV output so that
each out gets its own clock).
Essentially something like this:
Chan
|
---------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(D) (Optional CPFP Anchor?)
| | | |
1 block 1 block 1 block 1 block
| | | |
A B C D
Where A B C and D are all HTLCs.
Now because of the one-hop indirection, A B C and D can all expand
independently. It's also possible for the Channel Operator to do something
like:
Chan
|
---------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(D) (Optional CPFP Anchor?)
| | | |
1 block 1 block 1 block 10 blocks
| | | |
A B C D
To make D have a further out resolution time to prevent the
simultaneous-ness issue (trees or a linear-chain rather than total fan-out
can also be used but I think it's a bit more confusing for a basic
example). The benefit of trees is that I can do something like:
Chan
|
--------------------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(400 HTLC) (Optional CPFP Anchor?)
| | | | |
1 block 1 block 1 block 10 blocks (Optional CPFP Anchor?)
| | | |
| | | / ....\
A B C | ..... |
Which makes it so that the low-value new HTLCs can be deprioritized fee
wise. So that the attack, which occurs during a fee spike, doesn't end up
*requiring* substantial fees to be added to the channel to support a burst
of HTLCS.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Sat, Jun 20, 2020 at 8:34 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Jeremy,
>
> > 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.
>
> If the attacker stops responding, then all HTLC rules need to be published
> onchain for enforcement of the HTLC rules.
> And that publication onchain is the problem: every HTLC published requires
> onchain space, which must be paid for.
>
> The most compact way to expose the HTLCs is as a flat array, i.e. outputs
> of a single transaction.
> Every tree structure is going to take up more space than a flat array.
>
> What CTV buys is to be able to defer *when* you reveal scripts, possibly
> to a later time when blockchain space is cheaper.
> But in case the victim owns the timelock branch of an outgoing HTLC, it is
> unsafe for the victim to defer: it has to enforce the locktime soon or it
> could end up losing both incoming and outgoing HTLC amounts.
> And to enforce the locktime it has to publish the HTLC.
>
> Now of course with CTV you could publish only the HTLC you have to enforce
> *now*, and keep the rest in an CTV output.
> The attacker can counter this by pushing 483 HTLCs with the same timelock
> at the victim, so that the victim has to publish all HTLCs simultaneously.
> And a flat array of outputs is cheaper than a tree.
>
> What *can* be done would be to bin by timelock rather than amount; tree
> leaves are a transaction that exposes all HTLCs with a particular timelock
> as a flat array of outputs, but different timelocks go to different tree
> branches.
> But the attacker can still do the same-timelock trick, and the tree
> structure is likely to take up more space in the end than just a non-treed
> flat array of outputs.
>
> Regards,
> ZmnSCPxj
>
>
> > --
> > @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/20200621/8e0db1ae/attachment-0001.html>;
📝 Original message:
Hi ZmnSCPxj,
My understanding is that you can use the CTV deferral to also get
independent HTLC relative timelocks start points per output. This would
help with this sort of issue right?
And you're correct that there's overhead of indirection, but it's not super
large (minimally complicated something like an extra 100 bytes per output,
if you were to have a flat array where each entry is a CTV output so that
each out gets its own clock).
Essentially something like this:
Chan
|
---------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(D) (Optional CPFP Anchor?)
| | | |
1 block 1 block 1 block 1 block
| | | |
A B C D
Where A B C and D are all HTLCs.
Now because of the one-hop indirection, A B C and D can all expand
independently. It's also possible for the Channel Operator to do something
like:
Chan
|
---------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(D) (Optional CPFP Anchor?)
| | | |
1 block 1 block 1 block 10 blocks
| | | |
A B C D
To make D have a further out resolution time to prevent the
simultaneous-ness issue (trees or a linear-chain rather than total fan-out
can also be used but I think it's a bit more confusing for a basic
example). The benefit of trees is that I can do something like:
Chan
|
--------------------------------------------------------
| | | | |
CTV(A) CTV(B) CTV(C) CTV(400 HTLC) (Optional CPFP Anchor?)
| | | | |
1 block 1 block 1 block 10 blocks (Optional CPFP Anchor?)
| | | |
| | | / ....\
A B C | ..... |
Which makes it so that the low-value new HTLCs can be deprioritized fee
wise. So that the attack, which occurs during a fee spike, doesn't end up
*requiring* substantial fees to be added to the channel to support a burst
of HTLCS.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Sat, Jun 20, 2020 at 8:34 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Jeremy,
>
> > 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.
>
> If the attacker stops responding, then all HTLC rules need to be published
> onchain for enforcement of the HTLC rules.
> And that publication onchain is the problem: every HTLC published requires
> onchain space, which must be paid for.
>
> The most compact way to expose the HTLCs is as a flat array, i.e. outputs
> of a single transaction.
> Every tree structure is going to take up more space than a flat array.
>
> What CTV buys is to be able to defer *when* you reveal scripts, possibly
> to a later time when blockchain space is cheaper.
> But in case the victim owns the timelock branch of an outgoing HTLC, it is
> unsafe for the victim to defer: it has to enforce the locktime soon or it
> could end up losing both incoming and outgoing HTLC amounts.
> And to enforce the locktime it has to publish the HTLC.
>
> Now of course with CTV you could publish only the HTLC you have to enforce
> *now*, and keep the rest in an CTV output.
> The attacker can counter this by pushing 483 HTLCs with the same timelock
> at the victim, so that the victim has to publish all HTLCs simultaneously.
> And a flat array of outputs is cheaper than a tree.
>
> What *can* be done would be to bin by timelock rather than amount; tree
> leaves are a transaction that exposes all HTLCs with a particular timelock
> as a flat array of outputs, but different timelocks go to different tree
> branches.
> But the attacker can still do the same-timelock trick, and the tree
> structure is likely to take up more space in the end than just a non-treed
> flat array of outputs.
>
> Regards,
> ZmnSCPxj
>
>
> > --
> > @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/20200621/8e0db1ae/attachment-0001.html>;