<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>The Bloom Tree · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2002.03057/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2002.03057/feed.xml" rel="self" type="application/rss+xml" /><item><title>The Bloom Tree — mentioned by sitkack</title><link>https://news.ycombinator.com/item?id=28014965</link><guid isPermaLink="false">urn:hackerpapers:mention:2002.03057:28014965</guid><pubDate>Sat, 31 Jul 2021 03:20:28 GMT</pubDate><description>&lt;p&gt;I realize I wasn&amp;#x27;t clear. I used 2 sqlite databases just to store the article titles and offsets into binary files (&amp;lt;2GB) that had chunks of compressed data. Each chunk contained 10s-100s of stories, so that the decompressed around was around 20megs I believe. I had planned to store everything in sqlite, but there were too many issues. The FTS extension to sqlite is excellent, it made whole classes of problems literally melt away. Recalling now, the article text itself, I stored in groups of articles concatenated together so that that data compression could take advantage of similar texts.…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2002.03057/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>The Bloom Tree — mentioned by krcz</title><link>https://news.ycombinator.com/item?id=22374343</link><guid isPermaLink="false">urn:hackerpapers:mention:2002.03057:22374343</guid><pubDate>Thu, 20 Feb 2020 11:39:29 GMT</pubDate><description>&lt;p&gt;You still need one hash for every non-leaf node, so 30-40 hashes of 256 bits each. What this algorithm saves is 30-40 indices, which is 11 bits each for a 1000-leaf tree. Even aligning to 16 bits it&amp;#x27;s doesn&amp;#x27;t seem a great optimization. Unless I misunderstood something and we are not trying to minimize the size of whole proof, but just its structure - but I see no reason why it could be useful. But I can see there are two other papers: one on distributed Bloom filters [1] and the other on Bloom trees [2], maybe these can shed some light on it, I&amp;#x27;ll check later today. [1]…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2002.03057/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>The Bloom Tree — HN submission</title><link>https://news.ycombinator.com/item?id=22298020</link><guid isPermaLink="false">urn:hackerpapers:submission:2002.03057:22298020</guid><pubDate>Tue, 11 Feb 2020 12:48:25 GMT</pubDate><description>&lt;p&gt;The Bloom Tree&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;11 points; 3 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/2002.03057/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item></channel></rss>
