Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-15 📝 Original message: Hi Joost, Thanks for your ...
📅 Original date posted:2020-10-15
📝 Original message:
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 kinds of trustless payment schemes to keep users
> honest, but it appears that none of them is satisfactory. Maybe it is
even
> theoretically impossible to create a scheme that is trustless and has all
> the properties that we're looking for. (A proof of that would also be
> useful information to have.)
I don't think anyone has drawn yet a formal proof of this, but roughly a
routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
to answer the following question "Is this payment coming from Alice and
going to Caroll will compensate for my resources consumption ?". With the
current LN system, the compensation is conditional on payment settlement
success and both Alice and Caroll are distrusted yet discretionary on
failure/success. Thus the underscored question is undecidable for a routing
peer making relay decisions only on packet observation.
One way to mitigate this, is to introduce statistical observation of
sender/receiver, namely a reputation system. It can be achieved through a
scoring system, web-of-trust, or whatever other solution with the same
properties.
But still it must be underscored that statistical observations are only
probabilistic and don't provide resource consumption security to Bob, the
routing peer, in a deterministic way. A well-scored peer may start to
suddenly misbehave.
In that sense, the efficiency evaluation of a reputation-based solution to
deter DoS must be evaluated based based on the loss of the reputation
bearer related to the potential damage which can be inflicted. It's just
reputation sounds harder to compute accurately than a pure payment-based
DoS protection system.
> Perhaps a small bit of trust isn't so bad. There is trust in Lightning
> already. For example when you open a channel, you trust (or hope) that
your
> peer remains well connected, keeps charging reasonable fees, doesn't
> force-close in a bad way, etc.
That's a good recall, obviously we should avoid getting stuck in a false
trust-vs-trustlessness dichotomy but always bound the discussion to a
specific situation. Even the base layer involved some trust assumptions,
like fetching your initial p2p peers from DNS seeds, all the matter is how
do you minimize this assumption. You might not have the same expectation
when it's miners which might completely screw up the safety of your coin
stack than routing nodes which might only make your loss a tiny routing
fee, a minor nuisance.
> What I can see working is a system where peers charge each other a hold
fee
> for forwarded HTLCs based on the actual lock time (not the maximum lock
> time) and the htlc value. This is just for the cost of holding and
separate
> from the routing fee that is earned when the payment settles
Yes I guess any solution will work as long as it enforces an asymmetry
between the liquidity requester and a honest routing peer. This asymmetry
can be defined as guaranteeing that the routing peer's incoming/outgoing
balance is always increasing, independently of payment success. Obviously
this increase should be materialized by a payment, while minding it might
be discounted based on requester reputation ("pay-with-your-reputation").
This reputation evaluation can be fully delegated to the routing node
policy, without network-wise guidance.
That said, where I'm skeptical on any reputation-heavy system is on the
long-term implications.
Either, due to the wants of a subset of actors deliberately willingly to
trade satoshis against discounted payment flow by buying well-scored
pubkeys, we see the emergence of a reputation market. Thus enabling
reputation to be fungible to satoshis, but with now a weird "reputation"
token to care about.
Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys
from channel ownership or export your score across routing peers) and thus
you now have reputation scarcity which is introducing a bias from a "purer"
market, where agents are only routing based on advertised fees. IMO, we
should strive for the more liquid Lightning market we can, as it avoids
bias towards past actors and thus may contain centralization inertia. I'm
curious about your opinion on this last point.
Moving forward, I think t-bast is working on gathering materials to
checkbox the first step, establishing a fully-fledged threat model.
Cheers,
Antoine
Le lun. 12 oct. 2020 à 07:04, Joost Jager <joost.jager at gmail.com> a écrit :
> Hello list,
>
> Many discussions have taken place on this list on how to prevent undesired
> use of the Lightning network. Spamming the network with HTLCs (for probing
> purposes or otherwise) or holding HTLCs to incapacitate channels can be
> done on today's network at very little cost to an attacker. So far this
> doesn't seem to be happening in practice, but I believe that it is only a
> matter of time before it will become a real issue.
>
> Rate limits and other limits such as the maximum number of in-flight HTLCs
> increase the cost of an attack, but may also limit the capabilities of
> honest users. It works as a mitigation, but it doesn't seem to be the ideal
> solution.
>
> We've looked at all kinds of trustless payment schemes to keep users
> honest, but it appears that none of them is satisfactory. Maybe it is even
> theoretically impossible to create a scheme that is trustless and has all
> the properties that we're looking for. (A proof of that would also be
> useful information to have.)
>
> Perhaps a small bit of trust isn't so bad. There is trust in Lightning
> already. For example when you open a channel, you trust (or hope) that your
> peer remains well connected, keeps charging reasonable fees, doesn't
> force-close in a bad way, etc.
>
> What I can see working is a system where peers charge each other a hold
> fee for forwarded HTLCs based on the actual lock time (not the maximum lock
> time) and the htlc value. This is just for the cost of holding and separate
> from the routing fee that is earned when the payment settles.
>
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.
>
> I think the implementation of this is less interesting at this stage, but
> some ideas are:
>
> A. Prepayment: node pays an amount to its channel peer (for example via
> keysend) and the channel peer deducts the hold fees from that prepaid
> balance until it is at zero. At that point it somehow (in the htlc fail
> message?) communicates Lightning's version of http 402 to ask for more
> money.
>
> B. Tightly integrated with the htlc add/fail/settle messages. When an htlc
> is added, the maximum cost (based on maximum lock time) for holding is
> deducted from the sender's channel balance. When the htlc settles, a refund
> is given based on the actual lock time. An additional `update_fee`-like
> message is added for peers to update their hold fee parameters (fee_base
> and fee_rate).
>
> In both cases the sender needs to trust its peer to not steal the payment
> and/or artificially delay the forwarding to inflate the hold fee. I think
> that is acceptable given that there is a trust relation between peers
> already anyway.
>
> A crucial thing is that these hold fees don't need to be symmetric. A new
> node for example that opens a channel to a well-known, established routing
> node will be forced to pay a hold fee, but won't see any traffic coming in
> anymore if it announces a hold fee itself. Nodes will need to build a
> reputation before they're able to command hold fees. Similarly, routing
> nodes that have a strong relation may decide to not charge hold fees to
> each other at all.
>
> This asymmetry is what is supposed to prevent channel jamming attacks. The
> attacker needs to pay hold fees to send out the payment, but when it comes
> back to the attacker after traversing a circular route, they won't be able
> to charge a hold fee to cancel out the hold fee paid at the start of the
> route. (Assuming the attacker node is not trusted.)
>
> A consequence for honest users is that payment attempts are no longer
> free. The cost should however be negligible for fast-failing attempts. Also
> senders will have to be a lot more selective when building a route.
> Selecting a 'black hole' hop (hop that doesn't forward nor fail) can be
> costly.
>
> The hold fee scheme is a bit looser compared to previously proposed
> schemes (as far as I know...). It is purely an arrangement between channel
> peers and doesn't try to exactly compensate every hop for its costs.
> Instead trust relations that arguably exist already are leveraged to
> present a bill to the actor who deserves it.
>
> Interested to hear opinions about this proposal.
>
> I'd also like to encourage everyone to prioritize this spam/jam issue and
> dedicate more time to solving it. Obviously there is a lot more to do in
> Lightning, but I am not sure if we can afford to wait for the real
> adversaries to show up on this one.
>
> Cheers,
> Joost
>
> _______________________________________________
> 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/20201015/75e1091b/attachment.html>;
📝 Original message:
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 kinds of trustless payment schemes to keep users
> honest, but it appears that none of them is satisfactory. Maybe it is
even
> theoretically impossible to create a scheme that is trustless and has all
> the properties that we're looking for. (A proof of that would also be
> useful information to have.)
I don't think anyone has drawn yet a formal proof of this, but roughly a
routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
to answer the following question "Is this payment coming from Alice and
going to Caroll will compensate for my resources consumption ?". With the
current LN system, the compensation is conditional on payment settlement
success and both Alice and Caroll are distrusted yet discretionary on
failure/success. Thus the underscored question is undecidable for a routing
peer making relay decisions only on packet observation.
One way to mitigate this, is to introduce statistical observation of
sender/receiver, namely a reputation system. It can be achieved through a
scoring system, web-of-trust, or whatever other solution with the same
properties.
But still it must be underscored that statistical observations are only
probabilistic and don't provide resource consumption security to Bob, the
routing peer, in a deterministic way. A well-scored peer may start to
suddenly misbehave.
In that sense, the efficiency evaluation of a reputation-based solution to
deter DoS must be evaluated based based on the loss of the reputation
bearer related to the potential damage which can be inflicted. It's just
reputation sounds harder to compute accurately than a pure payment-based
DoS protection system.
> Perhaps a small bit of trust isn't so bad. There is trust in Lightning
> already. For example when you open a channel, you trust (or hope) that
your
> peer remains well connected, keeps charging reasonable fees, doesn't
> force-close in a bad way, etc.
That's a good recall, obviously we should avoid getting stuck in a false
trust-vs-trustlessness dichotomy but always bound the discussion to a
specific situation. Even the base layer involved some trust assumptions,
like fetching your initial p2p peers from DNS seeds, all the matter is how
do you minimize this assumption. You might not have the same expectation
when it's miners which might completely screw up the safety of your coin
stack than routing nodes which might only make your loss a tiny routing
fee, a minor nuisance.
> What I can see working is a system where peers charge each other a hold
fee
> for forwarded HTLCs based on the actual lock time (not the maximum lock
> time) and the htlc value. This is just for the cost of holding and
separate
> from the routing fee that is earned when the payment settles
Yes I guess any solution will work as long as it enforces an asymmetry
between the liquidity requester and a honest routing peer. This asymmetry
can be defined as guaranteeing that the routing peer's incoming/outgoing
balance is always increasing, independently of payment success. Obviously
this increase should be materialized by a payment, while minding it might
be discounted based on requester reputation ("pay-with-your-reputation").
This reputation evaluation can be fully delegated to the routing node
policy, without network-wise guidance.
That said, where I'm skeptical on any reputation-heavy system is on the
long-term implications.
Either, due to the wants of a subset of actors deliberately willingly to
trade satoshis against discounted payment flow by buying well-scored
pubkeys, we see the emergence of a reputation market. Thus enabling
reputation to be fungible to satoshis, but with now a weird "reputation"
token to care about.
Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys
from channel ownership or export your score across routing peers) and thus
you now have reputation scarcity which is introducing a bias from a "purer"
market, where agents are only routing based on advertised fees. IMO, we
should strive for the more liquid Lightning market we can, as it avoids
bias towards past actors and thus may contain centralization inertia. I'm
curious about your opinion on this last point.
Moving forward, I think t-bast is working on gathering materials to
checkbox the first step, establishing a fully-fledged threat model.
Cheers,
Antoine
Le lun. 12 oct. 2020 à 07:04, Joost Jager <joost.jager at gmail.com> a écrit :
> Hello list,
>
> Many discussions have taken place on this list on how to prevent undesired
> use of the Lightning network. Spamming the network with HTLCs (for probing
> purposes or otherwise) or holding HTLCs to incapacitate channels can be
> done on today's network at very little cost to an attacker. So far this
> doesn't seem to be happening in practice, but I believe that it is only a
> matter of time before it will become a real issue.
>
> Rate limits and other limits such as the maximum number of in-flight HTLCs
> increase the cost of an attack, but may also limit the capabilities of
> honest users. It works as a mitigation, but it doesn't seem to be the ideal
> solution.
>
> We've looked at all kinds of trustless payment schemes to keep users
> honest, but it appears that none of them is satisfactory. Maybe it is even
> theoretically impossible to create a scheme that is trustless and has all
> the properties that we're looking for. (A proof of that would also be
> useful information to have.)
>
> Perhaps a small bit of trust isn't so bad. There is trust in Lightning
> already. For example when you open a channel, you trust (or hope) that your
> peer remains well connected, keeps charging reasonable fees, doesn't
> force-close in a bad way, etc.
>
> What I can see working is a system where peers charge each other a hold
> fee for forwarded HTLCs based on the actual lock time (not the maximum lock
> time) and the htlc value. This is just for the cost of holding and separate
> from the routing fee that is earned when the payment settles.
>
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.
>
> I think the implementation of this is less interesting at this stage, but
> some ideas are:
>
> A. Prepayment: node pays an amount to its channel peer (for example via
> keysend) and the channel peer deducts the hold fees from that prepaid
> balance until it is at zero. At that point it somehow (in the htlc fail
> message?) communicates Lightning's version of http 402 to ask for more
> money.
>
> B. Tightly integrated with the htlc add/fail/settle messages. When an htlc
> is added, the maximum cost (based on maximum lock time) for holding is
> deducted from the sender's channel balance. When the htlc settles, a refund
> is given based on the actual lock time. An additional `update_fee`-like
> message is added for peers to update their hold fee parameters (fee_base
> and fee_rate).
>
> In both cases the sender needs to trust its peer to not steal the payment
> and/or artificially delay the forwarding to inflate the hold fee. I think
> that is acceptable given that there is a trust relation between peers
> already anyway.
>
> A crucial thing is that these hold fees don't need to be symmetric. A new
> node for example that opens a channel to a well-known, established routing
> node will be forced to pay a hold fee, but won't see any traffic coming in
> anymore if it announces a hold fee itself. Nodes will need to build a
> reputation before they're able to command hold fees. Similarly, routing
> nodes that have a strong relation may decide to not charge hold fees to
> each other at all.
>
> This asymmetry is what is supposed to prevent channel jamming attacks. The
> attacker needs to pay hold fees to send out the payment, but when it comes
> back to the attacker after traversing a circular route, they won't be able
> to charge a hold fee to cancel out the hold fee paid at the start of the
> route. (Assuming the attacker node is not trusted.)
>
> A consequence for honest users is that payment attempts are no longer
> free. The cost should however be negligible for fast-failing attempts. Also
> senders will have to be a lot more selective when building a route.
> Selecting a 'black hole' hop (hop that doesn't forward nor fail) can be
> costly.
>
> The hold fee scheme is a bit looser compared to previously proposed
> schemes (as far as I know...). It is purely an arrangement between channel
> peers and doesn't try to exactly compensate every hop for its costs.
> Instead trust relations that arguably exist already are leveraged to
> present a bill to the actor who deserves it.
>
> Interested to hear opinions about this proposal.
>
> I'd also like to encourage everyone to prioritize this spam/jam issue and
> dedicate more time to solving it. Obviously there is a lot more to do in
> Lightning, but I am not sure if we can afford to wait for the real
> adversaries to show up on this one.
>
> Cheers,
> Joost
>
> _______________________________________________
> 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/20201015/75e1091b/attachment.html>;