#Cjdns Domain Name System *The unnamable is the eternally real. Naming is the origin of all particular things.* ##Requirements r0: *must not fork* this is of critical importance, if a wxyz goes to 1.2.3.4 here it must also goto 1.2.3.4 over there. We must have an anti-fork logic, in simple terms, all honest nodes must be able to come to agreement on the truth even if that truth is wrong. There have been some suggestions of "trust based systems" and also people talked about just dishonering ICE/US.gov dns takedowns. Those things were never implemented because they violate the fundamental rule of names, they must always be the same. r1: Name hijacking must be impossible (or as close to it as is feasible) We can't have people going around taking someone else's name because they don't like them, by technical means (haxxors), or by social/political means (government, angry.com, etc) 21:57 <@ircerr> did you miss r2? 21:57 <@cjd> indeed 21:57 <@cjd> we'll leave it for extensibility r3: it needs to be fast if it's not fast then people will not use it. Fast is sub-100-milliseconds. cjdns network code will improve but we must not rely on underlying technologies improving, this needs to be fast out of the box or it's dead in the water. r4: It must be difficult to take more domains than you need but easy to take enough for your needs. Problem with bitcoin/dns is that it's fixed rate so at first noone wants it because it's all experimental and it costs money because telling a geek to pay money for the privilege of fooling around with a new system is like telling him to kill a kitten. Once it gets off the ground, all the sudden it doesn't cost enough and people are scrambling to vacuum up all of the domains. r5: Any "hot" signing key which needs to be on a live server must be revokable and replaceable using an offline key. TLDs should be able to have multiple offline keys which need a quorum to change the hot key. r6: Simplicity of installation and configuration. It is a lot to ask the user "who do you trust", asking "how do I find X" is too much. ##Implementation Proposal I propose a system whereby each TLD is a root signing key, users install the key for a TLD thus trusting the TLD (similar to how users trust certificate authorities). Each TLD is a central authority which has the power to intelligently fulfill r4. In order to best provide for r1 despite central authorities, we must make these central authorities as powerless as possible. I propose domain signatures be notarized using spam BTC transactions so that the world knows they are there and nobody, even the TLD, can "ninja transfer" them (see: [Security Considerations]). All registrations should expire after a set amount of time which can conveniently be measured in BTC blocks so everyone can agree on when the change occurs. r3 means there will need to be a lot of caches, like the clients, these must only accept domains for the TLDs which are authorized by the cache owner. To fulfill r3, clients must be able to prove validity of information given to them from a cache with a minimum of stored data. By making clients hold only the block headers back from the current one to the last one which could possibly hold a valid domain registration, the cache can show proof of the registration's validity through a merkle branch. A year of headers occupies about 5MB of space. In order to intelligently implement r5, it makes sense that TLD operators should hold multiple keys and a quorum of signatures should be required to make a change to the TLD's hot domain signing key. TLD operators must *not* be able to add or remove other keys for their TLD. The idea of TLD operators being able to maintain their TLD master keys for perpetuity is intoxicating but the prospect of feuds inside of the group is devastating whereas the need to remove a lost key or add a new member to the group is relatively small and in the worst cases (50% of the keys are lost or compromised), new updates can be advertized which authorize new keys. r6 requires that there be as little manual configuration as possible. I propose a peer-to-peer design where cache nodes gossip new BTC block headers and domains amongst each other and introduce clients and caches to other caches. ##Domain Lifecycle 1. Webmaster registers a domain linking a name to one or more ip addresses of his nameservers and authorizing a master key to make changes to that domain. 2. Webmaster maintains domain by re-registering using master key to sign the registration. 3. Webmaster changes nameserver ip addresses linked to the name by way of re-registration. 4. Webmaster abandons domain by not re-registering it, after a dormant period, the domain becomes available to new registrations. 5. Webmaster loses his master key and applies to the TLD operator to be able to re-register his domain. When expires and becomes registrable by anyone, TLD operator holds out allowing others to register it in order to get webmaster's domain back. Webmaster's domain is down for the 7 day blackout period. 6. Webmaster forgets about maintaining his domain, domain enters blackout period, webmaster has some time to re-register before domain becomes registrable by anyone. ##Details After a per-TLD defined amount of time following the time when a domain was registered, the domain will become inaccessible, this amount of time is defined by `Domain Validity Period` in the TLD META Information. After a second amount of time, known as `Domain Blackout Period` the domain may be registered by parties other than it's original owner. (See: [TLD Identifier and META Information] ) Registering a domain happens by hashing a domain entry and having the TLD operator sign the hash. This allows the TLD operator to choose to remain ignorant of the actual domain so they can ensure that if external pressure is placed on them to not re-register a particular domain, it is obvious as they are forced to abandon the hash signing policy. To register a domain, a TLD operator signs a hash of the domain entry then from a batch of entries, creates a Merkle tree and makes a trivially small Bitcoin payment to a Bitcoin wallet address derived from root of the Merkle tree thus notarizing the entry. A domain is valid if all of the following are true: 1. Contains a valid signature from TLD operators key. 2. A Merkle branch is known which hashes back to an accepted Bitcoin block header. 3. Domain is less than `Domain Validity Period` BTC blocks old. 4. No known valid domain with the same name is older by less than `Domain Validity Period` PLUS `Domain Blackout Period` blocks unless it's key is the one which signed this domain entry. 5. No known valid domain with the same name is newer. ##Domain entry 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | | + + 4 | First 12 bytes of SHA-256 of domain name | + + 8 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Version | Entry Metadata (version specific) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | | + + 20 | | + + 24 | | + + 28 | 32 Byte Entry Body | + Content is version specific + 32 | | + + 36 | | + + 40 | | + + 44 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 48 | | + + 52 | | + + 56 | | + + 60 | 32 Byte Re-Registration/Transfer Signing Key | + + 64 | | + + 68 | | + + 72 | | + + 76 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | | + + 84 | | + + 88 | | + + 92 | Re-Registration/Transfer Signature | + Undefined if not applicable. + 96 | | + + 100 | | + + 104 | | + + 108 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | | + + 116 | | + + 120 | | + + 124 | TLD Operator's Signature | + + 128 | | + + 132 | | + + 136 | | + + 140 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ###Notes 12 bytes of SHA-256 of domain name is plenty, collisions are not a security risk. Caches must keep a separate namespace for each TLD, lest a TLD operator allow registration of 2^96 domains. Signatures and signing keys are Edwards-curve25519-SHA-512 As described here: http://ed25519.cr.yp.to/software.html There is no global version number as I know of no case where a cryptographic break in a large scale system such as DNS was solvable with any measure of backward compatibility. TLD Operator's Signature is a signature on the SHA-256 of the first 112 bytes of the entry (everything up to it). TLD operators do not need the entry in order to sign, only the SHA-256. ###Domain entry version 0 - metadata Bytes 12-15 of the domain entry shall be as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Zero | Zero | Body Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ `Body Type` field shall denote the format of the content in the `Entry Body` field. Bytes one and two may be used with different `Body Types`. Nodes must treat as invalid any domain entry of `Body Type` 0-2 where these bytes are non-zero. ####Body Type 0 This type is intended for pointing to authoritative nameservers in the IPv4 space. Bytes 16-47 of the domain entry shall be as follows. If less than 8 nameservers are provided, the high entries shall be `0.0.0.0`. Any entry containing the address `0.0.0.0` and a non-zero address following it must be regarded as invalid. If there is not at least 1 non-zero entry, the body is invalid. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44 | IPv4 Address of Nameserver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####Body Type 1 This type is intended for pointing to authoritative nameservers in the IPv6 space. Bytes 16-47 of the domain entry shall be as follows. The second entry may be all zeros to indicate that there is only one entry, the first entry may not be or else the body is invalid. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | | + + 20 | | + IPv6 Address of Nameserver + 24 | | + + 28 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 | | + + 36 | | + IPv6 Address of Nameserver + 40 | | + + 44 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####Body Type 2 This type is intended for pointing to a single authoritative nameserver in a cjdns network. Bytes 16-47 of the domain entry shall be as follows. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | | + + 20 | | + + 24 | | + + 28 | | + Nameserver's cjdns Public Key + 32 | | + + 36 | | + + 40 | | + + 44 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #####Notes Caching subdomains is out of scope, it requires more signatures and creates more risk of out-of-date data and new attacks. if caching is required, it should use an entirely different protocol. ##Notarization process Once the domain entry has been created, the TLD operators will sign the hash of it, RIPEMD-160 the hash which they signed, Base-53 encode the RIPEMD-160 hash, creating a valid Bitcoin address, then make a micropayment to that address such that the address will be included in the Bitcoin chain. The reference implementation will make an RPC call against a companion Bitcoin daemon in order to avoid implementing the vast majority of the Bitcoin algorithm. Any transaction which is larger than 1020 bytes cannot be fit into a 1024 byte UDP packet and is thus not usable. Unfortunately, the Bitcoin engine makes it's own decisions about how to create a transaction so it is possible to make a tiny payment only to find it has used many sources and thus has a large transaction. In practice this seems not to be an issue, the average transaction length is 449 bytes [Average Bitcoin Transaction Size] and excluding intentionally large transactions, they are usually 259 bytes. In the short term, it is probably acceptable to simply check for oversized transactions and fail if there are any, if this ever proves to be an actual problem, the Bitcoin code could be patched to shuffle money around internally in order to prevent this from ever happening. To support registering as many as 8192 domains in a batch (using one Bitcoin transaction), TLD operators may create a SHA-256 Merkle tree from the hashes and only RIPEMD-160 the root of the tree. In order to fit inside of a 1024 byte response packet, a batch can contain only at most 13 nodes in the Merkle branch, thus limiting a batch to 8192 domains. ##On Wire Protocol Content shall be sent in UDP packets. All nodes must regard packets with content larger than 1024 bytes as invalid. Each packet begins with a single byte indicating what type of message it is. ###Lookup cycle A client will receive "legacy" DNS lookups from the programs in the operating system and must make requests in the DNS system. It is the responsibility of the client to convert all names to lowercase such that registering "WEBSITE.DOM", while valid, will not trap users who happen to type the domain in all caps. If the client has no key for the TLD installed, it must respond with "unauthorized for zone" DNS response, allowing the program to choose the next DNS server in resolv.conf. To resolve a domain, a client will begin by sending a request to a cache which is known to support the domain's TLD. A lookup request is defined by it's first byte which is zero, following three bytes which must also be zero, following 12 first bytes of the hash of the domain, and finally the 32 byte TLD identifier. ####Message Zero The Request 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Zero | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + + 8 | First 12 bytes of SHA-256 of domain name | + + 12 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | | + + 20 | | + + 24 | | + + 28 | | + TLD Identifier + 32 | | + + 36 | | + + 40 | | + + 44 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Caches must regard requests which are of the wrong length or whose first 4 bytes are not zero as invalid. The cache will send back the 144 byte domain entry, a buffer of pairs of SHA-256 hashes, comprising the Merkle branch leading back to the Bitcoin transaction, the content of the Bitcoin transaction in Bitcoin's on-wire transaction serialization format, the Double-SHA-256 hash entries comprising the Merkle branch leading from the transaction back to the block header, and finally the 8 byte index of the block header in the chain. ####Message One: The Response 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | One | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + + 8 | | + + --- 144 Byte Domain Entry --- --- --- + + 136 | | + + 140 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | | + + --- 0 to 13, 64 byte Merkle nodes --- --- --- + + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | + + ?? | Proof of validity | + + ?? | | ........ #####Notes The 144 byte Domain Entry and Merkle nodes leading back to the root which is in the Bitcoin transaction are mandatory, the proof of validity may be excluded to prevent the packet growing larger than 1024 bytes. Clients must regard as invalid, any response for which bytes 1, 2, or 3 are not zero. ####Proof of validity A proof of validity is the data which is needed to link the root of a Merkle tree from a response back to a Bitcoin block header. This includes the serialized Bitcoin transaction, and the Merkle branch leading back to the block header. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Transaction Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 4 | | + + 8 | | + + --- Bitcoin Transaction --- --- --- + + ?? | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | Zero Padded to next 4 byte Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | + + ?? | | + + --- Bitcoin Merkle Nodes Leading Back to Block Header --- --- --- + + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | + 8 Byte Block Header Index + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ `Transaction Length` is a Big Endian number representing the number of bytes in the Bitcoin transaction. Any entry for which this number is not between 80 and 1020 (inclusive) must be discarded as invalid, 80 is the size of the transaction structure with one output containing only 20 bytes (the size of a RIPEMD-160 hash). 1020 is the max size that a transaction can be. Since Bitcoin transaction structures sizes are only determinable by parsing out a number of size values which are sprinkled through the transaction, the Bitcoin transaction shall be searched for the RIPEMD-160 of the Merkle root using `memmem()` or equivalent, skipping the first 59 bytes of the transaction and ignoring last 4. These are the minimum sizes for the header and footer data in the transaction which cannot possibly contain the hash. Following the transaction are 0 to 3 bytes of zero padding such that the data which follows is 4 byte aligned, assuming the beginning of the message which contains the proof of validity is. If a message extends past the end of the Bitcoin transaction but does not contain required zero padding, clients must regard it as invalid. If a message extends past the end of the Bitcoin transaction and the length of the data which follows the zero padding is not 8 bytes longer than a multiple of 64, clients must regard it as invalid. Following the zero padding is an array of 64 byte Merkle branch nodes from the branch which links the transaction back to the Bitcoin block header. The final 8 bytes is the Big Endian index of the header in the block chain. If the response is larger than 1024 bytes, the response shall be truncated to the end of the transaction. ####Message Two: Request for Proof 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Two | Txid | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + + 8 | | + + 12 | | + + 16 | SHA-256 | + + 20 | | + + 24 | | + + 28 | | + + 32 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Request for Proof (RFP) is a message which a client sends to a cache, asking the cache to complete the Merkle branch back to the block header. Caches must regard as invalid any RFP whose bytes 2, or 3 are not zero or which is the wrong length. Byte 1 is an opaque transaction ID which allows a client to send multiple Requests for Proof to the same cache at the same time. The value of this byte is of no significance to the cache and should be reflected back to the client in the response Txid. The hash in the RFP may be a (single) SHA-256 of a domain batch Merkle root, or the Double-SHA-256 of a Bitcoin transaction. If the hash is of a Merkle root, the response will contain the Proof of Validity, abridged at the end of the Bitcoin transaction if necessary to prevent the packet from growing larger than 1024 bytes. If the hash is of a Bitcoin transaction, the response will contain second part of the Proof of Validity, IE: the Bitcoin Merkle nodes spanning back to the header and finally the header index. ####Message Three: Proof (containing Transaction) 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Three | Txid | Transaction Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + + 8 | | + + --- Bitcoin Transaction --- --- --- + + ?? | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | Zero Padded to next 4 byte Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | + + --- Bitcoin Merkle Nodes Leading Back to Block Header --- --- --- + + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | + 8 Byte Block Header Index + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #####Notes Everything past the end of the transaction, including the zero padding, shall be ommitted if including it would cause the packet to grow over 1024 bytes. ####Message Three: Proof (proving validity of Transaction) This will be sent if the client asks for proof and sends the Double-SHA-256 of the transaction. The client must regard this message as invalid if the value of `Zero` is not zero. A client must also regard this message as invalid if it's length is not 12 plus a multiple of 64. 12 being the header and footer and 64 being the size of a SHA-256 Merkle node. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Three | Txid | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + + 8 | | + + --- Bitcoin Merkle Nodes Leading Back to Block Header --- --- --- + + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ?? | | + 8 Byte Block Header Index + ?? | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####Message Four: Get Header This message is used when a node discovers a block header index which is higher than it's highest known header. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Four | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + 8 Byte Block Header Index + 8 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####Message Five: Response with header 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Five | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + 8 Byte Block Header Index + 8 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | | + + 16 | | + + 20 | | + + 24 | | + + 28 | | + + 32 | | + + 36 | | + + 40 | | + + 44 | | + + 48 | 81 Byte Block Header | + + 51 | | + + 56 | | + + 60 | | + + 64 | | + + 68 | | + + 72 | | + + 76 | | + + 80 | | + + 84 | | + + 88 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #####Notes This message must be regarded as invalid if either of the `Zero` fields are not zero or if the length is incorrect. ####Message Six: New Domains This message is used by one cache to advertize domains to other caches. The caches can then use requests to get all other necessary information about domains. If the length of the message length is not 44 plus a multiple of 12, the message must be regarded as invalid. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Six | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | | + 8 Byte Block Header Index + 8 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | | + + 16 | | + + 20 | | + + 24 | | + TLD Identifier + 28 | | + + 32 | | + + 36 | | + + 40 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44 | | + + 48 | First Altered Domain | + + 51 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 56 | | + + 60 | Second Altered Domain | + + 64 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | | + Third Altered Domain + 72 | | + ............ ##Validating Block Headers TODO: ##TLD Identifier and META Information The TLD Identifier is a SHA-256 hash of the TLD Meta Information. The TLD Meta Information contains a list of master keys for the TLD operators, these keys are valid only for signing changes to the hot key which signs domains. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Key Count | Sigs Required | Domain Blackout Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Domain Validity Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | | + + 12 | | + + 16 | | + + 20 | | + Key 1 + 24 | | + + 28 | | + + 32 | | + + 36 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40 | | + Key 2 + 44 | | + ........ If `Key Count`, `Sigs Required`, or `Domain Validity Period` is 0, or the length of the meta data is not equal to `32 * KeyCount + 8`, or if `Sigs Required` is greater than `Key Count`, the meta data is invalid. `Sigs Required` is a number of keys which must sign a change to the hot key and `Key Count` is the number of keys which are authorized to sign. `Domain Validity Period` is a Big Endian value representing the number of BTC blocks after the domain is created before it enters blackout period. `Domain Blackout Period` is the number of blocks before a domain becomes registrable by other parties. If my.dom is hashed in to a transaction in block 7 and `Domain Validity Period` for .dom is 10, my.dom will become unreachable when block 17 is announced. If the `Domain Blackout Period` for .dom is 4, my.dom will be registrable by other entities after block 21 is announced. There is no provision made to transfer the TLD Meta Information over the wire, it is expected that the user will install this information when they choose to trust a TLD. ##Security Considerations As pointed out by Stefan Buehler, a cache and a TLD operator can collude to fool a client into thinking that a DNS entry has been changed when they were not authorized to change it. The TLD operator signs a new domain despite an old one existing and the cache "forgets" about the old one, giving the client only the poison. This attack is very difficult to execute covertly as the "client" may in actuality be another cache which is looking to update it's records. Once the TLD operator signs poison and hashes it into the block chain, if anyone identifies it, it can be proven that they have acted against the specification. Finally, caches may choose not to introduce other caches or clients to any cache which has been known to participate in such a scheme. [Average Bitcoin Transaction Size]: http://blockexplorer.com/q/avgtxsize