From cjp at ultimatestunts.nl Wed Jan 2 21:06:49 2019 From: cjp at ultimatestunts.nl (CJP) Date: Wed, 02 Jan 2019 22:06:49 +0100 Subject: [Lightning-dev] An Argument For Single-Asset Lightning Network In-Reply-To: References: <1545984977.10970.1.camel@ultimatestunts.nl> <1546093191.7799.2.camel@ultimatestunts.nl> Message-ID: <1546463209.2513.2.camel@ultimatestunts.nl> 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