Prereqs:

• Add a new transaction, where a full node can register itself with its IPv4 or IPv6 address, public key / wallet ID. The sha256 hash of these details becomes its Node ID and gets locked in the blockchain.

Steps:

• All nodes are synchronized on time.
• Each new block has 10 minutes to be applied.
• On every 10 minute increment, calculate the target hash by doing:
  • Create sha256 hash of:
  • Hash of last block
  • The 10 minute timestamp in UTC. Will always end in some multiple of 10:00
• The winner is the Node ID that most closely matches the resulting target hash above.
• The winner has 10 minutes to create the next block, as usual, as if it were the Proof-of-Work winner. (See Problems below, alternately include some Proof-of-Full Node Knowledge here as well.)
• Every other node can calculate the winner based on the current blockchain and time, and verify that the new block was signed by the winner.
• If no block is produced in that 10 minute window, the Node ID is silently marked as de-listed, and the next 10 minute hash is calculated to find the next winner.

To find a list of all current nodes:

• Go through the entire blockchain, finding all Node ID registrations.
• For every winner that failed to produce a block in its 10 minute window, remove from list.

Closest match is defined as:

• Similar to network masking, starting with bit 0, the sha256 hash that matches the most bits wins.
• If multiple Node IDs match a maximum of X bits, turn the remaining Y bits into a number, and the lowest one wins.

Points:

• The blockchain will contain all known Node IDs, so everyone will know the winner at any given time.
• To get the chance to become a winner, you must register a full node on the blockchain.
• In the case of delays within the network, the correct history can be re-calculated based on what was known at the time (the blockchain to date).
• In the case of two potential chains, the one with the fewest missing blocks wins.
• No one can attack past blocks with a new better Node ID, because their Node ID isn't in the network yet.

Attacks:

• Forking the blockchain requires that you have a Node ID already in the blockchain that beats whoever else thinks he is the winner. You can't pick the blockchain of your choice, because the blockchain records the past and also determines the future.
• Johnny-come-lately: if a Node ID adds its block after its 10 minute window, it changes who the next winner will be. Contention over this will be resolved by the community adding to the blockchain it considers the winner. Over time, one will clearly have more valid blocks than the other, and therefore the winner. It is in every node's self interest to be strict in the time limit here, and ignore Johnny-come-lately's, since they are A) disruptive to the blockchain, and B) potential non-full node posers.
• IPv6 flooding: People could game the system by registering as many Node IDs as possible, but since every Node ID is tied to an IP address, there is some physical resource limitation and cost to this attack. Some creativity with IPv6 may be required to make registering IPv6 nodes more costly.
• DoS attacks: Since the winner of the next block, and its IP, will be readily known as soon as the blockchain grows, it will be possible to DoS / flood the IP off the network for 10 minutes to prevent him from adding his block. The workaround is to maintain a secondary IP address connected to the network used to send the next valid block.
• Registering a Node ID IP address that you don't control: Workaround to this attack is to update the registration process to involve contacting the registered IP and asking it to sign a nonce in real time to prove it is the Node ID. This is the bar to get into the blockchain. To maintain the blockchain, periodic tests can be done among nodes to prove their stability and reliability, using the same mechanism. So far, only failure to produce a new block in time is punished by de-listing, but de-listing over unreliability could also be useful.
• Favouring friends and Winners of History attack: (thanks to jfw) Part 1: The winner of block N-1 can use its 10 minutes to attempt to craft a special new block that favours himself or his friends' node IDs for block N. Combine this with registering many Node IDs and it becomes easier to future match blocks. Part 2: Note that "history books are written by the winners". How can a random observer at time T with a tip block of N verify that block N-500 was really created at T-(10*500) and not at some later time (along with all the following blocks)? There is no time limit for this attack, except for the additional work added every 10 minutes. But if the attack is at all possible, 10 minutes is a small amount of additional work. For example, any winner can take all the time he needs to craft a special block which A) results in another win for himself, and B) adds as many new NodeIDs as desired.

Problems:

• How do we encourage full nodes? Ideally, the winner should include something that only a full node can calculate or know within 10 minutes. The larger the blockchain becomes, the stronger this check would be. This is still an unsolved problem.
• All the monetarily-inspired attack vigor, innovation, creativity, and greed will turn from the CPU Proof-of-Work side of things to the security of the nodes and TaC protocol. So it better be solid.