BIP 158: Compact Block Filters for Light Clients #12254

jimpo · 2018-01-24T01:42:05Z

This implements the compact block filter construction in BIP 158. The code is not used anywhere in the Bitcoin Core code base yet. The next step towards BIP 157 support would be to create an indexing module similar to TxIndex that constructs the basic and extended filters for each validated block.

Filter Sizes

Here is a CSV of filter sizes for blocks in the main chain.

As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks:

The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements.

The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios for blocks after height 150,000:

Stat	Filter Type
Weighted Size Ratio Mean	0.0198
Size Ratio Mean	0.0224
Size Ratio Std Deviation	0.0202
Mean Element Size (bits)	21.145
Approx Theoretical Min Element Size (bits)	21.025

meshcollider · 2018-01-24T01:57:41Z

Big Concept ACK, excited about this

laanwj · 2018-01-24T14:36:42Z

Should this be labeled consensus? This is a P2P change, right?

jimpo · 2018-01-24T17:09:36Z

@laanwj This is a data structure to be used in a P2P change. I first thought that it shouldn't be tagged "Consensus", but there's an argument to be made for it. It doesn't affect blockchain consensus, but it is kind of a softer P2P consensus change, where network clients (though not other full nodes) may disconnect/ban you if you serve incorrectly computed block filters. I'll let you make the call on the tag.

sipa · 2018-01-24T17:12:29Z

Any fork that can be resolved by a P2P adaptor that speaks both protocols is not a consensus change.

laanwj · 2018-01-24T17:19:23Z

This is a data structure to be used in a P2P change.

Thanks for the explanation. With "consensus" we mean the blockchain consensus rules code. Banning\disconnecting is a P2P level issue. So changing the label to P2P.

jonasschnelli · 2018-01-25T22:33:27Z

Great work @jimpo!
Big Concept ACK,... will help to get this done.

jonasschnelli · 2018-02-09T09:13:33Z

src/blockfilter.cpp

+        throw std::invalid_argument("N must be <2^32");
+    }
+
+    // Surface any errors decoding the filter on construction.


Not sure, but I guess that comments belongs to L113?

No, the idea is that the below lines fully decode the filter in the constructor so that any errors decoding get raised during construction rather than when it is first matched against. I'll elaborate on the comment.

jonasschnelli · 2018-02-09T09:46:28Z

Reviewed and tested a bit... nice, clean PR!
I would wish we had more test vectors...

Sjors · 2018-02-09T15:14:18Z

Concept ACK. Would it useful to add some (hidden) RPC commands so other developers can test it?

jimpo · 2018-02-09T18:15:09Z

@jonasschnelli Thanks for reviewing. The test vectors were generated from a Go program I have that cross-validates against the btcsuite implementation. I can easily add any specific testnet blocks to the list of cases. The blocks were chosen to exercise certain edge cases (eg. empty filters, duplicate pushdatas, invalid output scripts), but the vectors aren't commented with which edges cases they exercise. I'll add the comments, because it seems worthwhile.

@Sjors I'd definitely like to see RPC commands to fetch specific filters and filter headers, but I think it makes more sense to do that after adding the filter index, so that the RPC handlers just have to look up a precomputed filter/header. (So basically, in a subsequent PR).

ryanofsky

(edited 2018-08-17)

utACK a23681bd6382f44a1246bcdd430e6f54f71c1f99. Left minor comments (feel free to ignore). Overall code looks very good.

ryanofsky · 2018-03-15T18:29:54Z

src/streams.h

@@ -138,6 +138,80 @@ class CVectorWriter
    size_t nPos;
 };

+/* Minimal stream for reading from an existing vector by reference
+ */
+class CVectorReader


In commit "streams: Create CVectorReader stream interface for vectors." (93f702b08e413c5c025b155bfb62b721d27939f5)

This is pretty similar to the VectorReader class @TheBlueMatt is adding here: TheBlueMatt@bb608a9 for master...TheBlueMatt:2018-02-miningserver

Your implementation is more general with support for deserialization in the constructor and more complete comments. But his has a pos() method and uses non-hungarian names which are recommended by the contrib guide. Anyway you may want to incorporate some of his changes.

OK, I can bring that commit over instead or modify this one to remove the hungarian notation.

Agree, it would be nice to align the two implementations.

ryanofsky · 2018-03-15T18:34:53Z

src/streams.h

+private:
+    const int nType;
+    const int nVersion;
+    const std::vector<unsigned char>& vchData;


In commit "streams: Create CVectorReader stream interface for vectors." (93f702b08e413c5c025b155bfb62b721d27939f5)

It would be nice if this just had const unsigned char* and size_t members instead of a requiring a reference to an actual vector. That way the class could be used to efficiently deserialize from any memory location, and be compatible with other containers like std::string.

I'd rather not deal with raw pointers because it leaves space for unsafe accesses. If generality is a concern, I'd prefer a templated approach with random access iterators.

An alternative (which could be done later, not a blocker for this PR) is using the Span class that was introduced in #12886 and is being extended in #13062).

Re: #12254 (comment)

I think it would be good to change VectorReader to SpanReader now that Span exists. It would be a simple change, and better describe what this class does, and make it more reusable.

Sjors · 2018-03-15T19:07:04Z

@Sjors I'd definitely like to see RPC commands to fetch specific filters and filter headers, but I think it makes more sense to do that after adding the filter index, so that the RPC handlers just have to look up a precomputed filter/header. (So basically, in a subsequent PR).

Even a proof-of-concept PR for that would be useful for review.

jimpo · 2018-03-20T01:48:16Z

@Sjors Here is a branch that exposes an RPC for testing/playing around: https://github.com/jimpo/bitcoin/tree/bip158-rpc. Is not intended to be merged for reasons stated above.

ryanofsky · 2018-04-02T17:47:00Z

src/streams.h

+private:
+    IStream& m_istream;
+    uint8_t m_buffer;
+    int m_offset;


In commit "streams: Implement BitStreamReader/Writer classes."

Comment for m_offset would be helpful. Maybe //!< Number of high order bits in m_buffer already returned by previous Read() calls.

ryanofsky · 2018-04-02T17:57:11Z

src/streams.h


+public:
+    BitStreamReader(IStream& istream)
+        : m_istream(istream), m_buffer(0), m_offset(8) {}


In commit "streams: Implement BitStreamReader/Writer classes."

Would be nice to initialize m_buffer, m_offset above, where they are declared (see "Initialize all non-static class members where they are defined" guideline from https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md). Similarly in BitStreamWriter below.

Didn't know about that guideline. Will do.

ryanofsky · 2018-04-02T17:59:57Z

src/streams.h


+template <typename OStream>
+class BitStreamWriter


In commit "streams: Implement BitStreamReader/Writer classes."

Would be nice to add a simple unit test writing values to a stream with BitStreamWriter, and then making sure same values are returned from BitStreamReader.

Added in 5f67272f5a2d8567faf7b139c0239bc2788ed8b1.

ryanofsky · 2018-04-02T18:05:44Z

src/streams.h


+public:
+    BitStreamWriter(OStream& ostream)


In commit "streams: Implement BitStreamReader/Writer classes."

Would be good to add destructor either asserting m_offset == 0, or calling Flush(). Discarding bits that have been written but not flushed seems less safe than you might want as default behavior.

ryanofsky · 2018-04-02T18:10:47Z

src/streams.h

+private:
+    OStream& m_ostream;
+    uint8_t m_buffer;
+    int m_offset;


In commit "streams: Implement BitStreamReader/Writer classes."

Would add = 0; //!< Number of high-order bits in m_buffer that have been written but not yet flushed to the stream.

ryanofsky · 2018-04-02T19:31:35Z

src/blockfilter.h

+ * This implements a Golomb-coded set as defined in BIP 158. It is a
+ * compact, probabilistic data structure for testing set membership.
+ */
+class GCSFilter


In commit "blockfilter: Declare GCSFilter class for BIP 158 impl."

It seems cumbersome for this to be implemented as a class, since none of the class members can change after construction, and some of the stored state is redundant (m_F is derived from m_N and m_P), m_N is redundant with elements.size() and can be derived from m_encoded).

If this were a simple set of functions instead, like:

struct FilterParams { k0; k1; P; }; vector<char> BuildFilter(FilterParams, set<Elements>); bool FilterContains(FilterParams, vector<char>, Element); bool FilterContainsAny(FilterParams, vector<char>, set<Element>);

usage would be more obvious, and you could get rid of the current runtime throws and asserts checking for inconsistencies in the state.

I originally tried something like that, but I preferred to make it an actual class. I see the ability to store derivable data in private fields and check data consistency before using the data as features of this approach.

ryanofsky · 2018-04-02T19:39:04Z

src/blockfilter.cpp

+constexpr int GCS_SER_VERSION = 0;
+
+template <typename OStream>
+static void GolombRiceEncode(BitStreamWriter<OStream>& bitwriter, uint8_t k, uint64_t n)


In commit "blockfilter: Implement GCSFilter constructors."

Here and other places, N seems like it should be 32 bits instead 64.

Why do you say that? This function can encode 64-bit ints if it needs to. Also, it would have to immediately get cast to a uint64_t either way.

I don't understand this comment either.

RE: #12254 (comment)

I don't understand this comment either.

The comment was just attached in the wrong place. In 15d529dfc2b65f2badaa520799187aff103af2b6 m_N was uint64_t (fixed now).

ryanofsky · 2018-04-02T19:45:15Z

src/blockfilter.cpp

+template <typename OStream>
+static void GolombRiceEncode(BitStreamWriter<OStream>& bitwriter, uint8_t k, uint64_t n)
+{
+    // Write quotient as unary-encoded: q 1's followed by one 0.


In commit "blockfilter: Implement GCSFilter constructors."

I wonder if the optimization below actually buys anything over a more direct:

for (int i = 0; i < q; ++i) bitwriter.Write(1, 1);

ryanofsky · 2018-04-02T20:12:15Z

src/blockfilter.cpp

+    return false;
+}
+
+bool GCSFilter::MatchAny(const std::set<Element>& elements) const


In commit "blockfilter: Implement GCSFilter Match methods."

Would suggest implementing Match and MatchAny in terms of a common

Match(const uint64_t* sorted_element_hashes, size_t size)

method to get rid of all the code duplication between the existing methods. No outside code would need to change, they could just call

Match(&query, 1); Match(queries.data(), queries.size());

respectively.

Good suggestion.

practicalswift · 2018-04-15T06:19:50Z

Concept ACK

Nice work!

braydonf · 2018-04-17T01:20:09Z

Has there been any work yet on using this to implement BIP 157? I've worked on indexing in the past, and could take a look at implementing it.

sipa · 2018-04-17T01:30:56Z

src/blockfilter.cpp

+            }
+        }
+
+        // Include all data pushes in output scripts.


This does not seem up to date with the latest version of BIP158 (I'll review in full later).

sipa

Code review ACK.

I'm very skeptical about the usefulness of the extended filter, and don't think it should be implemented in Bitcoin Core until there is a clear use case, but that's perhaps a discussion to be had about the BIP itself.

sipa · 2018-05-12T19:34:24Z

src/streams.h

@@ -138,6 +138,80 @@ class CVectorWriter
    size_t nPos;
 };

+/* Minimal stream for reading from an existing vector by reference
+ */
+class CVectorReader


Agree, it would be nice to align the two implementations.

sipa · 2018-05-12T19:36:10Z

src/streams.h

+private:
+    const int nType;
+    const int nVersion;
+    const std::vector<unsigned char>& vchData;


An alternative (which could be done later, not a blocker for this PR) is using the Span class that was introduced in #12886 and is being extended in #13062).

sipa · 2018-05-12T19:54:16Z

src/streams.h

@@ -509,12 +509,102 @@ class CDataStream
    }
 };

+template <typename IStream>


In commit "streams: Implement BitStreamReader/Writer classes.", any reason to not make these operate with a 64-bit (or even larger) buffer? That would both simplify the code (no need to loop in the read/write operations) and possibly improve performance (due to fewer read/flush calls to the underlying buffer).

Perhaps could improve performance, but it'd be trickier to handle streams that are not aligned on 8-byte boundaries. Since the buffer size is an implementation detail, would you be OK leaving that optimization for a later PR?

Yeah, let's look at this later. It would complicate the reader indeed. For the writer I think it's pretty straightfoward.

Agree with @jimpo, used IStream and OStream should be buffered implementations, not this specific algo.

sipa · 2018-05-12T19:55:57Z

src/blockfilter.cpp

+constexpr int GCS_SER_VERSION = 0;
+
+template <typename OStream>
+static void GolombRiceEncode(BitStreamWriter<OStream>& bitwriter, uint8_t k, uint64_t n)


I don't understand this comment either.

sipa · 2018-05-12T19:57:45Z

src/blockfilter.cpp

+// See: https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/
+static uint64_t MapIntoRange(uint64_t x, uint64_t n)
+{
+    // To perform the calculation on 64-bit numbers without losing the


Perhaps add a note here to use unsigned __int128 on supported platforms; that should be significantly faster than doing 4 separate multiplications.

Fixed in 07df986.

sipa · 2018-05-12T20:07:54Z

src/blockfilter.cpp

+
+bool GCSFilter::MatchAny(const std::set<Element>& elements) const
+{
+    const std::vector<uint64_t>&& queries = BuildHashedSet(elements);


I don't think the reference type is useful here; copy elision should apply, and otherwise at worst a move will occur.

sipa · 2018-05-12T20:08:57Z

src/blockfilter.cpp

+        throw std::ios_base::failure("N must be <2^32");
+    }
+
+    // Verify that the encoded filter contains exactly N elements. If it has too much or too little


Is this worth it? The filter will be decoded twice in practice due to this?

I'll drop it if people prefer. I think having the constructor check its input makes for a better API. I'd also note that Core won't actually use these match methods unless it implements a light client mode -- they are just here for completeness and testing.

I expect we'll start using it for rescanning pretty quickly, regardless of protocol implementations.

Do you have any numbers for how fast it is to iterate through a 10000 element set or so?

Benchmarks added in f1b341a. Decoding a 10,000 element filter and matching against one missing element takes about 20us, and grows linearly in the number of elements (as expected).

practicalswift · 2018-08-27T15:30:13Z

src/streams.h

+    explicit BitStreamReader(IStream& istream) : m_istream(istream) {}
+
+    /** Read the specified number of bits from the stream. The data is returned
+     * in the nbits least signficant bits of a 64-bit uint.


Post-merge nit: "signficant" should be "significant".

This misspelling was automatically identified by codespell.

Automatic codespell checking is introduced in PR #13954. It warns (note: warn only, no build failure) when a PR introduces spelling errors. Please review :-)

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of #12254 by @TheBlueMatt. #12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

@ryanofsky

…terface fef5adc blockfilter: Use unordered_set instead of set in blockfilter. (Jim Posen) 4fb789e Extract CSipHasher to it's own file in crypto/ directory. (Jim Posen) Pull request description: Use `std::unordered_set` (hash set) instead of `std::set` (tree set) in blockfilter interface, as suggested by @ryanofsky in #12254. This may result in a very minor speedup, but I haven't measured. This moves `CSipHasher` to it's own file `crypto/siphash.h`, so that it can be used in the libbitcoin_util library without including `hash.{h,cpp}`. I'm open to other suggestions on solving this issue if people would prefer to leave CSipHasher where it is. Tree-SHA512: 593d1abda771e45f2860d5334272980d20df0b81925a402bb9ee875e17595c2517c0d8ac9c579218b84bbf66e15b49418241c1fe9f9265719bcd2377b0cd0d88

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

254c85b bench: Benchmark GCS filter creation and matching. (Jim Posen) f33b717 blockfilter: Optimization on compilers with int128 support. (Jim Posen) 97b64d6 blockfilter: Unit test against BIP 158 test vectors. (Jim Posen) a4afb9c blockfilter: Additional helper methods to compute hash and header. (Jim Posen) cd09c79 blockfilter: Serialization methods on BlockFilter. (Jim Posen) c1855f6 blockfilter: Construction of basic block filters. (Jim Posen) 53e7874 blockfilter: Simple test for GCSFilter construction and Match. (Jim Posen) 558c536 blockfilter: Implement GCSFilter Match methods. (Jim Posen) cf70b55 blockfilter: Implement GCSFilter constructors. (Jim Posen) c454f0a blockfilter: Declare GCSFilter class for BIP 158 impl. (Jim Posen) 9b622dc streams: Unit tests for BitStreamReader and BitStreamWriter. (Jim Posen) fe943f9 streams: Implement BitStreamReader/Writer classes. (Jim Posen) 87f2d9e streams: Unit test for VectorReader class. (Jim Posen) 947133d streams: Create VectorReader stream interface for vectors. (Jim Posen) Pull request description: This implements the compact block filter construction in [BIP 158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki). The code is not used anywhere in the Bitcoin Core code base yet. The next step towards [BIP 157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) support would be to create an indexing module similar to `TxIndex` that constructs the basic and extended filters for each validated block. ### Filter Sizes [Here](https://gateway.ipfs.io/ipfs/QmRqaAAQZ5ZX5eqxP7J2R1MzFrc2WDdKSWJEKtQzyawqog) is a CSV of filter sizes for blocks in the main chain. As you can see below, the ratio of filter size to block size drops after the first ~150,000 blocks: ![filter_sizes](https://user-images.githubusercontent.com/881253/42900589-299772d4-8a7e-11e8-886d-0d4f3f4fbe44.png) The reason for the relatively large filter sizes is that Golomb-coded sets only achieve good compression with a sufficient number of elements. Empirically, the average element size with 100 elements is 14% larger than with 10,000 elements. The ratio of filter size to block size is computed without witness data for basic filters. Here is a summary table of filter size ratios *for blocks after height 150,000*: | Stat | Filter Type | |-------|--------------| | Weighted Size Ratio Mean | 0.0198 | | Size Ratio Mean | 0.0224 | | Size Ratio Std Deviation | 0.0202 | | Mean Element Size (bits) | 21.145 | | Approx Theoretical Min Element Size (bits) | 21.025 | Tree-SHA512: 2d045fbfc3fc45490ecb9b08d2f7e4dbbe7cd8c1c939f06bbdb8e8aacfe4c495cdb67c820e52520baebbf8a8305a0efd8e59d3fa8e367574a4b830509a39223f

@TheBlueMatt

f055995 blockfilter: Omit empty scripts from filter contents. (Jim Posen) Pull request description: Caught during review of bitcoin#12254 by @TheBlueMatt. bitcoin#12254 (comment) Tree-SHA512: cfc9e3eeaba12a14fd3d2e1ccce1a1f89e8cf44cc340ceec05d2d5fa61d27ff64e355603f4ad2184ff73c0ed23dfdab6e2103bddc48f3b76cb13b88d428770ac

fanquake added the Consensus label Jan 24, 2018

laanwj added P2P and removed Consensus labels Jan 24, 2018

jonasschnelli mentioned this pull request Feb 9, 2018

Compact Client Side Filtering for Light Clients (Neutrino server-side support) #11863

Closed

jonasschnelli reviewed Feb 9, 2018

View reviewed changes

jimpo force-pushed the bip-158 branch 3 times, most recently from 69f0acd to 68777c5 Compare March 12, 2018 16:01

ryanofsky reviewed Mar 15, 2018

View reviewed changes

ryanofsky reviewed Apr 2, 2018

View reviewed changes

sipa reviewed Apr 17, 2018

View reviewed changes

jimpo force-pushed the bip-158 branch from 68777c5 to 6bf7e0b Compare April 17, 2018 09:27

lontivero mentioned this pull request Apr 23, 2018

Light client p2p protocol MetacoSA/NBitcoin#401

Merged

jimpo force-pushed the bip-158 branch 3 times, most recently from 6e4d41a to 69f0b12 Compare May 1, 2018 07:31

sipa reviewed May 12, 2018

View reviewed changes

This was referenced Aug 26, 2018

blockfilter: Avoid out-of-bounds script access. #14073

Merged

Use std::unordered_set instead of set in blockfilter interface #14074

Merged

practicalswift mentioned this pull request Aug 27, 2018

Warn (don't fail!) on spelling errors. Fix typos reported by codespell. #13954

Merged

practicalswift reviewed Aug 27, 2018

View reviewed changes

Bushstar mentioned this pull request Sep 4, 2018

commits from bitcoin/master FeatherCoin/Feathercoin#359

Merged

oscarguindzberg mentioned this pull request Dec 12, 2018

Feasibility for replacing Bitcoinj with Bitcoin Core SPV bisq-network/bisq#1062

Closed

markblundeberg mentioned this pull request Apr 10, 2019

CF filtering outpoints vs scriptpubkeys gcash/bchd#205

Closed

PastaPastaPasta mentioned this pull request Apr 16, 2020

Backport 12254 and 14073 (BIP158) dashpay/dash#3416

Merged

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021

BIP 158: Compact Block Filters for Light Clients #12254

BIP 158: Compact Block Filters for Light Clients #12254

Conversation

jimpo commented Jan 24, 2018 • edited Loading

Filter Sizes

meshcollider commented Jan 24, 2018

laanwj commented Jan 24, 2018

jimpo commented Jan 24, 2018 • edited Loading

sipa commented Jan 24, 2018

laanwj commented Jan 24, 2018

jonasschnelli commented Jan 25, 2018

Choose a reason for hiding this comment

jimpo Feb 9, 2018 • edited Loading

Choose a reason for hiding this comment

jonasschnelli commented Feb 9, 2018

Sjors commented Feb 9, 2018 • edited Loading

jimpo commented Feb 9, 2018 • edited Loading

ryanofsky left a comment • edited Loading

Choose a reason for hiding this comment

ryanofsky Mar 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanofsky Aug 15, 2018 • edited Loading

Choose a reason for hiding this comment

Sjors commented Mar 15, 2018

jimpo commented Mar 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

practicalswift commented Apr 15, 2018

braydonf commented Apr 17, 2018

Choose a reason for hiding this comment

jimpo Apr 17, 2018 • edited Loading

Choose a reason for hiding this comment

sipa left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimpo May 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimpo commented Jan 24, 2018 •

edited

Loading

jimpo commented Jan 24, 2018 •

edited

Loading

jimpo Feb 9, 2018 •

edited

Loading

Sjors commented Feb 9, 2018 •

edited

Loading

jimpo commented Feb 9, 2018 •

edited

Loading

ryanofsky left a comment •

edited

Loading

ryanofsky Mar 15, 2018 •

edited

Loading

ryanofsky Aug 15, 2018 •

edited

Loading

jimpo commented Mar 20, 2018 •

edited

Loading

jimpo Apr 17, 2018 •

edited

Loading

sipa left a comment •

edited

Loading

jimpo May 14, 2018 •

edited

Loading