path: root/ca/e1a6be0da3e1245b57213d68e3463f08dd6e55

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 12B0FC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <rich@gotenna.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <5sZto_wJw0-IZBn9av7J3WvecfBndb5Q8LRAZLj2oMdY5gq-pnSGUGrYRrKjGPF0rW8eEFqlKDkEgzkJ0ZZlX43JgvjkLBAEfmt5ccxy-K8=@protonmail.com>
In-Reply-To: <CACJVCgKG9w8n7TzN3jdzirEYUMJq7YezYLhg_h00B8ELfoN9-g@mail.gmail.com>
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <CAO3Pvs8rkouxQY912VW04pmn-hdAhMNL_6E_nXDmkeibBegwkA@mail.gmail.com>
 <CALZpt+H1OOhrOXUMO7Fn_9Vgx8_sNPAshdd8+euAT_NWgd7uqA@mail.gmail.com>
 <CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@mail.gmail.com>
 <dcn-zTdD8PQxsZoDJtOP90GBPqRXKuCwYkvkOWeoJmArexkFapaA1M_xLONcoM6qTVh7nJCbmBCOvUQYobI_WPbC5deMOgfytSRi1zIgJ_o=@protonmail.com>
 <CACJVCgKG9w8n7TzN3jdzirEYUMJq7YezYLhg_h00B8ELfoN9-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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