rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2018-06-01 📝 Original message: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]