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 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:
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