Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Olaoluwa Osuntokun via bitcoin-dev
Hi Antoine,

> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients [0] each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the backbone network. If
> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
> signal BIP 157, that's an increase of 100GB/month for each. Which is
> consequent with regards to the estimated cost of 350GB/month for running
> an actual public node

One really dope thing about BIP 157+158, is that the protocol makes serving
light clients now _stateless_, since the full node doesn't need to perform
any unique work for a given client. As a result, the entire protocol could
be served over something like HTTP, taking advantage of all the established
CDNs and anycast serving infrastructure, which can reduce syncing time
(less latency to
fetch data) and also more widely distributed the load of light clients using
the existing web infrastructure. Going further, with HTTP/2's server-push
capabilities, those serving this data can still push out notifications for
new headers, etc.

> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment
> capabilities to price chain access resources [3]

Piggy backing off the above idea, if the data starts being widely served
over HTTP, then LSATs[1][2] can be used to add a lightweight payment
mechanism by inserting a new proxy server in front of the filter/header
infrastructure. The minted tokens themselves may allow a user to purchase
access to a single header/filter, a range of them in the past, or N headers
past the known chain tip, etc, etc.

-- Laolu

[1]: https://lsat.tech/
[2]: https://lightning.engineering/posts/2020-03-30-lsat/


On Tue, May 5, 2020 at 3:17 AM Antoine Riard 
wrote:

> Hi,
>
> (cross-posting as it's really both layers concerned)
>
> Ongoing advancement of BIP 157 implementation in Core maybe the
> opportunity to reflect on the future of light client protocols and use this
> knowledge to make better-informed decisions about what kind of
> infrastructure is needed to support mobile clients at large scale.
>
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node. Assuming a
> user adoption path where a full-node is required to benefit for LN may
> deprive a lot of users, especially those who are already denied a real
> financial infrastructure access. It doesn't mean we shouldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even a
> first-step to it.
>
> Designing a mobile-first LN experience opens its own gap of challenges
> especially in terms of security and privacy. The problem can be scoped as
> how to build a scalable, secure, private chain access backend for millions
> of LN clients ?
>
> Light client protocols for LN exist (either BIP157 or Electrum are used),
> although their privacy and security guarantees with regards to
> implementation on the client-side may still be an object of concern
> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
> estimation). That said, one of the bottlenecks is likely the number of
> full-nodes being willingly to dedicate resources to serve those clients.
> It's not about _which_ protocol is deployed but more about _incentives_ for
> node operators to dedicate long-term resources to client they have lower
> reasons to care about otherwise.
>
> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients [0] each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the backbone network. If
> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
> signal BIP 157, that's an increase of 100GB/month for each. Which is
> consequent with regards to the estimated cost of 350GB/month for running an
> actual public node. Widening full-node adoption, specially in term of
> geographic distribution means as much as we can to bound its operational
> cost.
>
> Obviously,  deployment of more efficient tx-relay protocol like Erlay will
> free up some resources but it maybe wiser to dedicate them to increase
> health and security of the backbone network like deploying more outbound
> connections.
>
> Unless your light client protocol is so ridiculous cheap to rely on
> niceness of a subset of node operators offering free resources, it won't
> scale. And it's likely you will always have a ratio 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread John Newbery via bitcoin-dev
There doesn't seem to be anything in the original email that's specific to
BIP 157. It's a restatement of the arguments against light clients:

- light clients are a burden on the full nodes that serve them
- if light clients become more popular, there won't be enough full nodes to
serve them
- people might build products that depend on altruistic nodes serving data,
which is unsustainable
- maybe at some point in the future, light clients will need to pay for
services

The choice isn't between people using light clients or not. People already
use light clients. The choice between whether we offer them a light client
technology that is better or worse for privacy and scalability.

The arguments for why BIP 157 is better than the existing light client
technologies are available elsewhere, but to summarize:

- they're unique for a block, which means they can easily be cached.
Serving a filter requires no computation, just i/o (or memory access for
cached filter/header data) and bandwidth. There are plenty of other
services that a full node offers that use i/o and bandwidth, such as
serving blocks.
- unique-for-block means clients can download from multiple sources
- the linked-headers/filters model allows hybrid approaches, where headers
checkpoints can be fetched from trusted/signed nodes, with intermediate
headers and filters fetched from untrusted sources
- less possibilities to DoS/waste resources on the serving node
- better for privacy

> The intention, as I understood it, of putting BIP157 directly into
bitcoind was to essentially force all `bitcoind` users to possibly service
BIP157 clients

Please. No-one is forcing anyone to do anything. To serve filters, a node
user needs to download the latest version, set `-blockfilterindex=basic` to
build the compact filters index, and set `-peercfilters` to serve them over
P2P. This is an optional, off-by-default feature.

Regards,
John


On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning ariard and luke-jr
>
>
> > > Trust-minimization of Bitcoin security model has always relied first
> and
> > > above on running a full-node. This current paradigm may be shifted by
> LN
> > > where fast, affordable, confidential, censorship-resistant payment
> services
> > > may attract a lot of adoption without users running a full-node.
> >
> > No, it cannot be shifted. This would compromise Bitcoin itself, which for
> > security depends on the assumption that a supermajority of the economy is
> > verifying their incoming transactions using their own full node.
> >
> > The past few years has seen severe regressions in this area, to the point
> > where Bitcoin's future seems quite bleak. Without serious improvements
> to the
> > full node ratio, Bitcoin is likely to fail.
> >
> > Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> > and should be actively avoided. BIP 157 improves privacy of fn-less
> usage,
> > while providing no real benefits to full node users (compared to more
> > efficient protocols like Stratum/Electrum).
> >
> > For this reason, myself and a few others oppose merging support for BIP
> 157 in
> > Core.
>
> BIP 157 can be implemented as a separate daemon that processes the blocks
> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>
> The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
> fullnode to get BIP157 service.
> This is supposed to improve to the situation relative to e.g. Electrum,
> where there are far fewer Electrum servers than fullnodes.
>
> Of course, as ariard computes, deploying BIP157 could lead to an effective
> DDoS on the fullnode network if a large number of BIP157 clients arise.
> Though maybe this will not occur very fast?  We hope?
>
> It seems to me that the thing that *could* be done would be to have
> watchtowers provide light-client services, since that seems to be the major
> business model of watchtowers, as suggested by ariard as well.
> This is still less than ideal, but maybe is better than nothing.
>
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Lloyd Fournier via bitcoin-dev
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>

Hi Luke,

I have heard this claim made several times but have never understood the
argument behind it. The question I always have is: If I get scammed by not
verifying my incoming transactions properly how can this affect anyone
else? It's very unintuative.  I've been scammed several times in my life in
fiat currency transactions but as far as I could tell it never negatively
affected the currency overall!

The links you point and from what I've seen you say before refer to "miner
control" as the culprit. My only thought is that this is because a light
client could follow a dishonest majority of hash power chain. But this just
brings me back to the question. If, instead of BTC, I get a payment in some
miner scamcoin on their dishonest fork (but I think it's BTC because I'm
running a light client) that still seems to only to damage me. Where does
the side effect onto others on the network come from?

Cheers,

LL
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread ZmnSCPxj via bitcoin-dev
Good morning ariard and luke-jr


> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP 157 in
> Core.

BIP 157 can be implemented as a separate daemon that processes the blocks 
downloaded by an attached `bitcoind`, i.e. what Wasabi does.

The intention, as I understood it, of putting BIP157 directly into bitcoind was 
to essentially force all `bitcoind` users to possibly service BIP157 clients, 
in the hope that a BIP157 client can contact any arbitrary fullnode to get 
BIP157 service.
This is supposed to improve to the situation relative to e.g. Electrum, where 
there are far fewer Electrum servers than fullnodes.

Of course, as ariard computes, deploying BIP157 could lead to an effective DDoS 
on the fullnode network if a large number of BIP157 clients arise.
Though maybe this will not occur very fast?  We hope?

It seems to me that the thing that *could* be done would be to have watchtowers 
provide light-client services, since that seems to be the major business model 
of watchtowers, as suggested by ariard as well.
This is still less than ideal, but maybe is better than nothing.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Luke Dashjr via bitcoin-dev
On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node.

No, it cannot be shifted. This would compromise Bitcoin itself, which for 
security depends on the assumption that a supermajority of the economy is 
verifying their incoming transactions using their own full node.

The past few years has seen severe regressions in this area, to the point 
where Bitcoin's future seems quite bleak. Without serious improvements to the 
full node ratio, Bitcoin is likely to fail.

Therefore, all efforts to improve the "full node-less" experience are harmful, 
and should be actively avoided. BIP 157 improves privacy of fn-less usage, 
while providing no real benefits to full node users (compared to more 
efficient protocols like Stratum/Electrum).

For this reason, myself and a few others oppose merging support for BIP 157 in 
Core.

> Assuming a user adoption path where a full-node is required to benefit for
> LN may deprive a lot of users, especially those who are already denied a
> real financial infrastructure access.

If Bitcoin can't do it, then Bitcoin can't do it.
Bitcoin can't solve *any* problem if it becomes insecure itself.

Luke

P.S. See also
https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-05 Thread Jonas Nick via bitcoin-dev
This is a reasonable suggestion. Committing to every spent scriptPubKey and
therefore every element of the TxOut instead of just the amount makes sense
conceptually. And it would be a small diff (~4 lines + rationale) compared to
the current bip-taproot version.

As far aas I understand, coinjoin with offline signers would be substantially
harder without this proposal. There is a WIP "SLIP" that helped me understand
how the Proof of Ownership would work [0]. For every input, the offline signing
device verifies a signature against the corresponding scriptPubKey. In order to
obtain the correct scriptPubKey, sending the whole input transaction to the
signing device is prohibitive when the available bandwidth is low (QR codes).
The idea of only sending the transaction midstate along with the rest of
to-be-hashed transaction data is an improvement, but still results in a lot of
data (whole vout and witness stacks). Adding a new sighash flag that marks
coinjoin transactions would be a step backwards fungibility-wise.

Thus, the same reasoning for for committing to the input values in the
transaction digest to allow compact fee proofs would similarly apply the
scriptPubKeys - with the only difference that coinjoins with offline signers are
less common.

The downsides of this proposal seem to be limited. It requires additional
review, but the BIP is only in the draft stage and should incorporate reasonable
feedback. It does not invite further scope creep because the full TxOut would be
already included. The costs to verifiers is only slightly increased using
Anthony Town's suggested sighash change. Availability of the scriptPubKeys for
signing devices does not seem to be an issue because the input amounts are
already required. And if all inputs belong to the signing device, there's no
additional data sent to the device.

[0] 
https://github.com/satoshilabs/slips/blob/slips-19-20-coinjoin-proofs/slip-0019.md


On 4/29/20 2:57 PM, Andrew Kozlik via bitcoin-dev wrote:
> Hi everyone,
> 
> In the current draft of BIP-0341 [1] the signature message commits to the
> scriptPubKey of the output being spent by the input. I propose that the
> signature message should commit to the scriptPubKeys of *all* transaction
> inputs.
> 
> In certain applications like CoinJoin, a wallet has to deal with
> transactions containing external inputs. To calculate the actual amount
> that the user is spending, the wallet needs to reliably determine for each
> input whether it belongs to the wallet or not. Without such a mechanism an
> adversary can fool the wallet into displaying incorrect information about
> the amount being spent, which can result in theft of user funds [2].
> 
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input. It must acquire the full transaction being spent and verify its
> hash against that which is given in the outpoint. This is an obstacle in
> the implementation of lightweight air-gapped wallets and hardware wallets
> in general. If the signature message would commit to the scriptPubKeys of
> all transaction inputs, then the wallet would only need to acquire the
> scriptPubKey of the output being spent without having to acquire and verify
> the hash of the entire previous transaction. If an attacker would provide
> an incorrect scriptPubKey, then that would cause the wallet to generate an
> invalid signature message.
> 
> Note that committing only to the scriptPubKey of the output being spent is
> insufficient for this application, because the scriptPubKeys which are
> needed to ascertain non-ownership of external inputs are precisely the ones
> that would not be included in any of the signature messages produced by the
> wallet.
> 
> The obvious way to implement this is to add another hash to the signature
> message:
> sha_scriptPubKeys (32): the SHA256 of the serialization of all
> scriptPubKeys of the previous outputs spent by this transaction.
> 
> Cheers,
> Andrew Kozlik
> 
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Antoine Riard via bitcoin-dev
Hi,

(cross-posting as it's really both layers concerned)

Ongoing advancement of BIP 157 implementation in Core maybe the opportunity
to reflect on the future of light client protocols and use this knowledge
to make better-informed decisions about what kind of infrastructure is
needed to support mobile clients at large scale.

Trust-minimization of Bitcoin security model has always relied first and
above on running a full-node. This current paradigm may be shifted by LN
where fast, affordable, confidential, censorship-resistant payment services
may attract a lot of adoption without users running a full-node. Assuming a
user adoption path where a full-node is required to benefit for LN may
deprive a lot of users, especially those who are already denied a real
financial infrastructure access. It doesn't mean we shouldn't foster node
adoption when people are able to do so, and having a LN wallet maybe even a
first-step to it.

Designing a mobile-first LN experience opens its own gap of challenges
especially in terms of security and privacy. The problem can be scoped as
how to build a scalable, secure, private chain access backend for millions
of LN clients ?

Light client protocols for LN exist (either BIP157 or Electrum are used),
although their privacy and security guarantees with regards to
implementation on the client-side may still be an object of concern
(aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
estimation). That said, one of the bottlenecks is likely the number of
full-nodes being willingly to dedicate resources to serve those clients.
It's not about _which_ protocol is deployed but more about _incentives_ for
node operators to dedicate long-term resources to client they have lower
reasons to care about otherwise.

Even with cheaper, more efficient protocols like BIP 157, you may have a
huge discrepancy between what is asked and what is offered. Assuming 10M
light clients [0] each of them consuming ~100MB/month for filters/headers,
that means you're asking 1PB/month of traffic to the backbone network. If
you assume 10K public nodes, like today, assuming _all_ of them opt-in to
signal BIP 157, that's an increase of 100GB/month for each. Which is
consequent with regards to the estimated cost of 350GB/month for running an
actual public node. Widening full-node adoption, specially in term of
geographic distribution means as much as we can to bound its operational
cost.

Obviously,  deployment of more efficient tx-relay protocol like Erlay will
free up some resources but it maybe wiser to dedicate them to increase
health and security of the backbone network like deploying more outbound
connections.

Unless your light client protocol is so ridiculous cheap to rely on
niceness of a subset of node operators offering free resources, it won't
scale. And it's likely you will always have a ratio disequilibrium between
numbers of clients and numbers of full-node, even worst their growth rate
won't be the same, first ones are so much easier to setup.

It doesn't mean servicing filters for free won't work for now, numbers of
BIP157 clients is still pretty low, but what is worrying is  wallet vendors
building such chain access backend, hitting a bandwidth scalability wall
few years from now instead of pursuing better solutions. And if this
happen, maybe suddenly, isn't the quick fix going to be to rely on
centralized services, so much easier to deploy ?

Of course, it may be brought that actually current full-node operators
don't get anything back from servicing blocks, transactions, addresses...
It may be replied that you have an indirect incentive to participate in
network relay and therefore guarantee censorship-resistance, instead of
directly connecting to miners. You do have today ways to select your
resources exposure like pruning, block-only or being private but the wider
point is the current (non?)-incentives model seems to work for the base
layer. For light clients data, are node operators going to be satisfied to
serve this new *class* of traffic en masse ?

This doesn't mean you won't find BIP157 servers, ready to serve you with
unlimited credit, but it's more likely their intentions maybe not aligned,
like spying on your transaction broadcast or block fetched. And you do want
peer diversity to avoid every BIP157 servers being on few ASNs for
fault-tolerance. Do people expect a scenario a la Cloudflare, where
everyone connections is to far or less the same set of entities ?

Moreover, the LN security model diverges hugely from basic on-chain
transactions. Worst-case attack on-chain a malicious light client server
showing a longest, invalid, PoW-signed chain to double-spend the user. On
LN, the *liveliness* requirement means the entity owning your view of the
chain can lie to you on whether your channel has been spent by a revoked
commitment, the real tip of the blockchain or even dry-up block
announcement to trigger unexpected behavior in the client logic. A
malicious