bao

In addition to loeg's point about timing, I'll add that BLAKE3 has its own internal tree structure. It would be unfortunate to have two tree structures layered on top of one another, both because it's "ugly" and because it won't do as good a job of parallelizing things. However, unifying the tree structures would be a big commitment. Every detail of the layout would need to be exactly as it is in BLAKE3. There wouldn't be any space for custom metadata on interior tree nodes, for example. I'm not familiar with the protocol details of BitTorrent myself, but I wouldn't be surprised if that unified approach turned out to be too limiting. (But for a file/tree project that does use the exact BLAKE3 structure, see github.com/oconnor663/bao.)

It's the set of parent nodes on the path from the root to the chunk(s), plus the chunks themselves. Parent nodes contain the hashes / chaining values of their two children, so you could also think of this as including sibling hashes. For example, consider this tree representing a 4 KiB file: root / \ parent1 parent2 / \ / \ chunk1 chunk2 chunk3 chunk4 Say we build a slice containing only chunk2. The contents of that slice will be: [4096][root][parent1][chunk2] The parent node parent1 is [hash of chunk1][hash of chunk2], and the root node is [hash of parent1][hash of parent2]. The 8-byte total length on the front (4096) is the same as in the full encoding; it defines the structure of the tree, so the decoder knows how many parent nodes to expect. For mo

If you squint at it, there's also a Python implementation here: https://github.com/oconnor663/bao/blob/master/tests/bao.py. But it's far too slow to use it for anything besides testing.

Verified streaming is implemented by https://github.com/oconnor663/bao.