Cool, thanks for that. Have you done any work on the economic aspects of the new tokens and their secondary markets?
On Thu, Nov 24, 2022, 21:22 Antoine Riard <antoine.ri...@gmail.com> wrote: > Hi Clara, > > The main benefit of this "staking"/reputational credentials is to save on > unconditional fees paid by HTLC senders. They benefit from their past HTLC > routing success in terms of more credentials allocated to them, and as such > minimize the overhead cost of their future HTLC sends, or allow them to > lock liquidity for longer periods. From a routing node viewpoint, a 0-risk > HTLC forwarding acceptance can be maintained by requesting strict binding > between credentials acquisition cost and channel liquidity routed. If > higher returns are seeked, the ratio credentials to liquidity can be > adjusted, of course coming with higher risks, and I think this is where the > model built for the current unconditional fees proposal could be useful (if > we integrate the channel congestion rate factor, I believe). > > On top of this monetary paradigm, we can layer a "pure reputation" system, > where in function of the quality of the identities (e.g > proof-of-utxo-ownership), HTLC senders are allocated more significant > liquidity slots. Here, the real bottleneck is the cryptosystem, i.e proving > a UTXO ownership without revealing any other information. The rationale of > this "pure reputation" system, we could even save more in > upfront/unconditional fees in the steady state of the network (however such > a probabilistic model breaks hard in presence of attackers). > > Best, > Antoine > > Le jeu. 24 nov. 2022 à 09:45, Clara Shikhelman <clara.shikhel...@gmail.com> > a écrit : > >> Hi Antoine, >> >> It sounds like unconditional fees cover most of what this policy does, >> without the extra risks that come from creating a new token. Is there a >> clear benefit to using a token compared to unconditional fees and >> local reputation? >> >> Best, >> Clara >> >> On Wed, Nov 23, 2022 at 9:48 PM Antoine Riard <antoine.ri...@gmail.com> >> wrote: >> >>> Hi Clara, >>> >>> I think the simplest recommended policy you can devise is credential >>> shown to the routing hop should cover for full routing fees, therefore the >>> routing hop benefits from a zero-jamming risk situation. Then you can >>> appreciate the "liquidity value" credentials requested in function of your >>> local channel congestion rate, or even network data. Increasing your >>> returns in exchange of higher risk exposure. And even more, you can lay on >>> top a reputation layer, where the reputation scores are fully fungible >>> against monetary credentials, in the acceptance of a HTLC forward request. >>> >>> So I think I agree with you a recommended policy is needed, let's just >>> start with a simple one! And refine it with time once we sense we have >>> solid foundations. >>> >>> Best, >>> Antoine >>> >>> >>> Le mer. 23 nov. 2022 à 11:00, Clara Shikhelman < >>> clara.shikhel...@gmail.com> a écrit : >>> >>>> Hi Antoine, >>>> >>>> To discuss your proposed solution in detail, I think that some kind of >>>> recommended policy is needed. If presenting one is a low priority, and >>>> waiting for other things, my main concern is that it will just never happen >>>> ("any decade now" kind of situation). >>>> >>>> Best, >>>> Clara >>>> >>>> On Tue, Nov 22, 2022 at 8:13 PM Antoine Riard <antoine.ri...@gmail.com> >>>> wrote: >>>> >>>>> Hi Clara, >>>>> >>>>> Shared the mail on #lightning-dev Libera chat to get more feedback on >>>>> schedule. >>>>> >>>>> > Do you have a timeline in mind for presenting such a policy? >>>>> >>>>> See the comments on the BOLT #1043 PR, for now I'm thinking more to >>>>> refine the proposed credentials architectural framework. >>>>> I think dynamic routing policy in function of channel congestion rate, >>>>> and you combine that with reputation to do active risk-management are far >>>>> more advanced questions. >>>>> >>>>> Best, >>>>> Antoine >>>>> >>>>> Le mar. 22 nov. 2022 à 15:54, Clara Shikhelman < >>>>> clara.shikhel...@gmail.com> a écrit : >>>>> >>>>>> Dear All, >>>>>> >>>>>> If the call time (Monday the 28th at 7 pm UTC) doesn't work out for >>>>>> you, please reach out! >>>>>> >>>>>> Thanks for your quick and detailed response, Antoine. >>>>>> >>>>>> If by recommend policy, you mean the set of algorithms that should >>>>>>> guide the token quantity, rate issuance, token acquisition cost, and the >>>>>>> adaptations in function of the local channel congestion, or even the >>>>>>> gossips of the other routing nodes, not at all. >>>>>>> >>>>>> >>>>>> Do you have a timeline in mind for presenting such a policy? >>>>>> >>>>>> Looking forward to discussing this further over the phone call, will >>>>>> make some inquiries to make sure the time works for most people. >>>>>> >>>>>> Best, >>>>>> Clara >>>>>> >>>>>
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev