[Lightning-dev] Lightning-dev Digest, Vol 62, Issue 14

Bitcoin Error Log bitcoinerrorlog at gmail.com
Wed Oct 14 06:17:59 UTC 2020


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>


More information about the Lightning-dev mailing list