📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 4:59 PM, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> Yea I generally would really prefer something like that but it
> significantly complicates the download logic - currently clients can
> easily cross-check [...] Maybe
> there is some other reasonable download logic to replace it with, however.
I think lite clients cross checking is something which very likely
will never be implemented by anyone, and probably not stay working
(due to under-usage) if it is implemented. This thought is driven by
three things (1) the bandwidth overhead of performing the check, (2)
thinking about the network-interacting-state-machine complexity of it,
and by the multitude of sanity checks that lite clients already don't
implement (e.g. when a lite client noticed a split tip it could ask
peers for the respective blocks and check at least the stateless
checks, but none has ever done that), and...
(3) that kind of checking would be moot if the filters were committed
and validated... and the commitment would be both much simpler to
check for lite clients and provide much stronger protection against
malicious peers.
My expectation is that eventually one of these filter-map designs
would become committed-- not after we already had it deployed and had
worked out the design to the n-th generation (just as your proposed
revisions are doing to the initial proposal), but eventually.
Also, even without this change clients can still do that "are multiple
peers telling me the same thing or different things" kind of checking,
which I expect is the strongest testing we'd actually see them
implement absent a commitment.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 18:12:12
in reply to nevent1q…q9pp
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 18:12:12Event JSON
{
"id": "befdab5ef328ee125fdc2f90e480af567d5ad00383f2eb96e2e41cf304ec4d20",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686161532,
"kind": 1,
"tags": [
[
"e",
"aefee7e3913729b7ef736d47c6f2a24954de10011f27b89dcaeaac62c51b6a6f",
"",
"root"
],
[
"e",
"90811b693dfbcb5901089eaeb5b52fa01ce9c219fcff996d560cfa3f4bb6ea4a",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-05-17\n📝 Original message:On Thu, May 17, 2018 at 4:59 PM, Matt Corallo \u003clf-lists at mattcorallo.com\u003e wrote:\n\u003e Yea I generally would really prefer something like that but it\n\u003e significantly complicates the download logic - currently clients can\n\u003e easily cross-check [...] Maybe\n\u003e there is some other reasonable download logic to replace it with, however.\n\nI think lite clients cross checking is something which very likely\nwill never be implemented by anyone, and probably not stay working\n(due to under-usage) if it is implemented. This thought is driven by\nthree things (1) the bandwidth overhead of performing the check, (2)\nthinking about the network-interacting-state-machine complexity of it,\nand by the multitude of sanity checks that lite clients already don't\nimplement (e.g. when a lite client noticed a split tip it could ask\npeers for the respective blocks and check at least the stateless\nchecks, but none has ever done that), and...\n\n(3) that kind of checking would be moot if the filters were committed\nand validated... and the commitment would be both much simpler to\ncheck for lite clients and provide much stronger protection against\nmalicious peers.\n\nMy expectation is that eventually one of these filter-map designs\nwould become committed-- not after we already had it deployed and had\nworked out the design to the n-th generation (just as your proposed\nrevisions are doing to the initial proposal), but eventually.\n\nAlso, even without this change clients can still do that \"are multiple\npeers telling me the same thing or different things\" kind of checking,\nwhich I expect is the strongest testing we'd actually see them\nimplement absent a commitment.",
"sig": "fbddf82804d42f7b9104508adc2e90d082851d3e49d645bbdf5dbcf72bb42b0906bac41fe2504d7288b404948acf21dc5df18ec85844edea9b6e705448b781f3"
}