Friday 29 August 2014

Cryptocurrency (Ethereum & Bitcoin)

   Ethereum   
(open source platform enabling creation & distribution of decentralised apps)

About Ethereum and Bitcoin


  • DONE Ethereum Dev Plan "ĐΞV" (open, transparent, decentralised future) 
    • Helper Protocols codenamed "Whisper" and "Swarm"
    • Base-level Apps
      • Dev Environment
      • Debugger for Contracts & Distributed Apps "Đapps" 
      • Reputational System (enhance Economic & Social interactions)
      • Identity System (Fair distribution of App Sub-Tokens)
      • Name Registries (for Contracts, Web Pages, Wallets, and an App Store)
    • "Đapps" Opportunities
      • Currencies
      • Consumer Protection
      • Crowdfunding Apps
      • Civil Liberties
      • International Finance & Contracts
      • Law
      • Lotteries
      • Sustainability
      • Decentralised Exchange (b/w ETH-based Assets & Different Cryptocurrencies)
      • Decentralised Marketplace
      • Financial Applications (i.e. Hedging, SchellingDollar, Insurance)
      • Escrow, Consumer Protection and Arbitration
      • Content Publishing (Incentivisation for Content Creators)
      • Decentralised Advertising Protocol
      • Decentralised Organisation Management
    • "meta-Đapps" Opportunities (Core "Đapps" that Help other Đapps)
      • Đapp Store
      • User Utilities
        • Wallets (Usability, Security, Withdrawal Policies including Limits and Two-Factor Auth, Ability to use Ethereum-based and Other Cryptocurrencies)
        • Messaging (i.e. "Whisper" with open-source P2P chat systems supported by EtherBrowser for onboarding)
      • Name Registries (several)
      • Reputation System in the DAO
        • Trust-networks between Users, and Đapps themselves that are Effective for successful e-commerce (i.e. Honest vs Scam, Skilled vs Unskilled, Highly-Leveraging Reputation vs..., etc) 
      • Identity System 
        • Reputation
          • CAPTCHA Schemes (Completely Automated Public Turing Test to Tell Computers and Humans Apart)
      • Anti-Sybil System (robust replacement High-Trust situations i.e. Passports)
      • Decentralised Governance Utilities { i.e. People's Republic of DOUG (operates like kernel of DAO, GitHub: Source Code } 
    • Tools Available (in Ethereum 1.0)
      • Ethereum Protocol
      • Ethereum Reference Clients, written in:
        • C++
          • Primary Development Client (build & debug Contracts and  "Đapps", Code Editing Tools, Libraries, SDKs for Contract Programming Languages (i.e. LLL, Serpent, Mutan) and JS) 
        • Go   
          • EtherBrowser (aka ĐBrowserto access "Đapps" based on Webkit and Qt, and supported by backbone Protocols (Etherium, Whisper, Swarm)
          • Ethereum Protocol (Contracts) - Basic implementation is a webpage with QML/JS (Back-end) and HTML/CSS/JS/QtQuick (Front-end) with Eth object as JS API to interact with Blockchain, accessible within Go Client to use the "Đapps"
          • Whisper Protocol (Dynamic Comms) - Generic P2P Decentralised Messaging Protocol, Message Time-to-Live & Priorities, Broadcast Messages to Subscribers Asyncronously, Nodes with Tag (aka Topic) Filters
          • Swarm Protocol (Net, Filestore) - File Storage and Decentralised Transmission Protocol where Static Web Content (i.e. HTML/JS/CSS) Hosted will be addressable by its Hash and stored in the P2P network
        • Python
          • Command-Line Client with minimal GUI
        • JavaScript
          • In-Browser Education, and Browser-Extensions
        • Java
          • Back-end for hardware and smartphone installations
        • Clojure (In development)
        • Objective-C (In development)
        • Node.js (In development)
      • Programming Languages & Compilers (Serpent, LLL, Mutan)
      • JavaScript API
      • Block Protocol (Concept) allowing 12-sec Block time
      • Proof of Work (Alpha Concept)
    • Tools In-Progress (see "Etherium 1.0 Summary Roadmap" (i'd like to help out with... ) )
      • Security Auditing
      • JIT Compilation as an Optimisation Strategy
      • Interface for Browser and IDE
      • Multi-Wallet & Permission System (to limit activity/consumption of Ether by Apps)
      • Production Ready Dev Environment for Decentralised Apps (start-to-finish, including JS/QML and Contracts, Integration Testing, Multi-Language Support, Syntax-Aware Code Editor)
      • Test suite Library for Consensus and Security of the EVM for a recursive Turing-Complete VM Spec with metered computation for egalitarian handling of program and input data
        • Simplistic Consensus Mechanism to Detect Failure and Raise Early Warning System (i.e. overcome Buffer Overrun Attacks)
        • "Đapps" Store with Multiple Layers combining Permission Systems, Custom Contract Certification Systems (Assurance), Reputation Systems, and Formal Proofs, to overcome potentially malicious Contracts or misleading Đapps
    • Tools Excluded 
      • Peter Todd's Tree Chains
      • Merge-Mined Hypercube Chains
      • Proof-of-Resource
      • "Moon Math" Advanced Cryptography Strategies { Eli Ben-Sasson's Succinct Computational Integrity and Privacy (aka SCIP, PCP, zk-SNARK) }
        • Fully Homomorphic Encryption (Ability to Run a Function on Encrypted Data and get Encrypted Result without knowing what the Data is, allowing Cloud Computing Privacy)
        • SCIP (Efficient and Verifiable Proofs that Long Computation has a given Result)
        • Obfuscation (Ability to Run an Encrypted Function on Data without knowing what the Function is, this allows Scripts with Private Data to be Run on Blockchains)
      • Lamport Signature Algorithms resistant to Quantum Computing Attacks
    • Tools Unknown (whether to be included in Ethereum 1.0)
      • Consensus
        • Transaction-as-PoS (Proof-of-Stake)
        • Delegated-PoS
        • Useful PoW (Proof-of-Work)
        • Next-Generation Centralisation/ASIC-Resistant PoW
        • Exotic Strategies for Bandwidth and Storage
    • Benefits of Diversity 
      • Cleaner Protocol
      • System Robustness Increased
    • Ethereum Installation

  • DONE Ethereum Whitepaper  (Overview of the Platform and Implementation)  (Luke's Summary of the Whitepaper is document below, Feedback is Welcome!)
Bitcoin (Page 1-12 of the Whitepaper)
  • Bitcoin Dfn: "decentralized peer-to-peer online currency that maintains a value without any backing, intrinsic value or central issuer", invented by Satoshi Nakamoto in 2009 (Ethereum Whitepaper, 2014, p1)
  • Opportunities (for Blockchains) (see Pages 10 - 11 for details)
    • On-Blockchain Smart Contracts (Digital Asset Control to specified Rules), Colored Coins Protocol (Custom Currencies with color assigned publicly to specific Bitcoin UTXOs), Metacoin Protocol (mechanism for advanced features built on top of the Bitcoin Protocol), Smart Property (registries), Namecoin (decentralised Name Registration Database, non-Fungible Asset), Decentralised Exchange, Identity and Reputation Systems, DAOs, Smart Law
  • Decentralised Autonomous Organisations (DAOs) Dfn - Smart Contracts with Assets and Bylaws of Orgs that need to interact
  • Deterministic Concept: Decentralised (rather than reliance on traditionally centralised trusted backend intermediaries) digital currency overcomes privacy concerns of using cryptographic security protocols, and overcomes the "race condition" by allowing intrinsic determination of the order of transactions through Blockchains
  • Consensus System (CS) - Decentralised Consensus Protocol & Process is based on the Bitcoin Blockchain Model, where decentralised currencies are reliant on First-to-file where order of transactions is important, which necessitates Protocols to achieve a multi-party Decentralised Consensus. Persistent Blockchains that constantly update, which represent the Bitcoin Ledger (its latest State) are created by distributed Nodes in a network continuously producing ever-growing packages of transactions (called Blocks), and combining the Transactions (i.e. creation or transfer of a Smart Contract) into a Block every 10 mins. Nodes gain the Right to participate (Data Mine) in the system based on a "proof of work" (PoW) mechanism, whereby their Influence is proportional to their Computational Power.
  • State Transition System (STS) - Blockchains with built-in coding language (customisable) that describes the logic of the State Transition System (transaction ledger with ownership status, and KV pairs in a Black Box leveraging a State Transition Function that converts input state to output state with error control) for creation and encoding of Smart Contracts for given systems 
  • Block - Stored in multi-level Data Structure having a Block Header (~200-bytes of Data) with the following contents:
    • Timestamp
    • Nonce (for use at the present occasion)
    • Previous Block Hash
    • Root Hash of the Data Structure (aka Merkle Tree storing all Transactions of the Block)
    • Note: It does not encode the State (handled by the validating Node)
  • Block Validation Algorithm (see Page 7 of the Whitepaper)
  • Merkle Tree Protocol (see diagram on Page 9 of the Whitepaper) - Binary Tree type whose Purpose is long-term Sustainability, allowing Block Data to be delivered piecemeal whilst ensuring accuracy of Data. It proposes checking only a small quantity of Nodes in the Merkle Tree to achieve "Proof of Validity" of a Blockchain (any Block change eventually leads to inconsistency being detected up the chain). It comprises the following Nodes:
    • Top Nodes - Root Node formed from Hash of its two Child Nodes
    • Intermediate Nodes - Also each having two Child Nodes, and formed from these
    • Bottom "Leaf" Nodes - Containing the underlying Block Data
    • Note:  In the Bitcoin network a Full Node that stores and processes every block in entirety is ~15Gb as at Apr 2014, growing 1Gb per month)
  • SPV Protocol (Simplified Payment Verification) - Uses Blockchain depth as a proxy for validity, where "Light Nodes" only download Block Headers to verify "Proof of Work", and then only download Branches of Nodes from the Merkle Tree containing relevant Transactions with strong Security guarantee (avoids having to download the entire Blockchain just to simply check the Transaction Status and Current Balance)
  • State - The "State" of Bitcoin is the collection of minted coins that are Unspent Transaction Outputs (UXTO)
  • UXTOs - Comprise the:
    • Owner (20 byte address aka cryptographic public key)
    • Inputs of the Transaction (containing Reference to existing UTXO and cryptographic signature generated by private key of Owner's address)
    • Outputs of the Transaction (new UTXO to be added to the State)
  • Nodes (aka Data Miners) Responsibility & Purpose
    • Responsible for using the Block Validation Algorithm to Validate and remember Abstractions of the State by securely computing Blocks with the correct order of transactions, starting from the Genesis State and sequentially applying every Transaction of every Block
    • Data Miners add an initial Block Number, then Chain additional Block Numbers after it to create a Blockchain (where each Block Number must point to a valid Transaction that is in-State, in order to "confirm it" and cause the Merchant to accept payment)
    • Legitimate Data Miners (see Page 8 of Whitepaper) work on the "longest" Blockchains in a Fork and consider it to be the Truth (as it is supported by the largest quantity of "Proof of Work"). Attackers of a Blockchain must have more computational power than the rest of the network combined to catch up and make the longest Blockchain to achieve a 51% (Majority) Attack
  • Decentralised Currency System (DCS) - Centralised services are untrustworthy and necessitate a Decentralised solution to ensure agreement on the order of transactions by leveraging DCS = STS + CS
  • Existing Scripting offered by Bitcoin
    • Weak version of the "Smart Contract" already exists in the Bitcoin Protocol
    • UXTO of Bitcoin can be owned by a Script in a Stack-based Coding Language (advanced alternative to just a Public Key) such that Transaction spending UXTO must provide Data satisfying the Script
    • Multisig - A Use-Case whereby a Script requires signatures from two out of three private keys to achieve Validation
  • Limitations of Scripting offered by Bitcoin (Page 12 of Whitepaper)
    • Lack of Turing-Completeness - Efficient approaches to subsets of computation including Loops are missing
    • Valid-Blindness - Unable to have UXTO Script provide "detailed" control over amount that can be withdrawn (see Page 12 for hedging contract example with an oracle that determines equivalent values between a traditional currency and a cryptocurrency) without an Inefficient Hack using many UXTOs of varying denominations (face values)
    • Lack of State - UXTO State is either Spent or Unspent. It does not yet include complex "Stateful" Contracts (Scripts with Extendable Internal States). So it can't necessarily support:
      • Multi-Stage Options Contracts
      • Decentralised Exchange Offers
      • Two-Stage Cryptographic Commitment Protocols (for Secure Computational Bounties)
      • Decentralised Organisations
      • Meta-Protocol implementation
      • Withdrawal Limits
    • Blockchain Blindness - Deprived of Randomness as the UXTO are blind to the Blockchain Data (i.e. Nonce and Previous Hash) making it difficult to support categories such as:
      • Gambling
  • Approaches to Building a Consensus Protocol - 2 OFF approaches:
    • Build an Independent Network 
    • Build a Protocol on top of Bitcoin (effectively what Ethereum has done, without eliminating the need for trust, which is a primary purpose of cryptocurrency)
  • Approaches to Building Advanced Apps on Cryptocurrency - 3 OFF approaches (effectively Ethereum is building a framework with advantages of all the below):
    • Building a New Blockchain  (unlimited freedom building feature set at low cost of development time and bootstrapping effort)
    • Scripting on top of Bitcoin  (easy implemented and standardized, limited capabilities)
    • Building a Meta-Protocol on top of Bitcoin  (potential faults in scalability)
  • Other Reading
    • Turing Complete (see The Annotated Turing) (do I have to ready everything?)
    • Chaumian Blinding (cryptographic primitive)
    • Wei Dai's b-money
    • Hal Finney "Reusable Proofs of Work" Concept (i.e. see Page 8 of the Whitepaper regarding different Block Data)
    • Adam Back's Hashcash puzzles
    • Secure Byzantine-Fault-Tolerant Multi-party Consensus Systems (systems that assume all parties in the system are known, and that provide security margins that can tolerate up to 25% of them being malicious)
    • Sybil Attacks (security margins susceptible to malicious behaviour in vulnerable anonymous settings whereby single attackers creates a botnet of infected and simulated nodes to secure majority share)
  • Q&A (online interview with answers from Stephan Tual, CCO @ Ethereum!!)  (slightly modified)
    • Q1) - Luke - What is Ether
    • A1) - Stephan - Ether is fuel
    • Q2) - Luke -  Was the Finney denomination named after Hal Finney’s "Reusable Proofs of Work" Concept?
    • A2) - Stephan -  Yes, bless his soul, RIP
    • Q3) - Luke -  What does the term “Value-Awareness” mean? (mentioned at the end of paragraph 2 on Page 13 of the Ethereum Whitepaper)
    • A3) - Stephan -  Ethereum Contracts can hold Ether, they are first class actors on Ethereum. You could build a contract that for example makes money selling something, and if you haven't programmed it to send you the profit, well, now you have one rich bot. Maybe the bot will buy a monocle or something.
    • Q3 Extension) - Luke -   I see, so the creator of an Ethereum Contract performs the role of an “oracle” figure, who now with the power of an in-built Turing-Completeness programming language that is being built, will have the capability of programming the Contract as being Value-Aware (an intelligent contract), and alternatively they also have the option of creating a Value-Blind Contract (if they don’t put much thought into it)?
    • A3 Extension) - Stephan -  Yes, in short, the Ethereum Contracts can be as dumb (validation machinery) or as smart (think intelligent agent) as you write them. That said it won't be Skynet, because Ethereum Contracts can't modify themselves anymore (we removed that), but they can copy themselves with transformations if needed (although it would be fairly expensive gas-wise).
    • Q4) - Luke -   What does Altcoins mean at Ethereum?
    • A4) - Stephan -  At its core, a Metacoin is a ledger protected by Consensus, so on Ethereum a Metacoin looks like a Ledger (i.e. basic idea is that given Person1.coins == 1 and Person2.coins == 2, when Person2 sends 1 coin to Person1, its simply a matter of Person1.coins++ and Person2.coins - -). Since Block Resolution, Protection via PoW/PoS hybrids is handled by Ethereum, it leaves the creator of the Metacoins to focus on the Issuance Model (i.e. 1MW of clean energy, 1 hour of CPU time on BOINC , or a Foursquare check-in). As such, trivialising Metacoins forces Innovation as anyone (any Tom, Dick, or Harry), will be able to build one. Then there's the COINBASE Opcode in Ethereum, where Miners can be Rewarded in Metacoins in the Ethereum chain, which means that Metacoins can be actually Mined In-Contract using whatever Crypto Function you'd like. Ethereum made SH3 as an Opcode to make things easy, but you can build your own Custom Opcode using a Native Contract Extension like C++ if desired.
Ethereum  (Page 13 onward in the Whitepaper)
    • Ethereum Dfn:   "a next-generation cryptocurrency platform that allows you to make a potentially unlimited range of smart contracts, transaction types and decentralized applications on the blockchain", invented by Vitalik Buterin in 2009 (Buterin, 2014)
    • Ethereum Intent:   "Ethereum is building a decentralized web. Our goal is to make it trivial to build blockchain apps, trivial as in 'you know html and a bit of javascript'", correspondence with Stephan Tual, CCO, Ethereum (Tual, 2014)
      • Concepts merged and improved:
        • Scripting
        • Altcoins (see Q&A responses above)
        • Meta-Protocols (on-chain)
      • Developers may create Consensus Protocol Apps with:
        • Scalability
        • Standardization
        • Feature-Complete
        • Ease of Development & Interoperability
    • Ethereum is Building - An Abstraction Foundation Layer
    • Abstraction Foundation Layer:
      • Blockchain with Turing-Completeness coding language, Value-Awareness, Blockchain-Awareness, and State
      • Smart Contracts (cryptographic boxes) and Decentralised Apps can be written by anyone
      • Customisable Ownership Rules, Transaction Formats, State Transition Functions
    • States - Comprise Objects called Accounts
    • Account Fields - Each having 20 byte address and State Transition
      • Nonce  (counter to ensure each Transaction only processed once)
      • Balance (of Ether currently)
      • Contract Code 
      • Storage
    • Account Types:
      • Externally Owned Accounts (Private Key Controlled but No Code, sends messages by creating and signing a Transaction)
      • Contract Accounts (Contract Code Controlled, such that when receive a message its Code activates, allowing read and write to internal storage, and then send other messages or create further contracts)
    • Ether - Internal crypto-fuel of Ethereum for Transaction fee payment 
    • Ethereum "Messages" -  Similar to Bitcoin Transactions, but with differences:
      • Creation by Contract is possible (not limited to just External Entities)
      • Data Contents within the Messages is an Explicit Option
      • Concept of Functions are encompassed in Contract Accounts allowing recipients the Option of returning a response
    • Ethereum "Transactions" - Signed Data Package that stores a Message to be sent, and contain the following:
      • Recipient (of the Message)
      • Sender Signature (identifying them)
      • Amount of Ether and Data to Send
      • Value of STARTGAS
      • Value of GASPRICE
    • STARTGAS Dfn - Limit of Computational Steps of code execution that the lifecycle of Transactions associated with a Message can spawn (must be set to prevent code exponential blowup and infinite loops)
    • GASPRICE Dfn - Fee paid to Miner per Computational Step
    • Ethereum Contracts - Creation of Ethereum Contracts (rather than just limited to an External Entities) have a separate Transaction Type and Message Type, containing:
      • Contract Address (calculated based on Hash of Account Nonce and Transaction Data)
    • Ethereum's "First Class Citizen" Property - 
      • Contracts may Serve Different Roles (as a result of the Message Mechanism allowing them to have Equivalent Powers to External Accounts, such as the ability to Create other Contracts, and Send Messages)
      • Example
        • Given this scenario |  C#3 <=> C#2[C#1] <=> C#4 | where an Escrow Account (Contract #1) that's a Member of a Decentralised Org (Contract #2), where C#1 (Member of C#2) is between a Paranoid Individual employing Custom Quantum-Proof Lamport Signatures (Contract #3) and the Account of a Co-Signing Entity that uses Five Keys for Security (Contract #4).
        • Ethereum's Platform has the strength to empower C#1 so they do not need to care about what kind of account each party to the contract is (as each Party can do everything that all other Parties can do through Ethereums Turing-Completeness coding language in the Abstract Foundation Layer)
    • Ethereum's "State Transition Function" Dfn - APPLY(S, TX) -> S' (refer to detailed Example on Page 16 of the Whitepaper)
      • Verify Transaction - "Well-Formed" else Return Error
      • Transaction Fee at Commencement - STARTGAS * GASPRICE Ether is deducted from Sender & Increase their Nonce
      • Transaction Fee per Bytes in Transaction - Deducting Gas per Byte after Initialise Gas (GAS = STARTGAS)
      • Tx Transaction Value - Transfer (Tx) from Sender to Receiver. Run Contract's code until Complete or "Run out of Gas" (if Receiving Account is a Contract)
      • Ethereum "Transactions" that "Run out of Gas" 
        • Transaction Execution Halts
        • Fees are Paid to Miners
        • Fees are Refunded to Sender (Remaining Gas portion)
        • Revert All other State changes 
      • Ethereum Successful "Transactions" 
        • Fees for All Remaining Gas Refunded to Sender
        • Fees Paid for amount of Gas consumed issued to the Miner 
      • Ethereum Gas Limits - Contracts can set strict Gas Limits to Sub-Computations they can spawn to secure limited Computational Resources
    • Ethereum Contract Code - Smart Contracts are written in higher-level languages to be human-readable (i.e. Serpent (Python inspired), Mutan (Go inspired), or LLL (LISP inspired) and compiled down to low-level EVM-code (Ethereum Virtual Machine code) to run on Ethereum Clients (see Smart Contracts FAQ on Ethereum's Forum)
    • EVM-Code Execution Model (see Page 17 of Whitepaper)
    • Ethereum Blockchain Architecture & Mining - Similar to Bitcoin's Blockchain, except that Ethereum Blocks contain:
      • Copy of Transaction List
      • Copy of Most Recent State
      • Block Number
      • Difficulty
    • Etherium Block Validation Algorithm (see Page 18 of Whitepaper) (why does only validate blocks that are timestamped less than 15 minutes after a previous block? what is an 'uncle' root referring to?)
    • Merkle Patricia Trie - Extra complexity is added to the data structure to create a modification to the Merkle Tree Concept that allows Nodes to be efficiently Inserted & Deleted (not just Changed), and overcomes inefficiencies due to the limitations of Radix Trees. Note: "Trie" comes from the word "Retrieval".
      • Last Block - Strategy whereby the Last Block contains all the State Information overcomes the need to store entire Blockchain History resulting in 5-20x space saving (if could be applied to Bitcoin)
    • Ephereum Applications -
      • Financial Applications -
        • Commercial Contracts (Powerful ones) 
        • Sub-Currencies (On-Blockchain Token Systems that implement Fundamental Transaction logic into a Contract that could represent Smart Property, Secure Unforgeable Coupons, Non-Value Token Systems, i.e. basic "Banking System" State Transition Function + Distribution of Currency Units + Edge Cases + Permit Queries for Address Balance from Other Contracts + Ability to Pay & Receive Transaction Fees Directly in that Currency)
        • Financial Derivatives & Stable-Value Currencies & Hedge Contracts (i.e. Hedging Contract that hedges against volatility in Ether by leveraging a Smart "Data Feed" Contract aka API interface maintained by say NASDAQ that's designed to be updated so other contracts can send it Messages and receive Responses with the latest ETH/US external price ticker reference value) (when will banks evolve $2 ATM fees into flat $2 API transaction fees?)
        • Savings Wallets (see bottom of Page 24 in Whitepaper), Full-Scale Employment Contracts (will exhorbitantly expensive legal advice finally become an affordable commodity trade?)
        • Insurance (i.e. Crop Insurance, see dot point 2, Page 25 in Whitepaper)
        • Smart Multi-Signature Escrow { Ethereum allows for more Granularity (more detailed Rules on spread of Spending Authority), and Ethereum Multisig is Asynchronous (Transaction Auto-sent when last signature obtained) } (see dot point 4, Page 25 in Whitepaper) 
        • P2P Gambling - Implement P2P Gambling Protocols on Ethereum Blockchain, such as: Frank Stajano, and Richard Clayton's Cyberdice { Protocol that resists Collusion, Drop-outs, Dishonesty from "Dealers" & "Gamblers" but relies on Honest Behaviour of Non-Gambling "Issuers" (Escrow Account, not a Bank) whose role is to Issue and convert Currency into Bit Strings (aka Messages) for a Fee and convince Independent Auditors they acted to Deterministic criterion } (see also Dolev-Yao Adversaries Model)
        • Other Economic Layers - Levering Ethereum's Open-Ended Design to establish itself as a Foundation Layer for future Protocols, increasing the Efficiency of the Computational Industry, and providing massive boosts to existing P2P Protocols }
      • Semi-Financial Applications - { 
        • Bounties that are Self-Enforcing for Solutions to Computational Problems
        • Decentralised Data Feed using SchellingCoin Protocol (players with estimates within bell curve as determinants of True Value of some Application i.e. weather, difficult computations, etc(see dot point 4, Page 25 in Whitepaper)
        • Cloud Computing Platform & Tasks Parallelization { Verify Correctness in Proofs of Computation with Spot-Checking at Checkpoints together with Security Deposits to ensure Trustworthiness (see dot point 5, Page 25 in Whitepaper) } 
        • On-Chain Decentralised Marketplaces - using Identity and Reputation System as a base }
      • Non-Financial Applications - { 
        • Voting Online
        • Decentralised Governance
        • Web Page Storage using Ethereums decentralised protocols }
    • Crypto-Commerce
      • Option #1 - Issuer-Backed Assets Mechanism - Single Issuer (high likelihood of untrustworthiness) creates a Sub-Currency, having the funds to back up an asset (having the Right to Issue/Revoke units) with promise to provide one unit of Currency for one unit of specified Underlying Asset (UA) (i.e. AUD, USD) and then promises to exchange one unit of the UA for one unit of Crypto-Asset (CA), effectively "Uplifting" Non-Crypto Assets into Crypto-Assets (provided the Issuer's promises are Trustworthy, when in reality they aren't) (confusing?)
      • Option #2 - Financial Derivatives - Decentralised Market of Speculators bet that Price of Crypto-Asset Reference will increase who are unable to Default on their side of the bargain (like Issues can), as Hedging Contract holds their Funds in Escrow (aka Third-Party). Although a "Trusted" (we hope) source is still required to provide the Price Ticker.
    • Identity & Reputation Systems - Register a Name in a public database alongside other Data with potential to add Reputation and Web-of-Trust Functionality on top.
    • Decentralised File Storage (see Page 22 - 23 of Whitepaper for "Decentralised Dropbox Contract" Example) - Ethereum Contracts allow for development of Decentralised File Storage Ecosystem where Users can earn income by renting unused space
    • Self-Regulatory Organisation (SRO) - 
      • Legal Process & Environment that prevents Undue Restriction using Ethereum
    • DAOs (Decentralised Autonomous Organisations) (see Page 23 of Whitepaper for DAO Example Code- Virtual Entities with Truly "Autonomous" Organisational Governance Protocol (without transitional Political-like Process) as described by "Robin Hanson's Futarchy Mechanism via Prediction Markets" with either an "oracle" or SchellingCoin, and a set of Shareholders, and with a majority having the right to spend Entity Funds and Modify Code, using Cryptographic Blockchain Technology for legal enforcement. Shareholders Collectively decide on Funds Allocation, such as:
      • Bounties
      • Salaries
      • Internal Currency to Reward work
    • Semi-DAOs
    • DAOification - Built on top of Ethereum. 
      • Multi-National Corporation          |    DAO (Decentralised Autonomous Orgs)
      • Corporate/Non-Profit                      |   Same
      • People, Resources, Rules Govern  |
      • Rules Govern                               |
      • Judicial System                           |   Rules Enforced in Decentralised Blockchain Publicly
      • Intelligence at Core                      |  Human Intelligence & Creative Inputs at Periphery
      • Automation at Periphery               |  Automation at Core
      • Distinction b/w Roles                   |  Remove Distinction (Staff, Investor, Client, Non-Staff)
      •                                                   |  Dynamic Relationships
      •                                                   |  Leverages Power Law Curve of People's Contributions  
      •                                                   |  New Org Mgmt (Liquid Democracy, Futarchy)
      •                                                   |  Merges DAO, Factory Automation, Artificial Intelligence
    • DACs (Decentralised Autonomous Corporations) - "Capitalist" Models of a DAO, with: 
      • Asset Management Functionality associated with:
        • Dividends
        • Tradable Shares (>=0)
      • 67% Vote by Shareholders for Decision Making
        • Liquid Democracy-style Vote Delegation by "Board of Directors"
    • DACs (Decentralised Autonomous Communities)
      • Equal Share in Decision Making (for each Shareholder/Member)
      • 67% Vote Required to (designed for organic growth and delegation of the task of Filtering members to specialist algorithms adopted depending on changes to alignment): 
        • Add or Remove a Shareholder/Member
        • Built-In Voting Ability for Features (i.e. Sending Transaction)
        • Liquid Democracy-style Vote Delegation
    • GHOST Protocol (help, this is difficult to grasp!) (Greedy Heaviest Observed Subtree) (see Page 26 of Whitepaper for Example) - GHOST is motivated by Problem effects such as:
      • Problems (Network Security Loss & Centralisation Bias) - the fact that Blockchains of mining pools with fast confirmation times have high "stale" rates of blocks; suffer from reduced security; and have high % of network hashpower allowing them to gain de facto control over the mining process.
      • Solutions - GHOST Solves the network security problem by including "stale" blocks in "uncles" for the calculation of which chain is longest (largest total "proof of work" backing it).
    • Uncles Dfn - Ethereum jargon that describes "stale" Ancestors of a Block, and "stale" children of its Ancestors (I could be wrong...)
    • Nephews Dfn (paragraph 2 of Page 26) - ???
    • Ethereum's Simplified 5-Level GHOST Implementation with Incentivisation (paragraph 3 of Page 26) - Miner Incentives impacting Efficiency and preventing Attacks, and the Hashpower of Miners as it relates to Centralization Gains (help!!!) 
    • Transaction Fee Regulatory Mechanism (Page 27 to 28) (sounds awesome, but help!...) - Prevent abuse, as every Transaction Published in the Blockchain imposes on the Network a Cost to Download and Verify it 
      • Tragedy-of-the-Commons Problems and Bitcoins use of the Default Approach with voluntary fees, relying on Miners to act as Gatekeepers setting dynamic minimums 
      • Flaw in Market-based Mechanism Cancels itself when given particularly Inaccurate Simplifying Assumption - Based on argument 
      • ...
    • Computation & Turing-Completeness (Page 28) 
      • Turing-Completeness - EVM-code is Turing-Complete meaning it can encode any computation conceivable including infinite loops
      • Commands: JUMP (Jumps to Previous Spot in code) JUMPI (Conditional Jumping)
      • Ephereum's Approach to the Halting Problem  (see Examples bottom of Page 28 & top of Page 29) - Halting Problem is the problem of determining whether a program will finish running or continue to run forever. Ephereum provides the ability for Contracts to call other Contracts, which opens the potential for malicious users to shut Miners and Full Nodes down by forcing them into infinite loops through recursion. Ephereum overcomes the problem by requiring Transactions & Messages to Set a Maximum Computational Steps they can take & Gas Limits (if execution takes longer or if execution stops halfway through, computation is reverted but fees still paid)
    • Turing-Incompleteness (Alternative) (see bottom of Page 29) - Difficult to manage
    • Currency & Issuance - 
      • Ethereum network's currency is Ether with purposes:
        • Liquidity Layer for Efficient Exchange between Different Asset types
        • Mechanism for Paying Transaction Fees
      • Pre-Labelled Denominations
        • 1: wei               (Technical Discussions of Fees & Protocol Implementation)
        • 10^12: szabo  (As above)
        • 10^15: finney  (Micro-Transactions)
        • 10^18: ether   (Ordinary Transactions)
      • Issuance Model & Breakdown (see Page 30 & 31)
    • Mining Centralisation - 
      • Bitcoin Mining Algorithm - Miners compute SHA256 on modified block headers repeatedly until a Node discovers a version with Hash less than Target (around 2^190), which is vulnerable to two forms of Centralisation:
        • ASICs (App-Specific Integrated Circuits) Dominance in Mining Ecosystems whereby chips designed to be ultra efficient at task of mining, so Bitcoin mining no longer highly Decentralised and Egalitarian pursuit, as it now requires millions of $ to effectively participate
        • Centralised Mining Pool is relied upon to by Bitcoin Miners to provide the Validation of Block Headers, whereby the top two Mining Pools indirectly control 50% of Processing Power in Bitcoin network
      • Ethereum Mining Algorithm Intent - Base it on Randomly generating Unique Hash Function for every 1000 Nonces with broad range of computation to remove benefit of specialised hardware to reduce the gain of Centralisation to below a ratio of Electricity and Hardware (see Page 32) so ordinary Miners can benefit too. Additionally, design it so Mining requires Access to Entire Blockchain forcing them to store the Entire Blockchain and be capable of Verifying every Transactions to remove need for Centralised Mining Pools and instead serve with P2P Pools with no central control and increasing the quantity of Full Nodes.
    • Scalability
      • Concerns - 
        • Transactions need to be processed by All Nodes in a network and Ethereum is likely to suffer a growth pattern where many Apps are on top of Ethereum Blockchain (instead of just a Currency like Bitcoin), but is overcome by the fact that Ethereum Full Nodes only need to Store the State instead of the Entire Blockchain history.
        • Centralisation Risk of large Blockchain sizes is that say, if the Blockchain size increases to 100TB then there would likely be on a few large businesses running Full Nodes, with regular users using light SPV Nodes. The problem of Collusion currently being experienced by Bitcoin arises since the Full Nodes could band together and agree to Cheat in a profitable fashion undetected immediately, and detected when it's too late.
      • Ethereum Solution Strategies (see bottom of Page 33)
    • Decentralised App Specs
      • Low-level Business-Logic Components
      • Ethereum Clients  Design (Web-browser) with "eth" Javascript API Object support for interaction with the Ethereum's Decentralised Protocols and Blockchain (acting as a Server)
      • Other Systems (i.e. P2P Messaging Layer)
      • High-level GUI Components
    Financial Investment
    • Coinjar.com (BitCoin for Australias, simply verify your ID with greenId and deposit from your local bank account, receive $5 Free for signing up)
    • Ethereum (Exchange your BitCoin for Ethereum)
    Developers (Open State)
    Community & News
    Articles
    Landscape
    • Mintchalk (a GitHub-like repository for Smart Contracts based on Serpent used in Ethereum)
    • Stellar (this looks very interesting, shout out to Dylan Flood) (GitHub Link
    • Ursium (The World's First Crypto Consultancy)
    Abbreviations
    • ASIC - Application-Specific Integrated Circuits
    • BBO - Black Box Obfuscation 
    • Cryptoeconomics = Math + Cryptography + Economics + Game Theory
    • Delta Caching - Caching the difference between two different documents to acheive optimisation somehow? 
    • DHT - Distributed Hash Table potentially used to store a Pointer to a third-party P2P data storage pool instead of trying to store lots of data in a field of the Blockchain
    • DSA - Digital Signature Algorithm
    • ECDSA - Elliptic Curve Digital Signature Algorithm is a Cryptographic Algorithm used by Bitcoin to ensure funds only spent by rightful owners
    • GFS - Generalised Feistel Structure (Type 1, Source-Heavy, Target-Heavy) encrypts a plaintext input with secret key into a ciphertext output using an iterated structure with numerous round functions
    • Hypercube - Type of Structured network
    • Lamport Signature Algorithms - Method for constructing a Digital Signature
    • Peter Todd's Tree Chains
    • QML - High level scripted language that leverages Qt libraries and modules (i.e. Qt WebKit and the WebView API) and uses JavaScript to implement high level user interface logic
    • QtQuick - Software for writing QML applications
    • SCIP (by Eli ben Sasson) - Succinct Computational Integrity and Privacy
    • SHA3 - a Cryptographic Hash Function
    • Slasher - "Proof-of-Stake" Algorithm (takes money to create work) used for Mining functions (has advantages over "Proof-of-Work" Algorithm, which instead takes computational power to create work) 
    • Toroken - Incentivised TOR (The ONION Router, "The Onions have layers Donkey") Relays (TOR is where a group of nodes pass encrypted packets that eventually exit the system at an "exit node")
    • TPS - Transactions per Second