š
Original date posted:2022-11-25
š Original message:
Good morning Antoine,
> It should be noted, this current reputation-credential architectural framework assumes credentials distribution at the endpoint of the network. However, the framework should be flexible enough for the credentials to be harvested by the LSPs, and then distributed in a secondary fashion to their spokes, when they need it, or even attached transparently thanks to trampoline. So one design intuition, there is no strong attachment of the reputation to the endpoint HTLC sender, even if the protocol is described in a "flat" view for now.
This seems incorrect.
If I am an LSP, and I know my competitor LSP distributes their credentials, then I can simply apply to be a spoke on my competitor and then make several payments to my node, which I then jam up.
This reduces the reputation of my competitor LSP.
This is even worse if my competitor LSP attaches their credentials on trampolines, I do not even need to apply to be a spoke on my competitor that way.
Thus in both cases the competitor LSP needs to have a similar way of ensuring that their spokes / trampoline requesters are not also trying to jam *them* in order to drain their reputation.
Thus all reputation still rests with ultimate senders, who have to convince LSPs to sell their reputation to them, because they might secretly be competitor LSPs who have incentive to drain their reputation.
If the price of sold reputation is too high, then it is no different from upfront fees.
If the price of sold reputation is too low, then I can drain the reputation of competitor LSPs.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 13:07:27
in reply to nevent1qā¦qg8w
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:07:27Event JSON
{
"id": "016744317f2682d15a72cbfcc3cc253be407111ccf9e5f665a5420ad81a73625",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686316047,
"kind": 1,
"tags": [
[
"e",
"9c3a63b3566ad83b1efc2410b067702e12877b167df07023410314f65ebf754b",
"",
"root"
],
[
"e",
"4cf480e8166a2b749ce461fad0821462eba032a20b8f7c0965a1bb6ffcf42f12",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "š
Original date posted:2022-11-25\nš Original message:\nGood morning Antoine,\n\n\u003e It should be noted, this current reputation-credential architectural framework assumes credentials distribution at the endpoint of the network. However, the framework should be flexible enough for the credentials to be harvested by the LSPs, and then distributed in a secondary fashion to their spokes, when they need it, or even attached transparently thanks to trampoline. So one design intuition, there is no strong attachment of the reputation to the endpoint HTLC sender, even if the protocol is described in a \"flat\" view for now.\n\nThis seems incorrect.\n\nIf I am an LSP, and I know my competitor LSP distributes their credentials, then I can simply apply to be a spoke on my competitor and then make several payments to my node, which I then jam up.\nThis reduces the reputation of my competitor LSP.\n\nThis is even worse if my competitor LSP attaches their credentials on trampolines, I do not even need to apply to be a spoke on my competitor that way.\n\nThus in both cases the competitor LSP needs to have a similar way of ensuring that their spokes / trampoline requesters are not also trying to jam *them* in order to drain their reputation.\nThus all reputation still rests with ultimate senders, who have to convince LSPs to sell their reputation to them, because they might secretly be competitor LSPs who have incentive to drain their reputation.\n\nIf the price of sold reputation is too high, then it is no different from upfront fees.\n\nIf the price of sold reputation is too low, then I can drain the reputation of competitor LSPs.\n\nRegards,\nZmnSCPxj",
"sig": "585a114fc83550081ad6783a22811fda92a0aba9b5c6815942f725a573a5214fcbc0927c783d9554a43cd1b9402d1a39931c4def3cd38dee5bb8bd36095476a0"
}