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 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
