Good morning Antoine, and Bastien,
> Instead of relying on reputation, the other alternative is just to have an
> upfront payment system, where a relay node doesn't have to account for a HTLC
> issuer reputation to decide acceptance and can just forward a HTLC as long it
> paid enough. More, I think it's better to mitigate jamming with a fees-based
> system than a web-of-trust one, less burden on network newcomers.
Let us consider some of the complications here.
A newcomer wants to make an outgoing payment.
Speculatively, it connects to some existing nodes based on some policy.
Now, since forwarding is upfront, the newcomer fears that the node it connected
to might not even bother forwarding the payment, and instead just fail it and
claim the upfront fees.
In particular: how would the newcomer offer upfront fees to a node it is not
directly channeled with?
In order to do that, we would have to offer the upfront fees for that node, to
the node we *are* channeled with, so it can forward this as well.
* We can give the upfront fee outright to the first hop, and trust that if it
forwards, it will also forward the upfront fee for the next hop.
* The first hop would then prefer to just fail the HTLC then and there and
steal all the upfront fees.
* After all, the offerrer is a newcomer, and might be the sybil of a hacker
that is trying to tie up its liquidity.
The first hop would (1) avoid this risk and (2) earn more upfront fees
because it does not forward those fees to later hops.
* This is arguably custodial and not your keys not your coins applies.
Thus, it returns us back to tr\*st anyway.
* We can require that the first hop prove *where* along the route errored.
If it provably failed at a later hop, then the first hop can claim more as
upfront fees, since it will forward the upfront fees to the later hop as well.
* This has to be enforcable onchain in case the channel gets dropped onchain.
Is there a proposal SCRIPT which can enforce this?
* If not enforcable onchain, then there may be onchain shenanigans possible
and thus this solution might introduce an attack vector even as it fixes
another.
* On the other hand, sub-satoshi amounts are not enforcable onchain too,
and nobody cares, so...
On the other hand, a web-of-tr\*st might not be *that* bad.
One can say that "tr\*st is risk", and consider that the size and age of a
channel to a peer represents your tr\*st that that peer will behave correctly
for fast and timely resolution of payments.
And anyone can look at the blockchain and the network gossip to get an idea of
who is generally considered tr\*stworthy, and since that information is backed
by Bitcoins locked in channels, this is reasonably hard to fake.
On the other hand, this risks centralization around existing, long-lived nodes.
*Sigh*.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
