├── .gitignore ├── Decentralized Prediction Markets.md ├── Forks Compilation.md ├── LICENSE ├── Op Codes.md ├── Orphans.md ├── Proof Of Stake.md ├── README.md ├── Transaction Fees.md ├── Utxo Commitments.md └── backups ├── 15d12ce7 ├── 2d99ca75 ├── README.md ├── be390dbf └── c84b4a98 /.gitignore: -------------------------------------------------------------------------------- 1 | .*~ -------------------------------------------------------------------------------- /Decentralized Prediction Markets.md: -------------------------------------------------------------------------------- 1 | ## Overview 2 | 3 | A prediction market enables the trading of uncertain future outcomes. An 4 | example prediction market offers the question "Will Hillary Clinton win the 5 | 2016 US Presidential election?". The possible answers are 'yes' and 'no', and 6 | everyone who owns shares of the winning answer will receive $1. Shares can be 7 | traded, and the price of each share indicates the probability of that result 8 | becoming true. 'Yes' trading for 65% indicates that Hillary Clinton, as 9 | perceived by the market, has a 65% chance of winning the election. In a 10 | sufficiently liquid market, 'No' will trade for 35%. 11 | 12 | A decentralized prediction market is a prediction market that is not controlled 13 | by a centralized party, and generally pursues features such as censorship 14 | resistance, manipulation resistance, and privacy for the participants in the 15 | system. 16 | 17 | The most notable existing decentralized predicion markets are Truthcoin and 18 | Augur. Each has a significant amount of criticism and skepticism stacked 19 | against it, though mostly only existing in an informal context. 20 | 21 | #### Vocabulary 22 | 23 | **Arbiter**: A fallible entity that must be trusted to provide correct 24 | information about the physical world. 25 | 26 | **Oracle**: While often referring to something that can provide any information 27 | as an act of God, within the context of prediction markets 'Oracle' typically 28 | refers to an entity that can accurately provide information about the physical 29 | world. 30 | 31 | **Trust Agility**: Trusting a central authority, but with the ability to choose 32 | a different trusted authority on short notice, with little risk, and with 33 | little cost. 34 | 35 | ## High Signal Links 36 | 37 | 2014-??-?? - [On Decentralizing Prediction Markets and Order Books](https://www.cs.princeton.edu/~kroll/papers/weis14_prediction.pdf) - 15d12ce7 38 | 39 | 2015-10-07 - [Truthcoin Whitepaper](http://www.truthcoin.info/papers/truthcoin-whitepaper.pdf) - 2d99ca75 40 | 41 | 2015-??-?? - [Augur: a Decentralized, Open-Source Platform for Prediction Markets](http://augur.link/augur.pdf) - c84b4a98 42 | 43 | ## Low Signal Links 44 | 45 | 2015-10-?? - [Stake Oracles](http://pastebin.com/wtwW4njR) - be390bf 46 | 47 | 2014-03-28 - [SchellingCoin: A Minimal-Trust Universal Data Feed](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) 48 | 49 | 2015-02-26 - [A Decentralized Lie Detector](http://www.augur.net/blog/a-decentralized-lie-detector) 50 | 51 | 2015-06-27 - [Building a better lie detector](http://www.augur.net/blog/building-a-better-lie-detector) 52 | 53 | --- 54 | 55 | #### Contributors 56 | 57 | David Vorick 58 | -------------------------------------------------------------------------------- /Forks Compilation.md: -------------------------------------------------------------------------------- 1 | # Forks Compilation 2 | 3 | 4 | ### High signal links 5 | 6 | 2015-06-20 - [BIP 99 - Types of forks and deployment mechanisms][bip99] 7 | 8 | 2013-03-12 - [Recommendation to miners and merchants in the aftermath of the fork][0.7_fork_alert] 9 | 10 | ### Low Signal links 11 | 12 | 2013-03-12 - [Conflict between the v0.8 and v0.7 versions of bitcoind, causing historic forking event in 2013][0.7_fork_event] 13 | 14 | 2015-05-10 - [Fork to extend transactions with UTXO info, saving space in node UTXO databases][UTXO-extend] 15 | 16 | 2014-11-03 - [Wishlist of changes to be made in next hard fork][hardfork-wishlist] 17 | 18 | 2013-10-09 - [Soft-fork proposal for nLockTime upper limits as well as lower limits][upper-nLockTime] 19 | 20 | 2013-07-15 - [Suggestion that increasing currency divisibility requires only a soft fork][soft-fork-div] 21 | 22 | 2013-07-22 - [On the dangers of forking][fork-danger] 23 | 24 | 2013-08-19 - [CoinWitness: soft-fork proposal for blockchain compression via SCIP proof-based checking][CoinWitness] 25 | 26 | 2013-04-18 - [Soft fork proposal for subchain system with faster confirms][subchain] 27 | 28 | 2013-07-20 - [Ideas on soft fork difficulty adjustment][difficulty] 29 | 30 | 2013-07-25 - [Proposal to avoid a repeat of the v.0.8 upgrade forking problem][handling-forks] 31 | 32 | 2015-05-21 - [Proposal for 'helix' system in which header chain loops through parallel subchains, allowing increase in block rate while holding conf time constant][helix] 33 | 34 | 2015-01-06 - [Problems in bitcoin core that led to 2013 forking event][core-problems] 35 | 36 | 2015-02-03 - [Transcript of Epicenter Bitcoin interview with Adam Beck and Greg Maxwell on sidechains][eb-65] 37 | 38 | 39 | [//]: ## 40 | 41 | [0.7_fork_event]: 42 | [0.7_fork_alert]: 43 | [bip99]: 44 | [UTXO-extend]: 45 | [hardfork-wishlist]: 46 | [upper-nLockTime]: 47 | [soft-fork-div]: 48 | [fork-danger]: 49 | [CoinWitness]: 50 | [subchain]: 51 | [difficulty]: 53 | [helix]: 54 | [eb-65]: 55 | [core-problems]: 56 | 57 | --- 58 | 59 | ##### Contributors 60 | 61 | Ray Wang, David Vorick, Jane Maunsell 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2015 David Vorick 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /Op Codes.md: -------------------------------------------------------------------------------- 1 | # Op Codes 2 | 3 | ### Summary 4 | 5 | Bitcoin uses a scripting system to implement transactions. A script is a series of "op codes" and their arguments. For example, 6 | 7 | From the Bitcoin wiki: 8 | >Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops. 9 | >A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide: 10 | > 11 | > a public key that, when hashed, yields destination address D embedded in the script, and 12 | > 13 | > a signature to show evidence of the private key corresponding to the public key just provided. 14 | > 15 | > Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all. 16 | > 17 | >A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally sent the Bitcoins now being spent, dictates the script operations that will occur last in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero). 18 | > 19 | >The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero. 20 | 21 | 22 | ### High-signal links 23 | 24 | https://en.bitcoin.it/wiki/Script 25 | 26 | Peter Todd discusses "merklized abstract syntax trees" 27 | https://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327 28 | 29 | Disccusion of OP_CODESEPARATOR 30 | https://bitcointalk.org/index.php?topic=52949.0 31 | 32 | Discussion of sidechains 33 | http://diyhpl.us/wiki/transcripts/gmaxwell-sidechains-elements/ 34 | 35 | Sidechain discussion transcript 36 | http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/ 37 | 38 | ### Low-signal links 39 | 40 | Proposed opcode (OP_OP_EXTEND) 41 | https://bitcointalk.org/index.php?topic=24651.0 42 | 43 | Proposed opcode (SIGHASH_WITHINPUTVALUE) 44 | https://bitcointalk.org/index.php?topic=181734.20 45 | 46 | Proposed opcode (OP_CHECKSIG2) 47 | https://bitcointalk.org/index.php?topic=258931.0 48 | 49 | Proposed opcode (OP_DROP) 50 | https://bitcointalk.org/index.php?topic=108423.0 51 | 52 | Proposed opcode (OP_EVAL) 53 | https://bitcointalk.org/index.php?topic=46538.0 54 | 55 | Proposed opcode (OP_RETURNTRUE) 56 | https://bitcointalk.org/index.php?topic=1106586.msg11773568#msg11773568 57 | 58 | Proposed opcode (OP_CHECKSEQUENCEVERIFY) 59 | https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010198.html 60 | -------------------------------------------------------------------------------- /Orphans.md: -------------------------------------------------------------------------------- 1 | ## Overview 2 | 3 | An orphan is an object with no known parent. Orphan also frequently refers to a 4 | block that is not in the longest known blockchain. 5 | 6 | #### Vocabulary 7 | 8 | **Orphan** - A block whose parent block is unknown. The term 'orphan block' is 9 | also frequently used in place of the term 'stale block'. 10 | 11 | **Stale Block** - A block that is valid but does not extend the longest chain. 12 | 13 | ##High signal links 14 | 2015-08-29 [Requesting parents for orphan transactions](https://bitcointalk.org/index.php?topic=1065390.0) 15 | 16 | 2015-08-29 [Adopting block chain orphans](https://bitcointalk.org/index.php?topic=194573.0) 17 | 18 | 2015-08-30 [How small blocks make deliberate orphan mining more costly](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002186.html) 19 | 20 | 2014-11-15 [What is the longest blockchain fork that has been orphaned to date?](http://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date/4638#4638) 21 | 22 | 2014-11-16 [How to avoid getting stuck in orphaned chains?](https://bitcointalk.org/index.php?topic=364191.0) 23 | 24 | 2015-08-29 [Propagating orphan block headers](https://bitcointalk.org/index.php?topic=219171.0) 25 | 26 | 27 | ##Low signal links 28 | 2015-08-29 [How a floating blocksize limit inevitably leads towards centralization](https://bitcointalk.org/index.php?topic=144895.0) 29 | 30 | 2015-08-29 [Reducing the chance for random reversal](https://bitcointalk.org/index.php?topic=244682.0) 31 | 32 | 2015-08-29 [Detecting and handling fork events](https://bitcointalk.org/index.php?topic=262281.0) 33 | 34 | 2014-11-15 [Chain reorganization](https://en.bitcoin.it/wiki/Chain_Reorganization) 35 | 36 | 2015-03-09 [Sidechains talk](http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/matt-corallo-sidechains/) 37 | 38 | 2015-08-29 [Decoupling transactions and POW](https://bitcointalk.org/index.php?topic=179598.0) 39 | 40 | 41 | --- 42 | #####Contributors 43 | Jinglan Wang 44 | 45 | -------------------------------------------------------------------------------- /Proof Of Stake.md: -------------------------------------------------------------------------------- 1 | ##Overview 2 | 3 | Proof-of-stake consensus is a power-efficient alternative to proof-of-work 4 | consensus. All modern POS schemes have significant security tradeoffs as 5 | compared to traditional proof-of-work. There are several operational 6 | cryptocurrencies using various forms of proof-of-stake, including centralized 7 | variants. 8 | 9 | #### Vocabulary 10 | 11 | **DPOS**: Delegated Proof-of-Stake - electing 'delegates' to find blocks. 12 | BitShare's variety of proof-of-stake. 13 | 14 | **Nothing at Stake**: A security issue with many proof-of-stake algorithms 15 | where it is costless to create competing blocks. The costlessness means that 16 | there is no reason to choose a single block as the winner of consensus, 17 | instead, numerous competing histories can be created, preventing consensus. 18 | 19 | **POS**: Proof-of-stake - abbreviation 20 | 21 | **POW**: Proof-of-work - abbreviation - what Bitcoin uses to achieve 22 | distributed consensus, frequently compared against Proof-of-stake systems. 23 | 24 | **Slasher**: A POS algorithm that punishes voters that submit votes for 25 | competing blocks. Slasher is ineffective against people who vote, then sell 26 | their stake, then use the old keys to create competing histories. 27 | 28 | **Weak Subjectivity**: Weak subjectivity is an algorithm for requiring a chain 29 | to be substantially (more than 1 block) heavier than the current chain before 30 | reorganizing to accept the other chain. Weak subjectivity solves a variety of 31 | long-term attacks (such as key selling attacks) at the cost of making 32 | bootstrapping a difficult and trust-requried process. 33 | 34 | ##High Signal Links 35 | 36 | 2015-03-22 - [On Stake and Consensus](https://download.wpsoftware.net/bitcoin/pos.pdf) 37 | 38 | 2015-10-06 - [Proof of Stake Summary Wikipedia](https://en.wikipedia.org/wiki/Proof-of-stake) 39 | 40 | 2015-07-07 - [Proof of Work Analysis](https://eprint.iacr.org/2014/765.pdf) 41 | 42 | 2015-02-01 - [Proof of Stake Security Issues](https://github.com/ConsensusResearch/articles-papers/blob/master/multistrategy/multistrategy.pdf) 43 | 44 | ##Low Signal Links 45 | 46 | 2014-??-?? - [Tendermint Consensus](http://tendermint.com/docs/tendermint.pdf) 47 | 48 | 2015-08-01 - [Casper POS Algorithm](https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/) 49 | 50 | 2014-11-25 - [Nxt Proof of Stake](http://www.scribd.com/doc/248208963/Multibranch-forging#) 51 | 52 | 2015-05-24 - [Proof of Stake Failures](http://cointelegraph.com/news/114359/the-inevitable-failure-of-proof-of-stake-blockchains-and-why-a-new-algorithm-is-needed) 53 | 54 | 2014-01-15 - [Slasher: Punitive POS](https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/) 55 | 56 | 2015-04-08 - [Decentralization and Proof of Stake](https://download.wpsoftware.net/bitcoin/asic-faq.pdf) 57 | 58 | 2014-11-25 - [Weak Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) 59 | 60 | 2015-03-20 - [Proof of Stake on side chains](https://bitcointalk.org/index.php?topic=997125.msg10835817#msg10835817) 61 | 62 | 2015-02-02 - [Proof of Stake Security Issues Discussion](https://www.reddit.com/r/Bitcoin/comments/2pvt1e/proof_of_work_proof_of_stake_and_the_consensus/) 63 | 64 | 2015-08-08 - [Review of Casper, POS Algorithm](http://bytemaster.github.io/2015/08/08/Review-of-Casper-Ethereums-proposed-Proof-of-Stake-Algorithm/) 65 | 66 | ##Other Forms of Consensus 67 | 68 | 2015-09-25 - [Stellar Consensus whitepaper](https://www.stellar.org/papers/stellar-consensus-protocol.pdf) 69 | 70 | 2015-09-25 - [Stellar Consensus Overview](https://medium.com/a-stellar-journey/on-worldwide-consensus-359e9eb3e949) 71 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Bitcoin Knowledge Systemization 2 | 3 | The primary goal of this repository is to simplify the process of learning the state-of-the-art with regards to Bitcoin and cryptocurrency in general. A first goal is providing links to all knowledge, and sorting the links by category. A second goal is summarizing each category and curating the links so that the most relevant information is easily accessible and noisier or redundant information sources are separated or pruned. A third goal is making sure that there is fluid and easy direction when learning - categories should comfortably link to prerequisite or related categories. 4 | 5 | A single link or discussion may be relevant to multiple categories. When this is the case, the link should appear in all categories. 6 | 7 | This repository is a work in progress. Some categories, such as 'Transaction Fees' should clearly be split into multiple categories, but not enough content has been curated yet to justify the split. Many obvious categories, such as snarks, are missing altogether. If there is something missing that you feel strongly about, please pitch in and make a pull request. 8 | 9 | Any high-signal content will be merged, especially during the early days of the repository. Every week at 8pm EST, a group of people get together to work for a few hours on the repository. 10 | 11 | ### Potential Sources of Information 12 | 13 | [Bryan Bishop - selected bookmarks](http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-selected-bookmarks.2015-09-09.txt) 14 | 15 | [Bryan Bishop - utxo-commitments or fraud proofs](http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt) 16 | 17 | [Bryan Bishop - big pile](http://diyhpl.us/wiki/bitcoin/big-pile/) 18 | 19 | [Brett Scott - an epic list of bitcoin research](https://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/edit?pli=1#gid=0) 20 | 21 | ### Overviews 22 | 23 | Overviews should be high signal and broad. Related topics should be mentioned. If anything is explained, it should be explained in the style of a reference, and not be explained as though the concept is being introduced to someone who doesn't know what it is. Introductory explanations and in-depth analyses belong in the 'high signal links' with an appropriate title. 24 | 25 | ### High Signal vs. Low Signal Links 26 | 27 | A high signal link contains content that is largely up-to-date and state-of-the-art, concise, and directly relevant to the category where the link is listed. 28 | 29 | A low signal link may contain content that is not fully up to date, may contain inaccurate content, or may contain large volumes of content that are not directly relevant to the category where the link is listed. 30 | 31 | Links are approximately sorted by signal strength. 32 | -------------------------------------------------------------------------------- /Transaction Fees.md: -------------------------------------------------------------------------------- 1 | ##Overview 2 | 3 | Transaction fees are coins in transactions that are given to miners when the transaction is mined into a block. The transaction fee is given to the miner, which provides an incentive for the miner to place the transaction into a block. There is a non-zero cost associated with including a transaction into a block, due to orphan risk. Infrastructure such as [IBLTs] and [Near Blocks] help reduce the orphan rate on larger blocks, and therefore help reduce the cost of adding a transaction to a block. 4 | 5 | Transaction fees establish a way to pick which transactions should go into a block. Transactions with insufficient fees may get stuck on the network, especially when mempools never accept a double spend of the outputs in an unconfirmed transaction. Policies such as [Replace By Fee] and [Child Pays for Parent] can help. Wallets can avoid making destined-to-fail transactions by participating in [Fee Discovery]. 6 | 7 | Fees are added to transactions by having the sum of the outputs of the transaction be less than the sum of the inputs of the transaction. People have infrequently added absurd transaction fees to a transaction by mistake. The transaction fee cannot be determined by looking at the transaction alone, additional information about the outputs being spent is required. These shortcomings have led to proposals such as [OP_FEE] and [OP_CHECKFEE]. 8 | 9 | The current block reward is 25 Bitcoins. Eventually, this reward will fall heavily towards 0. With a 0-value block reward, the primary source of income for miners becomes transaction fees. This can lead to issues such as [Fee Sniping] and [Underfunded Mining]. 10 | 11 | #### Vocabulary 12 | 13 | **Bogon Fee**: A transaction fee that is substantially higher than would would be expected. Example: 50btc when the average total block reward is around 25btc. 14 | 15 | **CPFP/CP4P**: Child Pays For Parent - a child transaction with high fees can incentivize miners to add the unconfirmed parent transaction to a block. 16 | 17 | **Fee Sniping**: Miners try to re-mine the most recent block so that they may steal the fees in the block. 18 | 19 | **RBF**: Replace By Fee - the outputs of an unconfirmed transaction are double-spent in a new transaction with higher miner fees. 20 | 21 | ##High Signal Links 22 | 23 | 2015-02-12 - [Replace by fee v0.10.0rc4] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007404.html) 24 | 25 | 2013-02-24 - [Fee backlogs discourage fee sniping] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002186.html) 26 | 27 | 2013-04-14 - [Funding network security in the future] (https://bitcointalk.org/index.php?topic=176684.0) 28 | 29 | 2015-05-26 - [First Seen Safe Replace By Fee] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html) 30 | 31 | 2014-04-28 - [Replace-by-fee scorched-earth without child-pays-for-parent] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html) 32 | 33 | ##Low Signal Links 34 | 35 | 2015-11-28 - [Replace by fee FAQ](https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/) 36 | 37 | 2015-06-29 - [Replace by fee deployment schedule] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009253.html) 38 | 39 | 2013-10-24 - [Have miners announce their required fees] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-October/003421.html) 40 | 41 | 2015-07-11 - [Random block size to facilitate a fee market] (https://bitcointalk.org/index.php?topic=1117914.0) 42 | 43 | 2014-08-07 - [SIGHASH_ANYONECANPAY extra inputs DoS attack] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-August/006438.html) 44 | 45 | 2015-11-23 - [Bogon Fees & Coinbase Forwarding] (http://gnusha.org/bitcoin-wizards/2015-11-23.log) 46 | 47 | 2015-06-10 - [SPV Fee Discovery mechnaism] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008549.html) 48 | 49 | 2014-04-24 - [Replace by fee game theory] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005504.html) 50 | 51 | 2013-04-29 - [OP_FEE - explicit transaction fees] (https://bitcointalk.org/index.php?topic=191003.0) 52 | 53 | 2013-11-22 - [OP_CHECKFEE - an opcode indicating the transaction fee] (so utxo can remain unknown to hardware wallets): https://bitcointalk.org/index.php?topic=343234.0 54 | 55 | 2013-09-23 - [Near Blocks for Fee Estimation] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-September/003275.html) 56 | 57 | 2015-02-12 - [Facing Replace By Fee] (http://sourceforge.net/p/bitcoin/mailman/message/33405247/) 58 | 59 | 2015-09-04 - [Fee pressure on utxo settling] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html) 60 | 61 | 2011-06-06 - [Future fee policy for relaying and mining] (https://bitcointalk.org/index.php?topic=12625.0) 62 | 63 | 2012-06-15 - [Fee policy for relaying and mining] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001533.html) 64 | 65 | 2011-11-07 - [Analysis of Bitcoin Pooled Mining Reward Systems] (https://bitcoil.co.il/pool_analysis.pdf) 66 | 67 | 2015-05-28 - [Replace by Fee is Harmful] (https://www.reddit.com/r/Bitcoin/comments/30lxo4/replace_by_fee_a_counter_argument_by_mike_hearn/) 68 | 69 | 2015-06-19 - [F2Pool enabled Full RBF] (https://www.reddit.com/r/Bitcoin/comments/3ae2e1/peter_todd_f2pool_enabled_full_replacebyfee_rbf/) 70 | 71 | 2015-05-07 - [Block size increase] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html) 72 | 73 | 2011-09-25 - [Network-Adjusted transaction fees] (https://bitcointalk.org/index.php?topic=45665.0) 74 | 75 | 2012-04-25 - [Mine in multiple pools to reduce variance] (https://bitcointalk.org/index.php?topic=78031.0) 76 | 77 | 2015-06-24 - [Fees are Inevitable] (https://www.reddit.com/r/Bitcoin/comments/3b0593/to_fork_or_not_to_fork/cshphic) 78 | 79 | 2014-06-09 - [Earn 1% more by mining replace-by-fee] (https://bitcointalk.org/index.php?topic=645120.0) 80 | 81 | 2015-06-18 - [Replace by Fee Cuts Waste - Reddit Discussion] (https://www.reddit.com/r/Bitcoin/comments/3aawqp/this_is_consensus/csb92so) 82 | 83 | ------ 84 | 85 | ##### Contributors 86 | 87 | David Vorick 88 | -------------------------------------------------------------------------------- /Utxo Commitments.md: -------------------------------------------------------------------------------- 1 | ## Overview 2 | 3 | Utxo commitments are hashes put into blocks that summarize the current unspent 4 | transaction output set. 5 | 6 | #### High-Signal Links 7 | 8 | 2015-05-04 - [Locally verifiable unspent transaction output commitments](https://bitcointalk.org/index.php?topic=1048021.0) 9 | 10 | 2013-12-20 - [BIP proposal: Authenticated prefix trees](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003921.html) 11 | 12 | 2013-10-19 - [Spending Outputs with Merkle Proofs](https://bitcointalk.org/index.php?topic=314467.0) 13 | 14 | #### Low-Signal Links 15 | 16 | 2011-06-24 - [Merkle tree of open transactions for lite mode](https://bitcointalk.org/index.php?topic=21995.0) 17 | 18 | 2014-03-28 - [miner commitments with compact proofs](https://github.com/bitcoin/bitcoin/pull/3977) 19 | 20 | 2015-05-10 - [Extending transactions to include UTXO info](https://bitcointalk.org/index.php?topic=1056866.0) 21 | 22 | 2014-03-03 - [Namecoin that sucks less](https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less) 23 | 24 | 2014-11-12 - [Auxiliary Header Format](https://github.com/TierNolan/bips/blob/00a8d3e1ac066ce3728658c6c40240e1c2ab859e/bip-aux-header.mediawiki) 25 | 26 | 2012-06-17 - [Trust-free lite nodes](https://bitcointalk.org/index.php?topic=88208.0) 27 | 28 | 2012-05-07 - [Using P2SH Hashes as the 'key' instead of txos](https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838) 29 | 30 | 2012-10-08 - [redblackmerkle - self balancing merkle trees](https://github.com/amiller/redblackmerkle) 31 | 32 | 2014-07-28 - [Unspent Transaction Output Based Certificates](https://bitcointalk.org/index.php?topic=713919.0) 33 | 34 | 2012-10-10 - [Pruning the Utxo Set](https://bitcointalk.org/index.php?topic=117716.0) 35 | 36 | 2013-05-13 - [Fundraising for Ultimate Blockchain Compression](https://bitcointalk.org/index.php?topic=204283.0) 37 | 38 | 2014-10-05 - [alt ideas](https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas) 39 | 40 | #### Other Utxo Links 41 | 42 | 2015-05-21 - [Helix Blockchains](https://bitcointalk.org/index.php?topic=1067534.0) 43 | 44 | 2012-07-06 - [Ultraprune - using utxo set instead of txn set](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-July/001645.html) 45 | 46 | 2015-08-30 - [Demurrage based utxo pruning](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-December/002031.html) 47 | 48 | 2015-07-21 - [Deleteting Abandoned UTXO](https://bitcointalk.org/index.php?topic=1129695.0) 49 | 50 | 2013-02-21 - [Allowing Blocks to be Prepared ahead of time](https://bitcointalk.org/index.php?topic=145677.0) 51 | 52 | 2014-11-03 - [Use block size hardfork to also implement utxo commitments](https://bitcointalk.org/index.php?topic=844944.0) 53 | 54 | Start from 52 55 | -------------------------------------------------------------------------------- /backups/15d12ce7: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DavidVorick/knosys/9d271f69a528f524fb577c5a06dd6f03415fc95c/backups/15d12ce7 -------------------------------------------------------------------------------- /backups/2d99ca75: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DavidVorick/knosys/9d271f69a528f524fb577c5a06dd6f03415fc95c/backups/2d99ca75 -------------------------------------------------------------------------------- /backups/README.md: -------------------------------------------------------------------------------- 1 | #### Backups 2 | 3 | A lot of the pages or sites or text listed in the knosys repository are linked 4 | to unstable/centralized places. This folder contains backups of at-risk data, 5 | with a SHA-256 checksum for the filename. 6 | -------------------------------------------------------------------------------- /backups/be390dbf: -------------------------------------------------------------------------------- 1 | First presented is the idea of a 'Stake Oracle', which is a generalization of 2 | existing concepts appearing in modern decentralized prediction markets such as 3 | Truthcoin [1] and Augur [2]. Second presented is an analysis of the stake 4 | oracles used by Truthcoin and Augur. Finally, a new foundation for 5 | decentralized prediction markets is presented that attempts to address the 6 | shortcomings of known stake oracle systems. 7 | 8 | [b]Stake Oracle[/b] 9 | 10 | A stake oracle is an oracle that operates using a stake based consensus 11 | mechanism. Stake is an arbitrarily divisible asset owned by one or more 12 | stakeholders. Decisions are made by a voting process, and stakeholders get 13 | voting power proportional to the amount of stake they own. A strict 14 | interpretation of the votes allows the oracle to make a single revelation that 15 | can be recognized as consensus between the stakeholders. 16 | 17 | The primary use of a stake oracle is to provide insight about events external 18 | to the cryptocurrency in which they operate. This is a service which can be 19 | bought, thus providing an income for the stake oracle. The income is divided 20 | among the stakeholders proportional to the volume of stake owned. The stake 21 | can be given a market value equal to the expected sum of all future payments. 22 | Stakeholders thus have a financial incentive to protect the trustworthiness of 23 | the oracle - incoherent or dishonest voting will damage the trust in the stake 24 | oracle, which will damage the income of the oracle - nobody will pay for a 25 | broken oracle. The valuation of the oracle's stake is a prediction market of 26 | the total expected future income of the oracle. 27 | 28 | Consensus: 29 | 30 | Decentraliezd stake oracles require consensus over who owns the stake, and 31 | which votes have been submitted. If a voter creates two different valid votes, 32 | there must be a way to determine which vote is accepted by the majority. 33 | Proof-of-work blockchains such as the Bitcoin blockchain [8] provide a 34 | well-researched method of achieving decentralized consensus around ownership 35 | and event ordering. 36 | 37 | Incentives: 38 | 39 | Stake oracles incentivize honesty among stakeholders through potential future 40 | revenue. If a stake oracle ever reveals incorrect information about the 41 | physical world, all confidence in the stake oracle will evaporate and the 42 | stake oracle will not be used again for fear of continued abuse. The income 43 | and value of the stake will drop, financially damaging the stakeholders. 44 | 45 | Verifying an oracle's trustworthiness requires auditability by the customers 46 | of the oracle (typically the general public). If an oracle is dishonest and 47 | nobody is able to realize it, the oracle will not begin losing contracts. The 48 | incentive model is only intact when all contracts from the oracle are fully 49 | auditable by all potential sources of revenue for the oracle. 50 | 51 | Exit scams lose financial incentive because stake can be sold for income. In a 52 | healthy ecosystem, any attempted malice will have a severe negative impact on 53 | the value of the stake that is greater than the potential profit from a 54 | successful attack. The value of the stake will fall whether the attack is 55 | successful or not because it will be transparent to the ecosystem surrounding 56 | the oracle. 57 | 58 | A stake oracle with a monopoly may be able to make abusive or malicious 59 | predictions without having the value drop significantly - if it is the only 60 | oracle available, people may be willing to pay for its services despite the 61 | risk of malice. If there are easily accessible competing stake oracles, the 62 | financial cost of dishonesty is much higher for an individual stake oracle. 63 | Stake oracles have stronger financial incentives towards honesty in a 64 | competitive environment. 65 | 66 | Oracle Confusion: 67 | 68 | Oracle confusion occurs when each stakeholder believes that they are 69 | submitting the correct result, yet the stakeholders present different results. 70 | As an example, consider a binary reveal for "The Price of Bitcoin will be 71 | above $400 on Jan 1st, 2016". If the price fluctuates above and below $400 72 | throughout the day, stakeholders may present different opinions on whether the 73 | event occurred. Or if the price only exceeds $400 on a single exchange, or if 74 | there is apparent market manipulation trying to push the price up temporarily, 75 | stakeholders may have different judgements about what happened. This is just 76 | one example - there are many types of questions and situations which may cause 77 | oracle confusion. 78 | 79 | Voter Exhaustion: 80 | 81 | Stakeholders of a stake oracle face the risk exhaustion when handling oracle 82 | contracts. If too many are presented, stakeholders may find themselves unable 83 | to keep up with the volume, even if each contract only takes a few seconds to 84 | resolve. Even in the automated case, there is the risk that the stake oracle 85 | takes on more work than can be successfully managed by the stakeholders. 86 | There must therefore be some method of controlling the volume of contracts 87 | accepted by the stake oracle. Exhaustion also creates centralization pressure. 88 | As the volume of contracts increase, increasingly specialized stakeholders are 89 | needed to keep up with the volume. Potential stakeholders who have exhaustion 90 | tolerance below the existing workload are excluded from participating. 91 | 92 | Poisoned Voting: 93 | 94 | A vote is considered 'poisoned' if it does not correctly reflect reality. A 95 | stake oracle can come to consensus on the correct interpretation of reality 96 | while having poisoned votes, though a stake oracle that consistently has a 97 | volume of poisoned votes is less secure, which should be reflected by a 98 | reduced price for the stake of the oracle. 99 | 100 | Stakeholders in a competitive environment are incentivized to poison the 101 | voting of competing stake oracles by buying stake and voting incorrectly - 102 | doing so reduces confidence in the competition and makes the stakeholders 103 | primary stake oracle seem more attractive by comparison. Financial penalties 104 | for poisoned voting add cost to the act of creating a posioned vote, and 105 | correspondingly incentive to always vote correctly. Determining whether a 106 | vote is poisoned or not is a non-trivial problem. 107 | 108 | Financial Games: 109 | 110 | Abusive use of financial tools such as 'shorting' may weaken the security of 111 | stake oracles. For example, an attacker may be able to fund their attack (even 112 | to the point of profit) by shorting the stake oracle asset. There is little 113 | that can be done by the stakeholders to prevent an attacker from shorting the 114 | asset, though it must be remembered that someone has to sell the short, and in 115 | doing so they have to account for the fact that the sale is financially 116 | incentivizing the buyer to attack the stake oracle. There may be additional 117 | financial games as well that disrupt the incentive model and security model of 118 | a stake oracle. 119 | 120 | Freeloaders: 121 | 122 | A large portion of the trust and incentive model of a stake oracle is derived 123 | from the income of the stake oracle. But the results from an oracle are easy 124 | to steal - once an oracle has revealed a result, the result can be copied or 125 | stolen without payment by an alternate chain. This behavior increases the pool 126 | of potential profit from an exit scam without increasing the value of the 127 | stake oracle for acting honestly. 128 | 129 | If a large portion of the ecosystem is freeloading, the security model becomes 130 | inherently unstable, and the ecosystem is put at risk. Freeloaders have 131 | financial incentive - they get to avoid the oracle's fees. This creates a 132 | classic Tragedy of the Commons [4]. A sufficiently long-range looking 133 | ecosystem will be able to avoid this problem, but the incentives are not well 134 | aligned for short-term thinking members of the ecosystem. To the best of the 135 | author's knowledge, this is an unsolved problem inherent to stake oracles. 136 | 137 | [b]Stake Oracles in Truthcoin[/b] 138 | 139 | Overview: 140 | 141 | The Truthcoin whitepaper defines an 'oracle corporation' which is governed by 142 | 'VoteCoins'. An oracle corporation is analogous to a stake oracle, and 143 | VoteCoins are analogous to stake. VoteCoins are used to participate in 144 | decision making when revealing information about external events, are 145 | tradeable and fungible, provide income to the stakeholders, and enable 146 | financial penalties for dishonest or lazy voting. Anybody is allowed to author 147 | a prediction market which the oracle corporation will vote on. Oracle 148 | corporations are created by a process of 'branching', in which an existing 149 | oracle corporation forks into two. Stakeholders retain all stake on each 150 | branch initially, but are allowed to sell it separately - over time the 151 | branches diverge and diversify. 152 | 153 | The Truthcoin whitepaper states that "Any user can create a prediction market 154 | ('Author a Market') about anything." The quantity of decision slots is 155 | ratelimited, and the fee for creating a market is driven by demand. Authors 156 | are also required to provide a small amount of seed capital to drive liquidity 157 | in a market maker that facilitates trades in Truthcoin. 158 | 159 | New oracle corporations are created through a process of splitting an existing 160 | oracle. The network starts with only a single oracle corporation, and all 161 | additional oracles must be created by splitting existing oracles. When an 162 | oracle is split, the stake in the new oracle matches the stake of the old 163 | oracle. That stake can then be traded independently. 164 | 165 | Consensus: 166 | 167 | Truthcoin uses a proof-of-work Bitcoin SPV sidechain [9] to achieve consensus. 168 | The pegged coins are protected at most by SPV security and the blockchain 169 | itself is merge-mined with the Bitcoin blockchain. A tradeoff to merge mining 170 | is miner apathy - income from the altchain is likely much smaller than income 171 | from the primary chain, potentially so much smaller that events such as 172 | softforks are not worth the miner's attention, adding roadblocks to making 173 | changes to the protocol and potentially damaging the growth of the coin in the 174 | early stages of refinement, bugfixing, and adjustment. There is also a 175 | tradeoff where the network is participating in an ecosystem with a huge amount 176 | of hashpower, but only a fraction of that hashpower is actually being paid 177 | for. Given the right financial incentive, it is not very difficult to attack a 178 | merge-mined currency. To the best of the author's knowledge, there has not yet 179 | been a successful attack on a cryptocurrency that is merge-mined with Bitcoin. 180 | 181 | Incentives: 182 | 183 | The voters in a corporation oracle have no ability to set the fees of the 184 | prediction market, that decision is made by the authors of the prediction 185 | market. Authors have strong incentives to provide low fees, as anybody can 186 | create any prediction market - including competing prediction markets. This 187 | could create ecosystems which inherently tend towards underpaid voters. 188 | Underpaid voters may be able to profit more from voting maliciously than from 189 | voting honestly, resulting in an unstable/unusable system. 190 | 191 | One of the incentive claims of the Truthcoin paper is that "Decision Authors 192 | have a strong incentive to only write easily measurable Decisions." The 193 | support for this claim is derived primarily from the idea that 'unclear 194 | decisions are unprofitable'. This should read 'unclear decisions are 195 | unprofitable for honest voters'. Authors are however a separate group from 196 | voters and may find significant profit opportunity in the authorship of 197 | unclear markets. Authors are strongly incentivzed to author prediction markets 198 | that will be profitable from traders, and there is no guarantee that trades 199 | will avoid markets that may be disruptive to the voting process. 200 | 201 | A competing oracle can only be created if stakeholders of an existing oracle 202 | successfully vote in favor of a split. This gives existing stakeholders great 203 | power over the oracle ecosystem. Even if a split is approved, the initial 204 | stake ownership of the new oracle matches the stake ownership of the parent 205 | oracle, which creates a large barrier-to-entry for creating diverse competing 206 | oracles. This may result in limited options for traders if one of the existing 207 | oracle corporations begins making incorrect revelations about the physical 208 | world. 209 | 210 | Oracle Confusion: 211 | 212 | Anyone is allowed to create a prediction market, and as discussed in the 213 | incentives section, the incentives for creating voter-friendly prediction 214 | markets are not aligned to eliminate oracle confusion. By leveraging confusing 215 | prediction markets combined with a weak voter penalty algorithm, an attacker 216 | may be able to costlessly acquire voting power from honest voters. For 217 | example, if an attacker can create a set of prediction markets where they know 218 | honest voters will be split 20/80, the attacker can join the 80% and 219 | collect voting power that is penalized from the 20%. The attacker can continue 220 | to split voters with confusing markets and over time substantially build up 221 | voting power. This is called a 'confusion attack'. 222 | 223 | Voter Exhaustion: 224 | 225 | Within Truthcoin, there are a limited number of prediction markets that can be 226 | created, and creating one comes at a cost. This eliminates some classes of 227 | voter exhaustion attacks, but leaves others. For example, 'Who won the 2016 US 228 | Presidential election' is easy to answer, but 'The 2016 State of the Union 229 | address will cover the topic of internet privacy for at most 5 minutes' is 230 | more exhausting. It may be possible to execute a voter exhaustion attack by 231 | filling the prediction market slots with a suffiicent number of exhausting 232 | questions. A proposed solution is give voters the ability to acknowledge a 233 | question as 'too difficult', however this solution opens up voters to 234 | confusion attacks - 'too difficult' is not sufficiently specific to guarantee 235 | that all voters will be in consensus about what counts as 'too difficult' - 236 | every potential definition of the term has vague boundaries that are 237 | insufficient for what needs to be a consensus system. 238 | 239 | Votes in Truthcoin go directly on the blockchain. Putting data on the 240 | blockchain requires paying a miner fee, and there is no guarantee that payout 241 | from voting on a prediction market is going to exceed the cost of putting a 242 | vote on the blockchain. Therefore, blockchain fees combined with low-payout 243 | markets represent another potential voter exhaustion vector. 244 | 245 | Poisoned Voting: 246 | 247 | Poisoned voting is decected and managed in Truthcoin via a complex process 248 | batching votes together across many prediction markets and comparing the 249 | variance of the answers between each voter. Voters that are least identical to 250 | other voters accept penalties to their stake ownership, and that stake is 251 | redistributed to the voters that voted most identically to other voters. An 252 | analysis of the techniques used by Truthcoin is discussed at [5]. The analysis 253 | shows significant weaknesses in the voting penalty structure of Truthcoin, and 254 | it is likely that a more thorough analysis would reveal further weakness. 255 | 256 | [b]Stake Oracles in Augur[/b] 257 | 258 | Augur features a single stake oracle with a fixed quantity of tradeable 259 | reputation that is analogous to stake. The reputation is fully premined and 260 | distributed according to contributions to a crowdfund. Anybody can create an 261 | event/prediction market on Augur by paying a nominal event creation fee. This 262 | fee is not set by supply and demand and there is no hard limit to the number 263 | of events that can be created. 264 | 265 | Consensus: 266 | 267 | Augur is built on the Ethereum platform, a virtual machine cryptocurrency that 268 | has a wide set of cutting-edge features, including a time-bomb on the current 269 | Proof-of-Work consensus algorithm that is intended to be replaced by a 270 | Proof-of-Stake consensus algorithm within the next year. In addition to a 271 | large volume of new and potentially buggy features, Ethereum features poor 272 | scaling properties and a limited set of resources that must be shared among 273 | all platforms. Augur is a heavyweight application that may become very 274 | expensive to run on Ethereum as the ecosystem matures and more valuable 275 | lightweight applications spring up. 276 | 277 | Incentives: 278 | 279 | Prediction market creation is incentivized similarly to in Truthcoin - market 280 | creaters make a fee-based profit when traders use their markets. Voters 281 | receive a portion of the fees, and are therefore given an income and able to 282 | place a valauation on the stake they own. 283 | 284 | The single stake oracle in Augur means that a corrupt stake oracle may be able 285 | to get away with lying occasionally - since there is no competition in the 286 | system, there is nowhere for traders to flee to in the event of apparent 287 | dishonesty. Furthermore, if at any point a single entity is able to achieve 288 | sufficient control of the stake, they will be able to maintain that control 289 | indefinitely. This model is very brittle, an eggs-in-one-basket approach. 290 | 291 | Oracle Confusion: 292 | 293 | Similar to Truthcoin, Augur has very little to protect against oracle 294 | confusion. Market creators are allowed to create any markets, and are not 295 | necessarily incentivized to create markets that are easy for voters to resolve 296 | with consensus. A malicious entitiy may be able to leverage oracle confusion 297 | to slowly increase stakeholdings over time. 298 | 299 | Voter Exhaustion: 300 | 301 | There is no hard limit to the number of prediction markets that can be created 302 | in Augur, and all voters must vote on every prediction market. As Augur grows 303 | in popularity, voting is likely going to require increasing specialization, 304 | limiting the pool of potential voters and exerting centralization pressure on 305 | the voting system. 306 | 307 | Poisoned Voting: 308 | 309 | Augur's approach to voter penalty algorithms is described in [5]. A clustering 310 | algorithm is chosen, and Monte-Carlo simulations are used to explore the 311 | robustness of the algorithm. While the voting penalty algorithm does seem to 312 | outperform the Truthcoin algorithm, the math is complex and no formal 313 | guarantee is provided that abuse is difficult under all potential vectors. 314 | 315 | [b]Proposal: Delphi - A Stronger Stake Oracle System[/b] 316 | 317 | Delphi is a system of stake oracles designed to facilitate decentralized 318 | prediction markets. Delphi features a master currency caled the 'drachma' 319 | which is used to price and trade oracle stake, and also to participate in 320 | prediction markets managed by Delphi's oracles. Consensus is managed by a 321 | traditional proof-of-work blockchain. 322 | 323 | Stake oracles can be created in Dephi by submitting an oracle genesis 324 | transaction. This transaction is responsible for distributing the initial 325 | stake and defining the two parameters of the oracel, the 'market creation 326 | threshold' and the 'penalty percentage'. Any volume of stake can be created 327 | and distributed in any number of outputs (other consensus rules - such as 328 | maximum transaction size - may be a limiting factor). 329 | 330 | The market creation threshold defines the percentage of stake that must sign a 331 | market genesis transaction in order for the transaction to be valid. A high 332 | market creation threshold means that new prediction markets are easy to 333 | filibuster. A low market creation threshold means that a low number of 334 | stakeholders will be able to create valid prediction markets, putting the 335 | other stakeholders at risk of confusion and exhaustion. 336 | 337 | The penalty percentage defines the percentage of stake that is foreit when a 338 | stakeholder is found to have submitted a posioned vote. A high penalty 339 | percentage strongly decentivizes risky voting and non-participation, but 340 | creates a brittle stake oracle - a single missed vote can have dramatic 341 | consequences for a stakeholder. A low penalty percantage provides more 342 | flexibility and tolerance for confusion and exhaustion but also means that 343 | there is less cost for attempted malice by attacking stakeholders. 344 | 345 | A market genesis transaction defines a prediction market with a question, a 346 | finite and discrete set of potential answers, a result deadline, and a 347 | prediction share creation fee. The question is intended to represent a future 348 | event whose outcome is uncertain. The results must contain all potential 349 | outcomes of the future event, and will be voted upon by the stakeholders 350 | before the result deadline. The result deadline indicates the date or block 351 | height by which all stakeholders must submit their vote. The prediction share 352 | creation fee defines the cost of introducing liquidity into the prediction 353 | market. 354 | 355 | Tranders buy and sell shares of the potential results of the prediction 356 | market. Shares can be bought at any time on the blockchain by putting drachmas 357 | into the prediction market. Assuming a 2% fee, paying 1 drachma into the 358 | prediction market will yield a 0.98 drachma share of each potential result. 359 | These shares can be traded on the blockchain in the same manner as drachmas. 360 | When the prediction market closes, one of the results will pay out its face 361 | value in drachmas. The fee will be distributed to the stakeholders of the 362 | oracle. 363 | 364 | When the prediction market closes, all stakeholders will either have submitted 365 | a vote towards a result or will have submitted nothing at all. A vote is 366 | considered 'valid' if it is cast towards the result that has the most stake 367 | voting for it. All other votes, including absent votes, are considered 368 | 'poisoned'. In the event of a tie, the block id will be used to seed a random 369 | number generator that will select a winner. A percentage of all stake that 370 | submitted poisoned votes will be destroyed according to the penalty 371 | percentage. 372 | 373 | Within a stake oracle, voters are only allowed to vote for one prediction 374 | market at a time, and that must be the prediction market with the nearest 375 | result deadline. Stake oracles are not allowed to create prediction markets 376 | that have result deadlines nearer than the nearest result deadline for that 377 | stake oracle. 378 | 379 | Example: 380 | 381 | A stake oracle is created via an oracle genesis transaction. 33% of stake is 382 | given to 'A', 33% is given to 'B', and 33% is given to 'C'. The market 383 | creation threshold is set to 51%, and the penalty percentage is set to 100%. 384 | 385 | A market genesis transaction is created, signed by both 'A' and 'B'. The 386 | market contains the proposal 'Winner of the 2016 U.S. Presidential Election' 387 | with the results 'Hilliary Clinton', 'Donald Trump, and 'Other Result'. The 388 | termination date is set to Jan 1st, 2016. The fee is set to 5%. 389 | 390 | Trader 'X' buys 1 drachma of shares directly from the prediction market, 391 | receiving 0.95 drachmas worth of each of the 3 results. Trader 'Y' buys 0.95 392 | drachmas of 'Donald Trump' from trader 'X' for 0.5 drachmas out-of-band. 393 | 394 | The election passes and the stakeholders submit their results. The election is 395 | disputed initially, and 'A' votes for 'Other'. The dispute is resolved and 396 | 'Donald Trump' is chosen as the winner. 'B' and 'C' then submit results for 397 | 'Donald Trump'. Jan 1st, 2016 arrives and all 'Donald Trump' shares are 398 | converted into drachmas. All other shares are pruned. Trader 'X' gets no 399 | payout, and trader 'Y' gets a 0.95 drachma payout, having paid only 0.5 400 | drachmas for the share. 401 | 402 | Because 'A' voted against the winning result, 'A' is penalized according to 403 | the penalty percentage - all stake is forfeit. 'B' and 'C' now each own 50% of 404 | the stake. 0.025 drachmas are distributed to each 'B' and 'C', collected from 405 | the fees paid to trade on the prediction market. 406 | 407 | Consensus: 408 | 409 | Delphi uses an independent proof-of-work blockchain to achieve consensus. The 410 | consensus rules of the chain are heavily modeled after the consensus rules of 411 | the Bitcoin blockchain. A new currency, the 'drachma' must be bootstrapped and 412 | may be subject to heavy volatility in the early days of the network. Using a 413 | unique mining algorithm avoids miner apathy, but leaves the coin vulnerable to 414 | mining farms that hop from coin to coin until specialized hardware is created 415 | to mine the coin. 416 | 417 | Incentives: 418 | 419 | Oracle stakeholders are incentivized to be honest and reliable by the 420 | potential for future income, and because there is a low barrier-to-entry for 421 | creating competing stake oracles in the event of dishonesty or unreliability 422 | from an established stake oracle. Stake is a fully fungible asset, and can be 423 | sold as an alternative retirement strategy to the traditional exit scam. 424 | 425 | Oracle Confusion: 426 | 427 | Oracle stakeholders have complete control over the prediction market creation 428 | process, which provides strong defense against oracle confusion. Due to the 429 | stake penalties, stakeholders are strongly incentivized against creating 430 | prediction markets which can cause confusion. Delphi features two variables 431 | that can be set during stake oracle creation - market creation threshold and 432 | penalty percentage - that allows stake oracles to optimize for different risk 433 | tolerances. Stake oracles with market creation thresholds and penalty 434 | percentages are at higher risk of confusion. 435 | 436 | Voter Exhaustion: 437 | 438 | Similar to oracle confusion, stakeholders have a large amount of control over 439 | which prediction markets are created and how many are created. Stake oracles 440 | can be optimized to accept varying amounts of risk with regards to voter 441 | exhaustion. 442 | 443 | Poisoned Voting: 444 | 445 | Unlike Augur and Truthcoin, Delphi features a very simple method for detecting 446 | and managing poisoned votes. Votes are analyzed one at a time, and any vote 447 | towards a result that did not win the plurality of stake is considered 448 | poisoned. The security properties are easy to analyze - honest voters are at 449 | risk if they are unable to get the plurality of stake voting towards the same 450 | result. For all situations where the honest voters are voting on a 451 | non-confusing prediction market and have the majority of the of the stake, 452 | there will be no problems. 453 | 454 | [b]Conclusion[/b] 455 | 456 | This paper has introduced the idea of a 'stake oracle' and explored the 457 | potential risks and attack vectors associated with stake oracles. These 458 | generalizations were applied to existing decentralized prediction market 459 | systems to highlight a set of weaknesses. An alternative, Delphi, was proposed 460 | which addresses many of the concerns raised about the existing decentralized 461 | prediction markets. 462 | 463 | The author considers the topic of stake oracles and decentraliezd prediction 464 | markets to be relatively under-explored. Further exploration may reveal 465 | addtional strengths and weaknesses of the stake oracles discussed, or 466 | alternative systems which are more powerful for the purpose of facilitating 467 | decentralized prediction markets. 468 | 469 | [b]Citations[/b] 470 | 471 | 1. http://www.truthcoin.info/papers/truthcoin-whitepaper.pdf 472 | 473 | 2. http://augur.link/augur.pdf 474 | 475 | 3. https://blog.ethereum.org/2015/09/03/security-alert-implementation-bug-in-go-clients-causing-increase-in-difficulty-fixed-miners-check-and-update-go-clients-if-necessary/ 476 | 477 | 4. https://en.wikipedia.org/wiki/Tragedy_of_the_commons 478 | 479 | 5. http://www.augur.net/blog/building-a-better-lie-detector 480 | 481 | 6. https://blog.ethereum.org/2015/09/02/security-advisory-implementations-bugs-in-go-and-python-clients-can-cause-dos/ 482 | 483 | 7. https://www.reddit.com/r/ethereum/comments/3jynkc/difficulty_adjustment_scheme_block_200000_coming/ 484 | 485 | 8. https://bitcoin.org/bitcoin.pdf 486 | 487 | 9. https://blockstream.com/sidechains.pdf 488 | -------------------------------------------------------------------------------- /backups/c84b4a98: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DavidVorick/knosys/9d271f69a528f524fb577c5a06dd6f03415fc95c/backups/c84b4a98 --------------------------------------------------------------------------------