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
