Quote from the bitcoin paper:

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

Why not provide that proof by signature of the majority of the nodes?

Prereqs:

• Each node registers its own signing and public key into the blockchain. There is no limit to the number of keys a node uses.
• There is NO connection to anything physical here, such as an IP address
• The same mechanism that allows for registration of a node into the blockchain should allow for the revokation certificate of the same keys at some later date, in case of compromise.

Assumptions:

• Every node's goal is to get transactions onto the blockchain as fast as possible.
• Every node will maintain a list of recently active nodes. This includes all nodes that have recently broadcast a transaction signature. 51% of this number is the "majority" required by Satoshi above.

New transactions:

• Wallet/address owner creates the transaction, including the timestamp he created it, and signs the whole thing.
• All nodes are synchronized to the correct current time using NTP or similar. It does not have to be microsecond precise, but does need to be roughly minute precise, depending on the block creation window time.
• Each incoming transaction is verified for correctness. Correctness means: the transaction is properly signed and fits the current node's blockchain knowledge. i.e. no double spend AND there is no conflict with transactions the node has seen but are not yet on the blockchain. For example, if a node has seen tx A signed by A' then later sees tx B signed by A' which causes a double spend, tx B gets the error.
• The node then signs a report and adds it to the bottom of the transaction: if correct, node signs the timestamp it was first seen; if incorret, node signs an error code why.
• The node then broadcasts the updated transaction to other connected nodes.

New blocks:

• As soon as a valid transaction reaches 51%, a new block is created by multiple nodes (all nodes that know it is a 51% txn) containing all known valid 51% transactions, which have NO known errors reported by nodes. Transactions are sorted by txid, and the block is broadcast through the network.
• Receiving nodes compare the block with their idea of reality, verify it for correctness (all signatures pass, no double spends, no conflict with what it currently knows, and 51% reached), and accepts it if ok. If multiple blocks come in, accept the largest valid block. In any case, rebroadcast the best known block as soon as the node knows it, even if that node does it multiple times (i.e. first a smaller block, later a larger one). Nodes that already have the larger block, should back-transmit the larger one if a node is trying to broadcast a small one.
• The goal is to get blocks created as soon as possible, even if the block contains only one transaction. Multiple transactions in a block is merely an optimization to get more transactions published faster.
• A node receiving a new block favours the largest valid block known.
• If anything is invalid in the block, it is ignored, and not broadcast at all.

Forks:

• Should a fork happen (network splits, etc.), a node will compare its own known good blockchain with the unknown one.
• If the new blockchain is completely valid and does not conflict with its own, the node will broadcast a merge block.
• If a node receives a merge block, it will validate the new blockchain to see if it agrees, and ignore it if not.
• If a merge is not possible, the chain with the earliest timestamps on the conflicting transactions is favoured.

Outside observers can validate the blockchain by:

• Checking the validity of checksums of all blocks in the chain.
• Checking the signature of the address of each transaction.
• Checking the signatures of the nodes on each transaction as well as the timestamp they claimed to have first seen the transaction.
• Building a reputation database of all known nodes.

To find a list of all current nodes:

• Go through the entire blockchain, finding all Node ID registrations.

Points:

• The verification work required by the above encourages full nodes to be run.

Attacks:

• A malicious node could sign an error on every transaction seen by a given address, to prevent spending. Defence: Node reputation should help with this.
• A malicious node could sign incorrect timestamps on otherwise valid transactions and broadcast them. Defence: if the timestamp is so far in the past that it references blockchain time, then this transaction is just an old one that hasn't gotten into the blockchain yet, and must pass all the usual double spend validations as if it were new. If the timestamp is in the future, the node will consider it an error by the node itself and mark that node as suspicious and rebroadcast the transaction without the error signature included.
• A malicious node could randomly drop "seen" signatures and broadcast its own. Defence: each node builds its own list of seen signatures as the transactions flow through the network... if new signatures are seen by an incoming transaction, it adds to the known list. If an incoming transactions has suddenly very few, it does not affect the internally built list the node maintains.
• A malicious node could reply past transactions as newly seen. Defence: if it's already in the blockchain, the new one is a double spend and therefore invalid.

Problems:

• There is no financial reward to running a node in this plan yet, and since there is no mining, no rewards there either.
• This decreases privacy, since the first time a transaction is submitted to the network, it will have no "seen" signatures, letting at least that node to know which IP was the source of the transaction. See Dandelion++ used by Digibyte for one idea to maybe fix this.
• 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 TaS protocol. So it better be solid.