📅 Original date posted:2018-06-01
📝 Original message:To address the at-least-one-honest peer security assumption for light
clients, I think this is a rather good security model for light clients.
First it significantly reduces the chances that an attacker can eclipse a
client just by chance, and clients can implement measures like ensuring
connectivity to peers from different subnets. But even if, as you suggest,
a network attacker controls the target's local network, peers still can
have good security guarantees by requiring authenticated connections to
semi-trusted peers. A client can select a set of N servers that it believes
will not collude to attack it, and only sync filters if connected to a
threshold of them. So even if the network is malicious, the attacker cannot
forge the authenticated responses. The level of trust in these designated
parties again is quite low because only one has to be honest. This would
require something like BIP 150.
Even if clients are uncomfortable with whitelisting required peers, it
could have a policy of requiring a certain number of connections to peers
that have honestly served it filters in the past. This is sort of like
trust-on-first-use. This type of scheme, however, would require nodes to
advertise a pubkey per address, which BIP 150/151 does not support at
present.
All in all, I think this is an acceptable security model for light clients.
Without the ability to verify filter validity, a client would have to stop
syncing altogether in the presence of just one malicious peer, which is
unacceptable.
The other concern you raise, Greg, is using a filter for P2P communications
that we expect may be replaced in the future. You also raise the point that
full node wallets can use the smaller filters for rescans because the
filter validity is not in question. I'd perfectly fine with the idea of
defining two filter types in the BIP, one that is output script + outpoint
and the other output script + prev script. But I imagine some people would
object to the idea of full nodes storing two different filters that overlap
in contents. If we had to pick just one though, I'm strongly in support of
output script + outpoint so that BIP 157 can be deployed ASAP without a
consensus change. It's entirely possible we will learn even more about
optimal filter design through deployment and adoption.
On Fri, Jun 1, 2018 at 5:22 PM Gregory Maxwell <greg at xiph.org> wrote:
> On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
> >> A typical network attacker (e.g. someone on your lan or wifi segmet, or
> >> someone who has compromised or operates an upstream router) can be all
> of
> >> your peers.
> >
> > This is true, but it cannot make us accept any invalid filters unless the
> > attacker is also creating invalid blocks w/ valid PoW.
>
> I wish that were the true, but absent commitments that wouldn't be the
> case unless you were always downloading all the blocks-- since you
> wouldn't have any sign that there was something wrong with the
> filter-- and downloading all the blocks would moot using the filters
> in the first place. :)
>
> Or have I misunderstood you massively here?
>
> For segwit originally I had proposed adding additional commitments
> that would make it possible to efficiently prove invalidity of a
> block; but that got stripped because many people were of the view that
> the "assume you have at least one honest peer who saw that block and
> rejected it to tell you that the block was invalid" security
> assumption was of dubious value. Maybe it's more justifiable to make
> use of a dubious assumption for a P2P feature than for a consensus
> feature? Perhaps, I'd rather have both filter types from day one so
> that things not implementing the comparison techniques don't get the
> efficiency loss or the extra work to change filter types for a
> consensus one.
>
> [I think now that we're much closer to a design that would be worth
> making a consensus committed version of than we were a few months ago
> now, since we are effectively already on a second generation of the
> design with the various improvements lately]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180601/b99c927d/attachment-0001.html>;
Jim Posen [ARCHIVE] /
npub1nc…lqt2n
2023-06-07 18:12:38
in reply to nevent1q…4t68
Author Public Key
npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2nPublished at
2023-06-07 18:12:38Event JSON
{
"id": "9d2137061a9fad31e68e0cffbe8db66781400078aa393eed4479a0cc685cd717",
"pubkey": "9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1",
"created_at": 1686161558,
"kind": 1,
"tags": [
[
"e",
"51a146fc69b159388af76f4dbc680a6d56f40357ab923d85aeb4f302294e74e6",
"",
"root"
],
[
"e",
"74628039f0dd99761fc3a2868a0f99d6f1b93ea57dddc05a2fd555db4a0b23e9",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-06-01\n📝 Original message:To address the at-least-one-honest peer security assumption for light\nclients, I think this is a rather good security model for light clients.\nFirst it significantly reduces the chances that an attacker can eclipse a\nclient just by chance, and clients can implement measures like ensuring\nconnectivity to peers from different subnets. But even if, as you suggest,\na network attacker controls the target's local network, peers still can\nhave good security guarantees by requiring authenticated connections to\nsemi-trusted peers. A client can select a set of N servers that it believes\nwill not collude to attack it, and only sync filters if connected to a\nthreshold of them. So even if the network is malicious, the attacker cannot\nforge the authenticated responses. The level of trust in these designated\nparties again is quite low because only one has to be honest. This would\nrequire something like BIP 150.\n\nEven if clients are uncomfortable with whitelisting required peers, it\ncould have a policy of requiring a certain number of connections to peers\nthat have honestly served it filters in the past. This is sort of like\ntrust-on-first-use. This type of scheme, however, would require nodes to\nadvertise a pubkey per address, which BIP 150/151 does not support at\npresent.\n\nAll in all, I think this is an acceptable security model for light clients.\nWithout the ability to verify filter validity, a client would have to stop\nsyncing altogether in the presence of just one malicious peer, which is\nunacceptable.\n\nThe other concern you raise, Greg, is using a filter for P2P communications\nthat we expect may be replaced in the future. You also raise the point that\nfull node wallets can use the smaller filters for rescans because the\nfilter validity is not in question. I'd perfectly fine with the idea of\ndefining two filter types in the BIP, one that is output script + outpoint\nand the other output script + prev script. But I imagine some people would\nobject to the idea of full nodes storing two different filters that overlap\nin contents. If we had to pick just one though, I'm strongly in support of\noutput script + outpoint so that BIP 157 can be deployed ASAP without a\nconsensus change. It's entirely possible we will learn even more about\noptimal filter design through deployment and adoption.\n\nOn Fri, Jun 1, 2018 at 5:22 PM Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\u003e A typical network attacker (e.g. someone on your lan or wifi segmet, or\n\u003e \u003e\u003e someone who has compromised or operates an upstream router) can be all\n\u003e of\n\u003e \u003e\u003e your peers.\n\u003e \u003e\n\u003e \u003e This is true, but it cannot make us accept any invalid filters unless the\n\u003e \u003e attacker is also creating invalid blocks w/ valid PoW.\n\u003e\n\u003e I wish that were the true, but absent commitments that wouldn't be the\n\u003e case unless you were always downloading all the blocks-- since you\n\u003e wouldn't have any sign that there was something wrong with the\n\u003e filter-- and downloading all the blocks would moot using the filters\n\u003e in the first place. :)\n\u003e\n\u003e Or have I misunderstood you massively here?\n\u003e\n\u003e For segwit originally I had proposed adding additional commitments\n\u003e that would make it possible to efficiently prove invalidity of a\n\u003e block; but that got stripped because many people were of the view that\n\u003e the \"assume you have at least one honest peer who saw that block and\n\u003e rejected it to tell you that the block was invalid\" security\n\u003e assumption was of dubious value. Maybe it's more justifiable to make\n\u003e use of a dubious assumption for a P2P feature than for a consensus\n\u003e feature? Perhaps, I'd rather have both filter types from day one so\n\u003e that things not implementing the comparison techniques don't get the\n\u003e efficiency loss or the extra work to change filter types for a\n\u003e consensus one.\n\u003e\n\u003e [I think now that we're much closer to a design that would be worth\n\u003e making a consensus committed version of than we were a few months ago\n\u003e now, since we are effectively already on a second generation of the\n\u003e design with the various improvements lately]\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180601/b99c927d/attachment-0001.html\u003e",
"sig": "715144507aed7db859d43173c18ac925ea727f760861f1fffeefbf581fc90bfaa3c391e75b640b9a3c995f631c586b7c8fb116929a997f0ac9cefb18ae6b9704"
}