Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-24 📝 Original message: Hi Antoine, It sounds ...
📅 Original date posted:2022-11-24
📝 Original message:
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.riard at 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.shikhelman at 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.riard at 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.shikhelman at 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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221124/ae8ebfc1/attachment.html>;
📝 Original message:
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.riard at 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.shikhelman at 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.riard at 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.shikhelman at 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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221124/ae8ebfc1/attachment.html>;