1. #Cjdns Domain Name System
2.  
3. *The unnamable is the eternally real. Naming is the origin of all particular things.*
4.  
5. ##Requirements
6.  
7. r0: *must not fork* this is of critical importance, if a wxyz goes to 1.2.3.4 here it must
8. also goto 1.2.3.4 over there. We must have an anti-fork logic, in simple terms, all honest nodes
9. must be able to come to agreement on the truth even if that truth is wrong.
10. There have been some suggestions of "trust based systems" and also people talked about just
11. dishonering ICE/US.gov dns takedowns. Those things were never implemented because they violate
12. the fundamental rule of names, they must always be the same.
13.  
14. r1: Name hijacking must be impossible (or as close to it as is feasible)
15. We can't have people going around taking someone else's name because they don't like them, by
16. technical means (haxxors), or by social/political means (government, angry.com, etc)
17.  
18. 21:57 <@ircerr> did you miss r2?
19. 21:57 <@cjd> indeed
20. 21:57 <@cjd> we'll leave it for extensibility
21.  
22. r3: it needs to be fast if it's not fast then people will not use it. Fast is sub-100-milliseconds.
23. cjdns network code will improve but we must not rely on underlying technologies improving,
24. this needs to be fast out of the box or it's dead in the water.
25.  
26. r4: It must be difficult to take more domains than you need but easy to take enough for your needs.
27. Problem with bitcoin/dns is that it's fixed rate so at first noone wants it because it's all
28. experimental and it costs money because telling a geek to pay money for the privilege of fooling
29. around with a new system is like telling him to kill a kitten. Once it gets off the ground,
30. all the sudden it doesn't cost enough and people are scrambling to vacuum up all of the domains.
31.  
32. r5: Any "hot" signing key which needs to be on a live server must be revokable and replaceable
33. using an offline key. TLDs should be able to have multiple offline keys which need a quorum to
34. change the hot key.
35.  
36. r6: Simplicity of installation and configuration. It is a lot to ask the user "who do you trust",
37. asking "how do I find X" is too much.
38.  
39.  
40.  
41. ##Implementation Proposal
42.  
43. I propose a system whereby each TLD is a root signing key, users install the key for a TLD thus
44. trusting the TLD (similar to how users trust certificate authorities). Each TLD is a central
45. authority which has the power to intelligently fulfill r4. In order to best provide for r1 despite
46. central authorities, we must make these central authorities as powerless as possible.
47.  
48. I propose domain signatures be notarized using spam BTC transactions so that the world knows they
49. are there and nobody, even the TLD, can "ninja transfer" them (see: [Security Considerations]).
50. All registrations should expire after a set amount of time which can conveniently be measured in
51. BTC blocks so everyone can agree on when the change occurs.
52. r3 means there will need to be a lot of caches, like the clients, these must only accept domains
53. for the TLDs which are authorized by the cache owner.
54.  
55. To fulfill r3, clients must be able to prove validity of information given to them from a cache
56. with a minimum of stored data. By making clients hold only the block headers back from the current
57. one to the last one which could possibly hold a valid domain registration, the cache can show proof
58. of the registration's validity through a merkle branch. A year of headers occupies about 5MB of
59. space.
60.  
61. In order to intelligently implement r5, it makes sense that TLD operators should hold multiple
62. keys and a quorum of signatures should be required to make a change to the TLD's hot domain
63. signing key. TLD operators must *not* be able to add or remove other keys for their TLD.
64. The idea of TLD operators being able to maintain their TLD master keys for perpetuity is
65. intoxicating but the prospect of feuds inside of the group is devastating whereas the need to
66. remove a lost key or add a new member to the group is relatively small and in the worst cases
67. (50% of the keys are lost or compromised), new updates can be advertized which authorize new keys.
68.  
69. r6 requires that there be as little manual configuration as possible. I propose a peer-to-peer
70. design where cache nodes gossip new BTC block headers and domains amongst each other and introduce
71. clients and caches to other caches.
72.  
73.  
74.  
75. ##Domain Lifecycle
76.  
77. 1. Webmaster registers a domain linking a name to one or more ip addresses of his nameservers
78. and authorizing a master key to make changes to that domain.
79.  
80. 2. Webmaster maintains domain by re-registering using master key to sign the registration.
81.  
82. 3. Webmaster changes nameserver ip addresses linked to the name by way of re-registration.
83.  
84. 4. Webmaster abandons domain by not re-registering it, after a dormant period, the domain becomes
85. available to new registrations.
86.  
87. 5. Webmaster loses his master key and applies to the TLD operator to be able to re-register his
88. domain. When expires and becomes registrable by anyone, TLD operator holds out allowing others to
89. register it in order to get webmaster's domain back. Webmaster's domain is down for the 7 day
90. blackout period.
91.  
92. 6. Webmaster forgets about maintaining his domain, domain enters blackout period, webmaster
93. has some time to re-register before domain becomes registrable by anyone.
94.  
95.  
96.  
97.  
98. ##Details
99.  
100. After a per-TLD defined amount of time following the time when a domain was registered, the
101. domain will become inaccessible, this amount of time is defined by `Domain Validity Period` in
102. the TLD META Information. After a second amount of time, known as `Domain Blackout Period` the
103. domain may be registered by parties other than it's original owner.
104. (See: [TLD Identifier and META Information] )
105.  
106. Registering a domain happens by hashing a domain entry and having the TLD operator sign the hash.
107. This allows the TLD operator to choose to remain ignorant of the actual domain so they can ensure
108. that if external pressure is placed on them to not re-register a particular domain, it is obvious
109. as they are forced to abandon the hash signing policy.
110.  
111. To register a domain, a TLD operator signs a hash of the domain entry then from a batch of entries,
112. creates a Merkle tree and makes a trivially small Bitcoin payment to a Bitcoin wallet address
113. derived from root of the Merkle tree thus notarizing the entry.
114.  
115. A domain is valid if all of the following are true:
116. 1. Contains a valid signature from TLD operators key.
117. 2. A Merkle branch is known which hashes back to an accepted Bitcoin block header.
118. 3. Domain is less than `Domain Validity Period` BTC blocks old.
119. 4. No known valid domain with the same name is older by less than `Domain Validity Period`
120. PLUS `Domain Blackout Period` blocks unless it's key is the one which signed this domain entry.
121. 5. No known valid domain with the same name is newer.
122.  
123.  
124.  
125. ##Domain entry
126.  
127.                           1               2               3
128.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
129.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
130.        0 |                                                               |
131.          +                                                               +
132.        4 |           First 12 bytes of SHA-256 of domain name            |
133.          +                                                               +
134.        8 |                                                               |
135.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
136.       12 |    Version    |        Entry Metadata (version specific)      |
137.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
138.       16 |                                                               |
139.          +                                                               +
140.       20 |                                                               |
141.          +                                                               +
142.       24 |                                                               |
143.          +                                                               +
144.       28 |                     32 Byte Entry Body                        |
145.          +                Content is version specific                    +
146.       32 |                                                               |
147.          +                                                               +
148.       36 |                                                               |
149.          +                                                               +
150.       40 |                                                               |
151.          +                                                               +
152.       44 |                                                               |
153.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
154.       48 |                                                               |
155.          +                                                               +
156.       52 |                                                               |
157.          +                                                               +
158.       56 |                                                               |
159.          +                                                               +
160.       60 |         32 Byte Re-Registration/Transfer Signing Key          |
161.          +                                                               +
162.       64 |                                                               |
163.          +                                                               +
164.       68 |                                                               |
165.          +                                                               +
166.       72 |                                                               |
167.          +                                                               +
168.       76 |                                                               |
169.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
170.       80 |                                                               |
171.          +                                                               +
172.       84 |                                                               |
173.          +                                                               +
174.       88 |                                                               |
175.          +                                                               +
176.       92 |              Re-Registration/Transfer Signature               |
177.          +                 Undefined if not applicable.                  +
178.       96 |                                                               |
179.          +                                                               +
180.      100 |                                                               |
181.          +                                                               +
182.      104 |                                                               |
183.          +                                                               +
184.      108 |                                                               |
185.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
186.      112 |                                                               |
187.          +                                                               +
188.      116 |                                                               |
189.          +                                                               +
190.      120 |                                                               |
191.          +                                                               +
192.      124 |                   TLD Operator's Signature                    |
193.          +                                                               +
194.      128 |                                                               |
195.          +                                                               +
196.      132 |                                                               |
197.          +                                                               +
198.      136 |                                                               |
199.          +                                                               +
200.      140 |                                                               |
201.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202.  
203. ###Notes
204.  
205. 12 bytes of SHA-256 of domain name is plenty, collisions are not a security risk.
206. Caches must keep a separate namespace for each TLD, lest a TLD operator allow registration of
207. 2^96 domains.
208.  
209. Signatures and signing keys are Edwards-curve25519-SHA-512
210. As described here: http://ed25519.cr.yp.to/software.html
211. There is no global version number as I know of no case where a cryptographic break
212. in a large scale system such as DNS was solvable with any measure of backward compatibility.
213.  
214. TLD Operator's Signature is a signature on the SHA-256 of the first 112 bytes of the entry
215. (everything up to it). TLD operators do not need the entry in order to sign, only the SHA-256.
216.  
217.  
218. ###Domain entry version 0 - metadata
219.  
220. Bytes 12-15 of the domain entry shall be as follows:
221.  
222.                           1               2               3
223.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
224.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
225.       12 |      Zero     |              Zero             |   Body Type   |
226.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
227.  
228. `Body Type` field shall denote the format of the content in the `Entry Body` field.
229. Bytes one and two may be used with different `Body Types`.
230. Nodes must treat as invalid any domain entry of `Body Type` 0-2 where these bytes are non-zero.
231.  
232.  
233. ####Body Type 0
234. This type is intended for pointing to authoritative nameservers in the IPv4 space.
235. Bytes 16-47 of the domain entry shall be as follows. If less than 8 nameservers are
236. provided, the high entries shall be `0.0.0.0`. Any entry containing the address
237. `0.0.0.0` and a non-zero address following it must be regarded as invalid. If there
238. is not at least 1 non-zero entry, the body is invalid.
239.  
240.                           1               2               3
241.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
242.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
243.       16 |                  IPv4 Address of Nameserver                   |
244.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
245.       20 |                  IPv4 Address of Nameserver                   |
246.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
247.       24 |                  IPv4 Address of Nameserver                   |
248.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
249.       28 |                  IPv4 Address of Nameserver                   |
250.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
251.       32 |                  IPv4 Address of Nameserver                   |
252.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
253.       36 |                  IPv4 Address of Nameserver                   |
254.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255.       40 |                  IPv4 Address of Nameserver                   |
256.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
257.       44 |                  IPv4 Address of Nameserver                   |
258.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
259.  
260.  
261. ####Body Type 1
262. This type is intended for pointing to authoritative nameservers in the IPv6 space.
263. Bytes 16-47 of the domain entry shall be as follows. The second entry may be all
264. zeros to indicate that there is only one entry, the first entry may not be or else
265. the body is invalid.
266.  
267.                           1               2               3
268.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
269.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
270.       16 |                                                               |
271.          +                                                               +
272.       20 |                                                               |
273.          +                  IPv6 Address of Nameserver                   +
274.       24 |                                                               |
275.          +                                                               +
276.       28 |                                                               |
277.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
278.       32 |                                                               |
279.          +                                                               +
280.       36 |                                                               |
281.          +                  IPv6 Address of Nameserver                   +
282.       40 |                                                               |
283.          +                                                               +
284.       44 |                                                               |
285.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
286.  
287.  
288. ####Body Type 2
289. This type is intended for pointing to a single authoritative nameserver in a cjdns network.
290. Bytes 16-47 of the domain entry shall be as follows.
291.  
292.                           1               2               3
293.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
294.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
295.       16 |                                                               |
296.          +                                                               +
297.       20 |                                                               |
298.          +                                                               +
299.       24 |                                                               |
300.          +                                                               +
301.       28 |                                                               |
302.          +                Nameserver's cjdns Public Key                  +
303.       32 |                                                               |
304.          +                                                               +
305.       36 |                                                               |
306.          +                                                               +
307.       40 |                                                               |
308.          +                                                               +
309.       44 |                                                               |
310.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
311.  
312.  
313. #####Notes
314. Caching subdomains is out of scope, it requires more signatures and creates more risk of
315. out-of-date data and new attacks. if caching is required, it should use an entirely different
316. protocol.
317.  
318.  
319. ##Notarization process
320.  
321. Once the domain entry has been created, the TLD operators will sign the hash of it, RIPEMD-160 the
322. hash which they signed, Base-53 encode the RIPEMD-160 hash, creating a valid Bitcoin address, then
323. make a micropayment to that address such that the address will be included in the Bitcoin chain.
324. The reference implementation will make an RPC call against a companion Bitcoin daemon in order to
325. avoid implementing the vast majority of the Bitcoin algorithm.
326.  
327. Any transaction which is larger than 1020 bytes cannot be fit into a 1024 byte UDP packet and is
328. thus not usable. Unfortunately, the Bitcoin engine makes it's own decisions about how to create a
329. transaction so it is possible to make a tiny payment only to find it has used many sources and thus
330. has a large transaction. In practice this seems not to be an issue, the average transaction length
331. is 449 bytes [Average Bitcoin Transaction Size] and excluding intentionally large transactions,
332. they are usually 259 bytes. In the short term, it is probably acceptable to simply check for
333. oversized transactions and fail if there are any, if this ever proves to be an actual problem,
334. the Bitcoin code could be patched to shuffle money around internally in order to prevent this from
335. ever happening.
336.  
337. To support registering as many as 8192 domains in a batch (using one Bitcoin transaction), TLD
338. operators may create a SHA-256 Merkle tree from the hashes and only RIPEMD-160 the root of the
339. tree. In order to fit inside of a 1024 byte response packet, a batch can contain only at most 13
340. nodes in the Merkle branch, thus limiting a batch to 8192 domains.
341.  
342.  
343. ##On Wire Protocol
344.  
345. Content shall be sent in UDP packets.
346. All nodes must regard packets with content larger than 1024 bytes as invalid.
347. Each packet begins with a single byte indicating what type of message it is.
348.  
349.  
350. ###Lookup cycle
351.  
352. A client will receive "legacy" DNS lookups from the programs in the operating system and must make
353. requests in the DNS system. It is the responsibility of the client to convert all names to
354. lowercase such that registering "WEBSITE.DOM", while valid, will not trap users who happen to type
355. the domain in all caps.
356.  
357. If the client has no key for the TLD installed, it must respond with "unauthorized for zone" DNS
358. response, allowing the program to choose the next DNS server in resolv.conf.
359.  
360. To resolve a domain, a client will begin by sending a request to a cache which is known to support
361. the domain's TLD. A lookup request is defined by it's first byte which is zero, following three
362. bytes which must also be zero, following 12 first bytes of the hash of the domain, and finally the
363. 32 byte TLD identifier.
364.  
365.  
366. ####Message Zero The Request
367.                           1               2               3
368.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
369.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
370.        0 |      Zero     |                      Zero                     |
371.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
372.        4 |                                                               |
373.          +                                                               +
374.        8 |           First 12 bytes of SHA-256 of domain name            |
375.          +                                                               +
376.       12 |                                                               |
377.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378.       16 |                                                               |
379.          +                                                               +
380.       20 |                                                               |
381.          +                                                               +
382.       24 |                                                               |
383.          +                                                               +
384.       28 |                                                               |
385.          +                         TLD Identifier                        +
386.       32 |                                                               |
387.          +                                                               +
388.       36 |                                                               |
389.          +                                                               +
390.       40 |                                                               |
391.          +                                                               +
392.       44 |                                                               |
393.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
394.  
395. Caches must regard requests which are of the wrong length or whose first 4 bytes are
396. not zero as invalid.
397.  
398. The cache will send back the 144 byte domain entry, a buffer of pairs of SHA-256 hashes, comprising
399. the Merkle branch leading back to the Bitcoin transaction, the content of the Bitcoin transaction
400. in Bitcoin's on-wire transaction serialization format, the Double-SHA-256 hash entries comprising
401. the Merkle branch leading from the transaction back to the block header, and finally the 8 byte
402. index of the block header in the chain.
403.  
404.  
405. ####Message One: The Response
406.  
407.                           1               2               3
408.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
409.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410.        0 |      One      |                      Zero                     |
411.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
412.        4 |                                                               |
413.          +                                                               +
414.        8 |                                                               |
415.          +                                                               +
416.         ---                   144 Byte Domain Entry                     ---
417.         ---                                                             ---
418.          +                                                               +
419.      136 |                                                               |
420.          +                                                               +
421.      140 |                                                               |
422.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
423.       16 |                                                               |
424.          +                                                               +
425.         ---                 0 to 13, 64 byte Merkle nodes               ---
426.         ---                                                             ---
427.          +                                                               +
428.       ?? |                                                               |
429.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
430.       ?? |                                                               |
431.          +                                                               +
432.       ?? |                      Proof of validity                        |
433.          +                                                               +
434.       ?? |                                                               |
435.            ........                                                            
436.  
437. #####Notes
438. The 144 byte Domain Entry and Merkle nodes leading back to the root which is in the Bitcoin
439. transaction are mandatory, the proof of validity may be excluded to prevent the packet growing
440. larger than 1024 bytes. Clients must regard as invalid, any response for which bytes 1, 2, or 3
441. are not zero.
442.  
443.  
444. ####Proof of validity
445. A proof of validity is the data which is needed to link the root of a Merkle tree from a response
446. back to a Bitcoin block header. This includes the serialized Bitcoin transaction, and the Merkle
447. branch leading back to the block header.
448.  
449.                           1               2               3
450.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
451.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
452.        0 |       Transaction Length      |                               |
453.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
454.        4 |                                                               |
455.          +                                                               +
456.        8 |                                                               |
457.          +                                                               +
458.         ---                      Bitcoin Transaction                    ---
459.         ---                                                             ---
460.          +                                                               +
461.       ?? |                                                               |
462.          +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
463.       ?? |                     |   Zero Padded to next 4 byte Boundary   |
464.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465.       ?? |                                                               |
466.          +                                                               +
467.       ?? |                                                               |
468.          +                                                               +
469.         ---      Bitcoin Merkle Nodes Leading Back to Block Header      ---
470.         ---                                                             ---
471.          +                                                               +
472.       ?? |                                                               |
473.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
474.       ?? |                                                               |
475.          +                    8 Byte Block Header Index                  +
476.       ?? |                                                               |
477.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
478.  
479.  
480. `Transaction Length` is a Big Endian number representing the number of bytes in the Bitcoin
481. transaction. Any entry for which this number is not between 80 and 1020 (inclusive) must be
482. discarded as invalid, 80 is the size of the transaction structure with one output containing
483. only 20 bytes (the size of a RIPEMD-160 hash). 1020 is the max size that a transaction can be.
484. Since Bitcoin transaction structures sizes are only determinable by parsing out a number of size
485. values which are sprinkled through the transaction, the Bitcoin transaction shall be searched for
486. the RIPEMD-160 of the Merkle root using `memmem()` or equivalent, skipping the first 59 bytes of
487. the transaction and ignoring last 4. These are the minimum sizes for the header and footer data
488. in the transaction which cannot possibly contain the hash.
489.  
490. Following the transaction are 0 to 3 bytes of zero padding such that the data which follows is
491. 4 byte aligned, assuming the beginning of the message which contains the proof of validity is.
492. If a message extends past the end of the Bitcoin transaction but does not contain required zero
493. padding, clients must regard it as invalid. If a message extends past the end of the Bitcoin
494. transaction and the length of the data which follows the zero padding is not 8 bytes longer than
495. a multiple of 64, clients must regard it as invalid.
496.  
497. Following the zero padding is an array of 64 byte Merkle branch nodes from the branch which links
498. the transaction back to the Bitcoin block header. The final 8 bytes is the Big Endian index of the
499. header in the block chain. If the response is larger than 1024 bytes, the response shall be
500. truncated to the end of the transaction.
501.  
502.  
503.  
504. ####Message Two: Request for Proof
505.  
506.                           1               2               3
507.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
508.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
509.        0 |      Two      |      Txid     |              Zero             |
510.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511.        4 |                                                               |
512.          +                                                               +
513.        8 |                                                               |
514.          +                                                               +
515.       12 |                                                               |
516.          +                                                               +
517.       16 |                            SHA-256                            |
518.          +                                                               +
519.       20 |                                                               |
520.          +                                                               +
521.       24 |                                                               |
522.          +                                                               +
523.       28 |                                                               |
524.          +                                                               +
525.       32 |                                                               |
526.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
527.  
528. A Request for Proof (RFP) is a message which a client sends to a cache, asking the cache to
529. complete the Merkle branch back to the block header. Caches must regard as invalid any RFP
530. whose bytes 2, or 3 are not zero or which is the wrong length. Byte 1 is an opaque
531. transaction ID which allows a client to send multiple Requests for Proof to the same cache at
532. the same time. The value of this byte is of no significance to the cache and should be
533. reflected back to the client in the response Txid.
534.  
535. The hash in the RFP may be a (single) SHA-256 of a domain batch Merkle root, or the
536. Double-SHA-256 of a Bitcoin transaction. If the hash is of a Merkle root, the response will
537. contain the Proof of Validity, abridged at the end of the Bitcoin transaction if necessary to
538. prevent the packet from growing larger than 1024 bytes. If the hash is of a Bitcoin transaction,
539. the response will contain second part of the Proof of Validity, IE: the Bitcoin Merkle nodes
540. spanning back to the header and finally the header index.
541.  
542.  
543.  
544. ####Message Three: Proof (containing Transaction)
545.  
546.                           1               2               3
547.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
548.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
549.        0 |     Three     |      Txid     |       Transaction Length      |
550.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
551.        4 |                                                               |
552.          +                                                               +
553.        8 |                                                               |
554.          +                                                               +
555.         ---                      Bitcoin Transaction                    ---
556.         ---                                                             ---
557.          +                                                               +
558.       ?? |                                                               |
559.          +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
560.       ?? |                     |   Zero Padded to next 4 byte Boundary   |
561.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
562.       ?? |                                                               |
563.          +                                                               +
564.         ---      Bitcoin Merkle Nodes Leading Back to Block Header      ---
565.         ---                                                             ---
566.          +                                                               +
567.       ?? |                                                               |
568.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
569.       ?? |                                                               |
570.          +                    8 Byte Block Header Index                  +
571.       ?? |                                                               |
572.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
573.  
574. #####Notes
575. Everything past the end of the transaction, including the zero padding, shall be ommitted
576. if including it would cause the packet to grow over 1024 bytes.
577.  
578.  
579. ####Message Three: Proof (proving validity of Transaction)
580.  
581. This will be sent if the client asks for proof and sends the Double-SHA-256 of the transaction.
582. The client must regard this message as invalid if the value of `Zero` is not zero. A client must
583. also regard this message as invalid if it's length is not 12 plus a multiple of 64. 12 being the
584. header and footer and 64 being the size of a SHA-256 Merkle node.
585.  
586.                           1               2               3
587.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
588.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
589.        0 |     Three     |      Txid     |              Zero             |
590.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
591.        4 |                                                               |
592.          +                                                               +
593.        8 |                                                               |
594.          +                                                               +
595.         ---      Bitcoin Merkle Nodes Leading Back to Block Header      ---
596.         ---                                                             ---
597.          +                                                               +
598.       ?? |                                                               |
599.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
600.       ?? |                                                               |
601.          +                    8 Byte Block Header Index                  +
602.       ?? |                                                               |
603.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
604.  
605.  
606. ####Message Four: Get Header
607.  
608. This message is used when a node discovers a block header index which is higher than it's
609. highest known header.
610.  
611.                           1               2               3
612.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
613.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
614.        0 |      Four     |                      Zero                     |
615.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
616.        4 |                                                               |
617.          +                    8 Byte Block Header Index                  +
618.        8 |                                                               |
619.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
620.  
621.  
622. ####Message Five: Response with header
623.  
624.                           1               2               3
625.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
626.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
627.        0 |      Five     |                      Zero                     |
628.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
629.        4 |                                                               |
630.          +                    8 Byte Block Header Index                  +
631.        8 |                                                               |
632.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
633.       12 |                                                               |
634.          +                                                               +
635.       16 |                                                               |
636.          +                                                               +
637.       20 |                                                               |
638.          +                                                               +
639.       24 |                                                               |
640.          +                                                               +
641.       28 |                                                               |
642.          +                                                               +
643.       32 |                                                               |
644.          +                                                               +
645.       36 |                                                               |
646.          +                                                               +
647.       40 |                                                               |
648.          +                                                               +
649.       44 |                                                               |
650.          +                                                               +
651.       48 |                     81 Byte Block Header                      |
652.          +                                                               +
653.       51 |                                                               |
654.          +                                                               +
655.       56 |                                                               |
656.          +                                                               +
657.       60 |                                                               |
658.          +                                                               +
659.       64 |                                                               |
660.          +                                                               +
661.       68 |                                                               |
662.          +                                                               +
663.       72 |                                                               |
664.          +                                                               +
665.       76 |                                                               |
666.          +                                                               +
667.       80 |                                                               |
668.          +                                                               +
669.       84 |                                                               |
670.          +                                                               +
671.       88 |                                                               |
672.          +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
673.       92 |               |                     Zero                      |
674.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
675.  
676. #####Notes
677. This message must be regarded as invalid if either of the `Zero` fields are not zero or
678. if the length is incorrect.
679.  
680.  
681. ####Message Six: New Domains
682. This message is used by one cache to advertize domains to other caches. The caches can then use
683. requests to get all other necessary information about domains. If the length of the message length
684. is not 44 plus a multiple of 12, the message must be regarded as invalid.
685.  
686.                           1               2               3
687.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
688.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
689.        0 |      Six      |                      Zero                     |
690.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691.        4 |                                                               |
692.          +                    8 Byte Block Header Index                  +
693.        8 |                                                               |
694.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
695.       12 |                                                               |
696.          +                                                               +
697.       16 |                                                               |
698.          +                                                               +
699.       20 |                                                               |
700.          +                                                               +
701.       24 |                                                               |
702.          +                        TLD Identifier                         +
703.       28 |                                                               |
704.          +                                                               +
705.       32 |                                                               |
706.          +                                                               +
707.       36 |                                                               |
708.          +                                                               +
709.       40 |                                                               |
710.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
711.       44 |                                                               |
712.          +                                                               +
713.       48 |                     First Altered Domain                      |
714.          +                                                               +
715.       51 |                                                               |
716.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
717.       56 |                                                               |
718.          +                                                               +
719.       60 |                    Second Altered Domain                      |
720.          +                                                               +
721.       64 |                                                               |
722.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
723.       68 |                                                               |
724.          +                     Third Altered Domain                      +
725.       72 |                                                               |
726.          +   ............
727.  
728.  
729.  
730. ##Validating Block Headers
731.  
732. TODO:
733.  
734.  
735. ##TLD Identifier and META Information
736.  
737. The TLD Identifier is a SHA-256 hash of the TLD Meta Information.
738. The TLD Meta Information contains a list of master keys for the TLD operators,  these keys are
739. valid only for signing changes to the hot key which signs domains.
740.  
741.                           1               2               3
742.           0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
743.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
744.        0 |   Key Count   | Sigs Required |     Domain Blackout Period    |
745.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
746.        4 |                     Domain Validity Period                    |
747.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
748.        8 |                                                               |
749.          +                                                               +
750.       12 |                                                               |
751.          +                                                               +
752.       16 |                                                               |
753.          +                                                               +
754.       20 |                                                               |
755.          +                            Key 1                              +
756.       24 |                                                               |
757.          +                                                               +
758.       28 |                                                               |
759.          +                                                               +
760.       32 |                                                               |
761.          +                                                               +
762.       36 |                                                               |
763.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
764.       40 |                                                               |
765.          +                            Key 2                              +
766.       44 |                                                               |
767.          +  ........
768.  
769. If `Key Count`, `Sigs Required`, or `Domain Validity Period` is 0, or the length of the
770. meta data is not equal to `32 * KeyCount + 8`, or if `Sigs Required` is greater than
771. `Key Count`, the meta data is invalid.
772. `Sigs Required` is a number of keys which must sign a change to the hot key and `Key Count`
773. is the number of keys which are authorized to sign. `Domain Validity Period` is a Big Endian
774. value representing the number of BTC blocks after the domain is created before it enters
775. blackout period. `Domain Blackout Period` is the number of blocks before a domain becomes
776. registrable by other parties.
777. If my.dom is hashed in to a transaction in block 7 and `Domain Validity Period` for .dom is
778. 10, my.dom will become unreachable when block 17 is announced. If the `Domain Blackout Period`
779. for .dom is 4, my.dom will be registrable by other entities after block 21 is announced.
780.  
781. There is no provision made to transfer the TLD Meta Information over the wire, it is expected
782. that the user will install this information when they choose to trust a TLD.
783.  
784.  
785. ##Security Considerations
786.  
787. As pointed out by Stefan Buehler, a cache and a TLD operator can collude to fool a client
788. into thinking that a DNS entry has been changed when they were not authorized to change it.
789. The TLD operator signs a new domain despite an old one existing and the cache "forgets"
790. about the old one, giving the client only the poison. This attack is very difficult to
791. execute covertly as the "client" may in actuality be another cache which is looking to
792. update it's records. Once the TLD operator signs poison and hashes it into the block chain,
793. if anyone identifies it, it can be proven that they have acted against the specification.
794. Finally, caches may choose not to introduce other caches or clients to any cache which has
795. been known to participate in such a scheme.
796.  
797.  
798. [Average Bitcoin Transaction Size]: http://blockexplorer.com/q/avgtxsize