CJP [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-02 📝 Original message: ZmnSCPxj schreef op wo ...

📅 Original date posted:2019-01-02
📝 Original message:
ZmnSCPxj schreef op wo 02-01-2019 om 13:02 [+0000]:
> I wonder however if this is a "small enough" hole that leaving it is
> an acknowledged security vulnerability may be better than replacing
> it with a trusted third party.
> One may compare with the SSH "trust the first pubkey, verify the
> second onwards" weakness, to SSL "trust the certificate authority to
> say whose pubkey is whose".

SSH's problem (non-authenticated initial key exchange) is small,
because there is a very small time window for an attack, and an
attacker has to place itself in the route *and* stay in the route to
not be detected later.

SSL's problem (trusted third parties for key authentication) is big,
because each website only uses a single certificate issuer, so you need
to trust every certificate issuer to be able to visit every website,
even the more questionable certificate issuers; the combined security
is as strong as the weakest certificate issuer.

Route Makers (RM) (maybe I should change that name) are not a big
problem, because, unlike websites, OMs and OTs are very fungible
towards each other, especially on popular asset pairs: it's not a big
deal if you lose, say, 10% of potential trading partners because you
don't want to use a certain RM. Also, a single attack by a RM is not
typically a big deal, and it is easily detectable. False positives are
possible though (both accidental and deliberate), so you might want to
suspend a RM after abuse detection for a while, and then give it
another chance after some time.

> The hop node just before the RM can provide proof that it offered an
> HTLC and the RM allowed the HTLC offer to be made.
> It can provide a commitment transaction signed by itself and the RM,
> with that commitment transaction containing the HTLC in question.
> This is proof that the RM *could* pull the HTLC, but did not do so
> quickly enough.
>
> Since RM nodes are publicly known, perhaps we can make a different
> routing from S to RM, one that reveals (to hop nodes) their distance
> to RM, but not to S.
> RM nodes provide a service to the network and we can argue that the
> loss of their privacy here is acceptable, as long as the payee S is
> still able to keep its privacy, as an acceptable cost to ensuring
> that RM behaves honestly.
>
> If the just-before-last node (let us call this G or "guard" node) can
> monitor the time that RM pulls the HTLC, then it can provide proof
> that RM had the ability to pull the HTLC but did not do so.

This, and the rest of your proposal, sounds like a lot of trouble,
while it hardly solves anything.

RM can have its node surrounded by other nodes also controlled by
itself. So it is possible that RM controls all nodes that can possibly
fulfill the 'G' role, and thereby stop any evidence being generated
against the RM node. If you then want to build evidence against the G
nodes, you end up recursively involving every single Lightning node in
trying to solve your problem. Maybe it is possible, but I'd like not to
do that. I like to see the exchange function as a higher layer (layer
3) on top of the Lightning layer, and have each layer solve its own
problems in a clean and elegant way. I prefer that nodes that aren't
involved in exchanging assets don't need to deal with its complexities
either.

CJP