├── NOTES.md ├── README.md ├── alphachain.pdf ├── binance.pdf ├── bitcoin-announce.txt ├── bitcoin-cash-satoshi-vision.md ├── bitcoin-cash.md ├── bitcoin-diamond.pdf ├── bitcoin-gold.pdf ├── bitcoin-retailmerchants.pdf ├── bitcoin-v0.1-released.txt ├── bitcoin.pdf ├── bitgold.md ├── bmoney.md ├── colored-coins.pdf ├── crypto-is-the-mother-of-all-scams.pdf ├── cryptokitties.pdf ├── decentraland.pdf ├── eo-terms.pdf ├── eo.pdf ├── eos-purchase.pdf ├── etherisc.pdf ├── flow-i.pdf ├── flow-ii.pdf ├── flow-iii.pdf ├── golem.pdf ├── hashcash-announce.txt ├── hashcash.pdf ├── hotstuff.pdf ├── howey.pdf ├── libra-blockchain.pdf ├── libra-consensus.pdf ├── libra-governance.pdf ├── libra-move.pdf ├── libra-reserve.pdf ├── libra-v2.pdf ├── libra.pdf ├── litecoin.md ├── mastercoin-risks.pdf ├── mastercoin-v05.pdf ├── mastercoin.pdf ├── mimblewimble.pdf ├── mimblewimble.txt ├── peercoin.pdf ├── ponzico.pdf ├── primecoin.pdf ├── savedroid.pdf ├── tether.pdf ├── tetherino.pdf └── what-satoshi-did-not-know.pdf /NOTES.md: -------------------------------------------------------------------------------- 1 | # Notes 2 | 3 | ## Todos 4 | 5 | - [ ] Add Intro / Background to README.md - Why? Why not? 6 | 7 | 8 | 9 | ## Intro / Background 10 | 11 | Welcome greater fools! Thanks for your money and hodling the bag! 12 | 13 | **Q: What's an Initial Coin Offering (ICO) / Token Sales?** 14 | 15 | Read the free excerpt titled [ICOs: Magic Beans and Bubble Machines](https://davidgerard.co.uk/blockchain/icos-magic-beans-and-bubble-machines/) from the book [Attack of the 50 Foot Blockchain](https://davidgerard.co.uk/blockchain/book/) by David Gerard. 16 | 17 | > Token offerings have been around a while, but kicked off enormously in the second bubble. 18 | > The usual pretext is crowdfunding, but in practice the tokens are just traded on the exchanges as commodities. 19 | > The creators then cash in. The value proposition for buyers is, as for the creators, easy money in a bubble. 20 | > 21 | > -- David Gerard (Attack of the 50 Foot Blockchain / ICOs: Magic Beans and Bubble Machines) 22 | 23 | 24 | **More (Free) Reading** 25 | 26 | See [Best of Bitcoin Maximalist - Scammers, Morons, Clowns, Shills & BagHODLers - Inside The New New Crypto Ponzi Economics](https://bitsblocks.github.io/bitcoin-maximalist) about 27 | Bitcoin's New New Crypto Ponzi Economics. 28 | 29 | See [Crypto Facts - Decentralize Payments - Efficient, Low Cost, Fair, Clean - True or False?](https://bitsblocks.github.io/crypto-facts) 30 | about the Mother of All Scams & Bubbles and the Austrian School of Economics Crypto-Utopia 31 | and the Future of Money and the Rich Getting Richer. 32 | 33 | See [Awesome Initial Coin Offerings (ICO) Truths](https://github.com/openblockchains/awesome-ico-truths) 34 | about the Scammers' Big Lies. 35 | 36 | 37 | 38 | ## Old Tagline 39 | 40 | - [ ] - Add - Why? Why not? 41 | 42 | _Inside the New New Crypto Ponzi Economics - Fiction, Fiction, Fiction - The Art of the Steal_ 43 | 44 | 45 | ## Currency Symbols 46 | 47 | - [ ] - Add - Why? Why not? 48 | 49 | BTC • BTG • BTD • LTC • SVD 50 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Bitcoin & Blockchain Whitepapers - Inside the New New Crypto Ponzi Economics 2 | 3 | 4 | 5 | ## Bitcoin 6 | 7 | - [Bitcoin White Paper - A Peer-to-Peer Electronic Cash System](https://bitsblocks.github.io/bitcoin-whitepaper) by Satoshi Nakamoto (pseudonym), October 2008 8 | 9 | 10 | -------------------------------------------------------------------------------- /alphachain.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/alphachain.pdf -------------------------------------------------------------------------------- /binance.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/binance.pdf -------------------------------------------------------------------------------- /bitcoin-announce.txt: -------------------------------------------------------------------------------- 1 | Subject: Bitcoin P2P e-cash paper 2 | From: Satoshi Nakamoto satoshi at vistomail.com 3 | Date: Fri Oct 31 14:10:00 EDT 2008 4 | 5 | I've been working on a new electronic cash system that's fully 6 | peer-to-peer, with no trusted third party. 7 | 8 | The paper is available at: 9 | http://www.bitcoin.org/bitcoin.pdf 10 | 11 | The main properties: 12 | Double-spending is prevented with a peer-to-peer network. 13 | No mint or other trusted parties. 14 | Participants can be anonymous. 15 | New coins are made from Hashcash style proof-of-work. 16 | The proof-of-work for new coin generation also powers the 17 | network to prevent double-spending. 18 | 19 | Bitcoin: A Peer-to-Peer Electronic Cash System 20 | 21 | Abstract. A purely peer-to-peer version of electronic cash would 22 | allow online payments to be sent directly from one party to another 23 | without the burdens of going through a financial institution. 24 | Digital signatures provide part of the solution, but the main 25 | benefits are lost if a trusted party is still required to prevent 26 | double-spending. We propose a solution to the double-spending 27 | problem using a peer-to-peer network. The network timestamps 28 | transactions by hashing them into an ongoing chain of hash-based 29 | proof-of-work, forming a record that cannot be changed without 30 | redoing the proof-of-work. The longest chain not only serves as 31 | proof of the sequence of events witnessed, but proof that it came 32 | from the largest pool of CPU power. As long as honest nodes control 33 | the most CPU power on the network, they can generate the longest 34 | chain and outpace any attackers. The network itself requires 35 | minimal structure. Messages are broadcasted on a best effort basis, 36 | and nodes can leave and rejoin the network at will, accepting the 37 | longest proof-of-work chain as proof of what happened while they 38 | were gone. 39 | 40 | Full paper at: 41 | http://www.bitcoin.org/bitcoin.pdf 42 | 43 | Satoshi Nakamoto 44 | 45 | (Source: ) 46 | -------------------------------------------------------------------------------- /bitcoin-cash-satoshi-vision.md: -------------------------------------------------------------------------------- 1 | # Bitcoin Cash Satoshi's Vision (SV) 2 | 3 | Four fundamental pillars form the basis of Bitcoin SV's roadmap 4 | to create the one blockchain for the world: 5 | stability, scalability, security, and safe instant transactions (a.k.a 0-confirmation). 6 | 7 | > "The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. 8 | > Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. 9 | > It never really hits a scale ceiling." 10 | > 11 | > -- Satoshi Nakamoto (April 2009) 12 | 13 | 14 | ## 1 - Stability 15 | 16 | Businesses, especially the biggest enterprises, require stability before they 17 | will operate on a technology platform. Repeated, unnecessary, and unproven changes 18 | to the Bitcoin protocol can be detrimental to the economic incentive structure 19 | and security of the blockchain. They can also cause significant uncertainties 20 | for large scale businesses that need to plan years in advance and commit 21 | significant resources before deciding to build applications and projects on Bitcoin Cash. 22 | 23 | The Bitcoin SV vision is to provide assured stability with only a limited 24 | and well known set of changes planned to restore the Bitcoin protocol to its original design, 25 | and enable innovation to occur on top of a stable base protocol. 26 | 27 | Part of this is restoring the Satoshi op_codes to enable businesses 28 | and development teams around the world to create the many solutions 29 | possible on the BSV blockchain, such as smart contracts, tokenisation, 30 | atomic swaps, and many more. 31 | 32 | ## 2 – Scalability 33 | 34 | In order for Bitcoin SV to truly act as a global money platform, 35 | it is necessary to demonstrate that the platform is ready to process transaction 36 | volume at the required scale. The Bitcoin SV roadmap is primarily focussed 37 | on delivering capacity increases, through bigger default or miner configurable 38 | block sizes and performance improvements. Out of the nine test environments 39 | in use by the project, the SV Gigablock Testnet (SV-GBTN) is specifically dedicated 40 | to identifying bottlenecks and performance measurement of proposed changes. 41 | The SV-GBTN is running on a continuous cycle of performance tests and the 42 | results of those are for public consumption so that miners and other industry 43 | participants will be able to make informed scaling decisions. 44 | 45 | By enabling massive scaling, Bitcoin SV will pave the way for the BSV blockchain 46 | to support significantly higher transaction volumes and more transaction fees for miners. 47 | This is important for miners to maintain profitability as the block reward 48 | will halve again in the year 2020 (reducing from 12 BSV to 6.25 BSV for each block), 49 | and halve again in later years. 50 | 51 | Massive scaling is also important to convince enterprises to use BSV for their 52 | blockchain applications - which will require big blocks and large throughput capacity. 53 | 54 | 55 | ## 3 - Security 56 | 57 | Bitcoin SV will be a global currency. To enable such a future, we need to be 58 | prepared to ensure a level of security commensurate with a global money system. 59 | To do this, the Bitcoin SV project has focused on rigorous Quality Assurance 60 | for mining node software. 61 | 62 | This is achieved by implementing a rigid set of test phases with full traceability 63 | throughout the test pipeline, to assure users that changes pass through a formal 64 | and rigorous validation process before they are accepted. In this respect, 65 | Bitcoin SV aspires to levels of Quality Assurance exemplified by mission critical 66 | industries such as aerospace, medicine and national security. 67 | 68 | First, the team will use best practice change management processes 69 | and engage external QA expertise from other security-sensitive industries 70 | to monitor and audit its QA processes. 71 | 72 | Second, the project will engage the services of an industry-leading blockchain 73 | security audit firm. 74 | 75 | Third, the project will offer a lucrative bug bounty program matching 76 | the likes of Google and Microsoft to motivate and mobilize security researchers 77 | around the world to find and responsibly report security vulnerabilities. 78 | The team has engaged expert service providers in the field to develop 79 | an industry best practice "Responsible Disclosure Program." 80 | 81 | ## 4 – Safe instant transactions (a.k.a. 0-conf) 82 | 83 | Instant transactions are key to unlocking the brick and mortar merchant market 84 | for Bitcoin SV payments. Security improvements can be made to better secure instant transactions 85 | for the future, and the Bitcoin SV roadmap treats safe instant transactions as a key priority. 86 | 87 | 88 | (Source: ) 89 | -------------------------------------------------------------------------------- /bitcoin-cash.md: -------------------------------------------------------------------------------- 1 | # Bitcoin Cash 2 | 3 | Bitcoin Cash brings sound money to the world, fulfilling the original promise of Bitcoin 4 | as "Peer-to-Peer Electronic Cash". 5 | Merchants and users are empowered with low fees and reliable confirmations. 6 | The future shines brightly with unrestricted growth, global adoption, 7 | permissionless innovation, and decentralized development. 8 | 9 | All Bitcoin holders as of block #478 558 are also owners of Bitcoin Cash. 10 | All are welcome to join the Bitcoin Cash community 11 | as we move forward in creating sound money accessible to the whole world. 12 | 13 | 14 | ## Bitcoin Cash Whitepaper 15 | 16 | The original whitepaper was published on October 31, 2008 by Satoshi Nakamoto, 17 | the anonymous creator of the worlds first cryptocurrency. 18 | The title of the Bitcoin whitepaper is 19 | "Bitcoin: A Peer-to-Peer Electronic Cash System". 20 | Bitcoin Cash aims to continue this vision of bringing sound money to the world. 21 | 22 | Read the Whitepaper: 23 | 24 | 25 | 26 | ## Bitcoin Cash Roadmap 27 | 28 | To become a solid base for application development and innovation, 29 | Bitcoin Cash must continuously improve and compete. 30 | Working together, we can build a technical foundation 31 | to empower Bitcoin Cash to be the best money the world has ever seen. 32 | 33 | View the Roadmap: 34 | 35 | 36 | **Fast** Transact in seconds. Get confirmed in minutes. 37 | 38 | **Reliable** A network that runs without congestion. 39 | 40 | **Low Fees** Send money globally for pennies. 41 | 42 | **Simple** Easy to use. No hassles. 43 | 44 | **Stable** A payment system that's a proven store of value. 45 | 46 | **Secure** World's most robust blockchain technology. 47 | 48 | 49 | (Source: ) 50 | 51 | 52 | --- 53 | 54 | # Bitcoin Cash Roadmap 55 | 56 | The goal for Bitcoin Cash is to become sound money that is usable by everyone in the world. 57 | This is a civilization-changing technology which will dramatically increase human freedom 58 | and prosperity. 59 | 60 | This roadmap is intended to provide high-level technical direction, 61 | and enable different technical teams to work together towards a common goal 62 | for advancing Bitcoin Cash. The role of developers in furthering this goal 63 | is to produce high-quality professional software that serves the needs of its users, 64 | miners and merchants. We strive for continuous technical improvement, 65 | to produce reliable products providing a solid foundation for Bitcoin Cash. 66 | 67 | The basic design of Bitcoin Cash is sound. However, this does not mean it is perfect. 68 | It is prudent to make incremental improvements to the system with technically 69 | sound design and careful engineering. By implementing optimizations and protocol upgrades, 70 | peer-to-peer digital cash will scale many orders of magnitude beyond current limits. 71 | 72 | The needed technical improvements can be divided into three categories: 73 | 74 | 1. Enable Bitcoin Cash to scale from ~100 Tx/s to over 5,000,000 Tx/s. 75 | Protocol improvements must be made so that mass-parallelization can enable this level 76 | of transaction processing. 77 | 78 | 2. Improving the payment experience to ensure that it is instant and reliable. 79 | Transactions should be secure within three seconds. 80 | 81 | 3. Make Bitcoin Cash extensible. An extensible protocol makes future improvements 82 | less disruptive, and provides a solid base for businesses and developers to build on. 83 | 84 | To become a solid base for application development and innovation, 85 | Bitcoin Cash must continuously improve and compete. 86 | Working together, we can build a technical foundation to empower Bitcoin Cash 87 | to be the best money the world has ever seen. 88 | 89 | 90 | ## Appendix - Roadmap 91 | 92 | **Scaling** 93 | 94 | - [Complete] - Canonical Transaction Ordering (scalable block processing) 95 | - [Under Way] - Faster Block Propagation (graphene or other) 96 | - [Planned] - Merklix-Metadata Tree (scalable block processing) 97 | - [Under Way] - UTXO Commitment (blockchain pruning) 98 | - [Under Way] - Schnorr Signatures (batched signature validation) 99 | - [Planned] - Adaptive Block Size (market driven growth to 1TB blocks) 100 | 101 | => Mankind Scale (50 transactions / day for 10 billion humans) 102 | 103 | **Usability** 104 | 105 | - [Complete] - Cashaddr (easier & safer to user) 106 | - [Complete] - Sighash (hardware wallet security) 107 | - [Under Way] - Fee Improvements (cheaper transactions) 108 | - [Under Way] - Pre-consensus (near instant security for merchants) 109 | - [Planned] - Fractional Satoshis (fee low forever) 110 | 111 | => Best Money (secure within 3 seconds, transaction fees forever low) 112 | 113 | 114 | **Extensibility** 115 | 116 | - [Complete] Basic Opcodes 117 | - [Complete] OP_RETURN At 223 bytes (social networks on chain) 118 | - [Complete] OP_CHECKDATSIG (oracles and advanced scripts) 119 | - [Under Way] More Basic Opcodes (activation may 2019) 120 | - [Planned] New Transaction Format (more capable, more compact) 121 | 122 | => Token Economy (all classes of assets traded on the blockchain) 123 | 124 | 125 | (Source: ) 126 | 127 | --- 128 | -------------------------------------------------------------------------------- /bitcoin-diamond.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/bitcoin-diamond.pdf -------------------------------------------------------------------------------- /bitcoin-gold.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/bitcoin-gold.pdf -------------------------------------------------------------------------------- /bitcoin-retailmerchants.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/bitcoin-retailmerchants.pdf -------------------------------------------------------------------------------- /bitcoin-v0.1-released.txt: -------------------------------------------------------------------------------- 1 | Subject: Bitcoin v0.1 released 2 | From: Satoshi Nakamoto satoshi at vistomail.com 3 | Date: Thu Jan 8 14:27:40 EST 2009 4 | 5 | Announcing the first release of Bitcoin, a new electronic cash 6 | system that uses a peer-to-peer network to prevent double-spending. 7 | It's completely decentralized with no server or central authority. 8 | 9 | See bitcoin.org for screenshots. 10 | 11 | Download link: 12 | http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar 13 | 14 | Windows only for now. Open source C++ code is included. 15 | 16 | - Unpack the files into a directory 17 | - Run BITCOIN.EXE 18 | - It automatically connects to other nodes 19 | 20 | If you can keep a node running that accepts incoming connections, 21 | you'll really be helping the network a lot. Port 8333 on your 22 | firewall needs to be open to receive incoming connections. 23 | 24 | The software is still alpha and experimental. There's no guarantee 25 | the system's state won't have to be restarted at some point if it 26 | becomes necessary, although I've done everything I can to build in 27 | extensibility and versioning. 28 | 29 | You can get coins by getting someone to send you some, or turn on 30 | Options->Generate Coins to run a node and generate blocks. I made 31 | the proof-of-work difficulty ridiculously easy to start with, so 32 | for a little while in the beginning a typical PC will be able to 33 | generate coins in just a few hours. It'll get a lot harder when 34 | competition makes the automatic adjustment drive up the difficulty. 35 | Generated coins must wait 120 blocks to mature before they can be 36 | spent. 37 | 38 | There are two ways to send money. If the recipient is online, you 39 | can enter their IP address and it will connect, get a new public 40 | key and send the transaction with comments. If the recipient is 41 | not online, it is possible to send to their Bitcoin address, which 42 | is a hash of their public key that they give you. They'll receive 43 | the transaction the next time they connect and get the block it's 44 | in. This method has the disadvantage that no comment information 45 | is sent, and a bit of privacy may be lost if the address is used 46 | multiple times, but it is a useful alternative if both users can't 47 | be online at the same time or the recipient can't receive incoming 48 | connections. 49 | 50 | Total circulation will be 21,000,000 coins. It'll be distributed 51 | to network nodes when they make blocks, with the amount cut in half 52 | every 4 years. 53 | 54 | first 4 years: 10,500,000 coins 55 | next 4 years: 5,250,000 coins 56 | next 4 years: 2,625,000 coins 57 | next 4 years: 1,312,500 coins 58 | etc... 59 | 60 | When that runs out, the system can support transaction fees if 61 | needed. It's based on open market competition, and there will 62 | probably always be nodes willing to process transactions for free. 63 | 64 | Satoshi Nakamoto 65 | 66 | (Source: ) 67 | -------------------------------------------------------------------------------- /bitcoin.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/bitcoin.pdf -------------------------------------------------------------------------------- /bitgold.md: -------------------------------------------------------------------------------- 1 | # Bit gold 2 | 3 | by Nick Szabo, December 2005 4 | 5 | A long time ago I hit upon the idea of bit gold. The problem, in a nutshell, is that our money currently depends on trust in a third party for its value. As many inflationary and hyperinflationary episodes during the 20th century demonstrated, this is not an ideal state of affairs. Similarly, private bank note issue, while it had various advantages as well as disadvantages, similarly depended on a trusted third party. 6 | 7 | Precious metals and collectibles have an unforgeable scarcity due to the costliness of their creation. This once provided money the value of which was largely independent of any trusted third party. Precious metals have problems, however. It's too costly to assay metals repeatedly for common transactions. Thus a trusted third party (usually associated with a tax collector who accepted the coins as payment) was invoked to stamp a standard amount of the metal into a coin. Transporting large values of metal can be a rather insecure affair, as the British found when transporting gold across a U-boat infested Atlantic to Canada during World War I to support their gold standard. What's worse, you can't pay online with metal. 8 | 9 | Thus, it would be very nice if there were a protocol whereby unforgeably costly bits could be created online with minimal dependence on trusted third parties, and then securely stored, transferred, and assayed with similar minimal trust. Bit gold. 10 | 11 | My proposal for bit gold is based on computing a string of bits from a string of challenge bits, using functions called variously "client puzzle function," "proof of work function," or "secure benchmark function.". The resulting string of bits is the proof of work. Where a one-way function is prohibitively difficult to compute backwards, a secure benchmark function ideally comes with a specific cost, measured in compute cycles, to compute backwards. 12 | 13 | Here are the main steps of the bit gold system that I envision: 14 | 15 | 1. A public string of bits, the "challenge string," is created (see step 5). 16 | 17 | 2. Alice on her computer generates the proof of work string from the challenge bits using a benchmark function. 18 | 19 | 3. The proof of work is securely timestamped. This should work in a distributed fashion, with several different timestamp services so that no particular timestamp service need be substantially relied on. 20 | 21 | 4. Alice adds the challenge string and the timestamped proof of work string to a distributed property title registry for bit gold. Here, too, no single server is substantially relied on to properly operate the registry. 22 | 23 | 5. The last-created string of bit gold provides the challenge bits for the next-created string. 24 | 25 | 6. To verify that Alice is the owner of a particular string of bit gold, Bob checks the unforgeable chain of title in the bit gold title registry. 26 | 27 | 7. To assay the value of a string of bit gold, Bob checks and verifies the challenge bits, the proof of work string, and the timestamp. 28 | 29 | Note that Alice's control over her bit gold does not depend on her sole possession of the bits, but rather on her lead position in the unforgeable chain of title (chain of digital signatures) in the title registry. 30 | 31 | All of this can be automated by software. The main limits to the security of the scheme are how well trust can be distributed in steps (3) and (4), and the problem of machine architecture which will be discussed below. 32 | 33 | Hal Finney has implemented a variant of bit gold called RPOW (Reusable Proofs of Work). This relies on publishing the computer code for the "mint," which runs on a remote tamper-evident computer. The purchaser of bit gold can then use remote attestation, which Finney calls the transparent server technique, to verify that a particular number of cycles were actually performed. 34 | 35 | The main problem with all these schemes is that proof of work schemes depend on computer architecture, not just an abstract mathematics based on an abstract "compute cycle." (I wrote about this obscurely several years ago.) Thus, it might be possible to be a very low cost producer (by several orders of magnitude) and swamp the market with bit gold. However, since bit gold is timestamped, the time created as well as the mathematical difficulty of the work can be automatically proven. From this, it can usually be inferred what the cost of producing during that time period was. 36 | 37 | Unlike fungible atoms of gold, but as with collector's items, a large supply during a given time period will drive down the value of those particular items. In this respect "bit gold" acts more like collector's items than like gold. However, the match between this ex post market and the auction determining the initial value might create a very substantial profit for the "bit gold miner" who invents and deploys an optimized computer architecture. 38 | 39 | Thus, bit gold will not be fungible based on a simple function of, for example, the length of the string. Instead, to create fungible units dealers will have to combine different-valued pieces of bit gold into larger units of approximately equal value. This is analogous to what many commodity dealers do today to make commodity markets possible. Trust is still distributed because the estimated values of such bundles can be independently verified by many other parties in a largely or entirely automated fashion. 40 | 41 | In summary, all money mankind has ever used has been insecure in one way or another. This insecurity has been manifested in a wide variety of ways, from counterfeiting to theft, but the most pernicious of which has probably been inflation. Bit gold may provide us with a money of unprecedented security from these dangers. The potential for initially hidden supply gluts due to hidden innovations in machine architecture is a potential flaw in bit gold, or at least an imperfection which the initial auctions and ex post exchanges of bit gold will have to address. 42 | 43 | (Source: ) 44 | -------------------------------------------------------------------------------- /bmoney.md: -------------------------------------------------------------------------------- 1 | # b-money - a scheme for a group of untraceable digital pseudonyms to pay each other with money and to enforce contracts amongst themselves without outside help 2 | 3 | by Wei Dai, November 1998 4 | 5 | I am fascinated by Tim May's crypto-anarchy. Unlike the communities 6 | traditionally associated with the word "anarchy", in a crypto-anarchy the 7 | government is not temporarily destroyed but permanently forbidden and 8 | permanently unnecessary. It's a community where the threat of violence is 9 | impotent because violence is impossible, and violence is impossible 10 | because its participants cannot be linked to their true names or physical 11 | locations. 12 | 13 | Until now it's not clear, even theoretically, how such a community could 14 | operate. A community is defined by the cooperation of its participants, 15 | and efficient cooperation requires a medium of exchange (money) and a way 16 | to enforce contracts. Traditionally these services have been provided by 17 | the government or government sponsored institutions and only to legal 18 | entities. In this article I describe a protocol by which these services 19 | can be provided to and by untraceable entities. 20 | 21 | I will actually describe two protocols. The first one is impractical, 22 | because it makes heavy use of a synchronous and unjammable anonymous 23 | broadcast channel. However it will motivate the second, more practical 24 | protocol. In both cases I will assume the existence of an untraceable 25 | network, where senders and receivers are identified only by digital 26 | pseudonyms (i.e. public keys) and every messages is signed by its sender 27 | and encrypted to its receiver. 28 | 29 | In the first protocol, every participant maintains a (seperate) database 30 | of how much money belongs to each pseudonym. These accounts collectively 31 | define the ownership of money, and how these accounts are updated is the 32 | subject of this protocol. 33 | 34 | 1. The creation of money. Anyone can create money by broadcasting the 35 | solution to a previously unsolved computational problem. The only 36 | conditions are that it must be easy to determine how much computing effort 37 | it took to solve the problem and the solution must otherwise have no 38 | value, either practical or intellectual. The number of monetary units 39 | created is equal to the cost of the computing effort in terms of a 40 | standard basket of commodities. For example if a problem takes 100 hours 41 | to solve on the computer that solves it most economically, and it takes 3 42 | standard baskets to purchase 100 hours of computing time on that computer 43 | on the open market, then upon the broadcast of the solution to that 44 | problem everyone credits the broadcaster's account by 3 units. 45 | 46 | 2. The transfer of money. If Alice (owner of pseudonym K_A) wishes to 47 | transfer X units of money to Bob (owner of pseudonym K_B), she broadcasts 48 | the message "I give X units of money to K_B" signed by K_A. Upon the 49 | broadcast of this message, everyone debits K_A's account by X units and 50 | credits K_B's account by X units, unless this would create a negative 51 | balance in K_A's account in which case the message is ignored. 52 | 53 | 3. The effecting of contracts. A valid contract must include a maximum 54 | reparation in case of default for each participant party to it. It should 55 | also include a party who will perform arbitration should there be a 56 | dispute. All parties to a contract including the arbitrator must broadcast 57 | their signatures of it before it becomes effective. Upon the broadcast of 58 | the contract and all signatures, every participant debits the account of 59 | each party by the amount of his maximum reparation and credits a special 60 | account identified by a secure hash of the contract by the sum the maximum 61 | reparations. The contract becomes effective if the debits succeed for 62 | every party without producing a negative balance, otherwise the contract 63 | is ignored and the accounts are rolled back. A sample contract might look 64 | like this: 65 | 66 | K_A agrees to send K_B the solution to problem P before 0:0:0 1/1/2000. 67 | K_B agrees to pay K_A 100 MU (monetary units) before 0:0:0 1/1/2000. K_C 68 | agrees to perform arbitration in case of dispute. K_A agrees to pay a 69 | maximum of 1000 MU in case of default. K_B agrees to pay a maximum of 200 70 | MU in case of default. K_C agrees to pay a maximum of 500 MU in case of 71 | default. 72 | 73 | 4. The conclusion of contracts. If a contract concludes without dispute, 74 | each party broadcasts a signed message "The contract with SHA-1 hash H 75 | concludes without reparations." or possibly "The contract with SHA-1 hash 76 | H concludes with the following reparations: ..." Upon the broadcast of all 77 | signatures, every participant credits the account of each party by the 78 | amount of his maximum reparation, removes the contract account, then 79 | credits or debits the account of each party according to the reparation 80 | schedule if there is one. 81 | 82 | 5. The enforcement of contracts. If the parties to a contract cannot agree 83 | on an appropriate conclusion even with the help of the arbitrator, each 84 | party broadcasts a suggested reparation/fine schedule and any arguments or 85 | evidence in his favor. Each participant makes a determination as to the 86 | actual reparations and/or fines, and modifies his accounts accordingly. 87 | 88 | In the second protocol, the accounts of who has how much money are kept by 89 | a subset of the participants (called servers from now on) instead of 90 | everyone. These servers are linked by a Usenet-style broadcast channel. 91 | The format of transaction messages broadcasted on this channel remain the 92 | same as in the first protocol, but the affected participants of each 93 | transaction should verify that the message has been received and 94 | successfully processed by a randomly selected subset of the servers. 95 | 96 | Since the servers must be trusted to a degree, some mechanism is needed to 97 | keep them honest. Each server is required to deposit a certain amount of 98 | money in a special account to be used as potential fines or rewards for 99 | proof of misconduct. Also, each server must periodically publish and 100 | commit to its current money creation and money ownership databases. Each 101 | participant should verify that his own account balances are correct and 102 | that the sum of the account balances is not greater than the total amount 103 | of money created. This prevents the servers, even in total collusion, from 104 | permanently and costlessly expanding the money supply. New servers can 105 | also use the published databases to synchronize with existing servers. 106 | 107 | The protocol proposed in this article allows untraceable pseudonymous 108 | entities to cooperate with each other more efficiently, by providing them 109 | with a medium of exchange and a method of enforcing contracts. The 110 | protocol can probably be made more efficient and secure, but I hope this 111 | is a step toward making crypto-anarchy a practical as well as theoretical 112 | possibility. 113 | 114 | ------- 115 | 116 | Appendix A: alternative b-money creation 117 | 118 | One of the more problematic parts in the b-money protocol is money 119 | creation. This part of the protocol requires that all of the account 120 | keepers decide and agree on the cost of particular computations. 121 | Unfortunately because computing technology tends to advance rapidly and 122 | not always publicly, this information may be unavailable, inaccurate, or 123 | outdated, all of which would cause serious problems for the protocol. 124 | 125 | So I propose an alternative money creation subprotocol, in which account 126 | keepers (everyone in the first protocol, or the servers in the second 127 | protocol) instead decide and agree on the amount of b-money to be created 128 | each period, with the cost of creating that money determined by an 129 | auction. Each money creation period is divided up into four phases, as 130 | follows: 131 | 132 | 1. Planning. The account keepers compute and negotiate with each other to 133 | determine an optimal increase in the money supply for the next period. 134 | Whether or not the account keepers can reach a consensus, they each 135 | broadcast their money creation quota and any macroeconomic calculations 136 | done to support the figures. 137 | 138 | 2. Bidding. Anyone who wants to create b-money broadcasts a bid in the 139 | form of where x is the amount of b-money he wants to create, and y 140 | is an unsolved problem from a predetermined problem class. Each problem in 141 | this class should have a nominal cost (in MIPS-years say) which is 142 | publicly agreed on. 143 | 144 | 3. Computation. After seeing the bids, the ones who placed bids in the 145 | bidding phase may now solve the problems in their bids and broadcast the 146 | solutions. 147 | 148 | 4. Money creation. Each account keeper accepts the highest bids (among 149 | those who actually broadcasted solutions) in terms of nominal cost per 150 | unit of b-money created and credits the bidders' accounts accordingly. 151 | 152 | 153 | (Source: ) 154 | -------------------------------------------------------------------------------- /colored-coins.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/colored-coins.pdf -------------------------------------------------------------------------------- /crypto-is-the-mother-of-all-scams.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/crypto-is-the-mother-of-all-scams.pdf -------------------------------------------------------------------------------- /cryptokitties.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/cryptokitties.pdf -------------------------------------------------------------------------------- /decentraland.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/decentraland.pdf -------------------------------------------------------------------------------- /eo-terms.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/eo-terms.pdf -------------------------------------------------------------------------------- /eo.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/eo.pdf -------------------------------------------------------------------------------- /eos-purchase.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/eos-purchase.pdf -------------------------------------------------------------------------------- /etherisc.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/etherisc.pdf -------------------------------------------------------------------------------- /flow-i.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/flow-i.pdf -------------------------------------------------------------------------------- /flow-ii.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/flow-ii.pdf -------------------------------------------------------------------------------- /flow-iii.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/flow-iii.pdf -------------------------------------------------------------------------------- /golem.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/golem.pdf -------------------------------------------------------------------------------- /hashcash-announce.txt: -------------------------------------------------------------------------------- 1 | To: cypherpunks@toad.com 2 | Subject: [ANNOUNCE] hash cash postage implementation 3 | From: Adam Back 4 | Date: Fri, 28 Mar 1997 16:52:26 GMT 5 | Sender: owner-cypherpunks@toad.com 6 | 7 | A partial hash collision based postage scheme 8 | 9 | I've been talking about a partial hash collision based postage scheme 10 | on the crypto lists for the last few days. The idea of using partial 11 | hashes is that they can be made arbitrarily expensive to compute (by 12 | choosing the desired number of bits of collision), and yet can be 13 | verified instantly. 14 | 15 | A first cut implementation of these ideas can be fetched from here: 16 | 17 | * hashcash.tgz 18 | * PGP signature of hashcash.tgz 19 | 20 | I will describe what the implementation allows by example, using the program 21 | so you can follow along if you wish. 22 | 23 | There is an integrated partial hash collision generator (hashcash mint) and 24 | remailer plug-in. The remailer plug-in should be easy to hook into typeI 25 | remailers. typeII or nymserver would require modifying the mixmaster 26 | client/remailer, the code has been designed to make this relatively easy to 27 | do, and link directly into mixmaster, or alpha or newnym. 28 | 29 | Compiling 30 | 31 | % gcc -O6 -c *.c 32 | % gcc -o hashcash hashcash.o sha1.o 33 | % gcc -o sha1 sha1file.o sha1.o 34 | % gcc -o sha1test sha1test.o sha1.o 35 | % 36 | 37 | The functions provided by the program are 38 | 39 | Run with no arguments and it prints a list of flags and terse usage 40 | instructions. 41 | 42 | Speed test: 43 | 44 | % hashcash -t 45 | speed: 7218 hashes per sec 46 | % 47 | 48 | This tells you the number of hashes it can search per second. (Note, the 49 | implementation of sha1 it is using is not optimised, it is my reference 50 | implementation. I have another speed freak sha1 implementation which needs 51 | 1/2 hrs work, and has the same interface, so I'll plug it in later. It's 52 | commented in sha1.c). 53 | 54 | Estimate time required to find 17-bit partial hash collision: 55 | 56 | % hashcash -t -17 57 | speed: 7274 hashes per sec 58 | find: 17 bit partial sha1 collision 59 | estimate: 9 seconds 60 | % 61 | 62 | (varies quite widely from estimated time) 63 | 64 | Calculate a 17 bit collision on string "flame" 65 | 66 | (flame is a now dead remailer): 67 | 68 | % hashcash -17 flame 69 | speed: 7274 hashes per sec 70 | find: 17 bit partial sha1 collision 71 | collision: 09948flame356018443 72 | tries: 57450 73 | % 74 | 75 | The collision is actually found on the hash of the date since Jan 1 1970 in 76 | days (5 digit leading zero filled) and string given. 77 | 78 | So the collision is found on: 79 | 80 | % echo -n 09948flame | sha1 81 | fbbea210abafe3e72afe7849eaea2052e309e017 82 | % 83 | 84 | The collision that was found can be seen manually as the collision is 85 | constrained to be the MSbits of the digest: 86 | 87 | % echo -n 09948flame356018443 | sha1 88 | fbbead76da651cf856f7466fed9624d3ada061d9 89 | % 90 | 91 | You can manually see that the first 20 bits match. (Note we asked for a 17 92 | bit hash, but it generates a 17 bit or larger hash. We just got lucky and 93 | got an extra 3 bits, which would happen about 1 time in 8). 94 | 95 | The hashcash client can also report on a collision: 96 | 97 | % hashcash flame 09948flame356018443 98 | collision: 20 bits 99 | % 100 | 101 | You can check on the validity period as compared to todays date: 102 | 103 | % hashcash flame 09948flame356018443 28 104 | validity: 28 days remaining 105 | collision: 20 bits 106 | % 107 | 108 | You can check that a hash has a requested number of bits: 109 | 110 | % hashcash -25 flame 09948flame356018443 111 | collision: 20 bits 112 | required: 25 bits 113 | rejected: too few bits 114 | % 115 | 116 | The exit status is set to failure if any of the tests fail: ie if there are 117 | too few bits, or if you do a validity check and the hash has expired, or 118 | isn't yet in it's validity period. 119 | 120 | Double spending protection 121 | 122 | You can also ask the hashcash client to remember collisions within a 123 | selected validity period. 124 | 125 | % hashcash -d -25 flame 09948flame356018443 28 126 | validity: 28 days remaining 127 | collision: 20 bits 128 | required: 20 bits 129 | database: not double spent 130 | adding: 28 09948flame356018443 131 | % 132 | 133 | The collision will only be added if all the tests pass (in validity period, 134 | required number of bits). The exit status also tells you if the hash was ok. 135 | 136 | The database would grow indefinately as the mailer accepted new payments, so 137 | the validity period is stored in the database, and at the next use of the 138 | database after the validity period expires, the collision will be discarded. 139 | There is no need to keep expired collisions around because we wouldn't 140 | accetp it anyway because it's out of date, so who cares if we've previously 141 | accepted it. A validity period of 0 means valid forever, and it will never 142 | be discarded from the database. 143 | 144 | An example of double spending 145 | 146 | A new test now is whether a hash has been presented before, so we the above 147 | command and expect it to be rejected as already spent, because it is in the 148 | database: 149 | 150 | % hashcash -d -25 flame 09948flame356018443 28 151 | validity: 28 days remaining 152 | collision: 20 bits 153 | required: 25 bits 154 | rejected: too few bits 155 | database: double spent 156 | % 157 | 158 | (exit status is set to failure, due to double spent cash) 159 | 160 | That's it 161 | 162 | It's very lightly tested, so if anything breaks let me know. 163 | 164 | It's got some inefficiencies in places, but working code comes first, 165 | efficiency later. 166 | 167 | (Also I have not tested my SHA1 implementation on a big endian machine, it 168 | auto-detects byte endian-ness, theoretically). 169 | 170 | Remailer applications discussed so far 171 | 172 | * exit remailer postage per post 173 | * spam filter on mail you receive, if it hasn't got a 20 bit hash, or 1c 174 | digicash you have a program which bounces it with a notice explaining 175 | the required postage, and where to obtain software from. This would put 176 | spammers out of business overnight, as 1,000,000 x 20 = 100 MIP years 177 | which is going to be more compute than they've got, and 1,000,000 x 1c 178 | = $10,000 is going to be more than they are likely to make through 179 | sales interest from the spam. 180 | * good behaviour bond for nymserver users. The nymserver user pays the 181 | nymserver (in a largish hash collision, or $25 digicash) for a 182 | replyable nymserver account. They agree an contract with the penalty 183 | clause that breaking the contract means the nymserver keeps the 184 | digicash/collision, and disables the account. They user's identity 185 | isn't known, but to join in again they have to pay up another large 186 | hash collision or more digicash. 187 | * there are lots of other ideas to play with. 188 | 189 | How does this fit in with digicash 190 | 191 | Digicash postage on remailers, and mail would be useful, however there are a 192 | number of problems with digicash: 193 | 194 | * It is more onerous to set up an account (form filling etc) 195 | * Not many people have accounts 196 | * It's only anonymous for the payer anonymous (and not anonymous for the 197 | seller) 198 | 199 | So my suggestion is that we have remailers which accept either hash 200 | collision postage, or digicash postage. The advantages of this approach are: 201 | 202 | * Hashcash may provide a stop gap measure until digicash becomes more 203 | widely used 204 | * Hashcash is free, all you've got to do is burn some cycles on your PC. 205 | It is in keeping with net culture of free discourse, where the 206 | financially challenged can duke it out with millionaires, retired 207 | government officials, etc on equal terms. 208 | * Hashcash may provide us with a fall back method for controling spam if 209 | digicash goes sour (gets outlawed or required to escrow user 210 | identities). 211 | 212 | Any comments, code, etc gratefully received. A couple of remailers 213 | alpha testing it would be nice also. 214 | 215 | Adam 216 | 217 | (Source: ) 218 | -------------------------------------------------------------------------------- /hashcash.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/hashcash.pdf -------------------------------------------------------------------------------- /hotstuff.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/hotstuff.pdf -------------------------------------------------------------------------------- /howey.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/howey.pdf -------------------------------------------------------------------------------- /libra-blockchain.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra-blockchain.pdf -------------------------------------------------------------------------------- /libra-consensus.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra-consensus.pdf -------------------------------------------------------------------------------- /libra-governance.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra-governance.pdf -------------------------------------------------------------------------------- /libra-move.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra-move.pdf -------------------------------------------------------------------------------- /libra-reserve.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra-reserve.pdf -------------------------------------------------------------------------------- /libra-v2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra-v2.pdf -------------------------------------------------------------------------------- /libra.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/libra.pdf -------------------------------------------------------------------------------- /litecoin.md: -------------------------------------------------------------------------------- 1 | # [ANN] Litecoin - a lite version of Bitcoin. Launched! 2 | 3 | by Charlie Lee 4 | 5 | October 09, 2011, 06:14:28 AM 6 | 7 | --- 8 | 9 | **LAUNCHED** 10 | 11 | - Download the binaries from: http://litecoin.org 12 | - Check out the source: https://github.com/litecoin-project/litecoin 13 | - Wiki: http://litecoin.info 14 | - Forum: http://forum.litecoin.net/ 15 | 16 | --- 17 | 18 | Litecoin is the result of some of us who joined together on IRC in an effort to create a real alternative currency similar to Bitcoin. We wanted to make a coin that is silver to Bitcoin's gold. Various alternative currencies have come and gone. Some brought innovation, but they all had problems. 19 | 20 | - ixcoin - Nasakioto premined 580k coins. Seemed like a pump and dump. Competed with Bitcoin for GPU resources - Dead (~2 gh/s) 21 | - i0coin - Basically ixcoin without the premine. Not much support was given to this coin after it was released. - Dead (~5 gh/s) 22 | - SolidCoin - Innovative quick transaction times. Appears to have been run aground by CoinHunter, its creator, due to insecure changes and immature forum presence. - Dead, shutdown by CoinHunter 23 | - GeistGeld - Lolcust premined 7.7 million coins. 15 second block time is probably a bit extreme. - Alive, but limping (~15 gh/s) 24 | - Tenebrix - Lolcust premined 7.7 million coins. CPU proof of work using scrypt is very innovative. Price doing fairly well on btc-e.com. - Alive (~0.003 gh/s) 25 | - Fairbrix - Basically Tenebrix without the premine. First launch was crippled due to bad config. Relaunch attacked initially - Doing OK now, but no exchange so far. - Alive, but limping (~0.0001 gh/s) 26 | 27 | We wanted the best innovations of Bitcoin and these other currencies to create a coin with all of their benefits, but nearly none of their problems. 28 | 29 | **Proof of Work** 30 | 31 | We really liked Tenebrix's Scrypt proof of work. Using Scrypt allows one to mine Litecoin while also mining Bitcoin. We humbly offer a big thanks to ArtForz for the implementation. 32 | 33 | **Premines** 34 | 35 | Litecoin will come with 150 premined coins: just the genesis block and the first 2 blocks to confirm the genesis is valid. We believe a coin needs to be released in a fair manner. Having one person (or a group) control a large amount of coins that can be used as they see fit is against the decentralized vision of Bitcoin. Yes, it is true that without a stash of premined coins, we will not be able to afford to pay for bounties, but we believe people will see the virtue of this coin, invest in it as early adopters, and will be willing to spend time creating services to make this coin better. 36 | 37 | **Fast transactions** 38 | 39 | We were impressed by the convenience of SolidCoin's fast transactions. Although we know that fast confirmations are not necessarily as secure as Bitcoin's slower confirmations, they are very convenient for small merchants who don't need transactions to be super secure. The average Litecoin block takes 2.5 minutes, one quarter of Bitcoin's 10 minutes. So if merchants wanted to be as safe as Bitcoin, they can wait for 4 times the number of Litecoin confirmations as compared to Bitcoin. But most merchants can readily accept 1-confirmed transactions for small amounts of litecoins. 40 | 41 | **Difficulty retarget** 42 | 43 | We will keep the retarget block the same as Bitcoin's 2016, but because blocks are found 4 times faster, difficulty will retarget about every 3.5 days. The combination of fast retarget times and Scrypt proof of work (Litecoin will not compete with Bitcoin for miners) means we expect to not see the sort of problem Namecoin encountered; hashing power that leaves more suddenly than it came, causing a high difficulty slog for everyone who stayed. 44 | 45 | **Coin generation** 46 | 47 | Miners will generate 50 coins per block. In light of our faster blocks, to properly mimic Bitcoin's generation trajectory, we needed to change the blocks at which coin generation is halved. Bitcoin generation is halved every 210,000 blocks. Litecoin generation will be halved every 840,000 blocks. For those of you doing the math, Litecoin is scheduled to produce roughly 4 times as many coins as Bitcoin, about 84 million litecoins. 48 | 49 | **Fairness** 50 | 51 | We have come up with a plan that we believe is most fair. Some previous coins were released without Windows binaries or without source code; we consider this as unfair as it is unsafe. 52 | 53 | We released the source code and binaries ahead of time... 3 days before launch. People had time to compile the source and run the client on their machines against the Litecoin testnet. So people were able to make sure everything was working well before the launch. We also had a poll so that people can vote for a launch time that best suits them. At the time of the launch (Oct 12 03:00 GMT), we released the genesis hash and everyone started mining at the same time. All it took was a simple change in the config file in order to mine the real coin instead of the testnet coin. 54 | 55 | **51% attack** 56 | 57 | The problem with alternative currencies is that the network hashrate is likely low when the coin starts up, making an easy target for any potential 51% attacker. With a little hope, a little prayer, a lot of hype, and due to our innovative release, there was a large hashrate from minute one. We believe this deterred any attackers from targeting this chain. As expected, there was a lot of natural orphaning of blocks, due to having so many people mining on the chain at once. With block locking at every difficulty change, we were able to avoid any attacks from succeeding. (if there were any) 58 | 59 | **Source code** 60 | 61 | The source code is here: 62 | - https://github.com/litecoin-project/litecoin 63 | 64 | This is based on the latest Bitcoin code. You can either build the daemon version (litecoind) or you can build the gui version (Litecoin QT). See the build docs. 65 | 66 | Similar to Bitcoin, you may want to create a litecoin.conf file here: 67 | - Windows: C:\Documents and Settings\\Application Data\Litecoin 68 | - Win7: C:\Users\\AppData\Roaming\Litecoin 69 | - Mac: ~/Library/Application Support/Litecoin 70 | - Unix: ~/.litecoin 71 | 72 | Port is 9333. Open if on your router if you know how. This will allow you to have more than 8 connections. 73 | And default RPC port is 9332. This is the port miners will use to communicate with your client/daemon. 74 | 75 | Sample litecoin.conf file: 76 | 77 | ``` 78 | server=1 79 | rpcuser=user 80 | rpcpassword=password 81 | 82 | #Change this if you want to use a different rpc port for mining 83 | #rpcport=9332 84 | 85 | #Only uncomment this if you are running litecoind and want to run Litecoin in the background (not Litecoin QT) 86 | #daemon=1 87 | ``` 88 | 89 | So tell us what you think. Come to the Litecoin forums (http://forum.litecoin.net) or drop by #litecoin or #litecoin-dev on freenode IRC to chat. 90 | 91 | (Source: ) 92 | -------------------------------------------------------------------------------- /mastercoin-risks.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/mastercoin-risks.pdf -------------------------------------------------------------------------------- /mastercoin-v05.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/mastercoin-v05.pdf -------------------------------------------------------------------------------- /mastercoin.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/mastercoin.pdf -------------------------------------------------------------------------------- /mimblewimble.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/mimblewimble.pdf -------------------------------------------------------------------------------- /mimblewimble.txt: -------------------------------------------------------------------------------- 1 | MIMBLEWIMBLE 2 | Tom Elvis Jedusor 3 | 19 July, 2016 4 | 5 | \****/ 6 | Introduction 7 | /****\ 8 | 9 | Bitcoin is the first widely used financial system for which all the necessary 10 | data to validate the system status can be cryptographically verified by anyone. 11 | However, it accomplishes this feat by storing all transactions in a public 12 | database called "the blockchain" and someone who genuinely wishes to check 13 | this state must download the whole thing and basically replay each transaction, 14 | check each one as they go. Meanwhile, most of these transactions have not 15 | affected the actual final state (they create outputs that are destroyed 16 | a transaction later). 17 | 18 | At the time of this writing, there were nearly 150 million transactions 19 | committed in the blockchain, which must be replayed to produce a set of 20 | only 4 million unspent outputs. 21 | 22 | It would be better if an auditor needed only to check data on the outputs 23 | themselves, but this is impossible because they are valid if and only if the 24 | output is at the end of a chain of previous outputs, each signs the next. In 25 | other words, the whole blockchain must be validated to confirm the final 26 | state. 27 | 28 | 29 | Add to this that these transactions are cryptographically atomic, it is clear 30 | what outputs go into every transaction and what emerges. The "transaction graph" 31 | resulting reveals a lot of information and is subjected to analysis by many 32 | companies whose business model is to monitor and control the lower classes. 33 | This makes it very non-private and even dangerous for people to use. 34 | 35 | 36 | Some solutions to this have been proposed. Greg Maxwell discovered to encrypt 37 | the amounts, so that the graph of the transaction is faceless but still allow 38 | validation that the sums are correct [1]. Dr Maxwell also produced CoinJoin, 39 | a system for Bitcoin users to combine interactively transactions, confusing 40 | the transaction graph. Nicolas van Saberhagen has developed a system to blind 41 | the transaction entries, goes much further to cloud the transaction graph (as 42 | well as not needed the user interaction) [3]. Later, Shen Noether combined 43 | the two approaches to obtain "confidential transactions" of Maxwell AND the 44 | darkening of van Saberhagen [4]. 45 | 46 | These solutions are very good and would make Bitcoin very safe to use. But 47 | the problem of too much data is made even worse. Confidential transactions 48 | require multi-kilobyte proofs on every output, and van Saberhagen signatures 49 | require every output to be stored for ever, since it is not possible to tell 50 | when they are truly spent. 51 | 52 | Dr. Maxwell's CoinJoin has the problem of needing interactivity. Dr. Yuan Horas 53 | Mouton fixed this by making transactions freely mergeable [5], but he needed to 54 | use pairing-based cryptography, which is potentially slower and more difficult 55 | to trust. He called this "one-way aggregate signatures" (OWAS). 56 | 57 | OWAS had the good idea to combine the transactions in blocks. Imagine that we 58 | can combine across blocks (perhaps with some glue data) so that when the outputs 59 | are created and destroyed, it is the same as if they never existed. Then, to 60 | validate the entire chain, users only need to know when money is entered into 61 | the system (new money in each block as in Bitcoin or Monero or peg-ins for 62 | sidechains [6]) and final unspent outputs, the rest can be removed and forgotten. 63 | Then we can have Confidential Transactions to hide the amounts and OWAS to blur 64 | the transaction graph, and use LESS space than Bitcoin to allow users to fully 65 | verify the blockchain. And also imagine that we must not pairing-based cryptography 66 | or new hypotheses, just regular discrete logarithms signatures like Bitcoin. 67 | Here is what I propose. 68 | 69 | I call my creation Mimblewimble because it is used to prevent the blockchain from 70 | talking about all user's information [7]. 71 | 72 | 73 | \****/ 74 | Confidential Transactions and OWAS 75 | /****\ 76 | 77 | The first thing we need to do is remove Bitcoin Script. This is sad, but it is too 78 | powerful so it is impossible to merge transactions using general scripts. We will 79 | demonstrate that confidential transactions of Dr. Maxwell are enough (after some 80 | small modification) to authorize spending of outputs and also allows to make 81 | combined transactions without interaction. This is in fact identical to OWAS, 82 | and allows relaying nodes take some transaction fee or the recipient to change 83 | the transaction fees. These additional things Bitcoin can not do, we get for free. 84 | 85 | We start by reminding the reader how confidential transactions work. First, the 86 | amounts are coded by the following equation: 87 | 88 | C = r*G + v*H 89 | 90 | where C is a Pedersen commitment, G and H are fixed nothing-up-my-sleeve elliptic 91 | curve group generators, v is the amount, and r is a secret random blinding key. 92 | 93 | Attached to this output is a rangeproof which proves that v is in [0, 2^64], so 94 | that user cannot exploit the blinding to produce overflow attacks, etc. 95 | 96 | To validate a transaction, the verifer will add commitments for all outputs, plus 97 | f*H (f here is the transaction fee which is given explicitly) and subtracts all 98 | input commitments. The result must be 0, which proves that no amount was created 99 | or destroyed overall. 100 | 101 | We note that to create such a transaction, the user must know the sum of all the 102 | values of r for commitments entries. Therefore, the r-values (and their sums) act 103 | as secret keys. If we can make the r output values known only to the recipient, 104 | then we have an authentication system! Unfortunately, if we keep the rule that 105 | commits all add to 0, this is impossible, because the sender knows the sum of 106 | all _his_ r values, and therefore knows the receipient's r values sum to the 107 | negative of that. So instead, we allow the transaction to sum to a nonzero value 108 | k*G, and require a signature of an empty string with this as key, to prove its 109 | amount component is zero. 110 | 111 | We let transactions have as many k*G values as they want, each with a signature, 112 | and sum them during verification. 113 | 114 | To create transactions sender and recipient do following ritual: 115 | 116 | 1. Sender and recipient agree on amount to be sent. Call this b. 117 | 118 | 2. Sender creates transaction with all inputs and change output(s), and gives 119 | recipient the total blinding factor (r-value of change minus r-values of 120 | inputs) along with this transaction. So the commitments sum to r*G - b*H. 121 | 122 | 3. Recipient chooses random r-values for his outputs, and values that sum 123 | to b minus fee, and adds these to transaction (including range proof). 124 | Now the commitments sum to k*G - fee*H for some k that only recipient 125 | knows. 126 | 127 | 4. Recipient attaches signature with k to the transaction, and the explicit 128 | fee. It has done. 129 | 130 | Now, creating transactions in this manner supports OWAS already. To show this, 131 | suppose we have two transactions that have a surplus k1*G and k2*G, and the 132 | attached signatures with these. Then you can combine the lists of inputs and 133 | outputs of the two transactions, with both k1*G and k2*G to the mix, and 134 | voilá! is again a valid transaction. From the combination, it is impossible to 135 | say which outputs or inputs are from which original transaction. 136 | 137 | Because of this, we change our block format from Bitcoin to this information: 138 | 139 | 1. Explicit amounts for new money (block subsidy or sidechain peg-ins) with 140 | whatever else data this needs. For a sidechain peg-in maybe it references 141 | a Bitcoin transaction that commits to a specific excess k*G value? 142 | 143 | 2. Inputs of all transactions 144 | 145 | 3. Outputs of all transactions 146 | 147 | 4. Excess k*G values for all transactions 148 | 149 | Each of these are grouped together because it do not matter what the transaction 150 | boundaries are originally. In addition, Lists 2 3 and 4 should be required to be 151 | coded in alphabetical order, since it is quick to check and prevents the block 152 | creator of leaking any information about the original transactions. 153 | 154 | Note that the outputs are now identified by their hash, and not by their position 155 | in a transaction that could easily change. Therefore, it should be banned to have 156 | two unspent outputs are equal at the same time, to avoid confusion. 157 | 158 | 159 | 160 | \****/ 161 | Merging Transactions Across Blocks 162 | /****\ 163 | 164 | Now, we have used Dr. Maxwell's Confidential Transactions to create a noninteractive 165 | version of Dr. Maxwell's CoinJoin, but we have not seen the last of marvelous Dr. Maxwell! 166 | We need another idea, transaction cut-through, he described in [8]. Again, we create a 167 | noninteractive version of this, and to show how it is used with several blocks. 168 | 169 | We can imagine now each block as one large transaction. To validate it, we add all the 170 | output commitments together, then subtracts all input commitments, k*G values, and all 171 | explicit input amounts times H. We find that we could combine transactions from two 172 | blocks, as we combined transactions to form a single block, and the result is again 173 | a valid transaction. Except now, some output commitments have an input commitment exactly 174 | equal to it, where the first block's output was spent in the second block. We could 175 | remove both commitments and still have a valid transaction. In fact, there is not even 176 | need to check the rangeproof of the deleted output. 177 | 178 | The extension of this idea all the way from the genesis block to the latest block, we 179 | see that EVERY nonexplicit input is deleted along with its referenced output. What 180 | remains are only the unspent outputs, explicit input amounts and every k*G value. 181 | And this whole mess can be validated as if it were one transaction: add all unspent 182 | commitments output, subtract the values k*G, validate explicit input amounts (if there 183 | is anything to validate) then subtract them times H. If the sum is 0, the entire 184 | chain is good. 185 | 186 | What is this mean? When a user starts up and downloads the chain he needs the following 187 | data from each block: 188 | 189 | 1. Explicit amounts for new money (block subsidy or sidechain peg-ins) with 190 | whatever else data this needs. 191 | 192 | 2. Unspent outputs of all transactions, along with a merkle proof that each 193 | output appeared in the original block. 194 | 195 | 3. Excess k*G values for all transactions. 196 | 197 | Bitcoin today there are about 423000 blocks, totaling 80GB or so of data on the hard 198 | drive to validate everything. These data are about 150 million transactions and 5 million 199 | unspent nonconfidential outputs. Estimate how much space the number of transactions 200 | take on a Mimblewimble chain. Each unspent output is around 3Kb for rangeproof and 201 | Merkle proof. Each transaction also adds about 100 bytes: a k*G value and a signature. 202 | The block headers and explicit amounts are negligible. Add this together and get 203 | 30Gb -- with a confidential transaction and obscured transaction graph! 204 | 205 | 206 | \****/ 207 | Questions and Intuition 208 | /****\ 209 | 210 | Here are some questions that since these weeks, dreams asked me and I woke up sweating. 211 | But in fact it is OK. 212 | 213 | Q. If you delete the transaction outputs, user cannot verify the rangeproof and maybe 214 | a negative amount is created. 215 | 216 | A. This is OK. For the entire transaction to validate all negative amounts must have 217 | been destroyed. User have SPV security only that no illegal inflation happened in 218 | the past, but the user knows that _at this time_ no inflation occurred. 219 | 220 | 221 | Q. If you delete the inputs, double spending can happen. 222 | 223 | A. In fact, this means: maybe someone claims that some unspent output was spent 224 | in the old days. But this is impossible, otherwise the sum of the combined transaction 225 | could not be zero. 226 | 227 | An exception is that if the outputs are amount zero, it is possible to make two that 228 | are negatives of each other, and the pair can be revived without anything breaks. So to 229 | prevent consensus problems, outputs 0-amount should be banned. Just add H at each output, 230 | now they all amount to at least 1. 231 | 232 | 233 | 234 | \****/ 235 | Future Research 236 | /****\ 237 | 238 | Here are some questions I can not answer at the time of this writing. 239 | 240 | 1. What script support is possible? We would need to translate script operations into 241 | some sort of discrete logarithm information. 242 | 243 | 2. We require user to check all k*G values, when in fact all that is needed is that their 244 | sum is of the form k*G. Instead of using signatures is there another proof of discrete 245 | logarithm that could be combined? 246 | 247 | 3. There is a denial-of-service option when a user downloads the chain, the peer can give 248 | gigabytes of data and list the wrong unspent outputs. The user will see that the result 249 | do not add up to 0, but cannot tell where the problem is. 250 | 251 | For now maybe the user should just download the blockchain from a Torrent or something 252 | where the data is shared between many users and is reasonably likely to be correct. 253 | 254 | 255 | 256 | [1] https://people.xiph.org/~greg/confidential_values.txt 257 | [2] https://bitcointalk.org/index.php?topic=279249.0 258 | [3] https://cryptonote.org/whitepaper.pdf 259 | [4] https://eprint.iacr.org/2015/1098.pdf 260 | [5] https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf 261 | [6] http://blockstream.com/sidechains.pdf 262 | [7] http://fr.harrypotter.wikia.com/wiki/Sortilège_de_Langue_de_Plomb 263 | [8] https://bitcointalk.org/index.php?topic=281848.0 264 | -------------------------------------------------------------------------------- /peercoin.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/peercoin.pdf -------------------------------------------------------------------------------- /ponzico.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/ponzico.pdf -------------------------------------------------------------------------------- /primecoin.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/primecoin.pdf -------------------------------------------------------------------------------- /savedroid.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/savedroid.pdf -------------------------------------------------------------------------------- /tether.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/tether.pdf -------------------------------------------------------------------------------- /tetherino.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/tetherino.pdf -------------------------------------------------------------------------------- /what-satoshi-did-not-know.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openblockchains/blockchain-whitepapers/3dd581df6dfb885a2a7c9e59497aa5c7fa31f54e/what-satoshi-did-not-know.pdf --------------------------------------------------------------------------------