rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 Original date posted:2020-10-06 📝 Original message: 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