- The integrity checking scheme is unified for two usecases of\r
- download and streaming. Also, it works down to the level of a\r
- single datagram by employing Merkle hash trees [MERKLE]. Peers\r
- receive chains of uncle hashes just in time to check the incoming\r
- data. As metadata is restricted to just a single root hash,\r
- newcomer peers derive the size of a file from hashes. That\r
- functionalities heavily depend on the concept of peak hashes,\r
- discussed in Sec. 4.4.1. Any specifics related to the cases of file\r
- download and streaming is discussed in Sec. 4.4.2, 4.4.3\r
- respectively.\r
-\r
- Here, we discuss the common part of the workflow. As a general\r
- rule, the sender SHOULD prepend data with hashes which are\r
- necessary for verifying that data, no more, no less. While some\r
- optimistic optimizations are definitely possible, the receiver\r
- SHOULD drop data if it is impossible to verify it. Before sending a\r
- packet of data to the receiver, the sender inspects the receiver's\r
- previous acknowledgments to derive which hashes the receiver\r
- already has for sure.\r
- Suppose, the receiver had acknowledged bin 1 (first two kilobytes\r
- of the file), then it must already have uncle hashes 5, 11 and so\r
- on. That is because those hashes are necessary to check packets of\r
- bin 1 against the root hash. Then, hashes 3, 7 and so on must be\r
- also known as they are calculated in the process of checking the\r
- uncle hash chain. Hence, to send bin 12 (i.e. the 7th kilobyte of\r
- data), the sender needs to prepend hashes for bins 14 and 9, which\r
- let the data be checked against hash 11 which is already known to\r
- message itself, i.e.:\r
-\r
- 04 00000009 F01234567890ABCDEF1234567890ABCDEF123456\r
+ The integrity checking scheme is unified for two usecases of download\r
+ and streaming. Also, it works down to the level of a single datagram\r
+ by employing Merkle hash trees [MERKLE]. Peers receive chains of\r
+ uncle hashes just in time to check the incoming data. As metadata is\r
+ restricted to just a single root hash, newcomer peers derive the size\r
+ of a file from hashes. That functionality heavily depends on the\r
+ concept of peak hashes, discussed in Sec. 4.4.1. Any specifics\r
+ related to the cases of file download and streaming is discussed in\r
+ Sec. 4.4.2 and 4.4.3, respectively.\r
+\r
+ Here, we discuss the common part of the workflow. As a general rule,\r
+ the sender SHOULD prepend data with hashes which are necessary for\r
+ verifying that data, no more, no less. While some optimistic\r
+ optimizations are definitely possible, the receiver SHOULD drop data\r
+ if it is impossible to verify it. Before sending a packet of data to\r
+ the receiver, the sender inspects the receiver's previous\r
+ acknowledgments to derive which hashes the receiver already has for\r
+ sure. Suppose, the receiver had acknowledged bin 1 (first two\r
+ kilobytes of the file), then it must already have uncle hashes 5, 11\r
+ and so on. That is because those hashes are necessary to check\r