Date: Mon, 11 May 2020 05:44:08 +0000
To: Richard Myers <rich@gotenna.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dcn-zTdD8PQxsZoDJtOP90GBPqRXKuCwYkvkOWeoJmArexkFapaA1M_xLONcoM6qTVh7nJCbmBCOvUQYobI_WPbC5deMOgfytSRi1zIgJ_o=@protonmail.com>
In-Reply-To: <CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@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>
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
Precedence: list

Good morning Richard, and all,


> 2) a=C2=A0light client can query an ISP connected full node on the same u=
nmetered local WiFi network and exchange differences in block headers oppor=
tunistically or pay for large missing ranges of headers, filters or full bl=
ocks using a payment channel. Cost is reduced and privacy=C2=A0is enhanced =
for the light client by not using a centralized ISP. Bandwidth for running =
the full node can be amortized=C2=A0and subsidized by payments from light c=
lients 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 information=
 (whether full blocks, headers, or filters), the direct peers it has could =
just as easily not forward any payments, thus preventing the light client f=
rom paying for the validation information.

Indeed, if the direct peer *is* defrauding the light client, the direct pee=
r has no real incentive to actually forward *any* payments --- to do so wou=
ld be to reduce the possible earnings it gets from defrauding the light cli=
ent.
("Simulating" the payments so that the light client will not suspect anythi=
ng runs the risk that the light client will be able to forward all its mone=
y 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.)

What would work would be to use a system similar to watchtowers, wherein th=
e 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 lapto=
p is running a validation-information-provider-for-payment program on the s=
ame 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 if it=
 were for (on-Lightning) payment.


So it seems to me that this kind of service is best ridden on top of watcht=
ower service providers.

Regards,
ZmnSCPxj