Loader

CRYPTOSPACE – METCALFE’S LAW – PEER2PEER SOCMED

Table of Contents

REPLACING CORPORATE SOCIAL MEDIA?

In theory, Metcalfe’s law is an impossible problem to overcome. But in reality? It may not be necessary to face Metcalfe’s law head-on but instead to _steal_ the network effect of the existing network. Par ex: it’s very hard to compete with Twitter, but not so hard to give a user control over their own Twitter data (with a neat UI/UX to use Twitter too), especially if you get them include their own API key. From controlling your own Twitter data, you can move to mirroring it; from 1-way mirroring, to 2-way sync; from 2-way sync, to discarding the silo. No need to replace Twitter in one impossible step. Instead, baby steps for users to migrate off gradually, seamlessly, sans friction.

“…[the] more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus.”Vitalik Buterin (2013)

BLOCKCHAIN TECHNOLOGY

HISTORY

  • 1980s / 1990s
    • Anonymous – “e-cash” protocols mostly reliant on a cryptographic primitive known as Chaumian blinding good privacy but centralized
  • 1998
    • Wei Dai – “b-money” – creating money through solving computational puzzles – de jure decentralized no consensus on decentralized consensus
  • 2005
    • Hal Finney – “reusable proofs of work” combining of b-money with Adam Back’s “Hashcash” puzzles potential for cryptocurrency but relied on trusted backend (centralized)
    • Nick Szabo – “secure property titles with owner authority” – new advances in replicated database technology will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax.
  • 2009
    • Satoshi Nokamoto – “Bitcoin” – synthesis of ownership management primitives, public key cryptography and distributed proof-of-work consensus ledger
  • 2013
    • “Greedy Heaviest Observed Subtree” (GHOST) protocol is an innovation first introduced in December 2013 by Yonatan Sompolinsky and Aviv Zohar

DEFINITIONS

 

PROOF OF WORK

First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier – the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings.

PROOF OF STAKE (alternative to proof-of-work)

Calculating the weight of a node as being proportional to its currency holdings and not computational resources. Hello Klaus Schwab and organic recentralisation of power.

HOW DOES BITCOIN WORK?

State transition system (ledger): where there is a “state” consisting of the ownership status of all existing bitcoins and a “state transition function” that takes a state and a transaction and outputs a new state which is the result. Bitcoin is trying to build a decentralized currency system, so it needs to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin’s decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called “blocks”.  Each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state.

The one validity condition present in the above list that is not found in other systems is the requirement for “proof-of-work”. The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally “hard”, thereby preventing sybil attackers from remaking the entire blockchain in their favour. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.

MERKLE TREES

Scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The “hash” of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the “top” of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. 

LIGHT NODES

A protocol known as “simplified payment verification” (SPV) allows for another class of nodes to exist, called “light nodes”, which download the block headers, verify the proof-of-work on the block headers, and then download only the “branches” associated with transactions that are relevant to them.

BITCOIN BASED BLOCKCHAIN

Currently, all “light” implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.

ETHEREUM

Ethereum intended to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security. Smart contract Ethereum: “a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions.” Ethereum also includes, as standard, cryptographic “boxes” that contain value and only unlock it if certain conditions are met, etc.

References and Further Reading

  1. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
  2. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
  3. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
  4. Smart property: https://en.bitcoin.it/wiki/Smart_Property
  5. Smart contracts: https://en.bitcoin.it/wiki/Contracts
  6. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
  7. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
  8. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
  9. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
  10. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
  11. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
  12. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
  13. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
  14. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
  15. Ethereum Dagger: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Dagger
  16. Ethereum C-like language: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-CLL
  17. Ethereum Slasher: http://blog.ethereum.org/?p=39/slasher-a-punitive-proof-of-stake-algorithm
  18. Scrypt parameters: https://litecoin.info/User:Iddo/ComparisonbetweenLitecoinandBitcoin#SHA256miningvsscryptmining
  19. Litecoin ASICs: https://axablends.com/merchants-accepting-bitcoin/litecoin-discussion/litecoin-scrypt-asic-miners/
  20. Liquid Democracy: https://en.wikipedia.org/wiki/Liquid_democracy


0