📅 Original date posted:2020-05-05
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200505/be23bd38/attachment-0001.html>;
John Newbery [ARCHIVE] /
npub1ap…608ff
2023-06-09 13:00:06
in reply to nevent1q…afsn
Author Public Key
npub1aprq807up25mkugnhlr9nc2jkqqxd3wyrct3uj0kzhsdunaj7q8s7608ffPublished at
2023-06-09 13:00:06Event JSON
{
"id": "7fd3f44769ba2b861aacf164f59c905ee64c4b705505b660c0e211120b9d500b",
"pubkey": "e84603bfdc0aa9bb7113bfc659e152b00066c5c41e171e49f615e0de4fb2f00f",
"created_at": 1686315606,
"kind": 1,
"tags": [
[
"e",
"fe60513fd93e5b8aa19bf74b8481dfcc2b3f8faff34b68fd71fc053010ec09c9",
"",
"root"
],
[
"e",
"48f4ce90d78839b3448bb02c2f95c4f4db689ff92deddb1bbd771b47c042dff7",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-05-05\n📝 Original message:\nThere doesn't seem to be anything in the original email that's specific to\nBIP 157. It's a restatement of the arguments against light clients:\n\n- light clients are a burden on the full nodes that serve them\n- if light clients become more popular, there won't be enough full nodes to\nserve them\n- people might build products that depend on altruistic nodes serving data,\nwhich is unsustainable\n- maybe at some point in the future, light clients will need to pay for\nservices\n\nThe choice isn't between people using light clients or not. People already\nuse light clients. The choice between whether we offer them a light client\ntechnology that is better or worse for privacy and scalability.\n\nThe arguments for why BIP 157 is better than the existing light client\ntechnologies are available elsewhere, but to summarize:\n\n- they're unique for a block, which means they can easily be cached.\nServing a filter requires no computation, just i/o (or memory access for\ncached filter/header data) and bandwidth. There are plenty of other\nservices that a full node offers that use i/o and bandwidth, such as\nserving blocks.\n- unique-for-block means clients can download from multiple sources\n- the linked-headers/filters model allows hybrid approaches, where headers\ncheckpoints can be fetched from trusted/signed nodes, with intermediate\nheaders and filters fetched from untrusted sources\n- less possibilities to DoS/waste resources on the serving node\n- better for privacy\n\n\u003e The intention, as I understood it, of putting BIP157 directly into\nbitcoind was to essentially force all `bitcoind` users to possibly service\nBIP157 clients\n\nPlease. No-one is forcing anyone to do anything. To serve filters, a node\nuser needs to download the latest version, set `-blockfilterindex=basic` to\nbuild the compact filters index, and set `-peercfilters` to serve them over\nP2P. This is an optional, off-by-default feature.\n\nRegards,\nJohn\n\n\nOn Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning ariard and luke-jr\n\u003e\n\u003e\n\u003e \u003e \u003e Trust-minimization of Bitcoin security model has always relied first\n\u003e and\n\u003e \u003e \u003e above on running a full-node. This current paradigm may be shifted by\n\u003e LN\n\u003e \u003e \u003e where fast, affordable, confidential, censorship-resistant payment\n\u003e services\n\u003e \u003e \u003e may attract a lot of adoption without users running a full-node.\n\u003e \u003e\n\u003e \u003e No, it cannot be shifted. This would compromise Bitcoin itself, which for\n\u003e \u003e security depends on the assumption that a supermajority of the economy is\n\u003e \u003e verifying their incoming transactions using their own full node.\n\u003e \u003e\n\u003e \u003e The past few years has seen severe regressions in this area, to the point\n\u003e \u003e where Bitcoin's future seems quite bleak. Without serious improvements\n\u003e to the\n\u003e \u003e full node ratio, Bitcoin is likely to fail.\n\u003e \u003e\n\u003e \u003e Therefore, all efforts to improve the \"full node-less\" experience are\n\u003e harmful,\n\u003e \u003e and should be actively avoided. BIP 157 improves privacy of fn-less\n\u003e usage,\n\u003e \u003e while providing no real benefits to full node users (compared to more\n\u003e \u003e efficient protocols like Stratum/Electrum).\n\u003e \u003e\n\u003e \u003e For this reason, myself and a few others oppose merging support for BIP\n\u003e 157 in\n\u003e \u003e Core.\n\u003e\n\u003e BIP 157 can be implemented as a separate daemon that processes the blocks\n\u003e downloaded by an attached `bitcoind`, i.e. what Wasabi does.\n\u003e\n\u003e The intention, as I understood it, of putting BIP157 directly into\n\u003e bitcoind was to essentially force all `bitcoind` users to possibly service\n\u003e BIP157 clients, in the hope that a BIP157 client can contact any arbitrary\n\u003e fullnode to get BIP157 service.\n\u003e This is supposed to improve to the situation relative to e.g. Electrum,\n\u003e where there are far fewer Electrum servers than fullnodes.\n\u003e\n\u003e Of course, as ariard computes, deploying BIP157 could lead to an effective\n\u003e DDoS on the fullnode network if a large number of BIP157 clients arise.\n\u003e Though maybe this will not occur very fast? We hope?\n\u003e\n\u003e It seems to me that the thing that *could* be done would be to have\n\u003e watchtowers provide light-client services, since that seems to be the major\n\u003e business model of watchtowers, as suggested by ariard as well.\n\u003e This is still less than ideal, but maybe is better than nothing.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200505/be23bd38/attachment-0001.html\u003e",
"sig": "afe8e96d3a8abe8b2134c80f3110159da93fcd7ee58236f920c7f96beef9aa87af94f2a9c20ed728be76537c0b26e04cc439f9a8ee46f4b3a9076516a389da94"
}