hcashd

README

Overview of Hybrid Consensus Scheme in Hcash

When designing the consensus scheme for Hcash, we need to determine which technology for permissionless distributed ledger should be adopted, blockchain-based or DAG(Directed Acyclic Graph)-based? On the one hand, blockchain technique has been well studied in the aspects of consensus model, scalability, efficiency, security, robustness, privacy preserving, etc. Also, it has been widely applied and thoroughly testified in various decentralized cryptocurrencies or systems such as Bitcoin, Ethereum, and so on. Hence, blockchain is considered as a reliable technique for permissionless distributed ledger though there is still lots of room for the improvement of this promising technology. On the other hand, DAG technique has been leveraged recently in a few cryptocurrencies. These DAG-based cryptocurrencies are merited for their potential high throughput, especially in the case of massive transactions. However, DAG-based distributed systems lack sufficiently rigid and convincing investigation and evaluation, as well as sophisticated trial in practice. Furthermore, we find that there are some security issues in the existing DAG-based cryptocurrencies, for instance, IOTA's security heavily relies on the transaction frequency; Security flaw exists in the consensus model of Byteball (specifically, in the strategy algorithm for moving forward stable point of the distributed system); Byteball's security depends on a few “witness” nodes, which leads to potential centralization. Consequently, we adopt blockchain-based instead of DAG-based technology in Hcash.

After bitcoin was presented in 2008, various cryptocurrencies have been proposed and developed. Also, enhancements to the existing decentralized systems have been devised and put into practice. Among all, the most attractive innovations include Ethereum (supporting smart contracts), CryptoNotes, ZeroCash (enhancing privacy via ring signatures or non-interactive zero-knowledge proofs), DASH, Decred (implementing hybrid consensus and basic DAO), IOTA, Byteball (improving the throughput with DAG-based structure), Bitcoin-NG (introducing keyblock and microblock to enhance throughput), and sidechain techniques (supporting interchangeability between some given cryptocurrencies).

Proof-of-work (PoW), the consensus scheme implemented in bitcoin and many other well-known decentralized cryptocurrencies, has lots of merits including trustworthy sustainability, strong robustness against malicious participants, delicate incentive-compatibility, and openness to any participant (i.e., participants could join and leave dynamically).

Meanwhile, PoW has been criticized due to its waste of resources and a potential centralization of hash power. Thus alternative consensus models have been introduced to replace (fully or partially) PoW, like proof-of-stake (PoS). However, PoS is controversial for its sustainability and security, due to lack of practical trials and the risk of data forgery.

Another drawback of PoW is its relatively poor efficiency. Bitcoin, equipped with PoW, can only support very limited transaction throughput (say, at most 7 transactions per second (TPS)), which greatly constrains the scalability of Bitcoin system. So far five approaches have been proposed to solve or relieve this issue as shown below:

1. Shorten the block interval;
2. Extend the block size;
3. Adopt two-layer chain structure (i.e., keyblock/microblock);
4. Introduce the lightning network;
5. Apply DAG-based framework/structure.

Among them, 1) compromises certain stability/security of decentralized system, which has been shown by the practice of ETH. More specifically, the short block interval (20-30s) adopted in ETH did cause instability of the system, and to face this issue, the “GHOST” protocol (somewhat controversial) was implemented in ETH. For 2), it seems simple but causes communication burden to the network. While for 3), it was presented in Bitcoin-NG and its main idea is as follows: the block created by a miner after solving hash puzzle is called a keyblock. After the creation of a keyblock (say, block A), the corresponding miner can release several microblocks before a keyblock succeeding block A is generated. The security and robustness of the decentralized system rely on the PoW mechanism for keyblock, and the system throughput can be improved greatly due to frequent release of microblocks. However, Bitcoin-NG is problematic for its vulnerability to selfish mining and a potential attack by keyblock proposer's spawning massive microblocks which undermines the convergence property of the system and causes network overburdening because of massive forks. Regarding 4), it provides an efficient off-chain transaction mechanism, targeting on transactions with small value and high frequency. As for 5), it draws much interest for its potential high throughput, however, this novel technique still needs to be sufficiently investigated and evaluated theoretically and practically.

To date, existing decentralized cryptocurrencies adopt either PoW consensus scheme or hybrid consensus model of PoW and PoS. However, these systems still encounter the issue of very limited efficiency/throughput.

Hcash project aims to build secure, efficient, robust and reliable decentralized system. Highlighted features such as newly-proposed hybrid consensus scheme, post-quantum digital signature, linkability among various blockchain-based and DAG-based decentralized cryptocurrencies, smart contract mechanism and post-quantum privacy-preserving scheme will be proposed and implemented in Hcash eventually. First of all, we present a novel hybrid consensus scheme with strong robustness, high throughput as well as sufficient flexibility in Hcash. On the one hand, with a newly-proposed two-layer framework of block chain, significant improvement of the efficiency is offered without compromising the security. On the other hand, with a hybrid consensus model, both PoW and PoS miners are incentivized to take part in the consensus process, thereby enhancing the security and flexibility of the consensus scheme, and providing a mechanism that supports basic DAO for future protocol updating and project investments.

Our brand-new consensus mechanism inherits the merits of Decred and Bitcoin-NG, based on which we propose key innovations to make our scheme more secure, efficient and flexible. Firstly, with the methodology from Bitcoin-NG's keyblock/microblock structure, we offer a two-layer chain structure. To tackle the aforementioned security issue existed in Bitcoin-NG, we present two-level mining mechanism and incorporate this mechanism into the two-layer chain structure. More specifically, two level of difficulties of PoW hash puzzle are set and these difficulties can be adjusted dynamically. When solving a hash puzzle, PoW miner can create a keyblock once the hard-level difficulty is met, and publish a microblock in the case that the low-level difficulty is satisfied. In this way, the system throughput could be enhanced significantly, and the security of the system is not compromised since malicious miners can not spawn massive microblocks freely. Furthermore, to tackle the selfish mining issue, strengthen the robustness against “the 51% attack” of PoW miners, and offer the sufficient flexibility (supporting both PoW and PoS mining), we borrow the idea of Decred's ticket-voting mechanism (a practical and flexible PoS scheme) and combine it with our newly-proposed two-layer chain structure delicately to devise a secure, efficient and flexible hybrid consensus scheme. In Hcash, keyblocks should be confirmed by certain voting tickets, and both PoW and PoS miners play important roles on the consensus of the system. With this novel hybrid scheme, we further implement basic DAO to provide PoW and PoS miners an effective mechanism for future protocol updating and project investments. Meanwhile, our scheme supports the segregated witness scheme, which facilitates the implementation of the lightning network and post-quantum signature schemes in the future. The schematic framework of our consensus scheme is shown in Figure I.

Figure I: The schematic framework of our consensus scheme

In Table I, comparisons are made between Hcash and a few well-known decentralized cryptocurrencies. Table I also includes throughputs of Hcash with different parameters for keyblock/microblock generations. The current release of Hcash corresponds to the row marked with bold font.

	Keyblock Average Interval	Block Size	Microblock Average Interval	Transaction Size	Throughput
BTC	10min	1MB		250B	6.99TPS
BTC(extended)	10min	2MB		250B	13.98TPS
BCC	10min	8MB		250B	55.92TPS
Decred	5min	1.25MB		250B	17.48TPS
Hcash	5min	2MB	18.75 sec	250B	447.39TPS
Hcash	5min	8MB	18.75 sec	250B	1789.57TPS

Table I: Comparisons between Hcash and a few well-known decentralized cryptocurrencies

Table II offers the relation between adversary’s PoW power and PoS capabilities (measured in proportion over all PoW power or PoS capabilities) and the success possibility of adversary undermining the system (α denotes the proportion of adversary's PoW power, β denotes the proportion of adversary's PoS capabilities).

Table II: Probability of adversary's succeeding in an attack with α fraction of total hash power and β fraction of total stake

The detailed description and analysis (including security and efficiency analysis) of the novel hybrid consensus scheme implemented in Hcash will be given in our research paper which will appear in the near future.

Starting Hcashd

Hcashd is a Hypercash full node implementation written in Go (golang).

This acts as a chain daemon for the Hypercash cryptocurrency. Hcashd maintains the entire past transactional ledger of Hypercash and allows relaying of transactions to other Hypercash nodes across the world. The installation of hcashd requires Go 1.7 or newer.

• Glide

  Glide is used to manage project dependencies and provide reproducible builds. To install:

  go get -u github.com/Masterminds/glide
  

• Build and Installation

  For a first time installation, the project and dependency sources can be obtained manually with git and glide (create directories as needed):

  git clone https://github.com/HcashOrg/hcashd $GOPATH/src/github.com/HcashOrg/hcashd
  cd $GOPATH/src/github.com/HcashOrg/hcashd
  glide install
  go install $(glide nv)
  

  To update an existing source tree, pull the latest changes and install the matching dependencies:

  cd $GOPATH/src/github.com/HcashOrg/hcashd
  git pull
  glide install
  go install $(glide nv)
  

• Start running hcash full node service to synchrnoze blocks

  hcashd
  

• Start hcash solo mining

  hcashctl setgenerate true x     # where x represents the number of CPU threads
  

• Stop hcash solo mining

  hcashctl setgenerate false
  

Using HcashWallet UI Version

HcashWallet UI version is a graphical wallet for HCASH. With it, you can send and receive HCASH, purchase tickets for PoS voting, get a history of all your transactions and more.

HcashWallet UI version is located here: https://github.com/HcashOrg/hcashwallet/releases. It could be extracted and used directly.

License

hcashd is licensed under the copyfree ISC License.

Documentation

Overview

hcashd is a full-node hypercash implementation written in Go.

The default options are sane for most users. This means hcashd will work 'out of the box' for most users. However, there are also a wide variety of flags that can be used to control it.

The following section provides a usage overview which enumerates the flags. An interesting point to note is that the long form of all of these options (except -C) can be specified in a configuration file that is automatically parsed when hcashd starts up. By default, the configuration file is located at ~/.hcashd/hcashd.conf on POSIX-style operating systems and %LOCALAPPDATA%\hcashd\hcashd.conf on Windows. The -C (--configfile) flag, as shown below, can be used to override this location.

Usage:

hcashd [OPTIONS]

Application Options:

-V, --version             Display version information and exit
-C, --configfile=         Path to configuration file
-b, --datadir=            Directory to store data
    --logdir=             Directory to log output.
-a, --addpeer=            Add a peer to connect with at startup
    --connect=            Connect only to the specified peers at startup
    --nolisten            Disable listening for incoming connections -- NOTE:
                          Listening is automatically disabled if the --connect
                          or --proxy options are used without also specifying
                          listen interfaces via --listen
    --listen=             Add an interface/port to listen for connections
                          (default all interfaces port: 14008, testnet: 14008)
    --maxpeers=           Max number of inbound and outbound peers (125)
    --nobanning           Disable banning of misbehaving peers
    --banduration=        How long to ban misbehaving peers.  Valid time units
                          are {s, m, h}.  Minimum 1 second (24h0m0s)
    --banthreshold=       Maximum allowed ban score before disconnecting and
                          banning misbehaving peers.
    --whitelist=          Add an IP network or IP that will not be banned.
                          (eg. 192.168.1.0/24 or ::1)
-u, --rpcuser=            Username for RPC connections
-P, --rpcpass=            Password for RPC connections
    --rpclimituser=       Username for limited RPC connections
    --rpclimitpass=       Password for limited RPC connections
    --rpclisten=          Add an interface/port to listen for RPC connections
                          (default port: 11009, testnet: 12009)
    --rpccert=            File containing the certificate file
    --rpckey=             File containing the certificate key
    --rpcmaxclients=      Max number of RPC clients for standard connections
                          (10)
    --rpcmaxwebsockets=   Max number of RPC websocket connections (25)
    --norpc               Disable built-in RPC server -- NOTE: The RPC server
                          is disabled by default if no rpcuser/rpcpass or
                          rpclimituser/rpclimitpass is specified
    --notls               Disable TLS for the RPC server -- NOTE: This is only
                          allowed if the RPC server is bound to localhost
    --nodnsseed           Disable DNS seeding for peers
    --externalip=         Add an ip to the list of local addresses we claim to
                          listen on to peers
    --proxy=              Connect via SOCKS5 proxy (eg. 127.0.0.1:9050)
    --proxyuser=          Username for proxy server
    --proxypass=          Password for proxy server
    --onion=              Connect to tor hidden services via SOCKS5 proxy
                          (eg. 127.0.0.1:9050)
    --onionuser=          Username for onion proxy server
    --onionpass=          Password for onion proxy server
    --noonion             Disable connecting to tor hidden services
    --torisolation        Enable Tor stream isolation by randomizing user
                          credentials for each connection.
    --testnet             Use the test network
    --simnet              Use the simulation test network
    --nocheckpoints       Disable built-in checkpoints.  Don't do this unless
                          you know what you're doing.
    --dbtype=             Database backend to use for the Block Chain (ffldb)
    --profile=            Enable HTTP profiling on given port -- NOTE port
                          must be between 1024 and 65536
    --cpuprofile=         Write CPU profile to the specified file
    --memprofile=         Write mem profile to the specified file
    --dumpblockchain=     Write blockchain as a gob-encoded map to the
                          specified file
    --miningtimeoffset=   Offset the mining timestamp of a block by this many
                          seconds (positive values are in the past)
-d, --debuglevel=         Logging level for all subsystems {trace, debug,
                          info, warn, error, critical} -- You may also specify
                          <subsystem>=<level>,<subsystem2>=<level>,... to set
                          the log level for individual subsystems -- Use show
                          to list available subsystems (info)
    --upnp                Use UPnP to map our listening port outside of NAT
    --minrelaytxfee=      The minimum transaction fee in HCASH/kB to be
                          considered a non-zero fee.
    --limitfreerelay=     Limit relay of transactions with no transaction fee
                          to the given amount in thousands of bytes per
                          minute (15)
    --norelaypriority     Do not require free or low-fee transactions to have
                          high priority for relaying
    --maxorphantx=        Max number of orphan transactions to keep in memory
                          (1000)
    --generate            Generate (mine) bitcoins using the CPU
    --miningaddr=         Add the specified payment address to the list of
                          addresses to use for generated blocks -- At least
                          one address is required if the generate option is
                          set
    --blockminsize=       Mininum block size in bytes to be used when creating
                          a block
    --blockmaxsize=       Maximum block size in bytes to be used when creating
                          a block (750000)
    --blockprioritysize=  Size in bytes for high-priority/low-fee transactions
                          when creating a block (50000)
    --getworkkey=         DEPRECATED -- Use the --miningaddr option instead
    --nonaggressive       Disable mining off of the parent block of the blockchain
                          if there aren't enough voters
    --nominingstatesync   Disable synchronizing the mining state with other nodes
    --allowoldvotes       Enable the addition of very old votes to the mempool

    --nopeerbloomfilters  Disable bloom filtering support.
    --sigcachemaxsize=    The maximum number of entries in the signature
                          verification cache.
    --blocksonly          Do not accept transactions from remote peers.
    --relaynonstd         Relay non-standard transactions regardless of the
                          default settings for the active network.
    --rejectnonstd        Reject non-standard transactions regardless of the
                          default settings for the active network.

Help Options:

-h, --help           Show this help message