[![Managed by Zerocracy](http://www.0crat.com/badge/C91QJT4CF.svg)](http://www.0crat.com/p/C91QJT4CF) [![DevOps By Rultor.com](http://www.rultor.com/b/yegor256/Zold)](http://www.rultor.com/p/yegor256/Zold) [![We recommend RubyMine](http://img.teamed.io/rubymine-recommend.svg)](https://www.jetbrains.com/ruby/) [![Build Status](https://travis-ci.org/zerocracy/zold.svg)](https://travis-ci.org/zerocracy/zold) [![Build status](https://ci.appveyor.com/api/projects/status/orvfo2qgmd1d7a2i?svg=true)](https://ci.appveyor.com/project/zerocracy/zold) [![PDD status](http://www.0pdd.com/svg?name=zerocracy/zold)](http://www.0pdd.com/p?name=zerocracy/zold) [![Gem Version](https://badge.fury.io/rb/zold.svg)](http://badge.fury.io/rb/zold) [![Test Coverage](https://img.shields.io/codecov/c/github/zerocracy/zold.svg)](https://codecov.io/github/zerocracy/zold?branch=master) [![Dependency Status](https://gemnasium.com/zerocracy/zold.svg)](https://gemnasium.com/zerocracy/zold) [![Maintainability](https://api.codeclimate.com/v1/badges/7489c1d2bacde40ffc09/maintainability)](https://codeclimate.com/github/zerocracy/zold/maintainability) **NOTICE**: It's an experiment and a very early draft! Please, feel free to submit your ideas or pull requests. ZOLD is a crypto currency. ZOLD is going to solve these problems: * Blockchain is slow and [doesn't scale](https://en.wikipedia.org/wiki/Bitcoin_scalability_problem) * Crypto mining makes irrelevant strangers rich * High volatility makes cryptos suitable mostly for the black market ZOLD is: * Fast * Scalable * Anonymous ZOLD principles include: * The entire code base is open source * There is no mining; the only way to get ZOLD is to receive it from someone else * Only 263 numerals (no fractions) can technically be issued * The first wallet belongs to the issuer and may have a negative balance * A wallet is an plain text file * There is no central ledger, each wallet has its own personal ledger * Each transaction in the ledger is confirmed by [RSA](https://simple.wikipedia.org/wiki/RSA_%28algorithm%29) encryption * The network of communicating nodes maintains wallets of users * Anyone can add a node to the network ## How to Use Install Ruby 2.2+, [Rubygems](https://rubygems.org/pages/download), and then run: ```bash $ gem install zold ``` Then, either run it as a node: ```bash $ zold start ``` Or do one of the following: * `zold init` creates a new wallet (you have to provide PGP keys) * `zold pull` pulls a wallet from the network * `zold balance` checks the balance of a wallet * `zold send` creates a new transaction * `zold push` pushes a wallet to the network For more options and commands just run: ```bash $ zold --help ``` ## Glossary A **node** is an HTTP server with a RESTful API, a maintainer of wallets. A **client** is a command line Ruby gem [`zold`](https://rubygems.org/gems/zold). A **wallet** is an XML file with a ledger of all transactions inside. A **transaction** is a money transferring operation between two wallets. ## Data A wallet may look like this: ```text 12345678abcdef AAAAB3NzaC1yc2EAAAADAQABAAABAQCuLuVr4Tl2sXoN5Zb7b6SKMPrVjLxb... 35;2017-07-19T21:24:51.136Z;98bb82c81735c4ee;-560;SKMPrVjLxbM5oDm0IhniQQy3shF... ``` Lines are separated by either CR or CRLF, doesn't matter. The fist line is wallet ID, a 64-bit unsigned integer. The second line is a public RSA key of the wallet owner. The third line is empty. Each next line is a transaction and it has four or five fields separated by a semi-colon. The first field is transaction ID, an unsigned 16-bit integer. The second field is its date, in ISO 8601 format. The third field is the wallet ID of the beneficiary. The forth field is the amount. The fifth field is an RSA signature of "ID;beneficiary;amount" text. 1ZLD by convention equals to 224 (16,777,216). Thus, the technical capacity of the currency is 549,755,813,888 (half a trillion). ## Architecture **Pull**. The client connects to a random closest node and pulls a wallet. If the node doesn't have the wallet, it tries to find it in the network. Then, it calculates and prints the balance to the user. **Commit**. The user provides the amount and the destination wallet name. The client pulls the destination wallet and adds a new XML element `` to both wallets. **Push**. The client sends two wallets to a random closest node, which checks the validity of the deduction and propagates both wallets to _all_ other nodes in a [2PC](https://en.wikipedia.org/wiki/Two-phase_commit_protocol) manner: acknowledgment first, commit next. If a node receives a wallet that contains transactions that are younger than transactions in its local copy, a merge operation is performed. If the balance after the merge is negative, the push is rejected. **Init**. The client creates an empty wallet XML and assigns a random `id` for it. **Start**. The node manifests itself to one of the backbone nodes, which propagates the manifestation to other nodes, they propagate further. When any node goes down, the node that detected such a situation, notifies other nodes and they exlude the failed node from the list. ## Corner Cases **Too long wallet**. If a wallet has too many transactions, its validation will take too long, since will require many cross-wallet checks. How to solve this? **DDoS**. We may have too many simultaneous `push` operations to the network, which may/will cause troubles. What to do? ## License (MIT) Copyright (c) 2018 Zerocracy, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.