Skip to content

DHT hardening

Jump to bottom Edit New page
Gene Vayngrib edited this page May 21, 2015 · 42 revisions

The blockchain is logically centralized organizationally decentralized global DB. But it is limited in the type of transactions it can carry. We use the DHT to store the extended blockchain transactions thus avoiding blockchain bloat, which is created in other embedded consensus systems, like Counterparty and Mastercoin. We employ the bittorrent DHT (also called mainline DHT) since it has proven to support 5-10M active users. Unfortunately DHT has known attack vectors that were not addressed. We use a blockchain to harden the DHT against the the attacks described in S/Kademlia paper.

##Credits Mark @ Tradle has come up with most of the algorithms here. Bryan Vu has constantly taunted us about the impossibility of creating this algorithm, yet affirmed its great potential to the community. Peter Todd created an important thought framework (1, 2) that allowed to think of embedded consensus with the validation on client nodes as opposed to miner's nodes. Peter has also stated (I think at Cryptoeconomicon) that bitcoin blockchain's POW makes other consensus protocols possible and easier, which is what we rely on in this spec.

Bitpay's work on Foxtrot framed our thinking of nodes identified with pub keys and authenticating and encrypting traffic with those pub/priv key pairs. Ethereum's DHT work on Whisper and Swarm inspired us as we knew others thought DHT could be made more secure. Specifically a discussion with Gavin Wood and Alex Leverington was helpful in confirming the path taken by Foxtrot team. Bittorrent.com's Bleep and Bittorrent Sync products influenced our attitude towards DHT as a generic and scalable messaging and storage medium. And above all we are grateful to Petar Maymounkov for inventing Kademlia.

Nodeid validation

According to S/Kademlia paper, a whole set of attacks is eliminated if there is a central server that controls nodeid creation. Instead we are using the blockchain to derive the nodeid in a way that the node creator can not control:

nodeid acquisition

The node creator creates a blockchain tx announcing the intention to create a DHT node. When this tx is accepted into a blockchain block, the nodeid can be calculated as XOR(transaction hash, block hash). Since block hashes cannot be predicted, the nodeid cannot be chosen by the node creator. Since every nodeid has a corresponding blockchain transaction, this transparency is a deterrent for bad actors. Note that tx may take some time to confirm, thus creating an additional barrier for DOS and sybil attacks.

  • Question: This design does not place a limit on a number of nodes per blockchain block. Should we introduce this limit to further tighten against the DOS and sybil attacks?

  • Question: Should we require a payment or a sacrifice in a transaction that creates a node. If yes, how much?

verification by peer nodes

Every message by this node must include a signature, signed with the same private key as the first input of the tx that announced this node's creation on a blockchain. This requires every DHT node to be at least an SPV client.

  • Question: Should DHT node also be a full blockchain node? Full node is desirable anyway to be able to send and confirm blockchain transactions. This will also benefit the blockchain network and provide a better security for the above DHT verification. Full node will also allow us to add new types of DHT entry verifications in the future (possibly via UTXO commitments and/or mechanisms introduces by Zerocash).

##Encrypting all traffic All traffic is encrypted with the help of a shared secret. Shared secret is derived by using ECC math, combining the public key of the recipient node and the private key of the sender node. Public key of the recipient is part of the signature on the transaction that announced the node on the blockchain).

Node reputation

Each node is evaluating other nodes and may report bad actors to the blockchain. This needs to be done in a way that will not allow smearing the reputation.

New DHT Entry Validation

To prevent attacks that put fake objects into the DHT we can add a reference to the associated blockchain transaction. This pointer is inside an encrypted object, so privacy/anonymity is preserved. Verifier of the object can check that the tx exists and thus this DHT object is not fake.

We use two pointers, a pointer to current tx and a previous tx:

Link to a previous tx. Each object stored in the DHT contains the hash of the tx for the previous version of this object. This is necessary for SPV (but may not be sufficient).

Link to a blockchain transaction that created this object. We can't point to a tx that created this object directly, since this tx is pointing to our object, and it would be a circular dependency. But we can point to the current blockchain block height. Link verifier will need to scan the blockchain starting with this block for the tx that points to this object. Note that the verifier will need to step back several blocks to account for blockchain reorgs.

##Incentives for DHT nodes To provide long term data storage nodes need incentives. Please review the algorithm we came up with to get node operators some dough.

Resources

Add a custom footer

Design

###Software

###Front end

Clone this wiki locally