From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 12B0FC016F for ; Tue, 12 May 2020 15:48:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 0E6B18865A for ; Tue, 12 May 2020 15:48:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr0mJ5d6hB2Q for ; Tue, 12 May 2020 15:48:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by whitealder.osuosl.org (Postfix) with ESMTPS id 00A4D885E0 for ; Tue, 12 May 2020 15:48:44 +0000 (UTC) Date: Tue, 12 May 2020 15:48:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589298522; bh=5T/qNNxfEQuAewKC/nv8ZRPZPy/Nnu1o2/8PvFfeeQA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=j+hB7DiJ988VCZ6d9xmwziWflmlUWAGWFkTc/pbG8QSx9Z9Iwe/VtczKGnlOo0M+R p/XtyKhX2kc6onhXSIkEs6sEhrvK1dAZoyQOn4bvdBky3pCPbHGZJBVthDIhUiRZhp E0eO12q0Amf48R/2lQ+eRdO4AOa4i42nPe2XCgJg= To: Richard Myers From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <5sZto_wJw0-IZBn9av7J3WvecfBndb5Q8LRAZLj2oMdY5gq-pnSGUGrYRrKjGPF0rW8eEFqlKDkEgzkJ0ZZlX43JgvjkLBAEfmt5ccxy-K8=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 15:48:47 -0000 Good morning Richard, > Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your c= oncern as: A node without direct internet connectivity can not rely on an o= pportunistically incentivized local network peer for blockchain information= because the off-grid node's direct LN peers could collude to not forward t= he payment. Correct. > > > 2) a=C2=A0light client can query an ISP connected full node on the sa= me unmetered local WiFi network and exchange differences in block headers o= pportunistically or pay for large missing ranges of headers, filters or ful= l blocks using a payment channel. Cost is reduced and privacy=C2=A0is enhan= ced for the light client by not using a centralized ISP. Bandwidth for runn= ing the full node can be amortized=C2=A0and subsidized by payments from lig= ht clients who they resell data to. > > > > A relatively pointless observation, but it seems to me that: > > > > * The light client is requesting for validation information, because... > > * ...its direct peers might be defrauding it, leading to... > > * ...the money it *thinks* it has in its channels being valueless. > > > > Thus, if the light client opportunistically pays for validation informa= tion (whether full blocks, headers, or filters), the direct peers it has co= uld just as easily not forward any payments, thus preventing the light clie= nt from paying for the validation information. > > > > Indeed, if the direct peer *is* defrauding the light client, the direct= peer has no real incentive to actually forward *any* payments --- to do so= would be to reduce the possible earnings it gets from defrauding the light= client. > > ("Simulating" the payments so that the light client will not suspect an= ything runs the risk that the light client will be able to forward all its = money out of the channel, and the cheating peer is still potentially liable= for any funds it originally had in the channel if it gets caught.) > > One question I had is: how can a malicious direct payment peer "simulate"= a successful payment made by an off-grid victim peer to an information sou= rce?=C2=A0 The=C2=A0censoring peer wouldn't be able to return the preimage = for a payment they failed to forward. Also, since the information provider = and off-grid node can presumably communicate via their local network connec= tion, it would be obvious if all of the victims LN peers were failing to fo= rward payments (whether maliciously or due to routing failures) to an infor= mation provider they could otherwise communicate with. Perhaps "simulate" is not quite the correct term. Basically, if the eclipsing peer(s) are reasonably sure they have eclipsed = the light client, then all funds in those channels are semantically theirs = (they "0wn" the eclipsed light client). Then anything the light node offers from those channels (which it thinks ar= e its, but are now in reality owned by the eclipsing peer) has no value (th= e eclipsing node already 0wns the light node and all its funds, what can th= e light node offer to it?). The eclipsing peer could still "simulate" what the light node expects of re= ality by pretending that the light node actually still owns funds in the ch= annel (even though the eclipsing node has successfully stolen all those fun= ds), and forward as normal to get the payment preimage/scalar. > > What would work would be to use a system similar to watchtowers, wherei= n the validation-information-provider is prepaid and issues tokens that can= be redeemed later. > > But this is not suitable for opportunistic on-same-WiFi where, say, a l= aptop is running a validation-information-provider-for-payment program on t= he same WiFi as a light-client mobile phone, if we consider that the laptop= and mobile may have never met before and may never meet again. > > It would work if the laptop altruistically serves the blocks, but not i= f it were for (on-Lightning) payment. > > There's another problem if we can't rely on a recurring relationship with= an information provider besides not being able to prepay for validation in= formation doesn't make sense. We don't want an information provider=C2= =A0to collect payments for serving invalid information. Maybe for very smal= l payments this isn't a problem, but ideally validity could be coded into t= he HTLC. > > For example, an alternative HTLC construct that only paid for valid 81 B = headers that hash to 32 B values with a number of leading zeros committed t= o by the HTLC. It would make more economic sense for an internet gateway no= de to serve valid mined header to nodes on their=C2=A0local WiFi network th= an to create bogus ones with the same (high) amount of work. If you are considering this for on-Lightning payments, do note that the alt= ernative HTLC construct has to be known by every forwarding node, including= the direct peer(s) of the light client, which are precisely the potential = attackers on the light client. It seems to be impractical for onchain payments: the provider can drop the = data onchain to claim the funds, but it is precisely the blockchain data th= at the light client does not have direct access to, so --- > =C2=A0 > > > So it seems to me that this kind of service is best ridden on top of wa= tchtower service providers. > > Public watchtowers or some sort of HTTP proxy data cache similar to=C2= =A0a watchtower makes the most sense to me because they would be expected t= o be economically motivated and LN payment aware. Full nodes could potentia= lly be incentivized to exchange new data with other nodes in a tit-for-tat = way, but I don't expect them to be incentivized by light clients using LN m= icropayments in a server-client arrangement. > > Network agents that monetize full node information services beyond channe= l monitoring would be more than just a "Watchtower" for light clients. Woul= d they be more like incentivized Electrum servers? Possibly. > Are there still privacy concerns when they=C2=A0serve generic/un-personal= ized headers/filters/blocks to light clients? It marks the client as a light client, at least. Someone who gets read-only access to the logs of such a public-service node= now has a list of light clients. If the light clients are in any way identifiable and locatable, the hacker = can then attempt to hack the light client and redirect their understanding = of what the public-service node is (e.g. DNS poisoning) and then start perf= orming other attacks on the client once its view of the blockchain is eclip= sed. This would be helped if the light client, for example, always uses Tor to a= ccess the public-service node, if payments for services of that node are de= correlated (e.g. tokens issued by the node that will later be reclaimed for= service are blinded), etc. Such would make the light client harder to locate in the first place. (While a mobile client can certainly access the Internet over various acces= s points, most people who own mobile devices have a home they go to at nigh= t, which often has Internet access, possibly with a stable identifiable loc= ation that can be attacked) >=C2=A0A personal, altruistic or friends and family watchtower is also poss= ible, but I'm thinking about how light clients without this possibility can= be served. This is probably something we can expect to see as well; though it should b= e noted, for those philosophically interested in such things, that these ar= e the genesis of governments and states. Regards, ZmnSCPxj