Bitcoin Error Log [ARCHIVE] on Nostr: š Original date posted:2020-10-14 š Original message: Regarding putting trust ...
š
Original date posted:2020-10-14
š Original message:
Regarding putting trust on the table as a design solution to possible
attacks that aren't happening, wouldn't it be wise to start with whatever
trust solutions common networks already use and mutate that to this
situation?
Example: KYC, black/whitelisting, reputation scoring, permissioned/private
subnets, scoring/tiers
Of course, none of us actually want to design formal KYC into LN, but it
really is the same premise: "identifying" your counterparty and assessing
the amount of risk you would like to allocate. Permissioned access, reduced
public listening, out-of-band credentialing, etc, etc.
Networking issues like these might not even be appropriate to be handled at
the LN level. Possibly better to use a multipurpose context layer (gets
into ID systems, namespaces, WoTs).
Sorry if I'm oversimplifying the topic, but it is frustrating to watch devs
argue about the edge of an edge of a knife no one is using, and then
bikeshed every imperfection...
Cryptographic punishment schemes aren't swiss army knives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201014/c6636dc0/attachment.html>;
š Original message:
Regarding putting trust on the table as a design solution to possible
attacks that aren't happening, wouldn't it be wise to start with whatever
trust solutions common networks already use and mutate that to this
situation?
Example: KYC, black/whitelisting, reputation scoring, permissioned/private
subnets, scoring/tiers
Of course, none of us actually want to design formal KYC into LN, but it
really is the same premise: "identifying" your counterparty and assessing
the amount of risk you would like to allocate. Permissioned access, reduced
public listening, out-of-band credentialing, etc, etc.
Networking issues like these might not even be appropriate to be handled at
the LN level. Possibly better to use a multipurpose context layer (gets
into ID systems, namespaces, WoTs).
Sorry if I'm oversimplifying the topic, but it is frustrating to watch devs
argue about the edge of an edge of a knife no one is using, and then
bikeshed every imperfection...
Cryptographic punishment schemes aren't swiss army knives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201014/c6636dc0/attachment.html>;