Implement logs bloom filters / minor fix RPC API, tx pool #130
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
keccakState
interface fromtrie
package tocrypto
for bloom types to useAdd()
,Test()
, andTestBytes()
, make these function take[]byte
instead of abig.Int
.Bloom.Add()
takes a big.Integer, then callsd.Bytes()
to get a byte representation of the integer. It then hashes that byte representation, and uses the hash to populate the bloom filter. The problem is that if your value is an address, integer, or some other value that doesn't occupy the full 32 bytes, it gets truncated to the number of bytes that it has, and a hash of a truncated value is different than a hash of the same value with leading 0's.So, for example, if I tried to add the value
0x000000000000000000000000000000000000000000000001a055690d9db80000
to my bloom filter usingbloom.Add(value)
, the value that got hashed would actually be0x01a055690d9db80000
.The
bloom.Test()
function does the same thing, as doesbloom.TestBytes()
. So if I have a Bloom filter that properly entered the topic0x000000000000000000000000000000000000000000000001a055690d9db80000
as a 32 byte topic, and I runbloom.TestBytes(value)
(where value is the bytes corresponding to the above topic), it will truncate the value before hashing and end up returning false.It seems that neither of these functions are actually used by Geth. Bloom filters are created with
CreateBloom()
, which doesn't use.Add()
, and tested withBloomLookup()
which doesn't useTest
orTestBytes
. BothCreateBloom()
andBloomLookup()
treat 32 byte topics properly, but the corresponding BloomFilter functions do not.