Tomas wrote: > A rough estimate would indicate this to be about 2-2.5x as big per block > as your proposal, but comes with rather different security > characteristics, and would not require download since genesis.
Our proposal _doesnt_ require downloading from genesis, if by "downloading" you mean downloading all the blocks. Clients only need to sync the block+filter headers, then (if they don't care about historical blocks), will download filters from their "birthday" onwards. > The client could verify the TXIDs against the merkle root with a much > stronger (PoW) guarantee compared to the guarantee based on the assumption > of peers being distinct, which your proposal seems to make Our proposal only makes a "one honest peer" assumption, which is the same as any other operating mode. Also as client still download all the headers, they're able to verify PoW conformance/work as normal. > I don't completely understand the benefit of making the outpoints and > pubkey hashes (weakly) verifiable. These only serve as notifications and > therefore do not seem to introduce an attack vector. Not sure what you mean by this. Care to elaborate? > I think client-side filtering is definitely an important route to take, > but is it worth compressing away the information to verify the merkle > root? That's not the case with our proposal. Clients get the _entire_ block (if they need it), so they can verify the merkle root as normal. Unless one of us is misinterpreting the other here. -- Laolu On Thu, Jun 8, 2017 at 6:34 AM Tomas via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote: > > Hi y'all, > > Alex Akselrod and I would like to propose a new light client BIP for > consideration: > * > https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki > > > > Very interesting. > > I would like to consider how this compares to another light client type > with rather different security characteristics where each client would > receive for each transaction in each block, > > * The TXID (uncompressed) > * The spent outpoints (with TXIDs compressed) > * The pubkey hash (compressed to reasonable amount of false positives) > > A rough estimate would indicate this to be about 2-2.5x as big per block > as your proposal, but comes with rather different security characteristics, > and would not require download since genesis. > > The client could verify the TXIDs against the merkle root with a much > stronger (PoW) guarantee compared to the guarantee based on the assumption > of peers being distinct, which your proposal seems to make. Like your > proposal this removes the privacy and processing issues from server-side > filtering, but unlike your proposal retrieval of all txids in each block > can also serve for a basis of fraud proofs and (disprovable) fraud hints, > without resorting to full block downloads. > > I don't completely understand the benefit of making the outpoints and > pubkey hashes (weakly) verifiable. These only serve as notifications and > therefore do not seem to introduce an attack vector. Omitting data is > always possible, so receiving data is a prerequisite for verification, not > an assumption that can be made. How could an attacker benefit from "hiding > notifications"? > > I think client-side filtering is definitely an important route to take, > but is it worth compressing away the information to verify the merkle root? > > Regards, > Tomas van der Wansem > bitcrust > > _______________________________________________ > 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
