Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-25 📝 Original message: Cool, thanks for that. ...
📅 Original date posted:2022-11-25
📝 Original message:
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.riard at 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.shikhelman at 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.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/20221125/831d4b21/attachment.html>;
📝 Original message:
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.riard at 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.shikhelman at 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.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/20221125/831d4b21/attachment.html>;