Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-18 📝 Original message: > > > We've looked at all ...
📅 Original date posted:2020-10-18
📝 Original message:
>
> > 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.
>
I can totally see the issues and complexity of a reputation-based system.
With 'trustless payment scheme' I meant indeed a trustless pure
payment-based DoS protection system and the question whether such a system
can be proven to not exist. A sender would pay an up-front amount to cover
the maximum cost, but with the guarantee that nodes can only take a fair
part of the deposit (based on actual lock time). Perhaps the taproot
upgrade offers new possibilities with adaptor signatures to atomically swap
part of the up-front payment with htlc-received-in-time-signatures from
nodes downstream (random wild idea).
> > 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.
>
I am in favor of more liquidity and less centralization, but as far as I
know the reality is that we don't have a good solution yet to achieve this
without being vulnerable to DoS attacks. If those attacks would happen on a
large scale today, what would we do?
Also peers can implement these trusted upfront payments without protocol
changes. Just stop forwarding when the prepaid forwarding budget is used up
and require a top-up. It may have been implemented already in parts of the
network, I don't think there is a way to know. I've experimented a bit with
the fee model myself (
https://twitter.com/joostjgr/status/1317546071984427009). Node operators
don't need to wait for permission.
To me it seems that the longer it takes to come up with a good anti-DoS
system for Lightning, the further the outside world will have developed
their trust-based systems and established that potential bias towards
centralization.
That might be another reason to prioritize this issue. Not just because we
want the network to be safe, but also to be able to implement the preferred
solution while the opportunity window is still open.
- Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201018/6af64b5a/attachment.html>;
📝 Original message:
>
> > 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.
>
I can totally see the issues and complexity of a reputation-based system.
With 'trustless payment scheme' I meant indeed a trustless pure
payment-based DoS protection system and the question whether such a system
can be proven to not exist. A sender would pay an up-front amount to cover
the maximum cost, but with the guarantee that nodes can only take a fair
part of the deposit (based on actual lock time). Perhaps the taproot
upgrade offers new possibilities with adaptor signatures to atomically swap
part of the up-front payment with htlc-received-in-time-signatures from
nodes downstream (random wild idea).
> > 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.
>
I am in favor of more liquidity and less centralization, but as far as I
know the reality is that we don't have a good solution yet to achieve this
without being vulnerable to DoS attacks. If those attacks would happen on a
large scale today, what would we do?
Also peers can implement these trusted upfront payments without protocol
changes. Just stop forwarding when the prepaid forwarding budget is used up
and require a top-up. It may have been implemented already in parts of the
network, I don't think there is a way to know. I've experimented a bit with
the fee model myself (
https://twitter.com/joostjgr/status/1317546071984427009). Node operators
don't need to wait for permission.
To me it seems that the longer it takes to come up with a good anti-DoS
system for Lightning, the further the outside world will have developed
their trust-based systems and established that potential bias towards
centralization.
That might be another reason to prioritize this issue. Not just because we
want the network to be safe, but also to be able to implement the preferred
solution while the opportunity window is still open.
- Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201018/6af64b5a/attachment.html>;