BUIP010 (passed): Xtreme Thinblocks

[Peter Tschipper]

@awemany Such an attack would be very weak IMO just for the sake of slowing down p2p. We have right now about 97.5% compression average at best. Having to re-request a thinblock would only take another 4-6% average off the top so let's say 90% at worst compression..still pretty good i think. Another way to look at it is that if we have a normal xthin around 15KB then a thinblock re-request will be 60KB thereabouts...making 75KB plus any missing tx's...for a 1MB block.

 

[awemany]

@Peter Tschipper: I think the point here is to think along the lines of 'defense in depth'. It would change relatively little code and add relatively little complexity but add the belt and suspenders to the efficient transmission code.

Another point is that it prevents Greg from using it to do his unfair propaganda.

 

[Peter Tschipper]

@awemany yeah, point taken, i just meant to say we're not under any immediate danger here...but it sounds like the voices of our group and wanting to move in that direction. So what i propose is to just wait and see what Core comes up with...looks like they are going to use siphash which i believe they just merged...i'm a little unclear reading their BIP, but i think they plan on hashing the tx id's along with the block hash and nonce. So we can leverage that in the *near* future but right now I have other items on my plate that i need to work on first, i think...bloom filter tuning is primary, bloom filter DOS, identify fast downloaders, headers first and then finish datastream compression hopefully all for the next release and then maybe slip in salting tx id's.

if another developer wants to take on salting the tx id's they are welcome to do it. Just keep in mind to keep it backwardly compatible with current XTHIN clients.

 

[Chronos]

Does XTHIN use a K-value (number of hash functions) of 1 for its Bloom filter? See https://en.wikipedia.org/wiki/Bloom_filter.

 

[Peter Tschipper]

@Chronos The number of hash function is determined by the false positive rate. In the new targeted bloom filter code we start with a false positive rate of 0.0001 and slowly over time increase that to 0.005

* The ideal number of hash functions is filter size * ln(2) / number of elements

with filter size determined by

-1 / LN2SQUARED * nElements * log(nFPRate)) / 8

so as the fprate changes so does the number of hash functions as well as the size of the filter. Generally speaking when we start with a 0.0001 fprate, the bloom filter size in bytes will be about 2.5 times the number of elements falling to about 1.2 times when we hit an fprate 0.005.

So to answer your question, no k is not 1...it is determined dynamically based on the fprate chosen and the num elements to be added to the filter.

 

[Chronos]

Thanks for the detailed and helpful reply.

 

[Chronos]

One more quick question: is this now implemented in Bitcoin XT? Or being worked on?

 

[Peter Tschipper]

@Chronos They have merged it in i believe but it hasn't been released yet...@dagurval would know the answer to that.

 

[Chronos]

It looks like it was just added to release 0.11F. Awesome!