Hi Clara,
> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?
About the economic aspects, while I think 0-risk HTLC forwarding acceptance
would require credentials cost to perfectly bind to the routing fees, in an
open market like the LN routing one it is expected routing hops to bump the
liquidity value of their credentials. As such increase their forwarded HTLC
traffic volume, until the failure rate downgrades their routing income
beyond their opportunity costs. How the market of HTLC senders would react
to the liquidity value bump of their credentials, and how a routing node
should pick up this bump to reach their income target is a good research
question, I think.
About secondary-markets, the credentials themselves are subject to the
classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
both to Bob and Caroll, without any of them getting knowledge of the
duplication. So it could be expected secondary markets to only happen
between LSP and their spokes (where "trust" relationships already exist),
as such harder to formalize.
Best,
Antoine
Le ven. 25 nov. 2022 à 10:40, Clara Shikhelman <clara.shikhel...@gmail.com>
a écrit :
> 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
