cpt.Blockchain-Network (bcnnet)

Cpt-created: {2016-03-04}

bcnnet'DESCRIPTION

Description::
Blockchain-network (bcnnet) is a-peer-to-peer-network that stores in a-shared-file (blockchain) a-chain of blocks with the-history of the UNMODIFIABLE, TRANSPARENT transactions-of-information among its nodes.
[hmnSgm.2017-05-06]
===
Bcnnet is a young and fluid technology.
Our view about it is double fluid.
Do-NOT-expect my view to cover all its attributes and to-have a-small-amount of mistakes.
[hmnSgm.2017-03-26]

Name::
* cpt.bcndescription,
* cpt.bcnnet'description,

Description::
The blockchain is a recent development in the field of computer science, which uses a global peer-to-peer network to provide an open platform that can deliver neutrality, reliability and security.
[https://www.provenance.org/whitepaper]

Description::
These cryptoeconomic networks come in many flavors — ASIC-based PoW, GPU-based PoW, naive PoS, delegated PoS, hopefully soon Casper PoS — and each of these flavors inevitably comes with its own underlying philosophy.
[https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51#.gwuvm0m26]

Description::
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008.
While the use of blockchains for more general uses was already discussed in the original paper, it was not until a few years later that blockchain technology emerged as a generic term.
A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks.
Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network.
Individual user interactions with the ledger (transactions) are secured by strong cryptography.
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]

bcnnet'NAME

Name::
* cpt.bcnnet, {2017-03-05}
* cpt.blockchain-based-system,
* cpt.blockchain-ecosystem,
* cpt.blockchain-framework,
* cpt.blockchain-network,
* cpt.blockchain-technology,
* cpt.consensus-technology,
* cpt.cryptoeconomic-network,
* cpt.decentralised-consensus-based-transaction-system,
* cpt.decentralized-consensus-network,
* cpt.distributed-ledger-technology,
* cpt.DLT,
* cpt.netBcn, {2016-03-25}

NameGreek::
* ενν.αλυσιδωτών-μπλοκ-δίκτυο, {2017-01-25}
* ενν.δίκτυο-αλυσιδωτών-μπλοκ, {2017-01-25}
* ενν.δίκτυο-αλυσίδας-μπλοκ,
* ενν.μπλοκτσέιν-δίκτυο, {2017-05-06}

bcnnet'whole.DAO (bcndao)

Cpt-created: {2017-03-28}

Description::
IF a-bcnnet incorporates (= buildin) a-decentralized-autonomous-governing-system
THEN it is-becoming a-DAO (Decentralized-Autonomous-Organization).
[hmnSgm.2017-05-06]

Name::
* cpt.bcndao,
* cpt.blockchain-Decentralized-Autonomous-Organization,
* cpt.blockchain-DAO,
* cpt.DAO-of-blockchain,

Description::
Organization is a-system-of-humans with an-administering-system.
IF it has-no administering-system, it is a-GROUP.
No humans, no group, no organization, no DAO.
A-blockchain-network only if it will add an-administering-system is becoming organization.
Bitcoin, Ethereum networks do-not have such a-system and have a-tendency to split.
BitShares clearly states in its whitepaper that it is a-DAO-company (as it runs for profit).
"BitShares is a decentralized autonomous company, and as such offers products to earn their shareholders a profit.
As we have seen in the previous section, it also offers a way to pay for expense, such as development and administration but earns a profit by burnning (i.e. reducing supply).
Of course, the company can only be profitable if the income exceeds the expenses.
Thus, we will now discuss both in detail". [idBtswpr4]
A-DAO RUNS autonomously.
It evolves with decentralized-decision-making.
[hmnSgm.2017-03-29]
===
The proof-of-work structure that secures and maintains the Bitcoin network is one manner of organizing individuals who do not necessarily trust one another to act in the best interest of all participants of the network.
[http://docs.bitshares.eu/bitshares/whatis.html#consensus-technology]

bcndao'Resource

AddressWpg::
* {2013-09-19} Vitalik Buterin: Bootstrapping A Decentralized Autonomous Corporation: Part I: https://bitcoinmagazine.com/articles/bootstrapping-a-decentralized-autonomous-corp.../

SPECIFIC

Specific::
* Bitshares-DAO,
* BOScoin-DAO,
* DASH-DAO,
* Dfinity-DAO,
* Tezos-DAO,

bcnnet'Protocol (bcnprl)

Description::
Protocol is A-DESCRIPTION of the-communication-process of the-network.
[hmnSgm.2017-03-18]
===
Algorithm usually is-called a-description of info processing.
[hmnSgm.2017-04-03]

Name::
* cpt.bcnnet'protocol,
* cpt.bcnprl,
* cpt.blockchain-protocol,
* cpt.protocol-of-blockchain,

Generic::
* p2p-network-protocol,

bcnprl'White-paper (bcnwpr)

Description::
Usually, PDF-files that DESCRIBE the-protocol in natural-language.
[hmnSgm.2017-03-18]

Name::
* cpt.bcnprl'white-paper,
* cpt.bcnprlwpr,
* cpt.bcnwpr, {2017-03-26}
* cpt.blockchain-white-paper,
* cpt.white-paper-of-blockchain,

Specific::
* Bitcoin-white-paper,
* BitShares-white-paper,
* Ethereum-white-paper,
* ChronoBank-white-paper,

bcnprl'Implementation-language

Description::
The-computer-language used to write the-protocol.
[hmnSgm.2017-03-18]
===
Nxt was built from scratch in Java – one of the most popular programming languages for developers and users alike, and one ideally suited to the needs of the web. Most other cryptocurrencies are written in C++ (including Bitcoin and its immediate derivatives), which has a smaller base of developers. Java is cross-platform, meaning that it can be run on any operating system without modification. It’s also used on 3 billion phones and mobile devices worldwide.

The widespread use of Java and the open source nature of Nxt makes it a universal application that can be used on any mainstream device or operating system and can be maintained by potentially millions of software developers worldwide. The Nxt protocol reflects the values and strengths of the project itself: its development was entirely decentralised, spread across many different countries as its core members came together to create a platform that would not only improve upon the first generation of cryptocurrencies but add totally new features to position it for a whole new era in the history of the internet.
[http://nxt.org/about/what-is-nxt/]

Name::
* cpt.bcnnet'coding-language,
* cpt.bcnnet'implementation-language,
* cpt.bcnnet'source-code-language,
* cpt.bcnprl'implementation-language,
* cpt.blockchain-implementation-language,
* cpt.implementation-language-of-blockchain,

SPECIFIC

Name::
* bcnprl.specific,
* cpt.bcnprl.specific,

Specific::
* bitcoin-protocol,
* ethereum-protocol,

bcnnet'Node (bcnnod)

Description::
A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks.
Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network.
Individual user interactions with the ledger (transactions) are secured by strong cryptography.
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]

Name::
* cpt.bcnnet'network-node,
* cpt.bcnnet'node,
* cpt.bcnnod,
* cpt.blockchain-node,
* cpt.node-of-blockchain,

bcnnod'Operator (link)

SPECIFIC

Name::
* bcnnod.specific,
* cpt.bcnnod.specific,

Specific::
* Full-node,
* Light-node,
* Miner-node,
* Updater-node,

bcnnod.FULL

Description::
Full nodes are servers running on a p2p network, that allow peers to use them to receive updates about the events on the network.
These nodes require significant amounts of traffic and other resources that carry substantial cost.
[idDashwpr2]

Name::
* cpt.bcnnod.full,
* cpt.blockchain-full-node,
* cpt.full-node-of-blockchain,

bcnnod.LIGHT

Description::
A-light-node does-not-store the-whole-blockchain, only what interest it.

Name::
* cpt.bcnnod.light,
* cpt.blockchain-light-node,
* cpt.light-node-of-blockchain,

bcnnod.MINER

Description::
* Miner-node is a-node that adds blocks in a-blockchain with proof-of-work-consensus-algorithm.
It is-called 'miner' because in this process, new coins are-created.
[hmnSgm.2017-05-12]

Name::
* cpt.bcnnet'node.miner,
* cpt.bcnnodeMnr,
* cpt.netBct'miner-node,
* cpt.miner-node-of-blockchain,

NameGreek::
* ενν.εξoρύκτης-αλλυσίδας-μπλοκ-κόμβος,

bcnnodMnr'Human.Miner (bcnmnr)

Description::
* Miner-human is a-human that owns|operates a-miner-node.
[hmnSgm.2017-05-07]

Name::
* cpt.bcnhmn.miner,
* cpt.bcnminer-human,
* cpt.bcnnet'miner-human,
* cpt.miner-human-of-blockchain,

bcnnodMnr'Mining (bcnmng)

Description::
A-blockchain is-updating ONLY by adding new blocks by consensus.
Its history is unmodifiable.
[hmnSgm.2017-05-07]
===
In pow blockchains, updating is-called mining because in this process new coins are-created and resembles gold finding.
[hmnSgm.2017-05-09]
===
In NEM harvesting is the act of forming blocks (mining/forging).
[http://wiki.nem.io/index.php/Harvesting]

Name::
* cpt.bcnmining,
* cpt.bcnminting,
* cpt.bcnmng,
* cpt.bcnnet'mining,
* cpt.bcnnet'Forging,
* cpt.bcnnet'Harvesting,
* cpt.blockchain-mining,
* cpt.blockchain-updating,
* cpt.mining-of-blockchain,
* cpt.updating-blockchain,

Specific::
* Bitcoin-mining,
* Ethereum-mining,
* Lisk-mining,

bcnnodMnr'Pre-mining

Description::
Pre-mining:
The mining of coins by a cryptocurrency’s founder before that coin has been announced and details released to others who may wish to mine the coin.
Pre-mining is a common technique used with scamcoins, although not all pre-mined coins are scamcoins (see Scamcoins).
[http://www.coindesk.com/information/bitcoin-glossary/]

Name::
* cpt.blockchain-pre-mining,
* cpt.bcnpre-mining,
* cpt.pre-mining-of-blockchain,

bcnnodMnr'CLOUD-MINING

Description::
Most Bitcoin Cloud Mining Companies are Scams
Like the heading says, most cloud mining contracts are scams. Why? Because it’s easy for companies to take peoples’ money, and then not pay out. A company can claim to be a cloud mining company without any proof of actually owning any hardware.
So remember: 99% of cloud mining companies are scams.
Which Companies Are Not Scams?
There is only one cloud mining company we are willing to recommend on this site: Genesis Mining.
Just because it is not a scam, however, does not mean that you will make a profit by using it.
[https://www.hobbymining.com/bitcoin-cloud-mining/]

Name::
* cpt.blockchain-cloud-mining,
* cpt.cloud-mining-of-blockchain,

Specific::
* Bitcoin-cloud-mining,

bcnnodMnr'MINING-POOL (bcnmgpl)

Description::
Mining pools are groups of cooperating miners who agree to share block rewards in proportion to their contributed mining hashing power.
While mining pools are desirable to the average miner as they smooth out rewards and make them more predictable, they unfortunately concentrate power to the mining pool’s owner.
Miners can, however, choose to redirect their hashing power to a different mining pool at anytime.
[https://bitcoinworldwide.com/mining/pools/]

Name::
* cpt.bcnnet'mining-pool,
* cpt.mining-pool-of-blockchain,

bcnmgpl'Fee

bcnmgpl'Token-supported

SPECIFIC

bcnmgpl.MinerGate

Description::
MinerGate is a mining pool created by a group of cryptocoin enthusiasts.
It is the first pool which provides service for merged mining. This means that while mining on our pool you can mine different coins simultaniously without decrease of hashrate for major coin.
[https://minergate.com/faq/about]
===
Changelly was developed by MinerGate, one of the oldest mining pools on the market, that has
about two mln users all over the world.
[https://cointelegraph.com/news/with-charlie-shrem-as-advisor-shangelly-is-set-to-outperform-shapeshift]

Name::
* cpt.MinerGate,
* cpt.minergate,

AddressWpg::
* https://minergate.com/

bcnnod.UPDATER

Description::
Updater-node is a-node that updates the-blockchain.
[hmnSgm.2017-05-12]

Name::
* cpt.bcnnod.updater,
* cpt.blockchain-updater-node,
* cpt.updater-node-of-blockchain,

Specific::
* Miner-node,

bcnnet'Blockchain (bcnbcn)

Description::
A-blockchain is a-file which contains a-chain of blocks with the-history of the-transactions-of-information among the-nodes of the-network.
The-blockchain is-shared by all the-nodes and it is unmodifiable.
New-blocks with the-new-transactions are-added AUTOMATICALLY in the-blockchain with an-algorithm builtin in the-network (the-consensus-algorithm).
[hmnSgm.2017-05-06]

Name::
* cpt.bcnbcn,
* cpt.bcnledger,
* cpt.bcnlgr, {2017-03-19}
* cpt.blockchain,
* cpt.blockchain-database,
* cpt.blockchain-file,
* cpt.blockchain-ledger,
* cpt.blockchain-record,
* cpt.bcnnet'blockchain,
* cpt.bcnnet'distributed-database,
* cpt.consensus-ledger,
* cpt.distributed-database-of-bcnnet,
* cpt.mnyBcn'blockchain-ledger,
* cpt.mnyBcn'ledger,

NameGreek::
* ενν.βάση-δεδομέων-αλυσιδωτών-μπλοκ, {2017-01-25}
* ενν.καθολικό-αλυσιδωτών-μπλοκ, {2017-01-25}
* ενν.μητρώο-αλυσιδωτών-μπλοκ, {2017-01-25}
* ενν.μπλοκ-αλυσίδα,
* ενν.μπλοκτσέιν, {2017-04-10}

Description::
A blockchain is essentially just a record, or ledger, of digital events — one that’s “distributed,” or shared between many different parties.
It can only be updated by consensus of a majority of the participants in the system.
And, once entered, information can never be erased.
The bitcoin blockchain contains a certain and verifiable record of every single bitcoin transaction ever made.
[http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care/]

Description::
A blockchain is fundamentally a public record of state changes.
[https://media.consensys.net/time-sure-does-fly-ed4518792679#.rjkzhxgwo]

Description::
The security of cryptocurrency ledgers is based on the assumption that the majority of miners are honestly trying to maintain the ledger, having financial incentive to do so.
[https://en.wikipedia.org/wiki/Cryptocurrency]

Description::
The blockchain is a state-machine and every time a transaction takes place the state is updated.
So, you can always see at which block what transaction took place.
[https://www.newscombinator.com/article/7/ethereum-dapp-essentials-part-1]

Description::
blockchain
A list of validated blocks, each linking to its predecessor all the way to the genesis block.
[Mastering Bitcoin, Adonopoulos, https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/glossary.asciidoc]

Description::
Blockchain is a decentralized database shared among a network of computers, all of which must approve an exchange before it can be recorded. There’s no need for a trusted intermediary like a bank because the information is held securely and transparently on a digital ledger for all users on the network to see.
[https://www.weforum.org/agenda/2016/12/fighting-human-trafficking-tracing-blood-diamonds-and-other-surprising-uses-for-blockchain?]

Description::
A blockchain in all it’s incarnations is a database type designed specifically for use in a DCN.
It can hold any information, and can set rules on how information is updated.
Its primary feature is that it is updated in discrete chunks called ‘blocks’ which are ‘chained’ together using hashes of the previous blocks content.
A blockchain contains not only the information that is currently stored in the database, but also every change made to the database in its history.
Known as the state and transactions respectively it makes for a database with a complete custodial history that cannot be altered without altering every subsequent block.
A private key always signs ‘Transactions’ or requests to change the state of the database, and the signature is stored in the blockchain.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]

Description::
The major story from 2015 is undoubtedly the increasing focus on bitcoin's underlying technology, commonly referred to as blockchain or distributed ledger technology (DLT). Many parties, from government authorities to financial institutions, began to examine potential applications of DLT for securities transaction settlement and other use cases.
[http://www.coindesk.com/state-of-bitcoin-blockchain-2016/]

Description::
Nxt’s innovation is built on the idea of the blockchain: a public, secure record of every transaction that has ever occurred between any two parties within the network. Whilst the blockchain is completely transparent and anyone can access it, once an entry has been added it is impossible to change or remove it. The blockchain allows anyone to prove ownership and exchange of anything that has been agreed between two parties: money, property, rights, IP and more. The revolution that this enables cannot be underestimated.
[http://nxt.org/about/how-nxt-change-world/]

Description::
Blockchain technology, introduced by Satoshi Nakamoto with the proof-of-concept implementation of a simple value transfer system known as bitcoin, represents the best digital system we have (after the internet itself) for administering multi-user interactions without any need for centralized coordination or oversight.
[http://ethereum.gitbooks.io/frontier-guide/content/ethereum.html]

Description::
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller.
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physical device ("smart property"), non-fungible assets such as domain names ("Namecoin"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts") or even blockchain-based "decentralized autonomous organizations" (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
[https://github.com/ethereum/wiki/wiki/White-Paper]

bcnbcn'Attribute (bcnatt)

Recorded digital-information:

Timestabed:

Unchangeable:

bcnbcn'Block (bcnblk)

Description::
Block is a-package of transactions and meta-information that proves that it follows the-last confirmed block.
[hmnSgm.2017-05-08]
===
Block is a-package of transactions.
[hmnSgm.2017-04-21]
===
A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks.
Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block.
In this way, the blockchain’s “distributed database” is kept in consensus across the whole network.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]

Name::
* cpt.bcnblk,
* cpt.bcnnet'block,
* cpt.block-of-blockchain,

bcnblk'part'Header

Description::
A-block contains information that proves that it follows the-last block and a-number of transactions.
[hmnSgm.2017-05-07]

Name::
* cpt.bcnblk'header,
* cpt.bcnblkhdr,
* cpt.bcnnet'block-header,
* cpt.header-of-block-of-blockchain,

Specific::
* Bitcoin-block-header,
* Ethereum-block-header,

bcnblk'part'Transaction-list

Description::
A-block contains information that proves that it follows the-last block and a-number of transactions.
[hmnSgm.2017-05-07]

Name::
* cpt.bcnblk'transaction,
* cpt.bcnblk'transaction-list,
* cpt.bcnblktx,
* cpt.bcnnet'block-transaction,

BLOCK-NUMBER-OF-TRANSACTIONS:
The-number of transactions contained in a-block.

bcnblk'Consensus-algorithm (link)

bcnblk'Explorer (link)

bcnblk'Height

Description::
The number of blocks preceding a particular block on a block chain.
For example, the genesis block has a height of zero because zero block preceded it.
[https://bitcoin.org/en/glossary/block-height]

Name::
* cpt.bcnblock-height,
* cpt.bcnblock-number,
* cpt.bcnnet'block-height,
* cpt.block-height-of-blockchain,

bcnblk'Reward

Description::
The-miner who adds a-new block in the-blockchain is-rewarded with new coins or transaction-fees or both.
[hmnSgm.2017-05-07]

Name::
* cpt.bcnnet'block-reward,
* cpt.block-reward-of-blockchain,

bcnblk'Time (bcnblktim)

Description::
Time related with a-block.

Name::
* cpt.bcnblktime,
* cpt.bcnblk'time,
* cpt.bcnnet'Block-time,
* cpt.time-of-block-of-blockchain,

bcnblktim.Age

Description::
How long ago a-block was-added to a-blockchain.

Name::
* cpt.bcnblk'age,
* cpt.bcnnet'age-of-Block,

bcnblktim.Timestamp

Description::
The-time a-block created.

Name::
* cpt.bcnblk'timestamp,
* cpt.bcnnet'Block-timestamp,

bcnblktim.Generation

Description::
The-time BETWEEN block creation.

Name::
* cpt.bcnblk'blocktime,
* cpt.bcnnet'Blocktime,
* cpt.block-generation-time,
* cpt.block-interval-of-blockchain,
* cpt.blockchain-block-interval,
* cpt.blocktime-of-blockchain,

bcnblk'Hash

Description::
* Block-hash is the-hash of a-block's-header.
[hmnSgm.2017-05-07]

Name::
* cpt.blockchain-block-hash,
* cpt.blockchain-hash-of-block,
* cpt.bcnhash-of-block,

bcnblk'Size

Description::
The-size (in bytes) of a-block.

Name::
* cpt.bcnblksize,
* cpt.bcnnet'Block-size,

SPECIFIC

Name::
* bcnblk.specific,
* cpt.bcnblkSpc,

Specific::
* Bitcoin-block,
* Ethereum-block,

bcnblk.GENESIS

Description::
The-first block, height 0, written programatically into the-blockchain.

Name::
* cpt.bcnblk.genesis,
* cpt.bcnblkGns,
* cpt.genesis-block-of-blockchain,

Specific::
* Bitcoin-genesis-block,
* Ethereum-genesis-block,

bcnbcn'Block-Explorer (bcnbex)

Description::
Website that presents information about the-parts of a-blockchain-network.

Name::
* cpt.bcnblock-explorer,
* cpt.bcnnet'block-explorer,
* cpt.bcnnet'explorer,
* cpt.block-explorer-of-blockchain,
* cpt.blockchain-block-explorer,
* cpt.blockchain-explorer,

Specific::
* https://chainz.cryptoid.info/
* Bitcoin-block-explorer,
* Ethereum-block-explorer,

bcnbcn'Consensus-algorithm (bcncsa)

Description::
The-consensus-algorithm is an-algorithm describing how to UPDATE the-blockchain.
How the next block will-be-added with consensus.
[hmnSgm.2017-03-30]

Name::
* cpt.bcnnet'block-verification-method,
* cpt.bcnnet'consensus-algorithm,
* cpt.bcnnet'mining-system,
* cpt.bcnnet'model-of-security,
* cpt.bcnnet'transaction-verification-method,
* cpt.block-validation-algorithm-of-bcnnet,
* cpt.consensus-algorithm-of-bcnnet,

Description::
The consensus algorithm is core to any blockchain based currency or system.
The algorithm attempts to answer the question, ‘how can we prove with confidence that all distributed databases hold the same set of information?’
[BOScoin-whitepaper]

Description::
Ethereum Frontier like all blockchain technologies uses an incentive-driven model of security.
Consensus is based on choosing the block with the highest total difficulty.
[https://github.com/ethereum/wiki/blob/master/Mining.md]

Description::
Timestamping
Cryptocurrencies use various timestamping schemes to avoid the need for a trusted third party to timestamp transactions added to the blockchain ledger.

Proof-of-work schemes
The first timestamping scheme invented was the proof-of-work scheme. The most widely used proof-of-work schemes are based on SHA-256, which was introduced by bitcoin, and scrypt, which is used by currencies such as Litecoin.[22] The latter now dominates over the world of cryptocurrencies, with at least 480 confirmed implementations.[42]

Some other hashing algorithms that are used for proof-of-work include Blake, SHA-3, and X11.

Proof-of-stake and combined schemes
Some cryptocurrencies use a combined proof-of-work/proof-of-stake scheme,[22][43] The Proof-of-stake is a method of securing a cryptocurrency network and achieving distributed consensus through requesting users to show ownership of a certain amount of currency. It is different from proof-of-work systems that run difficult hashing algorithms to validate electronic transactions. The scheme is largely code dependent on the coin, and there's currently no standard form of it.
[https://en.wikipedia.org/wiki/Cryptocurrency]

bcncsa'Mining (link)

bcncsa'Evaluating

Description::
Distributed timestamping protocols were first applied to decentralizing a financial network in the ground-breaking paper on Bitcoin by Nakamoto[1]. The field has seen explosive research follow-up from both amateurs and professionals, competing to offer extensions, adjustments, improvements, and refinements of the existing protocol. Notable implementations of new ideas include Ethereum[2], which extended scripting, CryptoNote[3], which refined privacy, and Sidechains[4], which investigated two-way pegs with 1:1 Bitcoin tokens. These protocols all utilize proof-of-work (PoW) as originally described in the Bitcoin whitepaper.

A common extension to the Bitcoin protocol modifies the consensus mechanism to either completely or partially use proof-of-stake (PoS), or the use of one’s stake (tokens) rather than one’s computational power to participate in the timestamping process. The first proof-of-stake blockchain based on the Bitcoin protocol was implemented in 2012 by King and Nadal[5], and includes both PoW and PoS that gradually skew towards complete PoS over time. Criticisms of pure PoS consensus systems have themselves been abundant[6] [7], with the most vehement opposition coming from those working with purely PoW blockchains. The most common argument against PoS for distributed timestamping is “nothing-at-stake” or “costless simulation”, describing the systematic instability resulting from stakeholders being able to generate alternatively timestamped histories with no cost to themselves.

Despite the controversy, it is apparent that systems who have a PoS overlay dependent on a PoW timestamping system may be able to independently achieve consensus. This is mathematically explored by Bentov and colleagues[8] in a paper on their scheme, proof-of-activity (PoA), and appears to be a viable extension to the PoW protocols that may enable some interesting new properties. A similar design called MC2 was earlier proposed by Mackenzie in 2013[9]. Here we describe the construction and implementation of a similar consensus system that we have named “Decred”.
1.Nakamoto S. 2008. Bitcoin: A peer-to-peer electronic cash system.
2.Buterin V. 2014. A Next-generation smart contract and decentralized application platform.
3.von Saberhagen N. 2013. CryptoNote v2.0.
4.Back A., Corallo M., Dashjr L., Friedenbach M., Maxwell G., Miller A., Poelstra A., Timon A., Wuille P. 2014. Enabling Bitcoin innovations with pegged sidechains.
5.King S. and Nadal S. 2012. PPCoin: Peer-to-peer crypto-currency with proof-of-stake.
6.Bentov I., Gabizon A., Mizrahi A. 2015. Cryptocurrencies without proof-of-work.
7.Poelstra A. 2015. On stake and consensus.
8.Bentov I., Lee C., Mizrahi A., Rosenfeld M. 2014. Proof-of-activity: Extending Bitcoin’s proof-of-work via proof-of-stake.
9.Mackenzie A. 2013. MEMCOIN2: A hybrid proof-of-work, proof-of-stake crypto-currency.
[https://docs.decred.org/research/overview/]

bcncsa.SPECIFIC

Specific::
* Proof-of-work,
* Proof-of-stake,
* Proof-of-importance,

bcncsa.Proof-of-work (bcnpow)

Description::
proof-of-work (majority of computing power says which transactions settle) for
proof-of-stake (majority of coin wealth says which transactions settle)
[https://lykke.com/Whitepaper_LykkeExchange.pdf]

Name::
* cpt.bcnnet'pow,
* cpt.bcnpow,
* cpt.proof-of-work,

NameGreek::
* ενν.αλγόριθμος-απόδειξης-εργασίας,
* ενν.απόδειξη-εργασίας-σε-μπλοκτσέιν-δίκτυο,
* ενν.μπλοκτσέιν-απόδειξη-εργασίας,

Description::
Originally envisioned as a spam prevention system proof of work is a simple method for proving that you have *probably* performed a large number of mathematical operations.
It is implemented in the majority of cases using a cryptographic hash function; given an arbitrary piece of data, (like a list of transactions and the header of a block) you must find a second piece of data which, when combined with the first, produces a hash that has certain characteristics (like a number of trailing zeros).
Because it is impossible to predict what second piece of data will produce the required hash, you must randomly iterate through possible data until you find one that produces the hash you require.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
HashCash {1997} Antispam mechanism: you have to do some work in order to send a message.
This work for ONE message is almost nothing.
For a spammer of 1000000 messages is huge.
===
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work".
The mechanism behind proof of work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency
[https://github.com/ethereum/wiki/wiki/White-Paper]
===
A proof-of-work (POW) system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer. The concept may have been first presented by Cynthia Dwork and Moni Naor in a 1993 journal article.[1] The term "Proof of Work" or POW was first coined and formalized in a 1999 paper by Markus Jakobsson and Ari Juels.[2]
A key feature of these schemes is their asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known as a CPU cost function, client puzzle, computational puzzle or CPU pricing function. It is distinct from a CAPTCHA, which is intended for a human to solve quickly, rather than a computer. Proof of space (PoS) proposals apply the same principle by proving a dedicated amount of memory or disk space instead of CPU time. Proof of bandwidth approaches have been discussed in the context of cryptocurrency. Proof of ownership aims at proving that specific data are held by the prover.
[https://en.wikipedia.org/wiki/Proof-of-work_system]

Description::
A proof-of-work (POW) system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer. The concept may have been first presented by Dwork and Naor in a 1993 journal.[1] The term "Proof of Work" or POW was first coined and formalized in a 1999 paper.[2]

A key feature of these schemes is their asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known as a CPU cost function, client puzzle, computational puzzle or CPU pricing function. It is distinct from a CAPTCHA, which is intended for a human to solve quickly, rather than a computer.
[https://en.wikipedia.org/wiki/Proof-of-work_system]

Specific::
* CryptoNight,
* Dash,
* Primecoin,
* Scrypt,
* SHA-256,
* X11,
* Zerocoin,

bcnpow.CryptoNight

Description::
DigitalNote is an experimental open-source cryptocurrency based on CryptoNote technology and CryptoNight algorithm. It is a fork of Bytecoin - the very first implementation of CryptoNote.
[https://changelly.com/supported-currencies]
===
Bytecoin is a first CryptoNote-based cryptocurrency. A CPU-mined coin, it's primary advantages are extraordinary transaction untraceability and unlinkability features. BCN is stated to be much more anonymous than Bitcoin and all its existing forks. The developers claim a person’s right to privacy is their primary concern and strictly observe their own privacy. Bytecoin was started on July 4th, 2012.
BCN is based on CryptoNote, an open-source technology for anonymous cryptocurrencies. It utilizes ring signature and one-time addresses for completely anonymous payments. CryptoNote is designed in a way, which makes block chain analysis impossible. CryptoNote is focused on CPU-mining in order to make the special purposes devices useless.
[https://changelly.com/supported-currencies]

Name::
* cpt.CryptoNote-pow,
* cpt.pow.CryptoNight,
* cpt.pow.CryptoNote's-CryptoNight,
* cpt.proof-of-work.CryptoNight,

AddressWpg::
* https://cryptonote.org/,

bcnpow.Scrypt

Description::
In cryptography, scrypt is a password-based key derivation function created by Colin Percival, originally for the Tarsnap online backup service.[1]
The algorithm was specifically designed to make it costly to perform large-scale custom hardware attacks by requiring large amounts of memory.
In 2012, the scrypt algorithm was published by IETF as an Internet Draft, intended to become an informational RFC.[2]
A simplified version of scrypt is used as a proof-of-work scheme by a number of cryptocurrencies first implemented by Litecoin.[3]
[https://en.wikipedia.org/wiki/Scrypt]
===
Scrypt:
An alternative proof of work system to SHA-256, designed to be particularly friendly to CPU and GPU miners, while offering little advantage to ASIC miners.
[http://www.coindesk.com/information/bitcoin-glossary/]

Name::
* cpt.bcnpow.scrypt,
* cpt.bcnscrypt-pow,

bcnpow.X11

Description::
Dash uses a chained hashing algorithm approach called X11 for the proof-of-work. Instead of using the SHA-256 (from well-known Secure Hash Algorithm family) or scrypt it uses 11 rounds of different hashing functions.[3]
[https://en.wikipedia.org/wiki/Dash_%28cryptocurrency%29]

Name::
* cpt.bcnpow.X11,
* cpt.bcnX11-pow,

bcncsa.Proof-of-stake (bcnpos)

Description::
proof-of-work (majority of computing power says which transactions settle) for
proof-of-stake (majority of coin wealth says which transactions settle)
[https://lykke.com/Whitepaper_LykkeExchange.pdf]

Name::
* cpt.bcnnet'proof-of-stake,
* cpt.bcnpos,
* cpt.proof-of-stake,
* cpt.proof-of-stake-security,

Description::
Proof-of-stake is a method by which a cryptocurrency blockchain network aims to achieve distributed consensus.
While the more mainstream proof-of-work method asks users to repeatedly run difficult hashing algorithms to validate electronic transactions,[1] proof-of-stake asks users to prove ownership of a certain amount of currency (their "stake" in the currency).
Peercoin[2] was the first cryptocurrency to launch using Proof-of-Stake.
Other prominent implementations are found in BitShares, Nxt, BlackCoin, NuShares/NuBits and Qora.
[https://en.wikipedia.org/wiki/Proof-of-stake]
===
The proof-of-stake approach means that the security of the network is maintained by every existing holder of Nxt, who earn transaction fees in proportion to the number of coins they already own – rather than the network being maintained by the relatively small number of miners who can afford the expensive hardware required.
Improved security. This property also protects the network from the problems of mining power being concentrated in a few big pools or organisations, which renders it vulnerable to a ‘51 percent’ attack. Nxt’s proof-of-stake means that even if one person owns 90 percent of all the coins available, the network remains secure.
[http://nxt.org/about/what-is-nxt/]
===
Proof-of-stake (PoS) is a type of algorithm by which a cryptocurrency blockchain network aims to achieve distributed consensus. Unlike Proof-of-Work (PoW) based cryptocurrencies (such as bitcoin), where the algorithm rewards participants who solve complicated cryptographical puzzles in order validate transactions and create new blocks (i.e. mining), in PoS-based cryptocurrencies the creator of the next block is chosen in a deterministic (pseudo-random) way, and the chance that an account is chosen depends on its wealth (i.e. the stake). In PoS cryptocurrencies the blocks are usually said to be forged (in the blacksmith sense of this word), or minted, rather than mined. Also, usually all the coins are created in the beginning and the total number of coins never changes afterwards (although there are some other versions of PoS where new coins can be created). Therefore, in the basic version of PoS there are no block rewards (e.g. as in bitcoin); so, the forgers take only the transaction fees.[1]
Peercoin[2] was the first cryptocurrency to launch using proof-of-stake. Other prominent implementations are found in ShadowCash, Nxt, BlackCoin, NuShares/NuBits, Qora and Nav Coin.[3] Ethereum has planned a hard fork transition from PoW to PoS consensus. Both Peercoin and Decred[4] hybridize PoW with PoS and combine elements of both consensus approaches in an attempt to garner the benefits of the two systems and create a more robust notion of consensus.
[https://en.wikipedia.org/wiki/Proof-of-stake {2017-01-29}]

bcncsa.Proof-of-importance (bcnpoi)

Description::
The consensus of the Blockchain network is achieved utilizing the unique environmental and energy friendly algorithm “POI” (Proof of Importance).
POI is a technologically advanced algorithm compared to the earlier established PoW (Proof of Work) and PoS (Proof of Stake).
[https://blog.nem.io/nem-mijin-blockchain-technology-briefing-january-2017/]

Name::
* cpt.bcnnet'proof-of-importance,
* cpt.bcnpoi,
* cpt.proof-of-importance,
* cpt.proof-of-importance-consensus-algorithm,

bcnbcn'Address (bcnads)

Description::
Address is a-sequence of symbols a-blockchain uses to denote ownership of crypto-info in the-blockchain.
[hmnSgm.2017-04-03]

Name::
* cpt.bcnads,
* cpt.bcnnet'address,
* cpt.blockchain-address,

Specific::
* bitcoin: 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV,
* ethereum: 0x0998c9a0c7224Ec4ED782A4Ecfef53A0e25fA9FC,

bcnbcn'Transaction (bcntx)

Description::
Transactions are documents that broadcasted to the-network and change THE-STATE of the-blockchain.
Information on the-blockchain (exchange-value, programs, etc) is-stored cryptographically with public-private-keys.
Blockchain-addresses are unique-names of blockchain-info[1] which[1] can-be-managed only by the-owners of its[1] private-key.
[hmnSgm.2017-04-02]

Name::
* cpt.bcntransaction,
* cpt.bcntsn,
* cpt.bcntx,

Description::
A blockchain is a globally shared, transactional database. This means that everyone can read entries in the database just by participating in the network. If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others. The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied. Furthermore, while your transaction is applied to the database, no other transaction can alter it.

As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.

Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#transactions]

Description::
Transaction: a transaction is a document authorizing some particular action associated with the blockchain. In a currency, the dominant transaction type is sending currency units or tokens to someone else; in other systems actions like registering domain names, making and fulfilling trade offers and entering into contracts are also valid transaction types.
[https://github.com/ethereum/wiki/wiki/Glossary#blockchains]

NameGreek::
* ενν.συναλλαγή-μπικόιν-εννΠτ,

bcntx'Creator (sender)

Name::
* cpt.bcntx'creator,
* cpt.bcntx'sender,

bcntx'Fee

Description::
Transaction-fee is fee applied to transaction to support the-network. This fee is-collected by the-nodes that update the-blockchain.
[hmnSgm.2017-05-12]
===
As blocks began to fill up in 2015, it became clear that the best practice is to use a dynamic fee algorithm because it can respond to changing conditions on the network.
Bitcoin Core started calculating dynamic fee estimates as of the 0.10 release in February 2015, and Alex Morcos has been steadily improving them since then. Core's fee estimate algorithm is rather complex; you can view its code here and the english explanation here.
[http://www.coindesk.com/building-better-bitcoin-fee-market/]

bcntx'Number-per-second

Name::
* cpt.bcnnet'Number-of-transactions-per-second,
* cpt.bcnnet'Transactions-per-second,
* cpt.bcnnet'Transaction-speed,

Specific::
Bitcoin:  7tx/sec
Ethereum: 25tx/sec
BOSnet:   1,000tx/sec (target)

SPECIFIC

Name::
* bcntx.specific,
* cpt.bcntx.specific,

Specific::
* Bitcoin-transaction,
* Ethereum-transaction,

Specific::
Ethereum is at its heart based on the same fundamental technology as Bitcoin, and even shares many of the same principles, but with Ethereum we can create almost any conceivable type of transaction, opening new opportunities to automate industry verticals that previously were impossible.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]

bcntx.MICROTRANSACTION

Description::
Microtransaction:
Paying a tiny amount for an asset or service, primarily online.
Micro-transactions are difficult to perform under conventional payment systems, because of the heavy commissions involved.
It is difficult to pay two cents to read an online article using your credit card, for example.
[http://www.coindesk.com/information/bitcoin-glossary/]

Name::
* cpt.blockchain-microtransaction,
* cpt.bcnmicrotransaction,

bcnbcn'Crypto (bcncrpt)

Description::
Cryptography:
The use of mathematics to create codes and ciphers that can be used to conceal information.
Used as the basis for the mathematical problems used to verify and secure bitcoin transactions.
[http://www.coindesk.com/information/bitcoin-glossary/]

Name::
* cpt.blockchain-cryptography,
* cpt.bcncryptography,

bcncrpt'Algorithm (cipher)

Description::
In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption—a series of well-defined steps that can be followed as a procedure.
An alternative, less common term is encipherment.
To encipher or encode is to convert information from plain text into code or cipher.
[http://en.wikipedia.org/wiki/Cipher]

Name::
* cpt.blockchain-algorithm.cryptography,
* cpt.blockchain-cipher, /'saifer/
* cpt.blockchain-cypher,
* cpt.blockchain-encryption-algorithm,
* cpt.bcncipher,

bcncrpt'Cryptographic-hash-funciton (bcnchf)

Description::
Cryptographic hash functions are a third type of cryptographic algorithm.
They take a message of any length as input, and output a short, fixed length hash which can be used in (for example) a digital signature.
For good-hash-functions, an attacker cannot find two messages that produce the same hash.
MD4 is a long-used hash function which is now broken;
MD5, a strengthened variant of MD4, is also widely used but broken in practice.
The U.S. National Security Agency developed the Secure Hash Algorithm series of MD5-like hash functions:
SHA-0 was a flawed algorithm that the agency withdrew;
SHA-1 is widely deployed and more secure than MD5, but cryptanalysts have identified attacks against it;
the SHA-2 family improves on SHA-1, but it isn't yet widely deployed, and the U.S. standards authority thought it "prudent" from a security perspective to develop a new standard to "significantly improve the robustness of NIST's overall hash algorithm toolkit."[25]
Thus, a hash function design competition is underway and meant to select a new U.S. national standard, to be called SHA-3, by 2012.
[http://en.wikipedia.org/wiki/Cryptography#Symmetric-key_cryptography]

Name::
* cpt.blockchain-cryptographic-hash-function,
* cpt.blockchain-hash-function,
* cpt.bcncryptographic-hash-function,
* cpt.bcnhash-function,
* cpt.hash-algorithm-of-blockchain,
* cpt.hash-function-of-blockchain,

bcnchf'Input

bcnchf'Hash (output)

Description::
Hash is-called the-output of a-hash-function.
[hmnSgm.2017-04-08]

Name::
* cpt.blockchain-hash,
* cpt.bcncryptographic-has,
* cpt.bcndigest,
* cpt.bcnhash,
* cpt.bcnhash-function-output,
* cpt.bcnhash-value,
* cpt.hash-of-blockchain,

NameGreek::
* ενν.κατακερματισμός-μπλοκτσέιν,
* ενν.κρυπτογραφικός-κατακερματισμός-μπλοκτσέιν,
* ενν.μπλοκτσέιν-κατακερματισμός,

bcnchf'Hashing

Description::
Hashing is-called THE-PROCESS of using a-hash-function on input-data[1] and producing its[1] hash.
[hmnSgm.2017-04-08]

Name::
* cpt.blockchain-hashing,
* cpt.bcnhashing,
* cpt.hashing-of-blockchain,

bcncrpt.Public-key-cryptography

Description::
Public key cryptography, or asymmetric cryptography, is any cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner.
This accomplishes two functions:
- authentication, which is when the public key is used to verify that a holder of the paired private key sent the message, and
- encryption, whereby only the holder of the paired private key can decrypt the message encrypted with the public key.
[https://en.wikipedia.org/wiki/Public-key_cryptography]

Name::
* cpt.asymmetric-cryptography-of-blockchain,
* cpt.blockchain-asymmetric-cryptography,
* cpt.blockchain-publickey-cryptography,
* cpt.publickey-cryptography-of-blockchain,

bcnbcn'Hash-rate (bcnhhr )

Description::
The hash rate is the measuring unit of the processing power of the Bitcoin network. The Bitcoin network must make intensive mathematical operations for security purposes. When the network reached a hash rate of 10 Th/s, it meant it could make 10 trillion calculations per second.
[https://bitcoin.org/en/vocabulary#hash-rate]
===
Hash (Rate) ~ A hash is the output of a hash function and, as it relates to Bitcoin, the Hash Rate is the speed at which a compute is completing an operation in the Bitcoin code. A higher hash rate is better when mining as it increases your opportunity of finding the next block and receiving the reward.
[http://bitcoinsimplified.org/definitions/]

Name::
* cpt.bcnnet'hash-rate,
* cpt.bcnnet'hashing-power,
* cpt.blockchain-hash-rate,
* cpt.blockchain-hashing-power,
* cpt.blockchain-hashing-rate,
* cpt.hash-rate-of-blockchain,
* cpt.hashing-rate-of-blockchain,

bcnbcn'Size-of-blockchain

bcnbcn'State-of-blockchain

Description::
A blockchain contains not only the information that is currently stored in the database, but also every change made to the database in its history.
Known as the state and transactions respectively it makes for a database with a complete custodial history that cannot be altered without altering every subsequent block.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]

Name::
* cpt.bcnbcnstate,
* cpt.blockchain-state,

bcnbcn'Doing

Specific::
* Blockchain-creating,
* Blockchain-updating,

bcndng.UPDATING (link)

bcnbcn.SPECIFIC

Specific::
* Bitcoin-blockchain,
* Ethereum-blockchain,

bcnnet'Exchange-Value-Unit (bcnevu)

Cpt-created: {2013-08-24}

bcnevu'DESCRIPTION

Description::
Blockchain-Exchange-Value-Unit (bcnevu) is digital-information recorded on the-blockchain that REPRESENTS units of exchange-value (= no double-spending).
Information can-represents anything.
IF this bcnevu represents AND a-commodity, we say that this bcnevu IS-BACKED with this commodity.
Generally, there-are two theories about the-exchange-value of a-commodity.
1) the-supply-demand-theory (capitalism advocating):
the supply and demand of a-commodity defines its exchange-value.
2) the-average-work-TIMES-the-supply-demand-theory (sosialism advocating):
when there-is equilibrium between supply and demand the-exchange-value is the-average-work needed to produce a-commodity (= an-entity we exchange, not an-entity we use).
No matter what theory we accept, when we exchange commodities we accept|set an-exchange-value.
The-problem is to use A-FAIR-ONE.
Blockchain-DAOs can define a-fair-exchange-value and use it automatically.
[hmnSgm.2017-05-07]
===
Blockchain-Exchange-Value-Token (bevtkn) is digital-information recorded on the-blockchain that REPRESENTS units of exchange-value (= no double-spending).
Information can-represents anything.
IF this bevtkn represents AND a-commodity, we say that this bevtkn IS-BACKED with this commodity.
Generally, there-are two theories about the-exchange-value of a-commodity.
1) the-supply-demand-theory (capitalism advocating):
the supply and demand of a-commodity defines its exchange-value.
2) the-average-work-TIMES-the-supply-demand-theory (sosialism advocating):
when there-is equilibrium between supply and demand the-exchange-value is the-average-work needed to produce a-commodity (= an-entity we exchange, not an-entity we use).
No matter what theory we accept, when we exchange commodities we accept|set an-exchange-value.
The-problem is to use A-FAIR-ONE.
Blockchain-DAOs can define a-fair-exchange-value and use it automatically.
[hmnSgm.2017-04-02]
===
Exchange-value-token (bcnevt) is digital-information recorded on the-blockchain that REPRESENTS exchange-value.
Information can-represents anything.
IF this bcnevt represents AND a-commodity, we say that this bcnevt IS-BACKED with this commodity.
Generally, there-are two theories about the-exchange-value of a-commodity.
1) the-supply-demand-theory (capitalism advocating):
the supply and demand of a-commodity defines its exchange-value.
2) the-average-work-TIMES-the-supply-demand-theory (sosialism advocating):
when there-is equilibrium between supply and demand the-exchange-value is the-average-work needed to produce a-commodity (= an-entity we exchange, not an-entity we use).
Societies have to choose which view serves better their interests, because they have to correlate exchange-values to their commodities, fair or not.
[hmnSgm.2017-03-29]
===
exchange-value-of-commodity = average-work-measure TIMES demand / supply.
[hmnSgm.2017-04-15]
===
No matter what theory we accept, when we exchange commodities we accept|set an-exchange-value.
The-problem is to use A-FAIR-ONE.
Blockchain-DAOs can define a-fair-exchange-value and use automatically.
[hmnSgm.2017-04-01]
===
Satoshi Nakamoto solved the-double-spending-problem WHITHOUT a-central trust entity.
So blockchain is ideal for holding information representing exchange-value, ie any financial-product.
[hmnSgm.2017-03-30]
===
Blockchain-money is money a-bcnnet needs to operate or issued by it.
[hmnSgm.2017-03-27]

Description::
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum.
[https://www.ethereum.org/ether]

Description::
A cryptocurrency (or crypto currency) is a medium of exchange using cryptography to secure the transactions and to control the creation of new units.[1] Cryptocurrencies are a subset of alternative currencies, or specifically of digital currencies. Bitcoin became the first decentralized cryptocurrency in 2009.[2] Since then, numerous cryptocurrencies have been created. These are frequently called altcoins, as a blend of bitcoin alternative.[3][4]
Cryptocurrencies typically feature decentralized control[citation needed] (as opposed to a centralized electronic money system, such as PayPal) and a public ledger[citation needed] (such as bitcoin's block chain) which records transactions.
[https://en.wikipedia.org/wiki/Cryptocurrency] {retrieved 2015-08-12},

Description::
A cryptocurrency is a type of digital currency (which in turn is a type of alternative currency) that relies on cryptography, usually alongside a proof-of-work scheme, in order to create and manage the currency.[1][2] Cryptocurrencies are peer-to-peer and decentralized, and are currently all based on the first cryptocurrency, Bitcoin.[1][2][3][4][5][6] They are generally designed to have no inflation (once all the currency has been produced), in order to keep scarcity and hence value.[7][8] However, a few cryptocurrencies, such as PPCoin, do have a small amount of inflation. Cryptocurrencies are also designed to ensure that funds can neither be frozen nor seized.[7][9] Existing cryptocurrencies are all pseudonymous, though additions such as Zerocoin have been suggested, which would allow for anonymity.[10][11][12][13]
[http://en.wikipedia.org/wiki/Cryptocurrency]

Description::
Digital currencies or cryptocurrencies are a way of transferring money over the internet. These combine cutting-edge encryption with far-reaching developments in social networking. The resulting advantages that cryptocurrencies offer over traditional methods of payment are truly remarkable.

We have used the same way of transferring money for centuries. Even with the advent of the internet, these methods didn’t really change much. Cryptocurrency is something completely new – so new that it cannot be described in terms of these traditional means of payment.

Instead, it’s easier to understand cryptocurrencies in terms of what they can do. For the first time in history, it is possible to send money anywhere on the planet within a few minutes, directly between individuals and completely securely, without relying on any banks, payment companies or other third parties, and virtually free of cost.
[http://nxt.org/about/what-is-nxt/]

Description::
Cryptocurrency:
A form of currency based on mathematics alone.
Instead of fiat currency, which is printed, cryptocurrency is produced by solving mathematical problems based on cryptography.
[http://www.coindesk.com/information/bitcoin-glossary/]

bcnevu'NAME

Name::
* cpt.bcnevu, {2017-05-07}
* cpt.bcnnet'exchange-value-unit, {2017-05-07}
* cpt.blockchain-exval-unit, {2017-05-07}
* cpt.blockchain-exchange-value-unit, {2017-05-07}
* cpt.exchange-value-unit-of-bcnnet, {2017-05-07}
===
* cpt.bcnevt, {2017-04-14}
* cpt.bcnevtkn, {2017-03-29}
* cpt.bcnnet'exchange-value-token, {2017-03-29}
* cpt.bevtkn, {2017-04-02}
* cpt.blockchain-exval-token, {2017-03-30}
* cpt.blockchain-exchange-value-token, {2017-03-29}
* cpt.exchange-value-token-of-bcnnet, {2017-03-29}
===
* cpt.bcnmny,
* cpt.bcnnet'currency,
* cpt.bcnnet'money,
* cpt.bcnnet'token,
* cpt.blockchain-evu,
* cpt.blockchain-exchange-value-unit, {2017-05-12}
* cpt.blockchain-coin,
* cpt.blockchain-currency,
* cpt.blockchain-money,
* cpt.blockchain-token,
* cpt.coin-of-blockchain,
* cpt.cryptocoin, {2017-01-31}
* cpt.cryptocurrency,
* cpt.decentralized-currency,
* cpt.evu,
* cpt.mnyBcn, {2016-04-08}
* cpt.mnyBlockchain,
* cpt.mnyCrypto,
* cpt.money.blockchain, {2016-04-08}
* cpt.money.decentralized, {2016-06-01}
* cpt.netBcn'currency,
* cpt.netBcn'money,
* cpt.netBcn'token,

NameGreek::
* ενν.μπλοκτσέιν-μαα, {2017-05-09}
* ενν.μπλοκτσέιν-μονάδα-ανταλλακτικής-αξίας, {2017-05-09}
* ενν.κρυπτονόμισμα,

Internet-currency:
* including internet currencies such as Bitcoin and Ven,
[http://en.wikipedia.org/wiki/Ripple_monetary_system]

bcnevu'Short-name

Description::
Many bcnevu have and a 3 or 4 letter short-name ie BTC for bitcoin.

Name::
* cpt.bcnevu-code,
* cpt.bcnevu'short-name,
* cpt.bcnevu-short-name,

bcnevu'Symbol

Description::
A small picture denoting the-bcnevu.

bcnevu'Key

Description::
The-bcnevus are-stored cryptographically in the-blockchain.
We use public-keys to receive them and the corresponding private-keys to spend them.

Name::
* cpt.bcnevu'key,
* cpt.key-of-blockchain,

bcnevu'Wallet (link)

bcnevu'Exchange-rate (bcnexr|value)

Description::
Exchange-rate (value) of a-blockchain-token is its exchange-value measured with another UNIT of exchange-value.
[hmnSgm.2017-04-02]

Name::
* cpt.bcnevt'exchange-rate,
* cpt.bcnevt'foreign-exchange-rate,
* cpt.bcnevt'forex,
* cpt.bcnevt'rate,
* cpt.bcnevt'value, {2017-04-02}
* cpt.bcnevt'forex,
* cpt.bcnexr, {2017-04-15}

NameGreek::
* ενν.ισοτιμία-μπλοκτσέιν-μαα,

AddressWpg::
* https://coinmarketcap.com/
* https://www.cryptonator.com/rates,
* http://coincap.io/?gclid=CjwKEAiAn7HEBRDHw...FYokrLGFyNNJ1vGnktBoC3nLw_wcB,

bcnevu'BACKNESS

Description::
All bcnevt REPRESENT (as digital-info) exchange-value.
Backness is A-SECOND-REPRESENTATION with a-commodity.
Some are-backed with gold or other precious-metals.
Others are-backed with fiat-money, us-dollars, euros, etc.
Any commodity, financial or not can-be-used.
[hmnSgm.2017-04-19]

bcnevu'Activeness

Description::
Is the-token alive or dead?.

bcnevu'Blockchain-network (link)

bcnevu'Distribution

Description::
So, as of Dec. 3. [{2013}], using a price of $1,000 (which is basically where we are now), and assuming 12 million Bitcoins in circulation, here's the breakdown: 47 individuals own 28.9% of the approximately 12 million Bitcoins in existence so far.
Another 880 own 21.5%, meaning 927 people control half of the entire market cap of the digital currency.
Another 10,000 individuals control about a quarter.
And the rest of us (around a million of us) get the crumbs (500,000 are out of circulation, whether through government seizure or people losing their passwords).
[http://www.businessinsider.com/927-people-own-half-of-the-bitcoins-2013-12]
===
- NEM relatively large egalitarian distribution
[http://wiki.nem.io/index.php/About:_General]

bcnevu'Evaluation

Description::
Evaluating an Alt Coin
With so many alt coins out there, how does one decide which ones are worthy of attention?
Some alt coins attempt to achieve broad distribution and use as currencies.
Others are laboratories for experimenting on different features and monetary models.
Many are just get-rich-quick schemes by their creators.
To evaluate alt coins, I look at their defining characteristics and their market metrics.

Here are some questions to ask about how well an alt coin differentiates from bitcoin:
- Does the alt coin introduce a significant innovation?
- Is the difference compelling enough to attract users away from bitcoin?
- Does the alt coin address an interesting niche market or application?
- Can the alt coin attract enough miners to be secured against consensus attacks?

Here are some of the key financial and market metrics to consider:
- What is the total market capitalization of alt coin?
- How many estimated users/wallets does the alt coin have?
- How many merchants accept the alt coin?
- How many daily transactions (volume) are executed on the alt coin?
- How much value is transacted daily?
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#evaluating-an-alt-coin]

Description::
Without mentioning Litecoin, he ranks Bitcoin, Monero and Decred as his highest coins citing that Decred spent a year doing coding to improve its consensus and governance system, and Monero which didn’t have a GUI wallet. Ethereum is close, he adds, but the decision to hardfork and go back on the “uncensorable transaction” promise really hurts.
[https://cointelegraph.com/news/what-to-watch-out-for-before-investing-in-altcoins-litecoin-creator]

bcnevu'Fungibility

Description::
FUNGIBLE CRYPTOCURRENCY
In order to remain equally interchangeable, units of cryptocurrency must be unlinked from their history so that one unit is as good as any other unit.
Zcash brings fungibility to cryptocurrency by unlinking shielded coins from their history on the blockchain.
[https://z.cash/]

bcnevu'Human

bcnevuhmn.Creator

Name::
* cpt.bcnevt'creator,
* cpt.bcnevt'founder,
* cpt.bcnevt'founder,

bcnevuhmn.User-base

Name::
* cpt.bcnevt'adoption,
* cpt.bcnevt'usage,
* cpt.bcnevt'user-base,
* cpt.bcnevt'adoption,
* cpt.bcnevt'usage,

bcnevu'Law

Description::
As of 2013 cryptocurrencies were illegal in Iceland, due to its freeze on foreign exchange.[28] Controversy over the misuse of cryptocurrency has also led to restrictions in certain countries – regulators in China banned the handling of bitcoins by financial institutions during an extremely fast adoption period in early 2014.[29] In Russia, though cryptocurrencies are legal, it is illegal to actually purchase goods with any currency other than the Russian ruble.[30]

On March 25, 2014, the United States Internal Revenue Service (IRS) ruled that bitcoin will be treated as property for tax purposes as opposed to currency. This means bitcoin will be subject to capital gains tax. One benefit of this ruling is that it clarifies the legality of bitcoin. No longer do investors need to worry that investments in or profit made from bitcoins are illegal or how to report them to the IRS.[31] In a paper published by researchers from Oxford and Warwick it was shown that Bitcoin has some characteristics similar to the precious metals market more than to traditional currencies, hence in agreement to the IRS decision even if based on different reasons.[32]

Some cryptocurrency have legal issues such as Coinye, an altcoin that used, without permission, rapper Kanye West as its logo. This altcoin has been compared to the popular Dogecoin. Upon hearing of the release of Coinye, originally called Coinye West, attorneys for Kanye West sent a cease and desist letter to the email operator of Coinye, who since revealed himself as David P. McEnery Jr. The letter stated that Coinye was willful trademark infringement, unfair competition, cyberpiracy, and dilution and instructed Coinye to stop using the likeness and name of Kanye West.[33]
[https://en.wikipedia.org/wiki/Cryptocurrency]

AddressWpg::
* http://cointelegraph.com/news/ russian-law-enforcement-considers-further-criminalizing-cryptocurrencies,

bcnevu'Organization (bcnevtogn)

bcnevuogn.EXCHANGE (link)

bcnevuogn.MERCHANT (link)

bcnevuogn.EDUCATING

AddressWpg::
* http://digitalcurrency.unic.ac.cy/?utm_source=Twitter&utm_medium=Banner&utm_campaign=MScDigital,

bcnevu'Security

Description::
Reliable wallet/service for storage of your altcoins is the most important thing for you.
Every owner of cryptocurrency can tell their own story of how they failed to rescue their PC flooded with beer, on which wallet files were stored, or could not restore access to the online wallet linked to their lost mobile phone.
[http://cointelegraph.com/news/tips-for-revamping-your-cryptocurrency-job-search-in-2016]

bcnevu'Transaction (link)

bcnevu'Time

bcnevu'Time.release

Name::
* cpt.date-of-introduction-of-bcnevt,
* cpt.bcnevt'introduction,

bcnevu'Resource

AddressWpg::
* http://www.coinwarz.com/ How frequently is the information updated on CoinWarz?
The current difficulty, exchange rate, exchange volume, and current profit ratio versus BTC are updated every 5 minutes. All other information, including the difficulty charts, exchange rate charts, and profit ratio versus BTC charts are updated every hour.
* http://cointelegraph.com/news/ auroracoin-sterlingcoin-scotcoin-national-cryptocurrencies-provide-alternative-to-central-banking,
* http://cointelegraph.com/news/central-banking-is-broken-solution-is-bitcoin-panama-papers-reveal,
* http://www.links.org/files/decentralised-currencies.pdf,
* 2015-03-10: Masters joins cryptocurrency start-up http://www.ft.com/intl/cms/s/0/e29808a8-c744-11e4-9e34-00144feab7de.html?siteedition=intl#axzz3U5OWaspl,

bcnevu'env.OTHER-VIEW

Description::
XRP: Math-Based Currency
Feb 20, 2015 | Julian Martinez
A math-based currency, also referred to as a cryptocurrency, is a digital asset with verifiable mathematical properties, similar to how we can reliably verify gold as a substance made of atoms with 79 protons. Math-based currencies exist as digital assets in their own right and can be transferred directly between users (as fiat cash can be) without relying on a centralized protocol operator. XRP exists as a math-based currency on the Ripple protocol.

The supply of a math-based currency is governed by mathematics. There is no human intervention after the creation & implementation of the protocol rules. This is in contrast to the many “virtual currencies” that can be issued without restriction by companies and people (such as airline miles, reward points, etc.). In this example, XRP cannot be ‘devalued’ by the creation of additional XRP.

Bitcoin was the first example of a math-based currency. Bitcoin exists natively as a digital asset. On the network, it is not a balance that is redeemable at a central point of failure, and does not carry risk from a counterparty as “digital fiat” currencies do (as with an online balance from a bank that is not FDIC insured). You could hand someone a thumb drive with Bitcoin on it, and in doing so, you are transferring the asset itself, like handing over cash, as opposed to transferring an IOU or someone’s promise to pay. It does not require trust in any third party.

XRP exists natively within the Ripple protocol as a counterparty-free currency, as Bitcoin does on the Blockchain. Because XRP is an asset, as opposed to a redeemable balance, it does not require that users trust any specific financial institution to trade or exchange it. All other currencies on Ripple do require some amount of trust, as they each have an issuer, from whom that currency can be redeemed (this includes BTC on the Ripple network).

Users of the Ripple protocol are not required to use XRP as a medium of exchange or as a store of value. The Ripple protocol is currency agnostic. Users can use their preferred currency, whether that’s USD, BTC, XRP, or any other currency. Similarly, users may freely choose to trust any issuers they find reliable; this includes the trust implied by users trading in an issued non-XRP currency.
[https://ripple.com/knowledge_center/math-based-currency-2/]

Name::
* cpt.money.math-based,
* cpt.mny.math-based,

bcnevu'DOING

bcnevu'Acquiring

Description::
You can-acquire bcnevu:
- from an-exchange,
- updating the-blockchain,
- selling commodities,
- from an-ICO,
[hmnSgm.2017-05-09]

Name::
* cpt.bcnevt'acquiring,
* cpt.bcnevt'obtaining,
* cpt.bcnevt'acquiring,
* cpt.bcnevt'obtaining,

Specific::
* exchanging,
* mining,
* selling-goods-and-services,
* ICO,

bcnevu'Issuing

Description::
The-process of creating new bcnevu.
===
- NEM zero monetary inflation (fixed supply, all 9 billion coins released at launch).
[http://wiki.nem.io/index.php/About:_General]

Name::
* cpt.bcnevt'creating,
* cpt.bcnevt'issuing,
* cpt.bcnevt'issuance,

bcnevu'Rate-of-issuance

Name::
* cpt.bcnevt'Rate-of-issuance,

SPECIFIC

Name::
* bcnevu.specific,
* bcnevt.specific,
* cpt.bcnevtSpc,
* cpt.bcnevt.specific,

Specific::
=== GENERIC:
* Active-bcnevu,
* ActiveNo-bcnevu,
* Altcoin,
* Consensus-bcnevu,
* ConsensusNo-bcnevu,
* Minable-bcnevu,
* MinableNo-bcnevu,
* Protocol-bitcoin-based,
* Protocol-CryptoNote-based,
=== INSTANCE:
* Ardor-ARDR,
* Augur-REP,
* AuroraCoin-AUR,
* Bitcoin-BTC,
* BitShares-BTS,
* Bytecoin-BCN,
* BlackCoin-BLK,
* Counterparty,
* CureCoin-CURE,
* Dash,
* Dogecoin-DOGE,
* Ether-ETH,
* Factom-FCT,
* Faircoin-FAIR,
* Freicoin-FRC,
* Gulden-NLG,
* LBRY-Credits-LBC,
* Lisk-LSK,
* Litecoin-LTC,
* MaidSafeCoin-MAID,
* Mastercoin,
* Monero-XMR,
* Namecoin-NMC,
* NAV-Coin-NAV,
* Nxt-NXT,
* Nubits-USNBT,
* Peercoin-PPC,
* Radium-RADS,
* Reddcoin-RDD,
* Ripple-XRP,
* STEEM,
* Stellar,
* StorjcoinX,
* Stratis-STRAT,
* Synereo-AMP,
* Tether-USDT,

Specific::
* SHA-256-based: Bitcoin, Peercoin, Namecoin, Titcoin,
* Scrypt-based: Auroracoin, Dogecoin, Litecoin, PotCoin,
* Zerocoin-based: Zcash, Zcoin, ZeroVert,
* CryptoNote-based: Bytecoin, Monero,
* Other proof-of-work: Ethereum, Primecoin,
* Non proof-of-work: BlackCoin, Counterparty, Gridcoin, Lisk, NEM, Nxt, Ripple, Stellar, Shadow,
[https://en.wikipedia.org/wiki/Monero_(cryptocurrency)]

bcnevu.SPECIFIC-DIVISION.consensus-algorithm

Specific::
* consensus-bcnevu,
* consensusNo-bcnevu,

bcnevu.SPECIFIC-DIVISION.governance

Specific::
* builtin-governace-bcnevu,
* builtin-governaceNo-bcnevu,

bcnevu.SPECIFIC-DIVISION.time-of-genesis

Specific::
* {2017}:

* {2016}:
- Decred-DCR,
- LBRY-Credits-LBC,
- Lisk-LSK,
- NAV-Coin-NAV,
- PIVX,
- STEEM,
- Stratis-STRAT,
- WAVES,
- Zcash-ZEC,
* {2015}:
- BitShares-BTS,
- Ether-ETH,
- Factom-FCT,
- NEM-XEM,
- Radium-RADS,
* {2014}:
- AuroraCoin-AUR,
- BlackCoin-BLK,
- DASH,
- FairCoop-FAIR,
- Gulden-NLG,
* MaidSafeCoin-MAID,
- NuBits-USNBT,
* {2013}:
- DogeCoin-DOGE,
- Nxt-NXT,
* {2012}:
- Freicoin-FRC,
- Peercoin-PPC,
- Ripple-XRP,
* {2011}:
- Litecoin-LTC,
- Namecoin-NMC,
* {2010}:

* {2009}:
- Bitcoin-BTC,

bcnevu.SPECIFIC-DIVISION.protocol

Specific::
* Bitcoin-based,
* CryptoNote-based,
* Nxt-based,

bcnevu.protocol.Bitcoin-based

Name::
* cpt.bitcoin-based-cryptocurrency,
* cpt.bitcoin-based-token,
* cpt.bitcoin-fork-cryptocurrency,

Specific::
* Litecoin-LTC,

bcnevu.protocol.CryptoNote-based

Description::
CryptoNote Phylosophy
CryptoNote is the technology that allows the creation of completely anonymous egalitarian cryptocurrencies. A number of our community members have been focused on research and development for more than a decade. We aim to promote the derived principles to influence the contemporary economic paradigm.
The current power distribution on our planet is the legacy of the world where the economy is controlled by the few. The status quo was shaped throughout centuries, making human beings engage in rat races, detrimental rivalry, and bloodshed. In spite of humanity's hope to overcome local crises through education and internationalization, we still fail to have full control over our lives.
However, state-of-the-art advancements in technology, mathematics, and cryptography may become the key to subvert this paradigm. The advent of cryptocurrencies is the first sign that the new world is coming. It is marked with a hope that the economy will interlace with the technology, that communities will set new transparent principles, and impartial cryptographic algorithms will control its implementation.
It is in our philosophy to encourage enlightenment through breakthrough innovations. Emancipation begins with laymen getting access to financial resources that will give the oppressed the hope for quality education, drinking water, and a better life. CryptoNote is not about creating yet another digital currency. It is the mindset and concepts that represent the first small step to regain the power over ourselves in order to live peacefully and prosper.
[https://cryptonote.org/inside/]

Name::
* cpt.CryptoNote-based-cryptocurrency,
* cpt.CryptoNote-based-token,
* cpt.CryptoNote-fork-cryptocurrency,

AddressWpg::
* https://cryptonote.org/

Specific::
* AEON,
* ByteCoin-BCN,
* DarkNetCoin-DNC,
* Dashcoin-DSH,
* DigitalNote-XDN,
* Fantomcoin-FCN,
* Monero-XMR,
* Pebblecoin-XPB,
* QuazarCoin-QCN,

bcnevu.CryptoNote.Aeon (AEONcevu {2014-06-06})

Description::
Aeon AEON
Aeon is a CryptoNote-based anonymous cryptocurrency using the CryptoNight-light algorithm. It offers data protection features, untraceable payments with ring signatures and unlikable transactions to its users. Aeon was launched on 06.06.2014.
[https://changelly.com/supported-currencies]
===
AEON
AEON (Anonymous Electronic On-line coiN) is a Monero fork and also a privacy focused coin that is aimed towards open-source community to deliver fast and secure payment method while being simple enough to be used by anyone. ?AEON has started as an experiment but then found its supporters and now AEON is fully functional CryptoNote currency.
[https://cryptonote.org/coins/]
===
Aeon (AEON)
$0.235153 (5.35%)
0.00019879 BTC (5.74%)
Rank 96
Mineable Currency
Market Cap
$3,280,079
2,773 BTC
Volume (24h)
$10,689
9.04 BTC
Circulating Supply
13,948,703 AEON
[https://coinmarketcap.com/currencies/aeon/] {2017-04-16}

Name::
* cpt.AEONcevu,
* cpt.AEON-money,
* cpt.AEON-token,

AddressWpg::
* https://coinmarketcap.com/currencies/aeon/
* ANN: https://bitcointalk.org/index.php?topic=641696.0, {2014-06-06}
* http://chainradar.com/aeon/blocks,
* BlockH1: http://chainradar.com/aeon/block/1,

bcnevu.CryptoNote.ByteCoin (BCN byncevu {2012-07-04})

Description::
Bytecoin (BCN)
Bytecoin is the first CryptoNote-based currency, which has reached mass adoption successfully. Bytecoin also possesses one of the largest ecosystems. Bytecoin has been originally created in close cooperation with CryptoNote team. It is the first implementation of CryptoNote technology, with the release dating back to July 2012. Up to this date Bytecoin developers has been making significant contributions to the development of CryptoNote technology.
[https://cryptonote.org/coins/]
===
Bytecoin BCN
Bytecoin is a first CryptoNote-based cryptocurrency. A CPU-mined coin, it's primary advantages are extraordinary transaction untraceability and unlinkability features. BCN is stated to be much more anonymous than Bitcoin and all its existing forks. The developers claim a person’s right to privacy is their primary concern and strictly observe their own privacy. Bytecoin was started on July 4th, 2012.
BCN is based on CryptoNote, an open-source technology for anonymous cryptocurrencies. It utilizes ring signature and one-time addresses for completely anonymous payments. CryptoNote is designed in a way, which makes block chain analysis impossible. CryptoNote is focused on CPU-mining in order to make the special purposes devices useless.
[https://changelly.com/supported-currencies]
===
Bytecoin (BCN)
$0.000153 (10.58%)
0.00000013 BTC (10.99%)
Rank 31
Mineable Currency
Market Cap
$27,885,394
23,574 BTC
Volume (24h)
$99,601
84.20 BTC
Circulating Supply
182,759,167,360 BCN
[https://coinmarketcap.com/currencies/bytecoin-bcn/] {2017-04-16}

Name::
* cpt.BCN-token,
* cpt.byncevt, {2017-04-02}
* cpt.byncevu, {2017-05-10}
* cpt.ByteCoin-Consensus-Exval-Token, {2017-04-02}
* cpt.ByteCoin-token,
* cpt.mnyBCN,
* cpt.mnyByteCoin,

AddressWpg::
* https://bytecoin.org/
* http://chainradar.com/bcn/blocks,
* BlockH1: http://chainradar.com/bcn/block/1,

bynevuC'Exchange-rate

{time.2017-01-31}:
1 BTC is 14,721,300 BCN (Changelly)

bcnevu.CryptoNote.DarkNetCoin (DNC )

Description::
DarkNetCoin (DNC)
DarkNetCoin is the general currency of DarkNetSpace, a platform for anonymous applications such as p2p exchange, on-chain shop, lotto, gambling and bets. It uses Wild Keccak hash function instead of CryptoNight. Starting with the 4550th block 1% of block reward is donated to CryptoNote team and 9% to DarkNetSpace team.
DARKNETSPACE.ORG
[https://cryptonote.org/coins/]

Name::
* cpt.DarkNetCoin,
* cpt.DarkNetCoin-token,
* cpt.DNC-evuC,
* cpt.DNC-token,
* cpt.mnyDarkNetCoin,
* cpt.mnyDNC,

bcnevu.CryptoNote.Dashcoin (DSHevuC {2014-07-05})

Description::
Dashcoin (DSH)
Dashcoin is a cryptocurrency started on July 5, 2014. Dashcoin is a fork of Bytecoin and it also utilizes CryptoNote algorithm. ?The goal of Dashcoin is to automatically create a perfect mirror image of Bytecoin, the first CryptoNote based cryptocurrency, at any given moment of time. ?The only difference is the supply amount.
[https://cryptonote.org/coins/]
===
Dashcoin DSH
Dashcoin is a Next generation anonymous cryptocurrency and the first automatically mutating cryptocurrency created with CryptoNote technology.
[https://changelly.com/supported-currencies]
===
Dashcoin (DSH)
$0.018697 (-9.18%)
0.00001580 BTC (-8.86%)
Rank 228
Mineable Currency
Market Cap
$322,974
273 BTC
Volume (24h)
$1,508
1.27 BTC
Circulating Supply
17,273,729 DSH
[https://coinmarketcap.com/currencies/dashcoin/] {2017-04-16}

Name::
* cpt.Dashcoin,
* cpt.Dashcoin-token,
* cpt.DSH-evuC,
* cpt.DSH-token,
* cpt.mnyDashcoin,
* cpt.mnyDSH,

AddressWpg::
* http://dashcoin.info/
* BlockH1: http://chainradar.com/dsh/block/1,

bcnevu.CryptoNote.DigitalNote (XDNevuC {2014-05-30})

Description::
DigitalNote XDN
DigitalNote is an experimental open-source cryptocurrency based on CryptoNote technology and CryptoNight algorithm. It is a fork of Bytecoin - the very first implementation of CryptoNote. Nobody own or control DigitalNote. It is a scalable decentralized cryptocurrency with strong privacy protection. DigitalNote uses ring signatures, to provide unlinkable and untraceable transactions.
[https://changelly.com/supported-currencies]
===
DigitalNote (XDN)
$0.000155 (3.69%)
0.00000013 BTC (4.04%)
Rank 148
Mineable Currency
Market Cap
$1,068,910
903 BTC
Volume (24h)
$21,022
17.77 BTC
Circulating Supply
6,878,755,652 XDN
[https://coinmarketcap.com/currencies/digitalnote/] {2017-04-16}

Name::
* cpt.DigitalNote,
* cpt.DigitalNote-token,
* cpt.mnyDigitalNote,
* cpt.mnyXdn,
* cpt.mnyXdn,
* cpt.XDN-evuC,
* cpt.XDN-token,
* cpt.xdncevt,

AddressWpg::
* http://digitalnote.org/
* BlockH1: http://chainradar.com/xdn/block/1,

bcnevu.CryptoNote.Fantomcoin (FCNevuC {2014-05-06})

Description::
Fantomcoin FCN
Unlike other CryptoNote based cryptocurrencies, Fantomcoin supports merged mining. It can be possible with Bytecoin, Monero, QuazarCoin or any CN based coin. New blockchain needs no additional hashpower - it uses Bytecoin, Monero, QuazarCoin blocks or shares as PoW. Miners are free to choose "donor" chain they like. In case other chains based on CryptoNote will appear they also can be used as "donor" chains.
[https://changelly.com/supported-currencies]
===
Fantomcoin (FCN)
Fantomcoin is the first CryptoNote currency with merged mining support. Users who mine Fantomcoin are also able to mine other CryptoNote-based coins without additional hash power. This feature allows user to receive not only FCNs but also any other CryptoNote-based currency. As the result, Fantomcoin encourages fair distribution and stabilization of the cryptocurrency market through diversification.
FANTOMCOIN.ORG
[https://cryptonote.org/coins/]
===
Fantomcoin (FCN)
$0.089940 (3.15%)
0.00007601 BTC (3.50%)
Rank 193
Mineable Currency
Market Cap
$508,843
430 BTC
Volume (24h)
$1,159
0.98 BTC
Circulating Supply
5,657,591 FCN
[https://coinmarketcap.com/currencies/fantomcoin/] {2017-04-16}

Name::
* cpt.Fantomcoin,
* cpt.FCN-evuC,
* cpt.FCN-token,
* cpt.mnyFantomcoin,
* cpt.mnyFcn,
* cpt.mnyFCN,

AddressWpg::
* http://fantomcoin.org/
* BlockH1: http://chainradar.com/fcn/block/1,

bcnevu.CryptoNote.Monero (XMRevuC {2014-04-18})

Description::
Monero XMR
Monero is a new coin using the CryptoNote protocol. It's based on Bytecoin, which was coded from scratch and is not a descendent of Bitcoin. XMR was launched on April 18, 2014.
[https://changelly.com/supported-currencies]
===
Monero (XMR) is an open-source cryptocurrency created in April 2014 that focuses on privacy, decentralisation and scalability. Unlike many cryptocurrencies that are derivatives of Bitcoin, Monero is based on the CryptoNote protocol and possesses significant algorithmic differences relating to blockchain obfuscation.[1] Monero has ongoing support from the community,[2] and its modular code architecture has been praised by Wladimir J. van der Laan, a Bitcoin Core maintainer.[3] Initially meeting little popularity with the general public, Monero experienced rapid growth in market capitalization (from US$5M to US$185M)[4] and transaction volume[5] during the year 2016, partly due to adoption by major darknet market AlphaBay at the end of summer 2016.[6]
[https://en.wikipedia.org/wiki/Monero_(cryptocurrency)]
===
Monero (XMR)
Monero (previously known as Bitmonero) is one of the first CryptoNote coins. It utilizes the same values every CryptoNote coin does – privacy, decentralization and fungibility. Monero development is community-driven, based on donations and with a focus on decentralization and scalability.
MONERO.CC| BITMONERO.ORG
[https://cryptonote.org/coins/]
===
Monero (XMR)
$20.69 (-0.47%)
0.01746860 BTC (-0.22%)
Rank 6
Mineable Currency
Market Cap
$295,879,036
249,864 BTC
Volume (24h)
$4,271,650
3,607 BTC
Circulating Supply
14,303,624 XMR
[https://coinmarketcap.com/currencies/monero/] {2017-04-16}

Name::
* cpt.mnyMonero,
* cpt.mnyXmr,
* cpt.Monero-cryptocurrency,
* cpt.mnyMonero,
* cpt.Monero,
* cpt.XMR-evuC,
* cpt.XMR-token,
* cpt.xmrcevt,

AddressWpg::
* https://getmonero.org/
* Block1: http://chainradar.com/xmr/block/1,

bcnevu.CryptoNote.Pebblecoin (XPB)

Description::
Pebblecoin (XPB)
Pebblecoin is a CryptoNote-based coin with certain adjustments. XPB implemented a mining algorithm called Boulderhash that requires 13 GB RAM. This has been the successful attempt to block botnet-controlled computers from mining. XPB has a distinct emission curve: the standard block reward of 300 coins remains unchanged for the whole period of XPB mining.
[https://cryptonote.org/coins/]

Name::
* cpt.mnyQuazarCoin,
* cpt.mnyQCN,
* cpt.QuazarCoin,
* cpt.QCN-evuC,
* cpt.QCN-token,

bcnevu.CryptoNote.QuazarCoin (QCN {2014-05-08})

Description::
QuazarCoin QCN
QuazarCoin is a new cryptocurrency based on the CryptoNote and uses the CryptoNight algorithm. QCN protects your data and privacy with help of completely anonymous transactions with ring signatures.
[https://changelly.com/supported-currencies]
===
Quazarcoin (QCN)
Quazarcoin is a CryptoNote-based coin, which has been launched as a result of community discussions. It has a flatter emission curve and fair, open launch to attract the wider community. QCN's developers focus on usability aspects of the currency. Its main contribution is the popularization of CryptoNote technology.
QUAZARCOIN.ORG
[https://cryptonote.org/coins/]
===
QuazarCoin (QCN)
$0.009481 (3.45%)
0.00000800 BTC (3.65%)
Rank 448
Mineable Currency
Market Cap
$52,191
44 BTC
Volume (24h)
$13
0.01 BTC
Circulating Supply
5,505,034 QCN
[https://coinmarketcap.com/currencies/quazarcoin/] {2017-04-16}

Name::
* cpt.mnyQuazarCoin,
* cpt.mnyQCN,

AddressWpg::
* BlockH1: http://chainradar.com/qcn/block/1,

bcnevu.SPECIFIC-DIVISION.bitcoin

Specific::
* Bitcoin,
* BitcoinNo-altcoin,

Altcoin

Description::
Altcoin:
The collective name for cryptocurrencies offered as alternatives to bitcoin.
Litecoin, Feathercoin and PPcoin are all altcoins.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Altcoin:
A clone of the protocol with some modifications.
Usually all altcoins have rules incompatible with Bitcoin and have their own genesis blocks.
Most notable altcoins are Litecoin (uses faster block confirmation time and scrypt as a proof-of-work) and Namecoin (has a special key-value storage).
In theory, an altcoin can be started from an existing Bitcoin blockchain if someone wants to support a different set of rules (although, there was no such example to date).
See also Fork.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]

Name::
* cpt.altcoin-of-blockchain,
* cpt.blockchain-altcoin,
* cpt.bcnaltcoin,

bcnevu.SPECIFIC-DIVISION.activeness

bcnevu.ACTIVE

Name::
* cpt.bcnevu.active,

bcnevu.ACTIVE.NO

Description::
CT: Has CoinMarketCap ever permanently removed a coin from being listed on the site? If so is there a list of delisted coins? How about delisting an exchange?
G: About 40% of the coins ever added to the site are now "inactive" due to failing to meet the basic criteria. In virtually all cases, the reason for delisting is because all exchanges have delisted the coin. There is not currently a list of these coins, but perhaps in the future. Exchanges get delisted when their API fails ceases to work for a significant period of time.
[https://cointelegraph.com/news/coinmarketcap-about-40-of-the-coins-ever-added-to-the-site-are-now-inactive] {2015-08-21}

Name::
* cpt.bcnevu.activeNo,
* cpt.bcnevu.inactive,

Specific::
* Solocoin-SOL, https://coinmarketcap.com/currencies/solcoin/

bcnevu.SPECIFIC-DIVISION.mining

bcnevu.MINABLE

Name::
* cpt.bcnevu.minable,

Specific::
* Bitcoin-BTC,
* Ethereum-ETH,
* Litecoin-LTC,
* Dash-DASH,
* Monero-XMR,
* Ethereum Classic-ETC,
* Zcash-ZEC,
* Steem-STEEM,
* Decred-DCR,
* BitConnect-BCC,
* Dogecoin-DOGE,
* Bytecoin-BCN,
* GameCredits-GAME,
* Siacoin-SC,
* Peercoin-PPC,
* Emercoin-EMC,
* Komodo-KMD,
* Nexus-NXS,
* SysCoin-SYS,
* ZCoin-XZC,
* Creditbit-CRBIT,
* Namecoin-NMC,

bcnevu.MINABLE.NO

Name::
* cpt.bcnevu.minable,

Specific::
* Ripple-XRP,
* NEM-XEM,
* PIVX-PIVX,
* Stratis-STRAT,
* Waves-WAVES,
* Lisk-LSK,
* Stellar Lumens-XLM,
* BitShares-BTS,
* Ark-ARK,
* Nxt-NXT,
* Bitcrystals-BCY,
* Byteball-GBYTE,
* Counterparty-XCP,
* AntShares-ANS,
* I/O Coin-IOC,
* Rubycoin-RBY,
* Nexium-NXC,
* BlackCoin-BLK,
* NAV Coin-NAV,
* YbCoin-YBC,
* Radium-RADS,
* BitBay-BAY,
* ION-ION,
* Omni-OMNI,

bcnevu.MINABLE.SIGNIFICANTLY-PREMINED

Name::
* cpt.bcnevu.sigificantly-premined,

Specific::
* Gulden-NLG,

bcnevu.AGGREGATE

Description::
Most cryptocurrencies are designed to gradually decrease production of currency, placing an ultimate cap on the total amount of currency that will ever be in circulation.
This can mimic the scarcity (and value) of precious metals and avoid hyperinflation.
Compared with ordinary currencies held by financial institutions or kept as cash on hand, cryptocurrencies are less susceptible to seizure by law enforcement.
Existing cryptocurrencies are all pseudo-anonymous, though additions such as Zerocoin and its distributed laundry[13] feature have been suggested, which would allow for true anonymity.
[https://en.wikipedia.org/wiki/Cryptocurrency]

Name::
* cpt.bcnevu.supply,
* cpt.supply-of-bcnevu,

Description::
This is a list of notable cryptocurrencies. There were more than 530 cryptocurrencies available for trade in online markets as of 5 January 2015 and more than 740 in total[1] but only 10 of them had market capitalizations over $10 million.[2]
[https://en.wikipedia.org/wiki/List_of_cryptocurrencies]

SPECIFIC

Specific::
* Circulating-supply,
* Total-supply,
* Market-cap,

bcnevu.Market-cap

Description::
The-product of aggregate-tokens times its exchange-rate.

Name::
* cpt.bcnmarket-cap-of-bcnevt,
* cpt.blockchain-market-cap-of-bcnevt,
* cpt.market-cap-of-bcnevt,
* cpt.market-capitalization-of-bcnevu,

bcnevu.csa.CONSENSUS (bcnevuC)

Description::
Blockchain-Consensus-Exval-Token[1] is the main token of a-bcnnet, needed to make consensus to upadate the-blocs in a-blockchain.
As long as a-blockchain-network is public, this[1] token is a-commodity with exchange-value the-work needed to exist the-network TIMES demand/supply.
[hmnSgm.2017-04-09]
===
Blockchain-Consensus-Exval-Token is AUTOBACKED.
[hmnSgm.2017-04-04]

Name::
* cpt.bcnevuC, {2017-07-17}
* cpt.bcncevu, {2017-07-17}
* cpt.consensus-exchange-value-unit-of-blockchain, {2017-07-17}

* cpt.bcncevt, {2017-04-15}
* cpt.bcncet, {2017-03-31}
* cpt.blockchain-CEV-Token, {2017-04-04}
* cpt.blockchain-Consensus-Exval-Token, {2017-03-31}
* cpt.bcnctk, {2017-03-29}
* cpt.blockchain-consensus-token, {2017-03-29}
===
* cpt.core-token-of-bcnnet,
* cpt.basic-blockchain-token, [BitShares {2017-03-28}]
* cpt.base-token-of-bcnnet, [BitShares {2017-03-28}]
* cpt.bcncrc, {2017-03-28}
* cpt.bcnevt.consensus,
* cpt.bcnevt.main,
* cpt.bcnevt.currency,
* cpt.bcnnet'currency,
* cpt.bcnnet-currency,
* cpt.blockchain-currency, {2017-03-28}
* cpt.consensus-money, {2017-03-28}
* cpt.main-blockchain-token,
* cpt.main-network-token,
* cpt.bcnevt.currency,
* cpt.currency-in-blockchaine-network,

Description::
We believe that Bitcoin is in fact the first ever decentralized job network to exist, if we define jobs on the bitcoin network as actions by network participants who are paid directly and autonomously from a purely decentralized source such as the block reward.
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf, Evan Duffield]

Description::
Blockchain-currency is the main money of a-bcnnet, needed to create the-blockchain.
[hmnSgm.2017-03-28]

Description::
A-cryptocoin used in a-blochain that transacts money.
[hmnSgm.2017-02-06]

bcnevtC'Exchange-rate

Description::
As long as a-blockchain-network is public, this[1] token is a-commodity with exchange-value the-work needed to exist the-network TIMES demand/supply.
[hmnSgm.2017-04-09]

Name::
* cpt.bcncevt'exchange-rate,

bcnevtC'Energy-consumption

Description::
Low energy consumption.
Many cryptocurrencies rely on a ‘proof-of-work’ model to create new coins and secure the network.
This is an intensive computational process that can only be carried out by highly specialised hardware and requires huge amounts of electricity.
Nxt’s ‘proof-of-stake’ solution needs very little energy by comparison, with the result that the network has a fraction of the carbon footprint of other cryptocurrencies.
[http://nxt.org/about/what-is-nxt/]

Name::
* cpt.bcnnet'energy-consumption,
* cpt.blockchain-energy-consumption,
* cpt.energy-consumption-of-bcnnet,

SPECIFIC

Name::
* bcnevuC.specific,
* cpt.bcnevuC.specific,

Specific::
* {2017}:

* {2016}:
- Decred-DCR,
- LBRY-Credits-LBC,
- Lisk-LSK,
- NAV-Coin-NAV,
- PIVX,
- STEEM,
- Stratis-STRAT,
- WAVES,
- Zcash-ZEC,
* {2015}:
- BitShares-BTS,
- Ether-ETH,
- Factom-FCT,
- NEM-XEM,
- Radium-RADS,
* {2014}:
- AuroraCoin-AUR,
- BlackCoin-BLK,
- DASH,
- FairCoop-FAIR,
- Gulden-NLG,
- NuBits-USNBT,
* {2013}:
- DogeCoin-DOGE,
- Nxt-NXT,
* {2012}:
- Freicoin-FRC,
- Peercoin-PPC,
- Ripple-XRP,
* {2011}:
- Litecoin-LTC,
- Namecoin-NMC,
* {2010}:

* {2009}:
- Bitcoin-BTC,

bcnevu.csa.CONSENSUS.NO (bcnevtCNo)

Description::
Non-consensus-exchange-value-unit is an-exchange-value-unit which is-not-used as incentive in the-consensus-algorithm.
[hmnSgm.2017-05-17]
===
A-secondary-cryptocoin created in a-blochain with different MAIN money.
[hmnSgm.2017-02-13]

Name::
* cpt.bcnevuCN, {2017-05-17}
* cpt.consensusNo-exchange-value-of-blockchain, {2017-05-17}
* cpt.non-consensus-exchange-value-of-blockchain, {2017-05-17}

* cpt.bcnevuCNo, {2017-05-11}
* cpt.bcncevtNo, {2017-03-31}
* cpt.blockchain-consensusNo-exval-token, {2017-03-31}
* cpt.bcnctkNo, {2017-03-29}
* cpt.blockchain-consensusNo-token, {2017-03-29}
===
* cpt.bcnevt.consensusNo,
* cpt.bcnevt.secondary,
* cpt.bcnevt.subcurrency,
* cpt.bcnnet'subcurrency,
* cpt.bcnnet-subcurrency,
* cpt.bcnscrc, {2017-03-28}
* cpt.custom-blockchain-token,
* cpt.bcnevt.subcurrency,
* cpt.subcurrency-in-blockchaine-network,

Specific::
* Chronobank-LHT,
* Chronobank-TIME,
* Colored-coin,
* Ethereum-evuCN,

bcnevtCNo.Colored-coin

Description::
ColoredCoins started in 2013 as method to push metadata to the Bitcoin blockchain, and evolved over the years to a vibrant ecosystem for digital currencies.

As the open source community continues to develop, a consortium of stake-holders has formed with the realization that the blockchain movement will transform the way we do business in the future and that this revolution, much like the internet, will happen after standards will form around every layer of the stack.

The ColoredCoins project taps into the biggest and the most successful crypto-currency ecosystem in the world, Bitcoin, and creates a blockchain agnostic framework for digital-currencies that will apply those best practices to traditional finance.
[http://coloredcoins.org/]

Name::
* cpt.ColoredCoin,
* cpt.colored-coin,

bcnevtCNo.Bitcoin-colored-coin

Description::
Colored_coins:
A proposed add-on function for bitcoin that would enable bitcoin users to give them additional attributes.
These attributes could be user-defined, enabling you to mark a bitcoin as a share of stock, or a physical asset.
This would enable bitcoins to be traded as tokens for other property.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Colored_Coin:
A concept of adding a special meaning to certain transaction outputs.
This could be used to create a tradable commodity on top of Bitcoin protocol.
For instance, a company may create 1 million shares and declare a single transaction output containing 10 BTC (1 bln *satoshis*) as a source of these shares.
Then, some or all of these bitcoins can be moved to other addresses, sold or exchanged for anything.
During a voting process or a dividend distribution, share owners can prove ownership by simply singing a particular message by the private keys associated with addresses holding bitcoins derived from the initial source.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]

Name::
* cpt.bitcoin-ColoredCoin,
* cpt.bitcoin-colored-coin,
* cpt.btccolored-coin,

bcnevtCNo.ICO

Name::
* cpt.bcnico,

AddressWpg::
* http://cofound.it/ (ethereum-based),

bcnevu.NATIONAL

Description::
National cryptocurrencies provide a meaningful alternative to the central banking system, allow a people to gather equity instead of debt, and have a more focused distribution model than general purpose cryptocurrencies such as Bitcoin.
[http://cointelegraph.com/news/could-iceland-embrace-crypto-before-anyone-else]

Name::
* cpt.bcnevt.national,
* cpt.national-cryptocurrency,
* cpt.mnyNational-cryptocurrency,

AddressWpg::
* {2017-05-15} Palestine May Launch Its Own Cryptocurrency as Sovereign Legal Tender: https://bitcoinmagazine.com/,

Senegal

Name::
* cpt.eCFA-money,
* cpt.mnyeCFA,

NOV 27, 2016
By Joseph Young
Senegal Introduces Cryptocurrency Based on its National Currency

Senegal Introduces Cryptocurrency Based on its National Currency
Senegalmay become the first country to release a cryptocurrency based on its national currency.

Earlier this month, Senegal introduced eCFA, a digital currency currently in development in collaboration with Banque Regionale de Marches (BRM) and eCurrency Mint Limited. BRM bank, a Senegal-based financial institution specializing in capital markets and the implementation of tailor-made banking solutions, is leading both the development and integration of the digital currency, which the Senegal government states would serve as a legal tender.

Similar to the vision of Norway’s largest bank DNB, Senegal is attempting to secure a significant market share of Africa’s severely underbanked and underserved populations, which are struggling to find access to reliable and cost-efficient financial platforms and networks to settle cross-border transactions.

Interestingly, the development and launch of eCFA is overseen by the West African Economic and Monetary Union (WAEMU), which suggests that once ready for commercial roll-out, eCFA will be made available for other African countries including Benin, Burkina Faso, Cote d’Ivoire, Niger, Togo and more.

Criticisms and future plans

Upon the first announcement of plans to develop eCFA, BRM bank as well as the Senegal government received criticisms from cryptography experts and analysts due to eCFA’s dependence on a centralized banking system. It has been said that if eCFA is based on its national currency, it defeats the purpose of implementing a digital currency.

In spite of these criticisms, BRM bank CEO Alioune Camara, stated earlier this month that it will assist the Senegal government in creating a system which can facilitate interoperability between all financial applications, platforms and networks within the region.

Camara stated:

“An eCFA backed by our banking system and the central bank is the safest and most secure way to enable the digital economy. We can now facilitate full interoperability between all e-money payment systems. This is a great leap forward for Africa.”

Ambiguity in Blockchain specifications

However, BRM and eCurrency Mint Limited have yet to release any technical information and background on their Blockchain-based digital currency. In fact, it is still unknown whether the currency will be based on a permissioned ledger or a decentralized Blockchain network. If the latter, the bank will struggle with existing financial regulations.

If the bank opts for a permissioned ledger, various security consequences will lead to issues with the deployment process, which may turn out increasingly inefficient for both the bank and its future users.
[https://cointelegraph.com/news/senegal-introduces-cryptocurrency-based-on-its-national-currency]

bcnevu.Stratis (STRATevuC {2016-08-09})

Description::
Stratis STRAT
Stratis is a flexible and powerful Blockchain Development Platform designed for the needs of real-world financial services businesses.
[https://changelly.com/supported-currencies]

Name::
* cpt.STRAT-evuC,
* cpt.Stratis-token,
* cpt.mnyStratis,
* cpt.mnySTRAT,

AddressWpg::
* https://stratisplatform.com/
* Block#1: https://chainz.cryptoid.info/strat/block.dws?1.htm,

bcnevu.LBRY-Credits (LBCevuC {2016-06-23})

Description::
LBRY Credits LBC
LBRY is the first digital marketplace to be controlled by the market’s participants rather than a corporation or other 3rd-party.
[https://changelly.com/supported-currencies]
===
LBRY Credits (LBC)
$0.082279 (-4.60%)
0.00006966 BTC (-5.48%)
Rank 71
Mineable Currency
Market Cap
$5,039,968
4,267 BTC
Volume (24h)
$413,316
349.94 BTC
Circulating Supply
61,254,380 LBC
Total Supply
459,154,380 LBC
[https://coinmarketcap.com/currencies/library-credit/] {2017-04-16}

Name::
* cpt.LBC-evuC,
* cpt.LBC-token,
* cpt.lbccevt,
* cpt.lbry-credits,
* cpt.lbry-credits-token,
* cpt.mnyLBRY-Credits,
* cpt.mnyLBC,

AddressWpg::
* https://lbry.io/
* https://explorer.lbry.io/
* BlockH1: https://explorer.lbry.io/block/decb9e2cca03a...1b088f22f8f38556d93ac4358b86c24,

bcnevu.NAV-Coin (NAVevuC {2016-05-12})

Description::
NAV Coin NAV
NAV Coin is a X13 POS cryptocurrency. Anonymous Technology using Subchains and Community's Foundation
[https://changelly.com/supported-currencies]
===
NAV Coin (NAV)
$0.101782 (15.79%)
0.00008618 BTC (14.79%)
Rank 64
Currency
Market Cap
$6,198,229
5,248 BTC
Volume (24h)
$430,299
364.32 BTC
Circulating Supply
60,897,100 NAV
[https://coinmarketcap.com/currencies/nav-coin/] {2017-04-16}

Name::
* cpt.NAV-evuC,
* cpt.NAV-token,
* cpt.NAV-Coin-token,
* cpt.mnyNAV-Coin,
* cpt.mnyNAV,

AddressWpg::
* http://navcoin.org/
* Block#1: https://chainz.cryptoid.info/nav/block.dws?1.htm,

bcnevu.Steem (STEEMcevu {2016})

Description::
Steem STEEM
Steem is the first Reddit-like social media platform based on blockchain technologies. Each worthy content, instead of likes, is rewarded by STEEM, a crypto that fuels the platform. STEEM may also be mined through the p2p network.
[https://changelly.com/supported-currencies]
===
Steem (STEEM)
$0.216145 (9.80%)
0.00018364 BTC (10.63%)
Rank 19
Mineable Currency
Market Cap
$51,158,750
43,465 BTC
Volume (24h)
$1,942,640
1,650 BTC
Circulating Supply
236,687,178 STEEM
Total Supply
253,661,272 STEEM
[https://coinmarketcap.com/currencies/steem/] {2017-04-16}

Name::
* cpt.mnySTEEM,
* cpt.STEEM-evuC,
* cpt.STEEM-token,
* cpt.STEEMcevu,

AddressWpg::
* https://steem.io/
* ANN: https://bitcointalk.org/index.php?topic=1410943.0, {2016-03-24}

bcnevu.Factom (FCTevuC {2015-09-01})

Description::
Factom FCT
Factom is an open source project implementing blockchain technology for businesses. Entries in the ledger cannot be altered, thus there is no place for fraud and forgery, the system becomes transparent. Factom cryptocurrency is alternatively called Factoids.
Users of the system can exchange them for Entry Credits, in this case the coins are burnt.
Individuals who run FCT Servers pay transaction fees for Bitcoin and get Factoids as an incentive for that.
[https://changelly.com/supported-currencies]
===
Factom (FCT)
$5.84 (18.27%)
0.00494316 BTC (17.05%)
Rank 18
Currency
Market Cap
$51,078,534
43,269 BTC
Volume (24h)
$3,704,120
3,138 BTC
Circulating Supply
8,753,219 FCT
[https://coinmarketcap.com/currencies/factom/] {2017-04-16}

Name::
* cpt.Factom-token,
* cpt.FCT-evuC,
* cpt.FCT-token,
* cpt.mnyFactom,
* cpt.mnyFCT,

AddressWpg::
* http://factom.org/

bcnevu.Radium (RADSevuC {2015-05-25})

Description::
Radium RADS
Radium and its blockchain serve as a basis for the Radium SmartChain, a foundation for the progressive blockchain development. The ultimate goal is to set up an environment for completely decentralized services. RADS can be sent using traditional addresses or usernames recorded in the blockchain of the coin.
[https://changelly.com/supported-currencies]
===
Radium (RADS)
$1.53 (3.94%)
0.00129289 BTC (3.30%)
Rank 72
Currency
Market Cap
$4,880,240
4,134 BTC
Volume (24h)
$52,415
44.40 BTC
Circulating Supply
3,197,641 RADS
[https://coinmarketcap.com/currencies/radium/] {2017-04-16}

Name::
* cpt.Radium-token,
* cpt.RADS-evuC,
* cpt.RADS-token,
* cpt.mnyRadium,
* cpt.mnyRADS,

AddressWpg::
* http://projectradon.info/
* https://chainz.cryptoid.info/rads/
* Block#1: https://chainz.cryptoid.info/rads/block.dws?1.htm,

bcnevu.NuBits (USNBTevuC {2014-08-03})

Description::
NuBits NBT
NuBits is a digital currency developed in 2014 by the creators of Peershares. The unique feature of this cryptocurrency is its stable price. NuBits is always equal to $1 and it is the first decentralized cryptocurrency to maintain the $1 peg for over a year. They accomplish it by adjusting the coin supply to match investor demand, the markets don’t control the price.
[https://changelly.com/supported-currencies]
===
Nu is the first decentralized central bank in the world who issue NuBits, the first crypto-dollar with a stable prize 1NBT = 1USD. Value stability is highly desirable in a currency, and we expect more and more users will begin using NuBits for online purchases.
[http://cointelegraph.com/news/beyond-bitcoin-how-stable-are-alternative-cryptocurrencies]
===
NuBits (USNBT)
$0.988734 (1.19%)
0.00083747 BTC (0.51%)
Rank 294
Currency
Market Cap
$134,075
114 BTC
Volume (24h)
$838
0.71 BTC
Circulating Supply
135,603 USNBT
Total Supply
4,845,406 USNBT
[https://coinmarketcap.com/currencies/nubits/] 2017-04-16

Name::
* cpt.NBT-evuC,
* cpt.NBT-token,
* cpt.Nubits-token,
* cpt.mnyNuBits,
* cpt.mnyNBT,

AddressWpg::
* https://www.nubits.com/
* https://nuexplorer.ddns.net/
* BlockH0: https://nuexplorer.ddns.net/blocks/000003cc2d...9ddc1204efd169e947dd4cbad73f/1,

bcnevu.MaidSafeCoin (MAIDevuCN {2014-04-22})

Description::
MaidSafeCoin MAID
MaidSafeCoin is a part of MaidSafe network. The developers created SAFE (Secure Access For Everyone) network for invulnerable and private data storage with no governing party. Users of the network who grant their resources are automatically rewarded with the coins. They can exchange the received Safecoins for the services within SAFE Network or trade them as any other cryptocurrency.
[https://changelly.com/supported-currencies]
===
MaidSafeCoin (MAID)
$0.200548 (2.10%)
0.00016979 BTC (1.14%)
Rank 11
Asset
Market Cap
$90,758,481
76,838 BTC
Volume (24h)
$424,330
359.25 BTC
Circulating Supply
452,552,412 MAID
[https://coinmarketcap.com/assets/maidsafecoin/] {2017-04-16}

Name::
* cpt.MAID-evuCN,
* cpt.MAID-token,
* cpt.mnyMAID,
* cpt.mnyMaidSafeCoin,
* cpt.mnySafecoin,

AddressWpg::
* http://maidsafe.net/
* ann: https://bitcointalk.org/index.php?topic=579797.0, {2014-04-22}
* http://omnichest.info/lookupsp.aspx?sp=3, {2014-04-22}

bcnevu.Gulden (NLGevuC {2014-03-29})

Description::
Gulden NLG
Gulden is the first digital currency with a human approach. It is a Dutch cryptocurrency named after the national defunct currency of Netherlands. The crypto is determined by the demand for gold and silver. Guldens are stored on a mobile or desktop app and can be used anywhere Bitcoin is accepted, including IBAN banks.
[https://changelly.com/supported-currencies]
===
Gulden (NLG)
$0.040189 (12.73%)
0.00003402 BTC (11.60%)
Rank 44
Mineable Premined Currency
Market Cap
$13,817,731
11,698 BTC
Volume (24h)
$67,784
57.39 BTC
Circulating Supply
343,822,145 NLG
Total Supply
445,842,300 NLG
[https://coinmarketcap.com/currencies/gulden/] {2017-04-16}

Name::
* cpt.Gulden-token,
* cpt.mnyGulden,
* cpt.mnyNLG,
* cpt.NLG-evuC,
* cpt.NLG-token,

AddressWpg::
* https://gulden.com/
* BlockH1: https://blockchain.gulden.com/block/756e5147f4...950819c82d8d17ee7ceaa8e3a6628,

bcnevu.BlackCoin (BLKcevu {2014-02-24})

Description::
BlackCoin (BLK)
$0.081931 (12.03%)
0.00006927 BTC (10.84%)
Rank 63
Currency
Market Cap
$6,232,987
5,270 BTC
Volume (24h)
$163,031
137.84 BTC
Circulating Supply
76,076,517 BLK
[https://coinmarketcap.com/currencies/blackcoin/] {2017-04-15}
===
BlackCoin is a peer-to-peer cryptocurrency. BlackCoin uses a proof-of-stake system and is open-source.[3] BlackCoin was created by the developer Rat4, with the goal of proving that BlackCoin’s way of disabling proof-of-work is stable and secure.[4] BlackCoin secures its network through a process called "minting". Transactions in BlackCoin were called "significant" in a Citibank whitepaper.[5]
[https://en.wikipedia.org/wiki/BlackCoin]

Name::
* cpt.BlackCoin-token,
* cpt.BLK-evuC,
* cpt.BLK-token,
* cpt.BLKcevu,
* cpt.mnyBlackCoin,

AddressWpg::
* http://blackcoin.co/
* Block#1 https://chainz.cryptoid.info/blk/block.dws?1.htm,

bcnevu.Auroracoin (AURevuC {2014-01-24})

Description::
Auroracoin (AUR)
$0.177925 (8.19%)
0.00015040 BTC (7.06%)
Announcement
Rank 130
Mineable Premined Currency
Market Cap
$1,540,499
1,302 BTC
Volume (24h)
$2,686
2.27 BTC
Circulating Supply
8,658,139 AUR
[https://coinmarketcap.com/currencies/auroracoin/] {2017-04-15}
===
Auroracoin is a cryptocurrency launched in February 2014 as an Icelandic alternative to Bitcoin and the Icelandic krona.[1][2][3] Its unknown creator or creators use the pseudonym Baldur Friggjar O?insson (or Odinsson).[1][2][3] They stated that they planned to distribute half of auroracoins that would ever be created to all 330,000 people listed in Iceland's national ID database beginning on March 25, 2014, free of charge, coming out to 31.8 auroracoins per person.[1][3]
Auroracoin was created as an alternative currency to address the government restrictions on Iceland's krona, in place since 2008, which severely restricts movement of the currency outside of the country.[1] Iceland's Foreign Exchange Act also prohibits the foreign exchange of bitcoins from the country, according to a government minister.[4]
[https://en.wikipedia.org/wiki/Auroracoin]

Name::
* cpt.AUR-evuC,
* cpt.AUR-token,
* cpt.AURcevu,
* cpt.AuroraCoin-token,
* cpt.mnyAUR,
* cpt.mnyAuroraCoin,
* cpt.mnyAuroraCoin,

AddressWpg::
* http://new.auroracoin.is/
* https://github.com/aurarad/auroracoin,
===
* http://cointelegraph.com/news/saving-icelands-economy-did-auroracoin-fail-its-mission {2016-04-19}
* http://cointelegraph.com/news/could-iceland-embrace-crypto-before-anyone-else,

bcnevu.Dogecoin (DOGEevuC {2013-12-06})

Description::
Dogecoin (DOGE)
$0.000441 (4.92%)
0.00000037 BTC (3.83%)
Rank 21
Mineable Currency
Market Cap
$48,045,918
40,702 BTC
Volume (24h)
$1,411,570
1,196 BTC
Circulating Supply
108,982,504,127 DOGE
[https://coinmarketcap.com/currencies/dogecoin/] {2017-04-16}
===
Dogecoin DOGE
Dogecoin is a cryptocurrency featuring a likeness of the Shiba Inu dog from the "Doge" Internet meme as its logo. Started as a "joke currency" in late 2013, Dogecoin quickly developed its own online community and reached reasonable capitalization nowadays.
[https://changelly.com/supported-currencies]
===
Date of introduction     December 8, 2013; 19 months ago
User(s)     International
Inflation     Approximately 100 billion coins to be mined by early 2015, and 5.256 billion new coins per year.
Symbol     ?[1]
Nickname     Doge
Plural     DOGE, Dogecoins
Dogecoin (/?do??k??n/ DOHZH-koyn,[2] code: DOGE, symbol: ?[1] and D) is a cryptocurrency featuring a likeness of the Shiba Inu dog from the "Doge" Internet meme as its logo.[3][4][5][6] It was introduced on December 8, 2013.[7]

Started as a "joke currency" in late 2013, Dogecoin quickly developed its own online community and reached a capitalization of USD 60 million in January 2014;[8] as of January 2015, it had a capitalization of USD 13.5 million.[9]

Compared with other cryptocurrencies, Dogecoin has a fast initial coin production schedule: 100 billion coins have been in circulation by mid 2015 with an additional 5.256 billion coins every year thereafter. As of 30 June 2015, the 100 billionth Dogecoin has been mined.[10] While there are few mainstream commercial applications, the currency has gained traction as an Internet tipping system, in which social media users grant Dogecoin tips to other users for providing interesting or noteworthy content.[11] Many members of the Dogecoin community, as well as members of other cryptocurrency communities, use the phrase "To the moon!" to describe the overall sentiment of the coin's rising value.[12][13][14]
[https://en.wikipedia.org/wiki/Dogecoin]

Name::
* cpt.DOGE-evuC,
* cpt.DOGE-token,
* cpt.dogecevt,
* cpt.Dogecoin,
* cpt.mnyDogeCoin,
* cpt.mnyDOGE,

AddressWpg::
* http://dogecoin.com/

bcnevu.Freicoin (FRCcevu {2012-12-21})

Description::
Freicoin is a decentralized, distributed, peer-to-peer electronic currency designed to address the grievances of the working class and re-align financial interests of the wealthy elite with the stability and well-being of the economy as a whole. Whereas inflationary currencies like the U.S. Dollar or Euro are controlled by central bankers under rules that intentionally or not benefit the establishment, Freicoin is completely decentralized and self-regulating, with a demurrage fee that ensures its circulation and bearers of the currency pay this fee automatically to those community members who contribute work to secure the currency.
Freicoin is an implementation of the accounting concept of a proof-of-work block chain used by Satoshi Nakamoto in the creation of Bitcoin. It includes a downloadable client for Mac OS X, Windows, and Linux, and an electronic network for transferring funds denominated in Freicoin world-wide. You can download, review and improve the code of this free software project on Github.
[http://freico.in/about/]
===
Freicoin:
A cryptocurrency based on the inflation-free principles outlined by the economist Silvio Gessell.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Freicoin (FRC)
$0.001772 (1.05%)
0.00000150 BTC (0.00%)
Rank 335
Mineable Currency
Market Cap
$49,021
41 BTC
Volume (24h)
$1,112
0.94 BTC
Circulating Supply
27,665,859 FRC
Total Supply
100,000,000 FRC
[https://coinmarketcap.com/currencies/freicoin/] {2017-04-16}

Name::
* cpt.FRC-evuC,
* cpt.FRC-token,
* cpt.FRCcevu,
* cpt.Freicoin,

AddressWpg::
* http://freico.in/

bcnevu.Tether (USDTevt)

Description::
We’ve combined the best of both worlds
Get the joint benefits of the Bitcoin blockchain and traditional currency
[https://tether.to/]
===
Add more value to your business
Start reaping the rewards of stable currency on the Blockchain

Custodial Account
Avoid the hassle of the banking system.
Store cash as if it were bitcoin.

Provide a Bitcoin Alternative
Offer your customers stable currency with the benefits and functionality of the Blockchain.

Transact with Digital Currency
Store, send and receive 1-to-1 backed digital currency across exchanges, platforms, and wallets.
[https://tether.to/why-use-tether/]
===
Tether (USDT)
$0.999837 (0.00%)
0.00084977 BTC (0.79%)
Rank 19
Asset
Market Cap
$50,735,502
43,121 BTC
Volume (24h)
$11,925,500
10,136 BTC
Circulating Supply
50,743,773 USDT
Total Supply
54,950,871 USDT
[https://coinmarketcap.com/assets/tether/] {2017-04-16}

Name::
* cpt.mnyTether,
* cpt.Tether-token,
* cpt.USDT-evu,

AddressWpg::
* https://tether.to/
* https://bravenewcoin.com/assets/Whitepapers/Tether-White-Paper.pdf,
* http://omnichest.info/lookupsp.aspx?sp=31,

bcnevu.SCAM

Description::
Scamcoin:
An altcoin produced with the sole purpose of making money for the originator.
Scamcoins frequently use pump and dump techniques and pre-mining together.
[http://www.coindesk.com/information/bitcoin-glossary/]

Name::
* cpt.blockchain-scamcoin,
* cpt.bcnscamcoin,
* cpt.scamcoin,
====

bcnevu.EVOLUTING (bcnevuEvn)

Name::
* cpt.bcnevuEvn,
* cpt.bcnevt.evoluting,

{time.1998}:
=== GENESIS Wei-Dai:
Bitcoin is the first implementation of a concept called "cryptocurrency", which was first described in 1998 by Wei Dai on the cypherpunks mailing list, suggesting the idea of a new form of money that uses cryptography to control its creation and transactions, rather than a central authority.
The first Bitcoin specification and proof of concept was published in 2009 in a cryptography mailing list by Satoshi Nakamoto.
Satoshi left the project in late 2010 without revealing much about himself.
The community has since grown exponentially with many developers working on Bitcoin.
[https://bitcoin.org/en/faq#who-created-bitcoin]

bcnnet'Statistics (bcnstat)

Description::
Quantifiable information about many attributes of a-blockchain-network.

Name::
* cpt.bcnnet'statistics,
* cpt.blockchain-network-statistics,
* cpt.blockchain-statistics,

bcnstat'Block-explorer (link)

bcnnet'Governance-system (bcngov)

Description::
Recently, new blockchains equipped with built in governance system tried to cope with this problem.
Dash is the forerunner to implement governance system in their blockchain.
Dash, who call themselves as the “First Self Governing, Self Funding Protocol”,proposed a decentralized management system based on the masternode voting mechanism in 2015.
Dash has been steadily developed using this governance system.
Recently the price of Dash surpassed over $100 {March 16th, 2017}.
A stable governance structure may be the reason for the increased value.

More and more recent cryptocurrencies have governance systems.
Qtum, a Chinese cryptocurrency, has governance system named the “Judgement Committee”.
Dfinity and Tezos also have governance systems.
Needless to say BOScoin has a governance system as well.
...
If these systems are implemented in blockchain, the blockchain can adjust and evolve itself according to the contemporary environment.
If these systems work successfully, we can build a true DAO(Decentralized Autonomous Organization) self-governing community which is the dream of blockchain enthusiasts.
I believe these kinds of democratic systems are the key to sustaining and growing the cryptocurrency ecosystem.
Cryptocurrencies equipped with a governance structure will be the next wave of blockchain technology.
Myung Sahn Juhn
[http://cryptocentral.info/topic/913/boscoin-bos-a-congressional-cryptocurrency-platform-for-trust-contracts/4]

Name::
* cpt.bcngov,
* cpt.bcnnet'governance-system,
* cpt.blockchain-governance-system,

Attribute:

[http://cryptocentral.info/topic/913/boscoin-bos-a-congressional-cryptocurrency-platform-for-trust-contracts/4]

bcngov'Builtin

Description::
whether the-governance-system is built-in or not.

bcngov'Auto-updating

Description::
whether a-new-version or policy is applied automatically or manually.
Dash has no auto-updating function so have a penalty policy to urge the masternode to maintain the latest program.

bcngov'GOVERNING

Name::
* cpt.bcnnet'decision-making-process,
* cpt.bcnnet'governing,
* cpt.bcnnet'managing,

Specific::
Bitcoin:  Non-systematic
Ethereum: Non-systematic
BOSnet:   Democratic Congress (One node = One vote)

bcnnet'Program (bcnpgm)

Description::
Bcnnet-program is any computer-program used in a-blockchain-network.
[hmnSgm.2017-05-15]

Name::
* cpt.bcnnet-program,
* cpt.bcnnetpgm,
* cpt.blockchain-network-program,

SPECIFIC

Specific::
* Blockchain-program,
* Client-program,
* dApp,
* Wallet-program,

bcnpgm.CLIENT

Description::
Blockchain-client is the-program that implements the-protocol of the-blockchain-network.

Name::
* cpt.blockchain-client,

bcnpgm.BLOCKCHAIN-PROGRAM

Description::
Blockchain-program[1] is a-computer-program stored in a-blockchain that[1] process arbitrary transitions of the-blockchain's-information.
[hmnSgm.2017-05-15]
Smart-contract is a-program deployed on a-blockchain.

Name::
* cpt.smart-contract,

Specific::
* Ethereum-smart-contract,
* BOScoin-smart-contract,

bcnpgm.dApp (bcndap)

Cpt-created: {2016-02-24}

Description::
Dapp or decentralised-app is an-app running on a-decentralised-network.
Dapp CAN-HAVE a-front-end-code or user-interface written on any language.
[hmnSgm.2017-03-23]
===
Definition of a Dapp
For an application to be considered a Dapp (pronounced Dee-app, similar to Email) it must meet the following criteria:

The application must be completely open-source, it must operate autonomously, and with no entity controlling the majority of its tokens. The application may adapt its protocol in response to proposed improvements and market feedback but all changes must be decided by consensus of its users.

The application's data and records of operation must be cryptographically stored in a public, decentralized blockchain in order to avoid any central points of failure.

The application must use a cryptographic token (bitcoin or a token native to its system) which is necessary for access to the application and any contribution of value from (miners / farmers) should be rewarded in the application’s tokens.

The application must generate tokens according to a standard crytptographic algorithm acting as a proof of the value nodes are contributing to the application (Bitcoin uses the Proof of Work Algorithm).
[https://github.com/DavidJohnstonCEO/DecentralizedApplications#definition-of-a-dapp]

Name::
* cpt.blockchain-application.
* cpt.dApp,
* cpt.decentralised-application.

SPECIFIC

Specific::
* Ethereum-dApp,
* Lisk-dApp,

bcnnet'Wallet (bcnwlt)

Description::
Wallets are containers for private keys, usually implemented as structured files or simple databases.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch04.asciidoc#wallets]

Name::
* cpt.bcnwlt,
* cpt.bcnwallet,
* cpt.blockchain-wallet,

Description::
A Bitcoin wallet can refer to either a wallet program or a wallet file.
Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis.
Wallet files store private keys and (optionally) other information related to transactions for the wallet program.
[https://bitcoin.org/en/developer-guide#wallets]
===
Now that you are connected to the network, the next thing you need to do is create a wallet that will hold your account addresses and DCR balance.
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]

bcnwlt'Exval-unit

Description::
Wallet-evu is the-evu the-wallet stores.

Name::
* cpt.bcnwlt'exval-unit,
* cpt.bcnwlt'evu,
* cpt.bcnwlt'token,
* cpt.wallet-token-of-blockchain,

bcnwlt'Fee

Description::
What are transaction fees, and what fees does Jaxx apply?
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH. This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself. Note that transactions that interact with a contract address will be more costly.

The same is true of Bitcoin - BTC fees applied go to the Bitcoin network. The difference is that the BTC fees applied are dynamic - they are subject to go up or down based on the state of the network. Jaxx lets you specify between three different fee options depending on whether your transaction is time-sensitive or not (as the lower fee may face a longer confirmation period).

As newer coins are implemented, each coin is subjected to their own transaction fee that goes to their respected networks.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]

Name::
* cpt.bcnwlt'fee,
* cpt.wallet-fee-of-blockchain,
* cpt.wallet-transaction-fee-of-blockchain,

Generic::
* Transaction-fee,

bcnwlt'Resource

AddressWpg::
* https://wallet.mycelium.com/index.html,
* http://www.walletrecoveryservices.com/
* http://www.coindesk.com/meet-man-will-hack-long-lost-bitcoin-wallet-money/

bcnwlt'Seed

Description::
This is the list of words that make up your private key
[https://docs.decred.org/getting-started/user-guides/windows/]

Name::
* cpt.bcnwlt'seed,

bcnwlt'Creating

bcnwlt'Backuping

bcnwlt'Deleting

SPECIFIC

Specific::
=== Specific-division.network:
* Bitcoin-wallet,
* Ethereum-wallet,
=== Specific-division.medium:
* Program-wallet,
* Brain-wallet,
* Paper-wallet,
* Hardware-wallet,
=== Specific-division.same-address:
* Static-wallet,
* StaticNo-wallet,
 - HD-wallet,
=== Specific-division.determinism:
* Deterministic-wallet,
* Deterministic.No-wallet,
=== Specific-division.online:
* Online-wallet,
 - Web-wallet,
* OnlineNo-wallet,
=== Specific-division.number-of-tokens:
* Mono-wallet,
* MonoNo-wallet,
=== INSTANCE:
* Jaxx-wallet,

bcnwlt.PROGRAM

Description::
Computer-program that manages the-keys of coins. Public-keys to receive coins and the corresponding private-keys to spend them.

Name::
* cpt.bcnwlt.program,
* cpt.program-wallet-of-blockchain,

AddressWpg::
* https://coinomi.com/ Free Secure Open-Source Multi-Coin HD Wallet for Bitcoin and Altcoins,

bcnwlt.BRAIN

Description::
The-storage of private-key, as a memorable phrase, in once brain.

Name::
* cpt.bcnwlt.brain,
* cpt.blockchain-brain-wallet,
* cpt.brain-wallet-of-blockchain,

Specific::
* bitcoin-brain-wallet,

bcnwlt.PAPER

Description::
The-storage of keys on paper.

Name::
* cpt.blockchain-paper-wallet,
* cpt.bcnwlt.paper,
* cpt.paper-wallet-of-blockchain,

bcnwlt.HARDWARE

Description::
Hardware-wallet is a-device, such as trezor, ledger etc, that stores the-keys of bcnevus.

Name::
* cpt.blockchain-hardware-wallet,
* cpt.bcnwlt.hardware,
* cpt.hardware-wallet-of-blockchain,

bcnwlt.STATIC

Description::
Static (non-HD) wallets stick to using a single address for all transactions.
While that's simpler, address reuse greatly undermines your privacy.
[https://decentral.zendesk.com/hc/en-us]

Name::
* cpt.bcnwlt.static,
* cpt.static-wallet-of-blockchain,

bcnwlt.STATIC.NO

Description::
A-wallet that changes the-addressess of the-transactions to improve privacy.
[hmnSgm.2017-05-12]

Name::
* cpt.staticNo-wallet-of-blockchain,

bcnwlt.HD

Description::
HD (or "hierarchical deterministic") wallets like Jaxx generate a new address every time funds are sent to the current address.
All addresses generated from the same wallet can be used to receive funds, and all funds sent to any of these addresses will show up in your Jaxx balance.
The balance you see on your main wallet screens represent the total sum between those addresses.
[https://decentral.zendesk.com/hc/en-us]

Name::
* cpt.HD-wallet-of-blockchain,
* cpt.hierarchical-deterministic-wallet,

bcnwlt.DETERMINISTIC

Description::
A deterministic wallet is a system of deriving keys from a single starting point known as a seed. The seed allows a user to easily back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key.
[https://en.bitcoin.it/wiki/Deterministic_wallet]

Name::
* cpt.bcnwlt.deterministic,
* cpt.deterministic-wallet-of-blockchain,

bcnwlt.ONLINE

AddressWpg::
* https://www.cryptonator.com/ Online cryptocurrency wallet
Free multi-cryptocurrency accounts with instant exchange

bcnwlt.WEB

Description::
A-web-wallet is A-WEBPAGE using javascript to manage addresses.
It can store your keys locally or online.
[hmnSgm.2017-04-03]

Name::
* cpt.bcnwlt.web,
* cpt.blockchain-web-wallet,

HolyTransaction (Luxembourg)

Description::
Universal Wallet
Access Bitcoin, Litecoin, Dogecoin, Peercoin, Dash, Ethereum, Decred, Zcash, Faircoin, Gamecoin, Gridcoin and Blackcoin from one unified interface. Easy and instantly, right from this website. No software downloads required.
[https://holytransaction.com/]

Name::
* cpt.HolyTransaction,

AddressWpg::
* https://holytransaction.com/

bcnwlt.MONO

Description::
Mono-wallet is a-wallet that stores ONE token.

Name::
* cpt.bcnwlt.mono,
* cpt.mono-wallet-of-blockchain,

bcnwlt.MONO.NO

Description::
Mono-wallet is a-wallet that stores MANY token.

Name::
* cpt.bcnwlt.mono,
* cpt.bcnwlt.multi,
* cpt.mono-wallet-of-blockchain,
* cpt.multi-wallet-of-blockchain,

bcnwlt.Jaxx (jaxwlt)

Description::
Your Blockchain Interface.
Bye-bye gatekeepers. With Jaxx, you have the keys to control the new digital world.
[https://jaxx.io/]

Name::
* cpt.jaxwlt,
* cpt.Jaxx-wallet,

jaxwlt'Exchange-value-unit

Description::
Jaxx currently supports:
Bitcoin
Ether
TheDAO
Dash (not available for iOS wallets)
Ethereum Classic
Augur REP
Litecoin
Zcash (not available for iOS wallets)
Rootstock Testnet (not available for iOS wallets)
[https://decentral.zendesk.com/hc/en-us]

jaxwlt'Fee

Description::
What are transaction fees, and what fees does Jaxx apply?
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH.
This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself.
Note that transactions that interact with a contract address will be more costly.

The same is true of Bitcoin - BTC fees applied go to the Bitcoin network. The difference is that the BTC fees applied are dynamic - they are subject to go up or down based on the state of the network. Jaxx lets you specify between three different fee options depending on whether your transaction is time-sensitive or not (as the lower fee may face a longer confirmation period).

As newer coins are implemented, each coin is subjected to their own transaction fee that goes to their respected networks.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]

jaxwlt'Doing

What can Jaxx do?
Jaxx can perform the following functions:

Send currencies to another currency address
Receive currency from another currency address
Manage your DAO Tokens
Convert between currencies through the in-app ShapeShift integration
Pair from or to another device's Jaxx wallet so that you can access that same wallet across all devices (mobile, desktop, tablet, or browser extension format)
Transfer funds from a paper wallet / private key, including encrypted paper wallets
Send to contract addresses
Use your device's camera to scan addresses in QR code form (mobile only) for sending and receiving bitcoin and ether, as well as pairing wallets and transferring funds from a paper wallet
Scan websites for valid addresses (browser extensions only)
Split ETH/ETC
[https://decentral.zendesk.com/hc/en-us]

jaxwlt'Updating

How do I update Jaxx on desktop? (iOS / Windows)
Please visit Jaxx.io to find and download the latest version of Jaxx. Please make sure you write down your 12-word Backup Phrase in the exact sequence prior to updating.
[https://decentral.zendesk.com/hc/en-us]

bcnnet'Problem (bcnpbm)

Name::
* cpt.bcnnet'problem,
* cpt.bcnpbm,
* cpt.blockchain-issue,
* cpt.blockchain-problem,

bcnpbm.Security

Description::
Bcnnet solved the-problem of information-security.
And this is THE-TRANSPARENCY.
All security-systems are-created by humans and other humans broke them.
Our history shows that.
Transparency destroys the-need for security.
[hmnSgm.2017-03-26]

Name::
* cpt.bcnnet'security,
* cpt.bcnscrt,
* cpt.bcnsecurity,
* cpt.blockchain-security,

bcnscrt'Consensus-algorithm (link)

bcnscrt'51-percent-attack

Name::
* cpt.bcnnet'51-percent-attack,

bcnscrt'Resource

Name::
* cpt.bcnnet'resource.security,
* cpt.bcnnet'security-resource,

AddressWpg::
* https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51,

bcnnet'Human (bcnhmn)

Name::
* cpt.bcnhmn,
* cpt.bcnnet'human,
* cpt.blockchain-human,

bcnhmn'Skill

Name::
* cpt.bcnhmn'skill,

AddressWpg::
* https://cointelegraph.com/news/what-blockchain-skills-are-in-high-demand-digital-headhunter,

SPECIFIC

Name::
* bcnhmn.specific,
* cpt.bcnhmn.specific,

Specific::
* dapp-user-human,
* developer-human,
* miner-human,
* user,
* wallet-user-human,

bcnhmn.DEVELOPER (bcnhmnDvr)

Name::
* cpt.bcnhmnDvr,
* cpt.bcnhmn.developer,
* cpt.bcnnet'developer,

bcnhmn.USER (bcnusr)

Description::
User is a-human who uses the-services of the-network.

Name::
* cpt.bcnhmn.user,
* cpt.bcnusr,
* cpt.blockchain-user,

bcnhmn.NODE-OPERATOR (bcnhmnNor)

Name::
* cpt.bcnhmnNor,
* cpt.bcnhmn.node-operator,
* cpt.bcnhmn.node-owner,
* cpt.bcnnet'node-operator,

bcnhmn.WALLET-USER

Name::
* cpt.bcnhmn.user,
* cpt.bcnnet'node-operator,
* cpt.bcnnet'user,

bcnnet'Organization (bcnogn)

Name::
* cpt.cryptocurrency-venture,
* cpt.bcnnet'ogn,
* cpt.bcnogn,
* cpt.blockchain-organization,

AddressWpg::
* http://cryptovalleyzug.net/links.html,

bcnogn'ICO

Description::
DEFINITION of 'Initial Coin Offering (ICO)'
An unregulated means by which funds are raised for a new cryptocurrency venture. An Initial Coin Offering (ICO) is used by startups to bypass the rigorous and regulated capital-raising process required by venture capitalists or banks. In an ICO campaign, a percentage of the cryptocurrency is sold to early backers of the project in exchange for legal tender or other cryptocurrencies, but usually for Bitcoin.

Also called an Initial Public Coin Offering (IPCO).

BREAKING DOWN 'Initial Coin Offering (ICO)'
When a cryptocurrency startup firm wants to raise money through an Initial Coin Offering (ICO), it usually creates a plan on a whitepaper which states what the project is about, what need(s) the project will fulfill upon completion, how much money is needed to undertake the venture, how much of the virtual tokens the pioneers of the project will keep for themselves, what type of money is accepted, and how long the ICO campaign will run for. During the ICO campaign, enthusiasts and supporters of the firm’s initiative buy some of the distributed cryptocoins with fiat or virtual currency. These coins are referred to as tokens and are similar to shares of a company sold to investors in an Initial Public Offering (IPO) transaction. If the money raised does not meet the minimum funds required by the firm, the money is returned to the backers and the ICO is deemed to be unsuccessful. If the funds requirements are met within the specified timeframe, the money raised is used to either initiate the new scheme or to complete it.

Early investors in the operation are usually motivated to buy the cryptocoins in the hope that the plan becomes successful after it launches which could translate to a higher cryptocoin value than what they purchased it for before the project was initiated. An example of a successful ICO project that was profitable to early investors is the smart contracts platform called Ethereum which has Ethers as its coin tokens. In 2014, the Ethereum project was announced and its ICO raised $18 million in Bitcoins or $0.40 per Ether. The project went live in 2015 and in 2016 had an ether value that went up as high as $14 with a market capitalization of over $1 billion.

ICOs are similar to IPOs and crowdfunding. Like IPOs, a stake of the startup or company is sold to raise money for the entity’s operations during an ICO operation. However, while IPOs deal with investors, ICOs deal with supporters that are keen to invest in a new project much like a crowdfunding event. But ICOs differ from crowdfunding in that the backers of the former are motivated by a prospective return in their investments, while the funds raised in the latter campaign are basically donations. For these reasons, ICOs are referred to as crowdsales.

Although there are successful ICO transactions on record and ICOs are poised to be disruptive innovative tools in the digital era, investors are cautioned to be wary as some ICO or crowdsale campaigns are actually fraudulent. Because these fund-raising operatives are not regulated by financial authorities such as the Securities Exchange Commission (SEC), funds that are lost due to fraudulent initiatives may never be recovered.

Read more: Initial Coin Offering (ICO) Definition | Investopedia http://www.investopedia.com/terms/i/initial-coin-offering-ico.asp#ixzz4WU1TYEkA
Follow us: Investopedia on Facebook

Name::
* cpt.bcnico,
* cpt.bcnogn'ICO,
* cpt.ICO,
* cpt.initial-coin-offering,

bcnogn.SPECIFIC

Specific::
* Exchange-ogn,
* Foundation-ogn,
* Merchant-ogn,
* Mining-pool-ogn,
* Wallet-ogn,
===
* Akasha International, Zug, www.akasha.world,
* Bitcoin Suisse AG, Baar, www.bitcoinsuisse.ch,
* Bitfinitum GmbH, Zug, www.bitfinitum.com,
* Blockchain Source, Zug, www.blockchainsource.ch,
* Crypto AG, Zug, www.crypto.ch,
* Cryptocash AG, Uster, www.cryptocash.ch,
* Ethereum Foundation, Baar, www.ethereum.org,
* IFZ Zug, www.ifz.ch,
* InfoGuard AG, Zug, www.infoguard.ch,
* iprotus, Walchwil, www.iprotus.ch,
* MME Legal, Zug, www.mme.ch,
* Monetas AG, Zug, www.monetas.net,
* Mount10, Baar, www.mount10.ch,
* Netmon GmbH, Zurich, www.netmon.ch,
* Patria Digitalis, Zug, www.pd.coop,
* Sapphire Innovation, Zug, www.sapphireinnovation.com,
* Shapeshift, Zug, shapeshift.io,
* Xapo GmbH, Zug, www.xapo.com,

bcnogn.EXCHANGE (bcnx)

Description::
Crypto-exchange is a-company that shells and buys benevu.
[hmnSgm.2017-05-09]

Name::
* cpt.bcnnet'exchange,
* cpt.bcnx, {2017-02-04}
* cpt.blockchain-exchange, {2017-05-13}
* cpt.blockchainX, {2017-02-04}
* cpt.crypto-exchange,
* cpt.exchange-ogn-of-blockchain-currencies,
* cpt.exchange-organization-of-blockchain-currencies,

bcnx'Fee

Specific::
* Lykke    0
* Bittrex  0.25%
* Cashilla 1% plus 1€ for fiat deposit.

bcnx'Blockchain-token

Description::
The different bcnevu an-exchange offers.

Name::
* cpt.blockchain-exchange-token,

bcnx.SPECIFIC

Specific::
* BitPay-exchange,
* BitStamp-exchange,
* Blockchain-exchange,
* Changenlly-exchange,
* Coinbase-exchange,
* Kraken-exchange,
* LakeBTC-exchange,
* Liqui-exchange,
* LiteBit-exchange,
* Poloniex-exchange,
* QuadrigaCX-exchange,
* ShapShift-exchange,

bcnx.BitPay {2011}

Description::
BitPay was founded in 2011, while Bitcoin was still in its infancy. We saw the potential for bitcoin to revolutionize the financial industry, making payments faster, more secure, and less expensive on a global scale.

We started BitPay with the intention of making it easy for businesses to accept bitcoin payments, and we are currently the largest bitcoin payment processor in the world, serving more than 60,000 merchants on six continents.

Payment processing was our first contribution to the Bitcoin ecosystem, but it is not our last. We're building open source software to power the next applications of Bitcoin. Bitcoin's future looks very bright, and we plan on remaining on the forefront of this technology, creating more tools and services for everyone to use in innovative new ways.
[https://bitpay.com/about]

Name::
* cpt.BitPay,
* cpt.ognBtcsvc.BitPay

bitpay'Card

How works:
1.Order
Order your card for $9.95. Once your ID has been verified, your card will arrive within 7-10 business days.
2.Activate
When your card arrives in the mail, activate the card at bitpay.com/card/activate and create a cardholder account.
3.Load
Load your card with dollars using any bitcoin wallet, or via direct deposit through your employer.
4.Spend
Spend dollars anywhere Visa® debit cards are accepted, or withdraw cash from any Visa®-compatible ATM.
[https://bitpay.com/card]

bcnx.Bitstamp (3rd - EU)

Description::
Bitstamp is a European Union based bitcoin marketplace. It allows people from all around the world to safely buy and sell bitcoins.
ARE YOU SELLING BITCOINS?
No. We are providing a service. You are always buying bitcoins from another individual, who is selling them. All we do is provide a safe and simple environment to trade. We guarantee that buyers get their bitcoins and sellers get their money at agreed price.
[https://www.bitstamp.net/faq/]
===
This morning, Bitstamp announced that it has received a license from the Luxembourg Ministry of Finance to operate as a payment institution, and according to the company, this license applies to the European Union as a whole. “With this,” says Dan Morehead, the chairman of Bitstamp and the CEO of Pantera Capital, a firm that specializes in investments related to bitcoin, “Bitstamp is able to do business in all 28 countries of the EU.”
... FIFTEEN MONTHS AGO, hackers lifted more than $5 million from the bitcoin exchange operated by Bitstamp, a Slovenian company that aspired to push the digital currency across Western Europe. The hack wasn’t nearly as large or as devastating as the one that pilfered $460 million from Mt. Gox and sent the Japan-based exchange, then one of the world’s largest, spiraling into bankruptcy. But it was yet another black eye for bitcoin, the digital currency that holds so much promise as an alternative to fiat currencies but has never really broken into the mainstream.
[http://www.wired.com/2016/04/bitcoin-exchange-receives-approval-operate-across-eu/?mbid=social_twitter]

Name::
* cpt.Bitstamp-ogn,
* cpt.bitstamp,
* cpt.ognBtcsvc.Bitstamp,

Generic::
* blockchain-exchange,

AddressWpg::
* https://www.bitstamp.net/

bitstamp'office

OFFICES
UNITED KINGDOM
Bitstamp Ltd.
5 New Street Square
London EC4A 3TW
United Kingdom

LUXEMBOURG
Bitstamp Europe S.A.
10 rue Antoine Jans
L-1820 Luxembourg
Luxembourg

UNITED STATES
Bitstamp USA Inc.
2930 Magnolia Street
Berkeley, CA 94705
United States
[https://www.bitstamp.net/about_us/]

bcnx.Blockhain {2011}

Description::
Blockchain is the world’s most popular Bitcoin wallet. It is often confused with the core innovation that Bitcoin introduced. Founded in 2011, the company is one of the oldest and biggest Bitcoin’s companies.
Experiencing a rapid expansion in the last few years, the company has passed 6.7 million users, and the amount of wallets created on the platform is constantly increasing.
[http://cointelegraph.com/news/our-goal-is-to-replace-your-need-for-a-bank-says-blockchain-co-founder-and-ceo-nicolas-cary]
===
Blockchain is the world’s most popular Bitcoin wallet, and home to the most widely used Bitcoin APIs and trusted block explorer and search engine. It is recognized as the strongest, most trusted brand in Bitcoin.
[https://blockchain.com/about/]

Name::
* cpt.ognBlockchain,
* cpt.ognBlockchain,
* cpt.blockchain-service,
* cpt.ognBtcsvc.Blockhain,

bcnx.Changenlly-exchange {2016}

Description::
Changelly, an automated cryptocurrency exchange and a relatively new player on the market of cryptocurrency exchanges, made its services available to its users in April 2016 after six months of a successful beta.
[https://cointelegraph.com/news/with-charlie-shrem-as-advisor-shangelly-is-set-to-outperform-shapeshift]
===
https://cointelegraph.com/news/with-charlie-shrem-as-advisor-shangelly-is-set-to-outperform-shapeshift
[https://changelly.com/]
===
Changelly launched in 2013 as an instant exchange app, similar to the well-known ShapeShift. Rather than being a traditional exchange that requires users register before trading against an order book, with variable depth and the problems of slippage that can result, it aggregates rates from the largest trading platforms and offers a single rate. The commission is just 0.5%. By fundamentally rethinking the way cryptocurrencies are exchanged, Changelly aims to remove technical impediments to customers engaging with this critical element of the cryptocurrency world’s infrastructure.
[https://blog.chronobank.io/chronobank-makes-a-strategic-partnership-with-instant-exchange-service-changelly-b4fa39ca243e]

Name::
* cpt.bcnnet'Changenlly,
* cpt.ognChangenlly,

ognChangelly'Fee

Description::
Fair
Other cryptocurrency trading services charge you with withdrawal fees and commissions. We have a reasonable fee of 0.5%.
[https://changelly.com/]

ognChangelly'Exchange-rate-chart

2017-01-30:
1 BTC = 023.69664034 ZEC, {2017-01-30}
1 BTC = 057.98876409 DASH, {2017-01-30}
1 BTC = 072.59264636 XMR, {2017-01-30}
1 BTC = 087.7577885 ETH, {2017-01-30}
1 BTC = 219.63516402 REP, {2017-01-30}
1 BTC = 237.42056798 LTC, {2017-01-30}
1 BTC = 262.5505738 FCT, {2017-01-30}
1 BTC = 706.47412891 ETC, {2017-01-30}
1 BTC = 914.12273926 SBD, {2017-01-30}
1 BTC = 919.07541013 NBT, {2017-01-30}
1 BTC = 002,186.00736684 RADS, {2017-01-30}
1 BTC = 003,086.5626495 EXP, {2017-01-30}
1 BTC = 005,702.06699928 STEEM, {2017-01-30}
1 BTC = 005,749.10888812 LSK, {2017-01-30}
1 BTC = 006,724.72344574 MAID, {2017-01-30}
1 BTC = 007,403.29446603 AEON, {2017-01-30}
1 BTC = 008,836.26402756 STRAT, {2017-01-30}
1 BTC = 018,537.39920289 AMP, {2017-01-30}
1 BTC = 021,466.13716861 NAV, {2017-01-30}
1 BTC = 028,985.50724637 FCN, {2017-01-30}
1 BTC = 030,688.96731624 LBC, {2017-01-30}
1 BTC = 034,387.89546079 NLG, {2017-01-30}
1 BTC = 046,019.3281178 ARDR, {2017-01-30}
1 BTC = 144,927.53623188 NXT, {2017-01-30}
1 BTC = 146,735.14306676 XRP, {2017-01-30}
1 BTC = 179,856.11510791 XEM, {2017-01-30}
1 BTC = 222,222.22222222 QCN, {2017-01-30}
1 BTC = 257,367.13421696 DSH, {2017-01-30}

1 BTC = 04,444,444.44444444 DOGE, {2017-01-30}
1 BTC = 10,822,510.82251082 XDN, {2017-01-30}
1 BTC = 15,797,788.30963665 BCN, {2017-01-30}

bcnx.Coinbase (USA {2012})

Description::
Founded in June of 2012, Coinbase is a bitcoin wallet and platform where merchants and consumers can transact with the new digital currency bitcoin. We're based in San Francisco, California.
Bitcoin is the world's most widely used alternative currency with a total market cap of approximately $5.3 billion. The bitcoin network is made up of thousands of computers run by individuals all over the world.
[https://www.coinbase.com/about?locale=en]
===
Bitcoin, made simple.
Coinbase is an international digital wallet that allows you to securely buy, use, and accept bitcoin currency ›
[https://coinbase.com/]

Name::
* cpt.coinbase,
* cpt.ognBtcsvc.Coinbase

AddressWpg::
* https://coinbase.com/

coinbase'Exchange

Description::
Coinbase Exchange is the leading platform to trade bitcoin.
[https://exchange.coinbase.com/]

coinbase'API

AddressWpg::
* https://docs.exchange.coinbase.com/?javascript#introduction,

coinbase.EVOLUTING

{time.2015}:
Coinbase opens bitcoin exchange in UK
Company targets British enthusiasm for digital currency as it eyes an international expansion
[Financial Times Briefing 2015-04-29]

bcnx.Kraken-exchange (USA {2011})

Description::
KRAKEN BITCOIN EXCHANGE PUTS YOU FIRST
Founded in 2011, San Francisco-based Kraken is the largest Bitcoin exchange in euro volume and liquidity and also trading Canadian dollars, US dollars, British pounds and Japanese yen. Kraken is consistently rated the best and most secure Bitcoin exchange by independent news media. Kraken was the first Bitcoin exchange to have trading price and volume displayed on the Bloomberg Terminal, the first to pass a cryptographically verifiable proof-of-reserves audit, and is a partner in the first cryptocurrency bank. Kraken is trusted by hundreds of thousands of traders, the Tokyo government's court-appointed trustee, and Germany's BaFin regulated Fidor Bank.
[https://www.kraken.com/en-us/about]

Name::
* cpt.LiteBit,
* cpt.LiteBit-exchange,

bcnx.LakeBTC (CHINA)

Description::
Location Addr: Suite 613, 231-1 Ludi Avenue, Kunshan, Jiangsu, China
[https://en.bitcoin.it/wiki/LakeBTC]
===
LakeBTC project was started in early 2013 as a virtual bitcoin exchange initially for traders and other financial professionals interested in cryptocurrencies and blockchain technology. Later that year, the exchange was incorporated and operated under the current domain name. Today, LakeBTC stands for Lake Banking Technology Company.
With years of experience trading treasuries, agency bonds, currencies, commodities, interest rates, volatilities and all types of derivatives and structured products, LakeBTC is dedicated to building a bitcoin platform for pricing, liquidity, security, derivatives and indexes. On LakeBTC, individuals, merchants and institutions can easily trade bitcoins, lock down the prices, manage their exposures, and hedge their risks.
Today, as cryptocurrencies gained more and more exposures to the general public, LakeBTC is becoming one of the best bitcoin platforms around the globe. Our years of risk management and internal control experience in financial industries build the most solid foundation for ensuring customers' fund and privacy being safe and secure. LakeBTC is one of the Big Four exchanges in the world that determinesCoinDesk Bitcoin Price Index (BPI).
[https://www.lakebtc.com/s/about]

Name::
* cpt.LakeBTC,

AddressWpg::
* https://www.lakebtc.com/

lakebtc'security

Description::
Our years of risk management and internal control experience in financial industries build the most solid foundation for ensuring customers' fund and privacy being safe and secure.

To protect your fund, we implemented a number of rigorous mechanisms including SSL encryption, cold storage, 2-step verification, SMS withdrawal confirmation, trade notifications and so on.

High availability and fast trade matches, even under enormouse amount of load, are two attributes that are critical to high liquidity and make us stand out in the crowd.

Besides, we also provide highly-secure market data and trading API's for advanced users who prefer arbitrages, market making, or alogrithm trading.
[https://www.lakebtc.com/]

bcnx.Liqui ({2016})

Description::
Liqui is the latest exchange to add ChronoBank’s TIME token. The exchange launched on 1 September 2016, and is still a relatively new but fast-growing entrant to the cryptocurrency world. Its team of seven are located in various countries and jurisdictions around the world, and in a short period of time have managed to build a strong business that has gained the trust of an increasing number of traders thanks to its user-friendly interface, commitment to user support and rapid listing of some of the most popular and promising Ethereum-based tokens?—?including Iconomi, Golem and Wings.
One of Liqui’s unique features is its deposit accounts that allow users to earn annual interest of 24% for BTC and ETH, within a fixed limit. The exchange’s trading API has recently been implemented, and in the near future a Tether (USDT) market is expected. Liqui has established a reputation for pro-active cooperation with leading market-makers and businesses within the cryptocurrency industry.
[https://blog.chronobank.io/chronobank-announced-partnership-with-liqui-exchange-652140c46d84]

Name::
* cpt.Liqui-exchange,

bcnx.LiteBit-exchange (Netherlands {2013})

Description::
LiteBit is a young innovative company established in Zoetermeer, The Netherlands. LiteBit exists now more than two year and we, as a team, are very proud of that! LiteBit ensures that you and others can buy & sell bitcoins easily, safely and quickly. All our employees work accurately with a aim for the customer. We provide all kinds of services to make your life with crypto currency easier, quicker and more efficient. Did you try out our price alerts for bitcoin or any other crypto currency? It’s free!
Besides LiteBit we develop new applications that are using Blockchain Technology. We are also known as 2525 Ventures B.V.
Kenny Rokven
CEO
“I started LiteBit on 7th of december in 2013. I am responsible for all general business of LiteBit. ”
[https://www.litebit.eu/en/about]

Name::
* cpt.LiteBit,
* cpt.LiteBit-exchange,

bcnx.Lykke-exchange (lkx Swiss)

Description::
What is Lykke?
Lykke is a movement to build one global marketplace that is a level playing field where everyone has access.
We start with foreign exchange and expand to equities, fixed income, commodities and other asset classes.
Lykke Corp is incorporated in Switzerland and issued it's shares on the blockchain (Lykke Coins).
[https://lykke.com/city/faq]

Name::
* cpt.Lykke,
* cpt.Lykke-exchange,
* cpt.Lykke-exchange-ogn,
===
Why did we choose the name Lykke?
Lykke was the surname of Richard's grandmother on his father's side. The word means luck and happiness. His father explained to them that they are Lykke.
[https://lykke.com/city/faq]

lkx'Fee

Description::
What is the business-model?

Commissions & fees at Lykke Wallet are essentially zero. Lykke will make money on providing liquidity, issuance services and consulting.
[https://lykke.com/city/faq]

lkx'Blockchain

lkx'Block-Explorer

Name::
* cpt.Lykke-block-explorer,
* cpt.Lykke-explorer,
* cpt.lkxblk'explorer,
* cpt.lkxnet'explorer,
* cpt.lkxblkexr,

AddressWpg::
* https://blockchainexplorer.lykke.com/

lkx'Exchange-Value-Unit

Name::
* cpt.Lykke-asset,
* cpt.Lykke-evu,
* cpt.Lykke-token,

AddressWpg::
* https://blockchainexplorer.lykke.com/assets,

lkx'Lykke-coin

Description::
What is a Lykke coin?
A Lykke coin is a colored coin that is issued by Lykke Corp.
One Lykke colored coin is 0.01 (one one-hundredth) of one share of Lykke Corp. 100 Lykke colored coins are one share of Lykke Corp.
Lykke Corp has committed 2.5 Mio Lykke Corp shares (20% of Lykke's capital) for issuance as Lykke colored coins, which means that a total of 250 Mio Lykke colored coins will be outstanding.
Lykke Corp makes a market for its coins so that citizens can sell their coins and cash out.
See Lykke Coinprism Metadata
[https://lykke.com/city/faq]

What's the total supply of Lykke coins?
Total number of Lykke Coins issued is 1,285,690,000. The ownership structure is stored on the blockchain: https://www.coinprism.info/asset/AXkedGbAH1XGDpAypVzA5eyjegX4FaCnvM/owners
[https://lykke.com/city/faq]

lkx'Resource

AddressWpg::
* http://lykke.world/

bcnx.Poloniex-exchange (USA)

Description::
WELCOME TO POLONIEX
We are a US-based cryptocurrency exchange offering maximum security and advanced trading features.
[https://poloniex.com/]

Name::
* cpt.Poloniex-exchange,
* cpt.Poloniex-exchange-ogn,

bcnx.QuadrigaCX (Canada)

Description::
Quadriga CX is a Canadian Cryptocurrency exchange platform, with offices in Vancouver, BC. Our goal is to provide an easy to use platform to simplify the process of buying and selling Bitcoins.
[https://www.quadrigacx.com/about]

Name::
* cpt.ognBtcsvc.QuadrigaCX,

bcnx.ShapeShift

Description::
ShapeShift is a new piece of infrastructure in Bitcoinland. It is how digital currency exchange should work. From start to finish you can change currencies in under ten seconds, no account required.
...
Let's assume you have Bitcoin and you want Litecoin. It goes like this:
1. Select Bitcoin as the input and Litecoin as the output
2. Provide your Litecoin address in the box, then click the Start button
3. ShapeShift will generate a BTC deposit address for you. Please send your BTCs to this generated address. (Don't send more than the Deposit Limit).
That's it. In a few moments, your Litecoin will be sent to you.
No emails or passwords. No lengthy sign­up process. No accounts. No bid and ask orders. No friction.
[https://info.shapeshift.io/about]

Name::
* cpt.ShapeShift-ogn,
* cpt.ShapeShift,

AddressWpg::
* https://shapeshift.io/#/coins,

Exchange-rate

What exchange rate do you use?
Jon April 05, 2016 22:12
The exchange rate is our own, derived from several market sources and based on the amount we feel comfortable exchanging at that fixed rate (whether you do small or large order, the rate stays the same - no slippage).
We earn a profit to the extent we can source coins in other markets for a lower cost to replenish our reserves.
[https://shapeshift.zendesk.com/hc/en-us/articles/202585612-What-exchange-rate-do-you-use-]

Fee

What’s your fee structure?
January 08, 2017 11:04
ShapeShift does not charge a per exchange fee, while our exchange rates depend on the depth and spread of particular coin pairs and markets.
This means the amount that ShapeShift makes on any particular transaction varies based on current market conditions.
Depending on the liquidity and spread of a particular coin/coin pair, ShapeShift's spread usually falls in the range of about 0.5-1% or so.
[https://shapeshift.zendesk.com/hc/en-us/articles/202585602-What-s-your-fee-structure-]

bcnogn.MERCHANT

Description::
Wholesaler or retailer who may buy goods from any or all sources for resale to anyone and everyone for profit, using bitcoins.

Name::
* cpt.bcnogn.merchant,

bcnogn.Chain.com

Description::
The Chain Platform
Our solutions enable institutions to design, deploy, and operate blockchain networks that can power any type of asset in any market.
[http://chain.com/]

Name::
* cpt.chain.com,

bcnogn.Coin-Center

Coin Center, the industry’s leading public policy research and advocacy center.
[http://www.coindesk.com/events/consensus-2016/]

Name::
* cpt.Coin-Center,

bcnogn.CoinDesk

Description::
CoinDesk is the world leader in news and information on digital currencies such as bitcoin, and its underlying technology – the blockchain.

We cover news and analysis on the trends, price movements, technologies, companies and people in the bitcoin and digital currency world.

Our per-minute Bitcoin Price Index, a derived measure of bitcoin's value based on an agreed set of criteria, also serves as a point of reference for those involved in the bitcoin industry.

If you're new to bitcoin, read our straightforward guides on the basics of what bitcoin is, why people use it, where to buy bitcoins and how to spend them. We also explain the basics of bitcoin mining, how to set up a bitcoin miner, and how bitcoin transactions work.

Digital currency is a rapidly evolving industry and we believe one of the biggest developments in internet history in the making.

There are bitcoin exchanges, merchants accepting and promoting bitcoin, investors, traders, startups and developers all contributing to the ecosystem. There are also regulatory bodies all over the world trying to understand more about bitcoin, take a stance on it and assign guidelines to companies trading in or otherwise involved with bitcoin.

We strive to cover news accurately, fairly, objectively and responsibly. Obtaining original comment, corroborating information from other sources, and showcasing original opinion are fundamental to this. View our editorial policy here.

CoinDesk is an independent publication with reporters all over the world. If you're interested in writing for us, whether as a freelancer or occasional contributor, get in touch or check out our Jobs page.

If you have a question or a story, send us a tip. Contact us for anything else.
[http://www.coindesk.com/about-us/]

Name::
* cpt.CoinDesk,

bcnogn.Digital-Currency-Group

Description::
Digital Currency Group (DCG), the blockchain industry’s most active investor
[http://www.coindesk.com/events/consensus-2016/]

Name::
* cpt.DCG,

bcnogn.GBBC

Description::
Expanding Blockchain Technology Around the World
The Global Blockchain Business Council (GBBC) brings together the world’s leading businesses and business leaders to highlight the latest innovations and advances in Blockchain technology.
The GBBC is committed to fostering partnerships, raising awareness of the potential of this groundbreaking technology and providing a forum for education, collaboration and partnership.
[http://www.gbbcouncil.org/]
===
By Alicia Naumoff {2017-01-22}
The Blockchain Council Announced in Davos That Bitcoin Price Will Grow as Trump Takes Office
The Bitfury Group that develops Bitcoin mining hardware and operates mining farms has announced that in collaboration with the international law firm Covington it has launched the Global Blockchain Business Council (GBBC).

The announcement was made at the event held alongside the World Economic Forum’s annual meeting in Davos.

It happened just before the new United States President Donald Trump sent jitters down the spine of the world’s political and financial elite announcing at his inauguration: “From this day forward, a new vision will govern our land.” Trump has promised the American people “challenges” and “hardships” on the way of “getting the job done.” The price of Bitcoin took a cue from that message and immediately shot forward.

Top heads sighted

A number of technology, banking and financial experts and thought leaders were spotted at the Davos event where the Blockchain council has been created. They include former Swedish Prime Minister and senior advisor at Covington Carl Bildt, former Estonian President Toomas Hendrik, Dr. Wei Wang, founding chairman of China Mergers & Acquisitions (CMAA), and Don Tapscott the author of the best-seller “Blockchain Revolution”, just to name a few.

The Bitfury Group is a global team of experts in technology, business, communications, security and civil society, who are all big believers in the potential of Blockchain to open new doors for global economic opportunity and prosperity.

The main idea behind the Council is to bring together leading businesses, executives and government authorities to collaborate driving forward development and adoption of Blockchain technology around the globe.

A resource center and an educational forum

Valery Vavilov, the CEO of Bitfury Group, described the newly established Council as “a much-needed forum for businesses, innovators and technologists” to join forces and facilitate the advancement of Blockchain technology.

The GBBC will fulfill the role of a resource center and an educational forum to foster collaboration and partnerships across industries. It will assist companies by raising awareness of the potential of Blockchain technology and help engaging businesses interested in developing within the Blockchain space.

Covington brings to the table its broad-based experience in advising their clients in connection with policies, regulation litigation, enforcement and investigation, privacy and data security, consumer protection and transactional matters related to distributed ledger technology.

Sebastian Vos, Co-Chair of Covington’s global public policy and government affairs practice, said:

“Through advocacy and international engagement, Covington looks forward to working with the Global Blockchain Business Council to unlock the potential of Blockchain technology.”

Blockchain revolution

We saw how the Internet revolutionized many industries. We are now witnessing Blockchain technology steadily changing our approach to commerce, communications, financial services, entertainment industries, and many other spheres.

A lot has been said about the beauty of this technology and how it allows for any asset to be digitized, transferred and recorded on transparent and extremely secure ledgers.

Blockchain is marching across industries sweeping away slow, expensive and hackable intermediaries. When talking about the ways to facilitate this process, many experts often emphasize the need to increase collaboration between businesses and government authorities. Well, some are moving from words to deeds.

To learn more about the Global Blockchain Business Council please visit www.gbbcouncil.org.
[https://cointelegraph.com/news/the-blockchain-council-announced-in-davos-that-bitcoin-price-will-grow-as-trump-takes-office]

Name::
* cpt.GBBC,
* cpt.Global-Blockchain-Business-Council,

bcnogn.Guardtime

Description::
About Guardtime
Who we are
We are a team of over 100 cryptographers, network architects, hardware engineers, software developers and security architects, with decades of experience building cybersecurity solutions for enterprise, financial, telecommunications service providers, and military customers among others.

In 2007 we invented Keyless Signature Infrastructure, the first and only blockchain platform for ensuring the integrity of systems, networks and data at industrial scale.

What we do
We build products using our technology that solve problems no one else can solve. Examples include Anti-Tamper hardware designed to resist nation-state reverse engineering, a quantum-immune replacement for RSA digital signatures, cryptographic provenance tracking for software and IOT life cycles, insider threat mitigation and deterministic data loss prevention.

What we believe
We believe that integrity must be the basis for building reliable, resilient and secure systems. For the last 40 years security has come to mean confidentiality and encryption. Integrity has largely been forgotten, primarily because there hasn't been the tools to address it. Our contrarian view is that confidentiality is what you get when your systems have integrity.

If you can guarantee integrity (of systems, of processes, of supply chains) then you can guarantee the absence of compromise and replace a security strategy based on hope (that your security is working) with one based on mathematical certainty.

Office locations

Amsterdam
The Netherlands
Pinnacle Tower, Rapenburgerstraat 177/S,
1011 VM Amsterdam,
The Netherlands

Irvine, CA
United States
5151 California Ave,
Irvine, CA 92617,
United States

Tallinn
Estonia
A. H. Tammsaare tee 60,
Tallinn, 11316,
Estonia

Tartu
Estonia
Kόόni 5b,
Tartu, 51004,
Estonia

Please e-mail us at info@guardtime.com

For press inquiries: pr@guardtime.com and +1 (415) 625-8555
[https://guardtime.com/about]

Name::
* cpt.guardtime,

bcnogn.HyperLedger-Project (hlp)

Description::
The Hyperledger Project is a collaborative effort created to advance blockchain technology by identifying and addressing important features for a cross-industry open standard for distributed ledgers that can transform the way business transactions are conducted globally. The Project is a Linux Foundation Collaborative Project and implements many open source best practices familiar to other leading projects.

To facilitate an open ecosystem, the Hyperledger Project was structured with an open governance model.

The Technical Steering Committee (TSC) will provide leadership regarding the technical direction of the Hyperledger Project.
The Board of Directors will manage business leadership for the Hyperledger Project including governance, marketing and operational decisions.
For more information on the Hyperledger Project's Governance Model, IP Policy, Antitrust Guidelines, and other operational aspects, please read the Hyperledger Project Charter
[https://www.hyperledger.org/about]

Name::
* cpt.bcnogn.hyperledger,
* cpt.HLP,
* cpt.hyperLedger-project,

AddressWpg::
* https://www.hyperledger.org/
* {2017-04-18} https://cointelegraph.com/news/permissible-smart-contr...tion-with-ethereum,

hlp'Project

hlppjt'Ligecycle

AddressWpg::
* https://wiki.hyperledger.org/community/project-lifecycle,

Project Lifecycle
The term “project” within the Hyperledger Project will refer to a collaborative endeavor to deliver a work item. There may be some projects that are intended to produce a document, such as a requirements or use cases document, a whitepaper, or analysis. Others may be to develop a new capability, or refactor (or remove) an existing capability for the Hyperledger technology releases. Such projects may take the form of a new component (e.g. a new repository) or may propose additions, deletions or changes to an existing repository(s).

Many other open source initiatives leverage an incubation process for new work items, and this seems to have a desired effect of encouraging new ideas and tracks of work, while at the same time providing clear guidance to the broader community as to what is real and supported, versus what is still in the exploratory/experimental/developmental phases.

Therefore the Hyperledger Project has adopted a similar lifecycle process as follows:
Projects are in one of five possible states:
Proposal
Incubation
Active
Deprecated
End of Life
Projects may not necessarily move through those states in a linear way and may go through several iterations.

Proposal

Project Proposals shall be submitted to the TSC for review, using a Proposal Template. Proposals that are approved shall enter into an Incubation state, unless they are of a refactoring nature, in which case they will be turned over to the relevant project maintainer(s) to handle as they deem fit.

A Proposal must:

have a clear description
have a well-defined scope
identify committed development resources
identify initial maintainers
be vendor neutral
Incubation

Approved project proposals enter into Incubation. For new components/modules, a repository will be created under the hyperledger Github org, and optionally under Gerrit and JIRA, if requested. New features/capabilities should be handled through pull requests labeled with tags that identify the project and tag it as “incubator” (and will ideally be capable of being enabled/disabled with feature-flags).

Projects in Incubation may overlap with one another. Entering Incubation is meant to be fairly easy to allow for community exploration of different ideas.

Once a project qualifies to be declared Active, the project’s maintainers can then vote to request a graduation review by the TSC.

Projects seeking to graduate from Incubation must:

have fully functional code base
have test coverage commensurate with other Active projects
have an active and diverse community of developers
have a history of releases that follow the Active release process
Entering Incubation does not guarantee that the project will eventually get to Active state. Projects may never get to Active state.

The criteria to exit Incubation are defined in the Incubation Exit Criteria document.

Active

Projects that have successfully exited the Incubation phase are in the Active phase.

Anyone may propose that a project be deprecated, by submitting a rationale and identifying a substitute project/component (if any). The maintainers of the project shall vote on such a request and if it passes, make that recommendation to the TSC. Members of the community that disagree with the request shall make their case before the TSC. The TSC shall consider all points of view and render a final decision to deprecate or not.

Deprecated

A Deprecated project will be maintained for a six month period by its community, after which it will be removed from any subsequent formal releases. Notice will be given to the public of the project’s deprecation. After the six-month deprecation period, the project will be labeled End of Life.

End of Life

A project that is no longer actively developed or maintained.

bcnnet'Evaluation

Name::
* cpt.bcneln,
* cpt.bcnevaluation,
* cpt.bcnnet'evaluation,
* cpt.blockchain-evaluation,

Evaluation::
Throughout all the years I’ve been working as a software engineer, there has never been a technology breakthrough that I thought had more potential to change people’s lives for the better than Bitcoin.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]

Evaluation::
“Wherever trust is a problem, blockchain can be a solution.”
- Amanda Gutterman
[https://cointelegraph.com/news/podcast-amanda-gutterman-innovators-lab]

Evaluation::
Blockchain Features
Blockchains have the following properties.
Undeletable
The data that is on the blockchain will exist as long as there is some node in the network still operating. Once data has been put in a block, it can never be removed.
Unmodifiable
Using public-private key cryptography, all data are verifiably signed and cannot be modified by a third party.
No Downtime
Using the blockchain, zero downtime systems can finally be realized.
Advanced Features for the Blockchain
Mijin is not only a simple platform for creating points or custom currencies, but will have many advanced features.
Support for Multiple Assets
Unlike Bitcoin that has only a single digital asset, Mijin supports any arbitrary asset, allowing you to freely create and manage all your assets. We call these.
Support for Multi-signature Accounts
Mijin supports m-of-n multi-signature accounts at the platform level. You can designate multiple signatory accounts that need to sign off on transactions from an account. This can be useful for managing departmental budgets for companies or governments.
Smart Contract Support
Mijin will allow for powerful computational contracts and programs to be run in a decentralized and verifiable manner.
[http://mijin.io/en/about-mijin]

Evaluation::
Over a year ago, Marc Andreessen, the doyen of Silicon Valley’s venture capitalists, listed the blockchain’s distributed consensus model as the most important invention since the Internet itself.
[http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care/]

Evaluation::
This is why blockchain technology is so exciting – it is not just about an incremental improvement in utility e.g. escrow smart contracts, it is not just about dramatically lowering the cost of setting up a trusted business, see the Great Unbundle blog, it is also about the ability to quickly and cheaply experiment with new money creation models.
[https://www.linkedin.com/pulse/crypto-20-musings-bitcoin-money-creation-alex-batlin?]

Evaluation::
Blockchain technology allows the elimination of any centralized point of failure, storing all the platform data on all system nodes in a distributed fashion.
[http://wavesplatform.com/]

bcnnet'Law (bcnlaw)

Description::
A-bcnnet to exist must-issue money-(cryptocurrency).
Since {1971} money is-backed by thin-air and controlled by governments and financial-institutions.
This destroyed the-link (the-invisible-hand) of money with real-economy and was one of the-reasons that drived the-world into the-2008-global-cirisis.
Bcnnets decentralize the-control of money.
Obviously there-is a-conflict between the-usefulness-of-bcnnets and the-control of money by governments and financial-institutions.
That's why the-law on cryptocurrencies varies substantially from country to country and is still UNDEFINDED or CHANGING in many of them [wikipedia].
[hmnSgm.2017-03-26]

Name::
* cpt.bcnlaw,
* cpt.bcnnet'law,
* cpt.blockchain-law,
* cpt.law-of-blockchain,

bcnnet'Relation-to-other-computer-systems

Description::
To grasp the potential that applications built on top of blockchains can deliver, it is essential to understand the three key differences between blockchains and most existing computer designs.
We present these below as non-localization, security, and auditability.
[https://www.provenance.org/whitepaper]

Name::
* cpt.blockchain-relation-to-other-computer-systems,

bcnnet'Conference

Name::
* cpt.bcncfc,
* cpt.bcnnet'conference,
* cpt.bcnnet'event,
* cpt.blockchain-conference,
* cpt.conference-of-blockchain,

{time.2016-05-02-04} CONSENSUS-2016

CONSENSUS 2016
CoinDesk is proud to present its 2nd annual blockchain technology summit, Consensus 2016, in collaboration with Digital Currency Group (DCG), the blockchain industry’s most active investor, and Coin Center, the industry’s leading public policy research and advocacy center. The multi-day event will define what is “real” in blockchain technology and focus on how to mainstream real-world applications for consumers and enterprises alike. This May 2-4, professionals from leading industry startups, investment firms, financial services institutions, academic and policy groups will congregate at the New York Marriott Marquis for Consensus 2016.
[http://www.coindesk.com/events/consensus-2016/]

{time.2015} CONSENSUS-2015

CONSENSUS 2015
Consensus 2015, CoinDesk's inaugural summit on digital currencies and blockchain tech brought together more than 600 professionals from the tech, finance, and investment sectors – organizations such as Citi, PayPal, Wells Fargo, IBM and more. Experts, innovators, and executives across multiple sectors convened to explore the digital currency economy in-depth.
[http://www.coindesk.com/events/consensus-2016/]

bcnnet'Resource (bcnrsc)

Name::
* cpt.bcnnet'resource,
* cpt.bcnrsc,
* cpt.blockchain-resource,
* cpt.resource-of-blockchain,

AddressWpg::
* {2016-07-27} Vitalik Buterin: https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy/,
* {2016-06-22} http://cointelegraph.com/news/bitcoin-is-potential-national-threat-says-us-regulator,
* {2016-04-07} http://www.wsj.com/articles/ bitcoins-blockchain-technology-proves-itself-in-wall-street-test-1460021421,
* {2016-03-04} Jeff John Roberts: The Crisis in Bitcoin and the Rise of Blockchain
http://fortune.com/2016/03/04/crisis-in-bitcoin-rise-of-blockchain/
* https://www.weforum.org/agenda/2016/03/ could-blockchain-technology-make-big-banks-a-thing-of-the-past/
* https://www.weforum.org/agenda/2016/03/could-blockchain-technology-help-the-worlds-poor,
* http://recode.net/2015/07/05/forget-bitcoin-what-is-the-blockchain-and-why-should-you-care/
* http://www.ibm.com/blockchain/what_is_blockchain.html,
* http://edcab.eu/read/about,
* http://nakamotoinstitute.org/about/

bcnrsc.BOOK

Blockchain Revolution: How the Technology Behind Bitcoin Is Changing Money, Business and the World Paperback – 26 May 2016
[https://www.amazon.co.uk/Blockchain-Revolution-Technology-Changing-Business/dp/0241237858/]

"Mastering Bitcoin". Andreas M. Adonopoulos.
- https://www.bitcoinbook.info/
- https://github.com/bitcoinbook/bitcoinbook,
- (in Greek) http://synagonism.net/dirMiwMcs/dirTchInf/book-Mastering-Bitcoin.html,

bcnnet'DOING

Name::
* cpt.bcndng,
* cpt.bcnnet'doing,
* cpt.blockchain-doing,

bcndng.CREATING

Name::
* cpt.bcnnet'creating,
* cpt.bcndng.creating,
* cpt.blockchain-creating,

bcndng.UPGRATING

Description::
One of the important arguments in the blockchain space is that of whether hard forks or soft forks are the preferred protocol upgrade mechanism.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
===
To update means to bring someone or something up to date, whereas to upgrade means to raise or improve something to a higher standard.
The difference between these two is particularly apparent in the world of computers: an update is not always and improvement!
[https://english.stackexchange.com/a/13356]

Name::
* cpt.bcndng.upgrating,
* cpt.bcnnet'protocol-upgrate-mechanism,
* cpt.bcnnet'upgrating,
* cpt.blockchain-upgrating,

Hardfork (link)

Softfork (link)

Resource

AddressWpg::
* http://vitalik.ca/general/2017/03/14/forks_and_markets.html,

bcndng.GOVERNING (link)

bcndng.FUNDING

Description::
Money received (ICO) to build the system.

Name::
* cpt.bcndng.funding,
* cpt.blockchain-funding,

bcndng.SERVICE (bcnsvc)

Description::
Although currency transactions are the most common applications of the blockchain technology, some groups are also attempting to transfer other digital assets, such as financial products and services, logistics information, property ownership, identity etc.
[https://www.boscoin.io/wordpress/wp-content/themes/boscoin/src/pdf/boscoinwhitepaperv20170202.pdf]
===
The-service of a-blockchain-network and the-service of its consensus-money is the-same.
[hmnSgm.2017-02-04]

Name::
* cpt.bcnnet'adoption,
* cpt.bcnnet'application,
* cpt.bcnnet'service,
* cpt.bcnnet'usage,
* cpt.bcnsvc,
* cpt.blockchain-service,

bcnsvc'Resource

AddressWpg::
* http://www.blockchaintechnologies.com/blockchain-applications,
* {2016-12-13} Beyond bitcoin: 4 surprising uses for blockchain: https://www.weforum.org/agenda/...fighting-human-trafficking-tracing-blood-diamonds-and-other?
* https://news.bitcoin.com/ecb-plans-blockchain-e-governance/
* {2016-11-28} 5 Blockchain Applications That Are Shaping Your Future: http://www.huffingtonpost.com/ameer-rosic-/5-blockchain-applications_b_13279010.html,
* {2016-04-27} ECB Reveals Plans for Blockchain E-Governance http://cointelegraph.com/news/...blockchain-is-gaining-unprecedented-traction,
* {2016-04-10} Match & Teach Me: Blockchain, Psychometrics To Help Teach Refugees: http://cointelegraph.com/news/match-teach-me-blockchain-psychometrics-to-help-teach-refugees,
* {2016-04-09} Blockchain: Overhyped or Underexplored, It Will Be Deployed At Scale: http://cointelegraph.com/news/blockchain-overhyped-or-underexplored-it-will-be-deployed-at-scale,
* {2016-04-08} Filipino Breach: How Blockchain Can Bring Privacy Revolution To Masses: http://cointelegraph.com/news/filipino-breach...bring-privacy-revolution-to-masses,
* {2016-04-06} Blockchain Goes On A Brand Protection Mission, Fights Counterfeiting: http://cointelegraph.com/news/blockchain...brand-protection-mission-fights-counterfeiting,
* {2016-03-16} Response to Marcella Atzori: can the blockchain provide governance? https://bitnation.co/blog/response-marcella-atzori-can-blockchain-provide-governance/
* {2016-01-08} The Top 10 Blockchain Startups to Watch in 2016: https://medium.com/the-intrepid-review/the-top-...changing-the-game,

SPECIFIC

Name::
* bcnsvc.specific,
* cpt.bcnsvc.specific,

Specific::
* Academic-degree-blockchain-service,
* Administering-decentralized-blockchain-service,
* Asset-exchange-blockchain-service,
* Banking-blockchain-service,
* Birth-certificate-blockchain-service,
* Blockchain-service-providing,
* Charity-blockchain-service,
* Cloud-computing-blockchain-service,
* Cloud-storage-blockchain-service,
* Content-providing-blockchain-service,
* Coordination.global-blockchain-service,
* Crownd-funding-blockchain-service,
* Economy-blockchain-service,
* Energy-sector-blockchain-service,
* Exchange-value-blockchain-service,
* Financial-sector-blockchain-service,
* Freight-blockchain-service,
* General-purpose-computing-blockchain-service,
* Gold-exchange-blockchain-service,
* Healthcare-sector-blockchain-service,
* Identification-blockchain-service,
* Info-tech-sector-blockchain-service,
* Intellectual-property-blockchain-service,
* Invoice-managing-blockchain-service,
* Land-registry-blockchain-service,
* Legal-sector-blockchain-service,
* Manufacturing-sector-blockchain-service,
* Marketplace-blockchain-service,
* Money-transfer-blockchain-service,
* Music-service-blockchain-service,
* Notarization-blockchain-service,
* Program-blockchain-service,
* Proof-of-existance-blockchain-service,
* Recruitmen-sector-blockchain-service,
* Record-blockchain-service,
* Smart-contract-blockchain-service,
* Social-security-blockchain-service,
* Startup-funding-blockchain-service,
* Tech-info-blockchain-service,
* Trade-sector-blockchain-service,
* Transportation-sector-blockchain-service,
* Voting-blockchain-service,
* Wedding-certificate-blockchain-service,
* Welfare-benefit-blockchain-service,
* Will-blockchain-service,

bcnsvc.SPECIFIC-DIVISION.info-stored

Description::
Blockchain stores timestamped and unchanged information with many applications.

Name::
* cpt.bcnsve.info-stored-specific-division,

Specific::
* academic-degree-service,
* birth-certificate-service,
* charity-service,
* exchange-value-service,
* land-info-service,
* music-service,
* program-service,
* voting-service,
* wedding-certificate-service,
* will-service,

bcnsvc.SPECIFIC-DIVISION.sector

Name::
* cpt.bcnnet'industry,
* cpt.bcnnet'sector,
* cpt.bcnsvc.sector-division,

AddressWpg::
* {2017-02-07} Banking Is Only The Start: 27 Big Industries Where Blockchain Could Be Used, https://www.cbinsights.com/blog/industries-disrupted-blockchain/

Specific::
* Banking-sector,
* Energy-sector,
* Financial-sector,
* Healthcare-sector,
* Info-tech-sector,
* Legal-sector,
* Manufacturing-sector,
* Music-sector,
* Trade-sector,
* Transportation-sector,
==

bcnsvc.sector.FINANCIAL

Description::
“Bitcoin—or more precisely, the underlying technology that allows it to function, called distributed ledgers, or blockchain—could allow what many see as a radical rewiring of the financial sector.”
[http://cointelegraph.com/news/imf-magazine-examines-present-and-future-of-bitcoin]

Name::
* cpt.bcnsvc.financial,
* cpt.financial-sector-blockchain-service,

AddressWpg::
* https://www.bloomberg.com/news/articles/2016-06-06/ central-bankers-told-they-should-be-sprinting-toward-blockchain,
* https://www.weforum.org/agenda/2016/05/how-blockchain-could-shake-up-stock-markets/

bcnsvc.BANKING

Name::
* cpt.bcnsvc.banking,
* cpt.banking-blockchain-service,

AddressWpg::
* {2017-05-18} Bank Blockchain Pilot in India Sees Transactions Going From Weeks to Hours: https://cointelegraph.com/,
* Polybius Bank will combine features of modern banking, IoT, Big Data and Blockchain-based technologies while also meeting security and UX requirements.
- https://polybius.io/,
* Humaniq is a simple and secure 4th generation mobile bank. We are developing a completely new banking experience by dissolving all the barriers of archaic banks such as the need to come to a branch, doing endless paperwork, dealing with hard-to-use, buggy mobile apps, and protecting data with hard-to-remember, complex passwords.We have created a safe, strong financial tool, specifically designed to be used by people who are undereducated or who don’t possess identification. Most of them live in emerging economies on less than two dollars a day. We believe we can change that. Learn more about Humaniq…
- https://humaniq.co/

exchange.Gold

Name::
* cpt.bcnsvc.gold-exchange,
* cpt.gold-exchange-blockchain-service,

AddressWpg::
* https://www.dinardirham.com/

money

Name::
* cpt.bcnsvc.money,
* cpt.money-blockchain-service,

AddressWpg::
* http://dcebrief.com/tunisia-becomes-first-nation-to-put-nations-currency-on-a-blockchain/ {2015-12-28}
* https://cointelegraph.com/news/ukraine-to-become- next-country-to-go-cashless-plans-national-digital-currency,

Startup-funding

Name::
* cpt.bcnsvc.startup-funding,
* cpt.startup-funding-blockchain-funding,

Specific::
* Neufund-ogn,

Neufund-organization

Description::
Neufund is building a blockchain-based and investor-directed platform which bridges the world of cryptocurrency and equity. The fund unlocks the resources of cryptocurrency and blockchain to fund startups and all forms of technological innovation and disruption.
[http://neufund.org/]

Name::
* cpt.Neufund-ogn,

bcnsvc.sector.RECRUITMENT

Name::
* cpt.bcnsvc.recruitment,
* cpt.recruitment-sector-blockchain-service,

AddressWpg::
* https://chronobank.io/ ChronoBank.io is an ambitious and wide-ranging blockchain project, aimed at disrupting the HR/recruitment/finance industries in a similar way to how Uber disrupted the taxi business and how Upwork represented an evolution in freelancing.

bcnsvc.sector.TRADE

Name::
* cpt.bcnsvc.trade,
* cpt.trade-sector-blockchain-service,

AddressWpg::
* https://cointelegraph.com/news/wells-fargo-and-australian-bank- begin-sending-physical-products-via-blockchain,

bcnsvc.ASSET-EXCHANGE

Name::
* cpt.bcnsvc.asset-exchange,
* cpt.asset-exchange-blockchain-service,

bcnsvc.FREIGHT

Name::
* cpt.bcnsvc.handover,
* cpt.freight-blockchain-service,

AddressWpg::
* https://cointelegraph.com/news/ibm-maersk-to-deliver-first-blockchain-project-by-end-of-2017,

bcnsvc.Invoice-managing

Description::
The government in Singapore has turned to Blockchain developing a system to prevent invoice fraud cases.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]

Name::
* cpt.bcnsvc.invoice-managing,
* cpt.invoice-managing-blockchain-service,

bcnsvc.Provenance-project

Description::
Project Provenance began with a frustration for how little we know about the things we buy
We are now a growing collective with backgrounds in software design, product manufacturing and data science. Our base is in London, but our mission is global. Our common goal is to deliver meaningful change to commerce through open and accessible information about products and supply chains.
[https://www.provenance.org/about]

Name::
* cpt.provenance-ogn,

AddressWpg::
* The woman whose mum inspired her to track ethical food
By Matthew Wheeler
Business reporter
13 February 2017
- http://www.bbc.com/news/business-38773878,

bcnsvc.sector.ENERGY

Name::
* cpt.bcnsvc.energy,
* cpt.energy-blockchain-service,

AddressWpg::
* http://www.greentechmedia.com/articles/read/ the-energy-blockchain-could-bitcoin-be-a-catalyst-for-the-distributed-grid?

bcnsvc.sector.LEGAL

Name::
* cpt.bcnsvc.legal,
* cpt.law-blockchain-service,
* cpt.legal-blockchain-service,

AddressWpg::
* {2016-10-14} Argentina-Based Notarization Platform Launches Public Beta, Brings Bitcoin to Legal Industry: https://cointelegraph.com/news/argentina-based-notarization...legal-industry,
* Agrello: Have your own AI counselor help you create and manage smart-contract-based legal agreements. No coding or legal skills required.
- https://www.agrello.org/,

bcnsvc.sector.MANUFACTURING

Name::
* cpt.bcnsvc.manufacturing,
* cpt.manufacturing-blockchain-service,

AddressWpg::
* {2016-06-08} http://cointelegraph.com/news/ blockchain-watch-manufactures-start-using-blockchain-to-confirm-authenticity-of-luxury-goods,
- Upon the sale or transfer of assets, the original owner performs a simple operation on the blockchain to automatically transfer their right to ownership to the new owner.

bcnsvc.sector.MUSIC

Name::
* cpt.bcnsvc.music,
* cpt.music-blockchain-service,

AddressWpg::
* http://www.ibtimes.co.uk/ pink-floyd-blockchain-technology-music-could-be-truly-revolutionary-1569649,

bcnsvc.sector.TECH.INFO

Name::
* cpt.bcnsvc.info-tech,
* cpt.info-tech-blockchain-service,

GENERAL-PURPOSE-COMPUTING

Name::
* cpt.bcnsvc.general-purpose-computing,
* cpt.general-purpose-computing-blockchain-service,

AddressWpg::
* https://sonm.io/ SONM is a decentralized worldwide fog supercomputer for general purpose computing from site hosting to scientific calculations.
The purpose of SONM project is to replace traditional Proof-of-Work cryptocurrency mining prevalent in the blockchain community at the moment.

CLOUD-COMPUTING

Name::
* cpt.bcnsvc.cloud-computing,
* cpt.cloud-computing-blockchain-service,

AddressWpg::
* BLOCKCHAIN-BASED DISTRIBUTED CLOUD COMPUTING: http://iex.ec/

CLOUD-STORAGE

Name::
* cpt.bcnsvc.cloud-storage,
* cpt.cloud-storage-blockchain-service,
* cpt.sector.storage-bcnnet-service,

AddressWpg::
* https://cointelegraph.com/news/ sia-v103-comes-out-aims-at-revolution-in-blockchain-cloud-storage,
* http://cointelegraph.com/news/ cloud-storage-meets-bitcoin-blockchain-siacoin-takes-on-amazon-google-microsoft,
* https://sia.tech/

CONTENT-PROVIDING

Name::
* cpt.bcnsvc.content-providing,
* cpt.content-providing-blockchain-service,

AddressWpg::
* https://cointelegraph.com/news/how-to-monetize-content-using-blockchain-platforms,

bcnsvc.BLOCKCHAIN-SERVICE-PROVIDING

Name::
* cpt.bcnsvc.blockchain-service-providing,
* cpt.blockchain-service-providing,

AddressWpg::
* http://cointelegraph.com/news/emercoin-blockchain-engine-becomes- first-blockchain-solution-available-on-microsoft-azure-marketplace,
Emercoin joined the Microsoft Azure program in January 2016, becoming one of the first partners and blockchain implementing service providers. On this day, the Emercoin Blockchain Engine has become the first Microsoft Azure Market application to provide blockchain services to end users around the world.
* Blockchain-as-a-service-network,

bcnsvc.GOVERNANCE

Description::
Blockchain technology and dApps have the ability to decentralize power from existing authorities in business, law, and technology to a broad set of stakeholders.
This shift will disrupt current business, economic and social paradigms.
Transaction costs and barriers to entry in various industries will be reduced in these industries.
The result will likely be an increase in economic exchange and prosperity.
[https://consensys.net/vision/]

Name::
* cpt.bcnsvc.governance,
* cpt.administering-blockchain-service,
* cpt.governance-blockchain-service,

bcnsvc.GOVERNANCE.SOCIETY

Description::
The need to look beyond the currency and investigate the potential use of the technology in industries outside payments is often emphasized. So should global governments be embracing Blockchain?
Backing e-government platforms with Blockchain can solve a number of issues that arise when dealing with public authorities nowadays. Citizens feel so disconnected from their governments and think the general level of state bureaucracy is unbelievable. Therefore, digitization of state services in general and especially the integration of Blockchain in this sphere is an interesting process to follow.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]

Name::
* cpt.administering-socidety-blockchain-service,
* cpt.bcnsvc.governance,
* cpt.government-services-on-blockchain,
* cpt.bcnsvc.Public-sector,
* cpt.bcnsvc.sector.Public,
* cpt.public-services-on-blockchain,
* cpt.state-services-on-blockchain,

AddressWpg::
* http://www.borderless.tech/

bcnsvc.Land-registry

Description::
Ghana has been playing around with Blockchain to apply it in land registry with 28 communities involved in the project to enable tamper-resistant property ownership.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]
===
For instance, Sweden is working to back real estate transactions with Blockchain technology, enabling all parties involved to easily track the progress of agreements.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]

Name::
* cpt.bcnsvc.land-registry,
* cpt.bcnsvc.real-estate-transaction,
* cpt.blockchain.land-registry,
* cpt.land-registry-blockchain-service,

AddressWpg::
* {time.2017-04-04} https://cointelegraph.com/news/blockchain-land-registry-trial-in-sweden-concludes-second-phase,

bcnsvc.Social-security

Name::
* cpt.bcnsvc.social-security,
* cpt.social-security-blockchain-service,

AddressWpg::
* China recently announced that they would put their entire social security system on a Blockchain.
[https://cointelegraph.com/news/ukraine-to-become-next-country-to-go-cashless-plans-national-digital-currency 2016-11-13]

bcnsvc.Voting

Name::
* cpt.bcnsvc.voting,
* cpt.blockchain-voting,
* cpt.voting-blockchain-service,
* cpt.voting.blockchain,

AddressWpg::
* {2017.04-06} https://cointelegraph.com/news/blockchain-voting-may-lead-to-liquid-democracy-globally-in-20-years,
* {2016-06-30} https://cointelegraph.com/news/australia-to-make-blockchain-voting-app-a-global-democratic-movement,
While Russia is testing an e-proxy voting system based on a distributed ledger, Australia is launching a Blockchain voting app in hopes of starting a global political movement.
The Flux Party is a new Australian political party that aims to return power over important decisions made in Parliament to individual electors.
* http://cointelegraph.com/news/russia-tests-blockchain-voting-plans-to-launch-it-in-2017, National Settlement Depository, Russia’s central securities depository, has successfully tested an e-proxy voting system based on a distributed ledger (blockchain) technology.
* {2016} http://www.europarl.europa.eu/RegData/etudes/ATAG/2016/581918/EPRS_ATA(2016)581918_EN.pdf, European Parliament Research Service.

Specific::
* bitcoin-voting,

bcnsvc.Welfare-benefit

Description::
The UK has been exploring the use of Blockchain to manage and monitor the distribution of welfare benefits.
[https://cointelegraph.com/news/power-to-the-people-blockchain-replaces-government-in-europe]

bcnsvc.ECONOMY

Name::
* cpt.bcnsvc.decentralized,
* cpt.blockchain-decentralized-economy,
* cpt.economy-blockchain-service,

AddressWpg::
* {2017-03-30} How Amir Taaki Tried to Build Bitcoin Economy in Syria While Fighting ISIS: https://cointelegraph.com/news/how-amir...build-bitcoin-economy-in-syria-while-fighting-isis,

bcnsvc.IDENTIFICATION

Name::
* cpt.bcnsvc.identification,
* cpt.bcnsvc.ID,
* cpt.identification-blockchain-service,

AddressWpg::
* {2017-05-15} RegTech: New Blockchain Platform Seeks To Disrupt Identity Industry: https://cointelegraph.com/,
* https://uport.me/#home, Your universal digital passport
Simple, secure, self-sovereign identity on Ethereum
Self-sovereign identity puts you 100% in control of your identity and data
* https://shocard.com/how-it-works/

Specific::
* bitcoin-ID-service,

bcnsvc.COORDINATION.GLOBAL

Name::
* cpt.bcnsvc.coordination.global,
* cpt.bcnsvc.global-coordination,
* cpt.coordination.global-blockchain-service,

AddressWpg::
* http://www.telegraph.co.uk/business/2016/06/20/ skype-inventor-jaan-tallinn-wants-to-use-bitcoin-technology-to-s/

bcnsvc.FERMAT-FRAMEWORK

Description::
Fermat is a Decentralized, Blockchain enabled, Modular App Platform that unleashes the P2P “Internet of People” Economy.
Fermat seeks to deliver the better world, initially promised by Bitcoin. Through a decentralized app framework that incentivizes collaborative development, shared ownership and hyper-customization of modular software, the Project aims to unshackle free markets, by removing intermediaries from their current levels of influence, and to earn widespread mainstream adoption.
Fermat’s central premise is that there is a path to software development that is smarter, better and more efficient than the status quo. The Fermat framework allows anyone from anywhere to collaborate and mutually profit from shared ownership of modular applications: it enables an open-ended stream of micropayments to authors of reusable software components that can be perpetually combined and recombined across an ever-expanding library of useful, highly-customizable, peer-to-peer commercial applications (apps).
The blockchain-enabled system is built to be user-controlled, censorship-resistant and flexible – a platform for person-to-person exchange of goods, service, assets and data, free from the whims, risks, costs and interference of unwanted, self-interested third parties who put their priorities ahead of those of the people directly involved in the exchange.
Our roadmap to a better world starts from the view of mass adoption. Our first step is to envision a future where cryptocurrency is mass-adopted; fiat currencies are already completely digitized; and people have the freedom to choose which electronic currency to use, where to store them and how and when to exchange that purchasing power.
In this future people manage multiple online identities, using the one that best fits their current needs in each situation. They transact with whatever privacy level they choose. They not only have money on their devices, but a whole suite of software that can use their digital money to enable and sustain all kinds of p2p business models. Fermat is making this possible.
I envision a future where humans are more important than legal fictions like companies and corporations and non-objective realities like nations and states.
–LUIS FERNANDO MOLINA
[http://www.fermat.org/fermat-about-us/our-vision/]

Name::
* cpt.bcnsvc.Fermat-framwork,
* cpt.Fermat-framwork-blockchain-service,

AddressWpg::
* https://drive.google.com/file/d/0Bzq6JfsbkKrAUFAwWUNyNS12ekU/view?ts=56f6c013,

bcnsvc.MARKETPLACE

Description::
MARKETPLACE
The Nxt Marketplace feature allows you to list items for sale and make sales on the blockchain.

You do not need to rely on external market sites to conduct your business. Instead, transactions are done between seller and buyer directly.
[https://nxt.org/what-is-nxt/marketplace/]

Name::
* cpt.bcnsvc.marketplace,
* cpt.marketplace-blockchain-service,

bcnsvc.NOTARIZATION-service

Name::
* cpt.bcnsvc.notarization,
* cpt.notarization-blockchain-service,

NameGreek::
* συμβολαιογραφική-υπηρεσία,

AddressWpg::
* https://cointelegraph.com/news/argentina-based-notarization-platform-launches-public-beta- brings-bitcoin-to-legal-industry,

bcnsvc.RECORD-KEEPING

Description::
The opening for a blockchain intern at Disney illustrates that banks and financial institutions are no longer the only companies looking at blockchain solutions.
The blockchain can find applications in any industry where records need to be securely maintained and processed – whether they be land records, medical records or shipping records.
We can expect companies in other industries to follow Disney's lead and start looking at blockchain solutions in the near future.
[http://cointelegraph.com/news/walt-disney-now-loves-blockchain-going-trustless-in-seattle]

Name::
* cpt.bcnsvc.record-keeping,
* cpt.record-keeping-blockchain-service,

AddressWpg::
* student-credintials: http://www.cnbc.com/2016/05/09/schools-are-recording-students-results-on-the-blockchain.html,

Specific::
* Academic-degrees,
* intellectual-property,
* land-registry,
* medical-records-registry,
* shipping-registry,
* strudents-credentials,
* wedding-agreement,

bcnsvc.INTELLECTUAL-PROPERTY

Name::
* cpt.bcnsvc.intellectual-property,
* cpt.intellectual-property-blockchain-service,

AddressWpg::
* https://cointelegraph.com/news/blockai-uses-bitcoin-blockchain-to-protect-intellectual-property, blockai.com,

bcnsvc.WEDDING-AGREEMENT

Name::
* cpt.bcnsvc.wedding-agreement,
* cpt.wedding-agreement-blockchain-service,

{time.2014}:
This isn't the first connection that Disney has with the blockchain.
Way back in 2014, the first blockchain wedding took place at Disneyland, Florida.
David Mondrus and Joyce Bayo registered their wedding agreement on the blockchain, eliminating the role of both religious and government officials.
[http://cointelegraph.com/news/walt-disney-now-loves-blockchain-going-trustless-in-seattle]

bcnsvc.Blockstack (bsksvc)

Cpt-created: {2017-03-14}

Description::
Blockstack is a new internet for decentralized, server-less applications.
Building on Blockstack starts with single-page applications built in Javascript that are downloaded onto user devices.
Developers plug into blockstack.js, which provides API’s for authenticating the user, grabbing application data from the user, and storing new application data with the user (encrypted and backed up to cloud storage).
The blockchain is utilized to maintain a cross-application identity system, securely mapping user IDs to usernames, public keys, and data storage URIs.
Developers don’t have to worry about running servers, maintaining databases, or building out user management systems, and decentralized, server-less applications can be built more simply than their traditional counterparts.
[https://blockstack.org/about]

Name::
* cpt.bcnbsk,
* cpt.blockstack-platform,
* cpt.bsksvc,

bcnbsk'Resource

AddressWpg::
* {2017-03-14} https://cointelegraph.com/news/blockstack-launches-third-ever-blockchain-product-on-amazon-marketplace,

bcnnet'doing.service.ChronoBank (chbsvc)

Description::
The-ChronoBank-project is a-blockchain-service for the-recruitment-sector.
The second major attribute of the-project is that issues exchange-value-units, the-LH, BACKED with human-work.
The-project uses ethereum-dApps to achieve its goals.
[hmnSgm.2017-05-20]

Name::
* cpt.bcnchb,
* cpt.chbsvc, {2017-03-20}
* cpt.ChronoBank,
* cpt.ChronoBank-blockchain-based-project,
* cpt.ChronoBank-initiative,
* cpt.ChronoBank-platform,
* cpt.ChronoBank-service,

Description::
The ChronoBank project aims to make short-term employment as accessible and rewarding as long-term employment, giving workers the flexibility to determine their own schedules whilst being paid a fair rate for their time, expertise and reputation.
[https://blog.nem.io/the-chronobank-project/]

Description::
ChronoBank is a new blockchain-based project that takes aim at the short-term recruitment sector. By placing buyers and sellers of labour in direct contact, and paying in a native Labour Hour token (LH), the platform offers the possibility of substantial savings for employers, since it cuts out the expensive middlemen of the recruitment industry -- in the same way that Uber disintermediates the taxi business.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]
===
ChronoBank is designed to allow businesses to connect directly with professionals seeking work, cutting out recruitment agencies in much the same way that Uber disintermediates the taxi business.
[https://blog.chronobank.io/chronobank-partners-with-nem-to-create-chrononem-wallet-eebdc176351d]
===
Have you ever wanted a service that would let you do what you’re good at and get paid at the same time, but you struggle to find clients for your work? Chronobank solves this problem by utilizing a system that allows anybody to sell their labor and get money for it, as Chronobank’s system is designed to be similar to Uber’s in the sense that anybody can get paid and anyone can get work quickly without a middleman (which can get costly) and without any other fees.
[https://www.crypto-news.net/chronobank-time/]

chbsvc'Protocol (chbprl)

Name::
* cpt.chbprl,
* cpt.chronobank-protocol,

chbprl'White-paper (chbwpr)

Name::
* cpt.chbwpr,
* cpt.chronobank-whitepaper,

AddressWpg::
* https://chronobank.io/files/whitepaper.pdf,
* https://github.com/ChronoBank/Documentation/blob/master/whitepaper.pdf,

CHRONOBANK - PHASE 1: A NON-VOLATILE DIGITAL TOKEN BACKED BY LABOUR-HOURS
THE CHRONOBANK TEAM
CHRONOBANK.IO
INFO@CHRONOBANK.IO
{Retrieved 2017-03-20}

Abstract

This whitepaper abstractly describes a system designed to tokenise labour-hours using blockchain technology.
ChronoBank is a proposed implementation of the described system that can be deployed in several economic localities.
The proposed system leverages smart contract techniques to automate a process whereby a country-specific ‘labour-hour’ token may be redeemed for real labour-hours via legally binding (traditional) contracts with labour-offering companies.
The proposed ‘stable-coin’ implementation provides a non-volatile, inflation-resistant digital asset transfer system.

1. Introduction

With the advent of cryptocurrencies, relatively instant low-cost transfers of value have become a reality.
Blockchain technology, which is a defining feature of most cryptocurrencies, has recently been applied to solve a great variety of problems.
Currently the most widespread implementation of blockchain technology is Bitcoin [ 1 ], which is a simple asset transfer system.
The asset in Bitcoin’s case is a bitcoin (BTC).
The value of this token has seen rapid variation since its inception in 2009, which has hindered its feasibility as a global currency.

There have been a variety of attempts to realise the advantages of blockchain technology while simultaneously mitigating issues regarding the stability of value for cryptocurrency applications.
To achieve this, many attempts employ the notion of a stable-coin, whereby each token of value in the system has a counterpart of equal worth stored in a non-digital and tangible form in the ‘real world’.

Two example implementations of the aforementioned stable-coin paradigm are listed below:

USDT by Tether[ 2 ]:
Each USDT token is backed by an equivalent amount of United States Dollars (USD) held in a reserve account by the private company Tether Limited.

Digix[ 3 ]:
Each token is backed by an equivalent amount of gold, which is stored in reserves by a dedicated precious metal storage custodian.

In both examples, it is always possible for a token holder to redeem that token for its counterpart, thus ensuring its fundamental ‘stable’ value.

Another notable example of a stable-coin is Bitshares [ 4 ], which attempts to decentralise the entire system through the use of digital Contract For Differences (CFD) [ 5 ] interactions.
The system presented in this whitepaper does not attempt to achieve decentralisation, but instead attempts to address some of the drawbacks surrounding existing centralised stable-coins.
These drawbacks include difficulties regarding the storage of physical or economic wealth, and the increasing likelihood of attacks, as a single entity centralises the entire wealth of the system.
Typical stablecoins are also subject to fluctuations in the value of their underlying asset.
While these fluctuations are usually very small when compared with fluctuations in traditional cryptocurrencies, they are still significant.
For example, USDT is subject to the devaluation of USD due to inflation.

In this paper, we propose a stable cryptocurrency system which addresses the aforementioned drawbacks of existing stable currency solutions.
Specifically, we propose a new type of token which is not backed by any existing fiat currency or physical store of wealth, but instead is backed by legally binding contractual obligations to provide real-world labour-hours.
As such, the system and its controlling entity are not responsible for the centralised storage and management of wealth.
Further, the value of an unskilled labour-hour in a particular geographic region naturally adjusts according to economic conditions such as inflation, thereby maintaining the long-term intrinsic value of the cryptocurrency.

This paper is organised as follows:
In Section 2 we provide an overview of the system as a whole before discussing the technical details of the necessary system components and processes.
Section 3 provides economic considerations in brief, regarding the real-world deployment of this system and its feasibility.
Finally, Section 4 discusses future directions and applications of the system and of ChronoBank.
The appendix of this document provides supporting reference of several concepts introduced throughout the paper.
In particular Appendix B and C list the variables that encapsulate the functionality of the system.
These variables are also summarised in Table 1.

2. The ChronoBank System

Similar to existing stable-coins (such as USDT by Tether and Digix), we propose a centralised entity that coordinates the creation, redemption, and destruction of Labour-Hour Tokens (LHT).
We refer to this entity as the ChronoBank Entity (CBE).
It is responsible for the acquisition and coordination of legally binding contracts for labour, in addition to the creation and dissemination of LHT.
Ultimately the role of the CBE is to ensure the stability of the LHT system through careful management of the system’s underlying processes.
This section will provide details describing the proposed processes, practices, and operations undertaken by the CBE and its associates.
An overview of the functionality of the ChronoBank system’s
constituents is shown in Figure 1.

imgChbwprFig1.png
Figure 1.
An overview of the ChronoBank system.
This diagram shows the system’s constituents and their interactions.
CBE refers to the ChronoBank Entity, LOC to Labour-Offering Companies, LHT to Labour-Hour Tokens and TIME to the token purchased during the crowdsale.

The system as a whole is designed with the intent of a single deployment per economic region.
For instance, the system could be deployed once in Australia using the value of one labour-hour in the Australian economy, measured in Australian dollars.
As this document is an abstract description of the system, it does not refer to any region-specific implementation but instead refers to generalised system parameters that must be tailored for each region.
With few exceptions, all processes and structures described in this document may have slight variations in implementation between regions in which ChronoBank operates.

The initial implementation of the CBE will utilise the Ethereum[ 6 ] blockchain; however, future implementations may tokenise assets on alternative blockchain systems (e.g. Waves [ 7 ], Bitcoin [ 1 ]) when it is deemed appropriate.

The CBE provides economic benefit both to the environment in which it is deployed, and to a group of stakeholders that assist the CBE by providing initial operating capital.
Unlike the region-specific deployment of the CBE system, only one group of CBE stakeholders (a.k.a. TIME token holders) exists globally.
These stakeholders provide initial operating capital to the CBE in the form of both fiat and cryptocurrencies, in exchange for a portion of future profits attained by the CBE.

2.1. Stakeholders & TIME Tokens

In order to fund the development and operation of the ChronoBank system, there will be a fundraising phase known as the crowdsale.
During the crowdsale, individuals may purchase TIME tokens at a fixed rate, which provides the token holder with the right to receive a proportion of the profits arising from the operation of the system.
In addition to the entitlements regarding the system’s operating profit, holders of TIME tokens will also be granted the right to vote on important decisions regarding the ChronoBank system.

TIME tokens will be developed utilising the Ethereum ecosystem, specifically leveraging the ERC20 token standard[ 8 ].
The ERC20 specification will be extended to provide voting functionality and rewards distribution; this is discussed further in Sections 2.1.3 and 2.1.2 below.

2.1.1. Crowdsale

During the crowdsale, TIME tokens will be created as necessary and sold at the fixed price of 100 TIME tokens for 1 bitcoin (BTC).
There is no limit to the number of TIME tokens generated during the crowdsale; however, no further TIME tokens will be generated after this phase of the project.

imgChbwprTbl1.png
ρ Total percentage of minted LHT taken by the CBE
fc Fee taken during minting by the CBE
fr Fee taken during redemption by the CBE
fi Issuance fee taken during minting
S Percentage of minted LHT put into the SGF
LT Percentage of minted LHT put into the Liquidity Reserve
L0 Percentage of minted LHT used for LOC insurance
M Number of months until L0 is transferred into the SGF
l Percentage of LT used for LOC insurance
P Interval between TIME token reward payouts

Table 1. List of abstract variables and constants used throughout this paper for reader’s reference. See the Appendix for further details.

All TIME tokens purchased during the crowdsale will constitute 88% of the total TIME tokens generated during the initialisation of the ChronoBank system.
The remaining 12% of tokens will be split with 10% given to the ChronoBank.io team (for ongoing research and development) and 2% to advisors and early adopters of the system.

imgChbwprFig2.png
Figure 2.
Issuance fees (fi) and transaction fees (ft) are deposited into the rewards contract.
TIME holders can withdraw a portion of the LHT after each snapshot, if their TIME tokens were deposited into the contract.

2.1.2. TIME Token Rewards

For the use of the LHT, users will be charged a fixed fee, ft = 0.15% on all transactions.
Complementary to transaction fees, issuance fees (fi) will be taken during the minting process (further details in Section 2.2.1).
The issuance fees will start at 3% during the first year of operation and will stepwise decrease by 1% each year until a final issuance fee of 1% is achieved and maintained.

Both the transaction and issuance fees will be automatically collected and sent to a rewards contract on the Ethereum blockchain as shown in Figure 2.
The rewards contract is designed such that TIME token holders can withdraw their earned rewards in a manner that makes them non-unique (i.e. withdrawal of rewards is not tracked on a per-token basis) and hence tradeable on exchanges for equal value.

The rewards contract will allow TIME token holders to retrieve their rewards at regular payout intervals, P.
At any given stage, TIME holders may deposit their tokens into the rewards contract.
At the onset of a payout interval, a snapshot of deposited TIME tokens and the current contract reward balance will be taken.( 1 )
The rewards will be divided equally among the TIME tokens that were deposited at the time of the snapshot.
Depositors may then withdraw their share of rewards during the following payout interval.
At the next payout snapshot, any unclaimed rewards will be forfeited and added to the total balance of that snapshot.
Figure 3 illustrates this concept by plotting the rewards contract balance over time.
We also note that we expect P to be of the order of a few months.

TIME holders may deposit and withdraw their TIME tokens at any stage, however only TIME holders who have deposited before the snapshot of each payout interval can claim rewards.
Withdrawing TIME tokens from the contract will also withdraw any rewards currently owed to the depositor.
TIME holders may also leave their tokens deposited in the rewards contract indefinitely and claim their rewards periodically.

imgChbwprFig3.png
Figure 3.
The rewards contract receives Pr rewards for every payout interval P (in our example, we assume that Pr is constant).
At each snapshot, the portion of rewards that are not withdrawn is d.
Rewards that are not withdrawn roll over to the following payout interval P.
The dashed line indicates the withdrawable balance, which reduce over each payout interval as TIME holders withdraw their rewards.

This reward payout system gives upper bounds to the amount of rewards that can be stored in the contract in any interval, under some reasonable assumptions.
The total rewards obtained via fees for a particular payout interval, P, is Pr.
If we assume a constant amount of transaction and issuance fees per payout interval (i.e. a constant Pr), and an average percentage of locked TIME holders that do not withdraw in any payout interval, d, we can calculate the upper bound of the LHT stored in the smart contract through the limiting geometric series relation( 2 ):

To clarify this, let us take a conservative estimate, that 90% of all locked TIME token holders do not withdraw their rewards in every payout interval (only 10% actually withdraw).
In this scenario, no more than 10Pr worth of rewards will be stored in the rewards contract at any given time.
A less conservative estimate, being 50% of locked TIME holders withdrawing each payout interval, will ensure the rewards contract never contains more than 2Pr worth of rewards.
Through the careful (and potentially dynamic) choice of P we can find a balance between practicality (frequency of reward withdrawal) and security (safe level of stored value in a smart contract).

2.1.3. TIME Voting

From time to time, the CBE may hold polls on the Ethereum blockchain to elicit the opinion of TIME token holders.
Poll results will be incorporated into decisions made by the CBE concerning the financial or technical direction and/or implementation of the CBE system.
Only valid TIME holders are considered current stakeholders in the CBE system and are the only parties authorised to participate in a poll.

2.2. Labour-Hour Tokens

Labour-Hour Tokens (LHT) are the fundamental unit of value within the ChronoBank system.
The purpose of these tokens is to provide a non-volatile, inflationary-resistant digital store of value on various blockchains.
We envisage these tokens for utilisation in future systems, such as LaborX (see Section 4 for a brief overview).

A Labour-Hour Token will be derived from a standard Ethereum ERC20 token and will be tradeable on all major exchanges.
The ChronoBank system will ensure that these tokens will always have a 1 to 1 mapping with legally bound promises of labour-hours from various Labour-Offering Companies (LOC).
As such, token holders may also redeem these tokens at any given time for their real-world labour-hour counterpart.
This section details the various processes required to feasibly sustain the 1 to 1 mapping of LHT to offered labour-hours and ensure the economic stability of the ChronoBank system.

2.2.1. Minting

The minting process takes place when a company offering labour-hours (Labour-Offering Company (LOC)) chooses to enter into a legally binding agreement with the CBE.
The CBE must then run strict checks (the guidelines of which are described in the business outline [ 9 ]) of the LOC wishing to participate in the ChronoBank system.
Once the LOC is approved, the CBE and LOC will negotiate on various parameters (summarised in Appendix B) before entering a legally binding contract whereby the LOC promises labour-hours in exchange for LHT (or the fiat equivalent).
The CBE will then publish a hash of the contract on the Ethereum blockchain and store the contract on a decentralised storage system such as IPFS [10] or SWARM [11].
This gives a transparent ledger detailing the current state of the backed LHT.
The exact mechanisms behind the minting process are non-trivial and we refer the reader to Figures 4 and 5 during the following discussion of the process.
When an LOC and the CBE have agreed on terms, the CBE mints the equivalent amount of LHT as labour-hours offered by the LOC, ensuring the 1 to 1 relationship between the two.
Of the newly minted tokens, the CBE will retain ρ percent( 3 ), providing the remaining (1 - ρ) of minted LHT to the LOC.
In practice, the CBE can sell the (1 - ρ) of minted LHT on exchanges and provide the LOC with the fiat equivalent, should they not wish to deal with cryptocurrencies.
The ρ percent held by the CBE will be immediately subdivided into the following portions (shown diagrammatically in Figure 5).
• fc ;sblisin; [0, 0.01] - A fee charged by the CBE for services provided.
• fi - The issuance fee which will go to the rewards contract for TIME token holders (see Section 2.1.2).
• S - A portion to be sent to the Security Guarantee Fund (SGF) (see Section 2.3.2).
• LT - The total portion sent to the Liquidity Reserve (Section 2.3.1). This fund is further split by a variable percentage, l, into LI (LOC insurance) and L0 (liquidity) (see Section 2.3.1 for further details).

For clarity, we write the obvious explicit relation,

ρ = fc + fi + S + LT . (2)

We expect that the system will maintain fixed fees, but will vary S, l and LT (and hence ρ) on a case-by-case basis to control the stability and viability of the ChronoBank ecosystem.
The purpose of the Liquidity Reserve and Security Guarantee Funds are detailed in the Funds Section (2.3) and a brief discussion of the economic feasibility of this system is discussed in Section 3.

imgChbwprFig4.png
Figure 4.
Procedural overview of the ChronoBank minting process.

imgChbwprFig5.png
Figure 5.
Fund distribution of minted LHT.

2.2.2. Redemption

As LHT are fundamentally backed by real-world labourhours, holders may redeem their tokens at any time for these backed hours.
To do so, holders will deposit their LHT into a redemption contract on the Ethereum blockchain.
Along with the deposit, holders will provide relevant data detailing their redemption request, such as labour type(s), location(s) of work, date/time of work, contact information, etc.
The request will trigger the CBE to search and match relevant LOCs to the redemption request.
If found, the CBE will return the most suitable LOCs that fit the request.
To discourage recurrent requests and to remunerate the CBE for its service, the CBE will take a small fee, fr ;sblisin; [0, 0.01] from the deposited tokens.
The amount of labour-hours matched will be less than or equal to the LHT tokens deposited, less the CBE’s fee.
Any unmatched requests or unfulfilled hours can be withdrawn from the redemption contract by the depositor.
As a redundancy, the redemption contract will have a built-in holding period, after which depositors may withdraw their deposited LHT.
This protects depositors from inactive or stagnant CBEs.

Once the CBE has returned a list of compatible LOCs, a depositor may accept or reject the offered LOC(s).
If rejected, the depositor can withdraw their deposited LHT less the CBE’s service fee.
If accepted, the CBE will advise the chosen LOC of all relevant details.
The redemption contract will hold the LHT until the work has been completed and the depositor is satisfied.
A dispute resolution system may be used to ensure work is completed as requested.
Once the labour has been satisfactorily completed, the deposited LHT will be destroyed, again ensuring the 1 to 1 relationship of LHT to backed labour-hours.

2.2.3. Intrinsic Value

We have thus far ensured a 1 to 1 correspondence between LHT and labour-hours but have not yet defined the value of either.
The intrinsic value of one LHT and thus one labour-hour is region-dependant.
Although any arbitrary value can be chosen, we peg the value of one LHT to be roughly the average hourly wage of a region for practical reasons.

The average hourly wage of a region will be defined via the official statistics bureau of that specific region.
If one were to trivially adjust the LHT to the most recent statistics released for a given region, the price of LHT would stepwise shift on the release date of the statistics.
Typically these statistics are released yearly and in such scenarios a predictive stepwise jump each year would occur.
To implement a smooth transition from one statistics point to another, we propose that the pegged price of LHT be a linear interpolation between the two points.
This would require the LHT price to lag behind the most recent statistics by the duration of at least one extra statistics release.

Let us illustrate this with a clear example, as depicted in Figure 6.
Let us determine the price of LHT during April, 2010 in a region where the statistics bureau publishes a data point in January each year.
This data point indicates the average wage in that region for the previous year.
The price will be calculated by retrieving two data points: A2008
and A2009, the average wage in 2008 (released in January, 2009) and the average wage in 2009 (released in January, 2010) respectively.
We take a linear interpolation between these two points to find the price of LHT in April, 2010.
In this example, this will over-approximate( 4 ) the average wage in April, 2008.
This example shows that the LHT price in April 2010 will be the over-approximated average wage in April 2008, demonstrating how the pegged price of LHT will lag behind the current actual average wage.
It should be noted that this doesn’t affect any aspects of offering or redeeming labour.
The value of labour offered or redeemed is independent of the price of a single LHT.
However, the value will be measured with respect to the fixed price of a single LHT token.

imgChbwprFig6.png
Figure 6. The base price of one LHT in April 2010, X, can be calculated as the linear interpolation between the average wage in 2008 and 2009 (A2008 and A2009).

For any given region, typically there are sub-regions which have varying costs associated with providing labour work.
We wish to integrate these costs within our definition of a single LHT.
To do so, we take the maximum of each cost within a sub-region and add it to the average wage of the region to provide the fundamental price of LHT.
Specifically we have:

L = (1 + max(Y )) X , (3)

where X is the linearly interpolated function of average wages described above and Y is the individual cost in a sub-region as a percentage of work done.
L as defined in equation (3) is the pegged price of LHT for any given region.
This value will vary linearly throughout each year in a transparent and predictable manner.

2.3. Funds

The uniqueness of backing a digital token with contractual debt requires various safeguards to ensure contracts are always upheld and potential defaulting is accounted for.
There are a number of adverse scenarios that can occur with a debt-backed system.
Our proposed solutions involve the careful maintenance of two extra funds, the Liquidity Reserve and the Security Guarantee Fund (SGF).
In this section we detail the operation of these funds and how they address some of the issues that can arise in this system.

2.3.1. Liquidity Reserve

The liquidity reserve is an offline LHT storage fund controlled by the CBE.
It receives a percentage, LT, of newly minted LHT during the minting process (Section 2.2.1).
There are two services that this function provides the ChronoBank system:

(1) LOC Risk Mitigation - During the minting process, an LOC will be paid (1 - ρ) percent of the labourhours they contractually agree to provide.
Therefore LOCs inherently take some risk in the form of immediate redemption.
If an LOC’s promise of
labour-hours is immediately redeemed, they stand
to lose ρ percent of these hours. To mitigate this,
the CBE will store a percentage of minted LHT,
LI (see Section 2.2.1) for each LOC, to reimburse
the LOC in the event that more than (1 - ρ) labourhours
are redeemed. LI will cover all excess (i.e. more than (1 - ρ) ) redeemed tokens until the reserve, LI , is depleted.

We formalise this by introducing the mitigated tokens payed to an LOC, LM, as

LM = min(LI, E). (4)

where E is the excess LHT to be redeemed by the LOC, defined as:

E =
 a) R - (1 - ρ), if R > (1 - ρ).
 b) 0, if R = (1 - ρ). (5)


with R being the total percentage of LHT redeemed.

The mitigation reserve, LI is not constant, but is gradually transferred to the SGF (Section 2.3.2).
The rate at which this fund is transferred is derived from the parameter, M, which specifies the total number of months until the funds are entirely transferred, and is negotiated during the minting process.
The mitigation reserve funds will be transferred monthly at a uniform rate (LI / M).

This procedure then allows the CBE to statistically choose ρ, LT and M given the risk profile and reputation of any given LOC during the minting process.
For example, ρ, LT and M can be designed such that within a 95 percent confidence interval, an LOC does not lose more than (ρ - ζ) worth of the labour-hours promised over a given time( 5 ).
Here ζ is a number that quantifies the risk that the LOC is willing to accept.
This degree of freedom allows the CBE to manage LOCs of varying risk profiles.

(2) LHT Liquidity - The price of LHT will ultimately be governed by the price at which the CBE buys and sells LHT( 6 ).
The funds used for this are stored in the Liquidity Reserve.
L0 of newly minted tokens (see Section 2.2.1) will be accrued in this fund.
The CBE will then stabilise the price of LHT and provide liquidity in various markets by buying and selling LHT at the fundamental price detailed in Section 2.2.3.

The parameter, l, chosen during contract negotiations, specifies the percentage of LT that goes to LI (the amount used for LOC insurance and which is gradually transferred to the Safety Guarantee Fund) and L0 (the amount that is permanently used for liquidity).
Through careful management of the parameter, l, the CBE can maintain the desired volume of funds in the Liquidity Reserve.
As this fund will hold both LHT and volatile currencies, care must be taken to manage volume due to the potential price fluctuations of the held currencies.

One immediate-use case of this fund will be in the initial system set-up.
When the first LOCs become part of the system, the freshly minted LHTs will need to be sold to transfer the resulting funds to the LOC.
Initially the demand for LHT will be low and funds from the Liquidity Reserve will be used to bootstrap this process.
A percentage of the crowdsale funds will be deposited into the Liquidity Reserve for this purpose.

2.3.2. Security Guarantee Fund

One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC in our case) defaulting on their contractual obligations.
Despite the care in vetting LOCs during the minting process, we expect there to be a percentage of companies that will inevitably default.
The SGF’s main purpose is to provide a fund reservoir as insurance to protect against defaulting companies.
In practice, this fund will burn held LHT tokens to the equivalent amount of outstanding labour-hours promised by the defaulting LOC.

Statistical estimates should be taken for the average probability of LOCs defaulting.
These estimates will give a measure defining the amount of LHT that should be stored inside the SGF fund at any given time.
The amount stored in the SGF will be proportional to the amount of debt, and hence be proportional to the amount of LHT in existence (as every LHT is backed by one owed labour-hour).
This required value can be reached and maintained through the management of the minting variables, S, l and LT .

3. Economic Considerations

In this section we briefly mention some interesting properties and immediate economic consequences of this system.

3.1. Economic Incentives

First and foremost, the system must be designed such that there are economic incentives for both LOCs and LHT holders to participate in the system.
For an LOC, the incentive to participate in the ChronoBank system comes in the form of an interest-free-like loan.
When an LOC agrees to participate in the system and offers labour-hours, the company effectively receives an interest-free loan, which needs to be paid back when their contract expires.
For this to be enticing to an LOC, we require that over the period of the contract the amount of money paid for the service of the loan is less than that of alternate means for loans, e.g. local bank loans.

We consider a simplistic example to demonstrate the feasibility of such a scenario.
Consider that a bank loan, which charges IB percent in interest per annum, has an upfront cost of C and is of total amount H.
Over a period of time, t, and assuming no regular repayments are necessary( 7 ), the LOC stands to lose:

C + H((1 + IB)t - 1) - HIIt. (6)

The first term corresponds to the upfront cost of the loan, the second term to total interest owed at time, t, and the final term is potential interest earnings from external investments.
Here we’ve defined an average yearly interest gain from external investments, II.
Alternatively, the LOC may participate with the ChronoBank system.
If the LOC offers H hours of labour, it would receive H(1 - ρ) LHT in return, and would be required to pay (1 + st)H worth of LHT back upon the expiration of the contract (assumed at time, t).
Here s is a percentage representing the average yearly price increase( 8 ) of LHT. It quantifies an inflated price of LHT due to an assumed increase in average wage over the contract period.
Therefore, with the ChronoBank system, the LOC stands to lose,

H(ρ + st) - (1 - ρ)H II t. (7)

The first term here originates from the initial sum taken by ChronoBank, Hρ, and from the price fluctuation of LHT over time.
The second term comes from the potential earnings from external investments with the (1-ρ)H LHT received.
In this simplistic example, an LOC would be economically incentivised to participate in the ChronoBank system if the total fees of the ChronoBank system are less than the total fees of the alternative bank loan, explicitly:

H(ρ + (s + ρII)t) < C + H((1 + IB)t - 1). (8)

Here, (s + ρII) represents the average yearly price fluctuation of LHT combined with ρ percent of an average expected investment return.
With the reasonable assumption that this quantity is less than the interest rate of a bank loan, IB, equation (8) can always be satisfied for some time period, t, given all other variables fixed. In fact, the longer the contractual time, t, the greater the cost-saving is to the LOC.
So in this simplistic example, wecan see that this system incentivises LOCs to participate in the ChronoBank system for longer periods of time( 9 ).

Furthermore, the CBE and LOC are able to adjust both H and ρ during the negotiations of their initial contractual agreement, enabling the tuning of economic incentives in less favourable economic regions/scenarios.

As for LHT holders, their economic incentive is more obvious.
LHT, compared to its stable-coin predecessors, is inflationary-resistant.
Therefore, holders should have an economic incentive to use LHT as its value should increase relative to local inflationary fiat currencies.
We should note that buying and holding LHT as an investment (and therefore decreasing the liquidity of the token) is not in a holder’s best interest, as the gains in doing so are often less than external investment strategies.

3.2. System Stability

This section is concerned with the ability of the ChronoBank system to sustain various economic hurdles, which we refer to as its stability.

The stability of the ChronoBank system hinges on the CBE correctly managing the minting process.
Through the minting process, the two funds, Liquidity Reserve and SGF, are controlled and maintained.

As the system grows, funds will accrue in both the Liquidity Reserve and the SGF.
LHT is only removed from the SGF in the event of an LOC defaulting.
The Liquidity Reserve only decreases in value in the event that a held volatile currency devalues.
Therefore, both funds should grow as the system evolves.
As the funds reach a sustainable level, the percentage of LHT taken during the minting, ρ, can be decreased, further enhancing the economic incentive for more LOCs to join the system.
A greater number of LOCs participating will mean a greater number of LHT in existence and a greater volume of funds accrued in both the SGF and Liquidity Reserve.
The stability of the system will be proportional to the value stored in the SGF and Liquidity Reserve and, therefore, we expect the system to become more stable as it develops.

3.3. Potential Pitfalls

A number of potential pitfalls can occur during the operation of this system.
In this section we briefly summarise the major and most obvious ones, along with our proposed solutions.

An LOC defaulting on its promise of labour-hours.
As previously mentioned, this will be covered by the SGF.
The CBE will burn the necessary LHT from the SGF fund to maintain the 1 to 1 relation of LHT to labour-hours.

• Large supply/demand causing price fluctuations.
This can be handled by a sufficiently deep Liquidity Reserve, which will provide demand in times of high supply and vice versa.
Initially funds from the crowdsale will be placed into the liquidity fund, and as the system grows the liquidity fund will be maintained at a level deemed operationally safe to cover this scenario.

• Redemption of all LHT.
The LHT at any given time will always be backed by contractual labourhours in a 1 to 1 mapping.
Therefore, this scenario is possible and the system will continue to function in this event.
However, the risk in this occurrence lies with the participating LOCs, who will be required to pay back their LHT in the form of labour.
The SGF (Section 2.3.1) can also absorb some of the cost of this scenario.
It will be at the CBE’s discretion to use the SGF to assist in this very unlikely scenario.

• Increased demand at contract expiry.
As a contract expires, an LOC will be required to buy back an equivalent amount of LHT to the labour-hours that are left on the contract.
This could potentially create periods of large demand.
In these scenarios, we will counter the demand with the Liquidity Reserve and, if necessary, the SGF.

4. Future Work

Economic Models.
Key to the success of the ChronoBank system is an informed choice of the aforementioned economic parameters.
It is essential to perform further analysis so as to determine how parameter modification impacts the feasibility and sustainability of the system in a wider context.
This will necessarily be performed before a realworld implementation is constructed.

LaborX.
The digital asset transfer system described in this document is proposed as a first step towards a larger decentralised labour system.
LHT as described by this paper forms the base currency for a decentralised labour exchange platform entitled LaborX.
The intention of LaborX is to enable peer-to-peer exchange of labour-hours with LHT, thereby reducing the centralisation of the proposed ChronoBank system.
LaborX will incorporate a rating system whereby holders of LHT can identify fair trades by examining the quality and/or specialisation of the labour provider, given their history on the platform.
By enabling direct exchange of LHT with labour-hours, the system’s dependency on contractual arrangements with LOCs is significantly reduced.
This potentially reduces the cost and increases the stability of the system as a whole.

5. Conclusion

This paper proposes a non-volatile, inflationaryresistant, digital asset transfer system.
This innovative system is only made possible by recent advancements in blockchain and cryptographic technologies.
Leveraging these technologies, this system tokenises contractual debt in a manner that can be both economically feasible and highly practical for digital platforms, such as LaborX.
The intrinsic value of the proposed token mirrors the average hourly rate of human labour - the most fundamental unit of economic value.

References

[1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.

[2] Tether.to. Tether: Fiat currencies on the bitcoin blockchain. 2014.

[3] Anthony C. Eufemio Kai C. Chng Shaun Djie. Digix’s whitepaper: The gold standard in crypto-assets. 2016.

[4] Fabian Schuh Daniel Larimer. Bitshares 2.0: Financial smart contract platform. 2015.

[5] Investopedia. Contract for difference.

[6] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 2014.

[7] Sasha Ivanov. Waves whitepaper. 2016.

[8] Ethereum Request for Comments (ERC) 20.

[9] The ChronoBank Team. ChronoBank: Business Outline.

[10] IPFS: A peer-to-peer hypermedia protocol to make the web faster, safer, and more open.

[11] Viktor Tron Aron Fisher Daniel A. Nagy.

Notes

(1) The transaction for which may be initiated by anyone, but typically by the CBE.

(2) Assuming 0 ;sblle; d < 1.

(3) All percentages introduced in this document should be read as decimals. Hence (1 - ρ) ;sblge; 0.

(4) This is a poor approximation that assumes a linear growth, where the start of the year is the average wage of that year and the end of the year the is average wage of the following year.

(5) This can occur because the holdings of an LOC increase over time due to assumed external investment.

(6) Combined with the fact that one LHT has a fundamental intrinsic value of one labour-hour.

(7) We use a no-repayment loan to clarify the analogy to our system and remove some mathematical complexity which obscures our point.

(8) This could also potentially decrease.

(9) Adding regular repayments to bank loans adds complexity to this simplistic example and although decreasing the size of the right-hand side of equation (8) it does not change our final result.

Appendix A. Terminology

The following is a list of terms used throughout this document.
CBE - The ChronoBank Entity.
• LHT - Labour-Hour Token.
LOC - Labour-Offering Company.
SGF - Security Guarantee Fund.

Appendix B. Minting Contract Parameters

There are number of parameters that are required to be negotiated during the minting process.
For clarity we list here the variables that should be considered and determined by the CBE during the minting process:
• S - A percentage of the minted tokens to be stored in the Security Guarantee Fund.
• LT - The total percentage to be stored in the liquidity fund.
• l - The percentage of LT dictating how much of the liquidity fund is used as LOC insurance, LI . The remaining funds will be kept for liquidity in L0.
• M - The total number of months until the LOC Insurance LI is transferred to the Security Guarantee Fund. This dictates the rate at which the funds are transferred, i.e. LI /M per month.
• Expiry Date - The expiry date of the contract, whereby the LOC must buy back the value of the minted LHT.

Through the definition of the above variables, the CBE on a case-by-case basis will fix ρ, the total percentage deducted from LOCs initially through the relation (2).

Appendix C. Fee Summary

The fees of the ChronoBank system can be summarised in the following:
• fc - This is the fee taken by the CBE during the minting process for services rendered. We expect fc ;sblisin; [0, 0.01].
• fi - This is the issuance fee, which will be taken during minting and deposited into the TIME token holder’s rewards contract. This will start at 3 percent and decrease by 1 percent each year until it is maintained at a steady 1 percent.
• ft - These are transaction fees, which are deposited into the TIME token holders rewards contract. This is a flat fee of 0.15%.
• fr - This is a fee taken by the CBE during the redemption process for services provided and to add a deterrent to continual redemption requests. We expect fr ;sblisin; [0, 0.01].

chbprl'LaborX-white-paper (chblxw)

AddressWpg::
* https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf,

WORKING DRAFT: CHRONOBANK - PHASE 2: LABORX DECENTRALISED MARKETPLACE
THE CHRONOBANK TEAM
CHRONOBANK.IO
INFO@CHRONOBANK.IO
{retrieved 2017-03-20}

Abstract

In Phase 1, Chronobank introduced labour-hour tokens which represent the average value of one labour hour.
This phase involves the design and construction of a decentralised platform capable of making labour exchange as easy as riding a taxi with Uber.
This white paper describes a decentralised marketplace where people of real-world professions will be able to sell their labour to any participating client of the system.
LaborX is a proposed implementation of the described system.

This is a draft version of the white paper prepared for community review.
A Bounty of 1000 TIME tokens (an equivalent of 10 BTC) will be divided between the best contributors.
To participate, join our #whitepaper Slack channel.
To a get Slack invite, visit https://chronobank.herokuapp.com

1. Introduction

In 2009 (the same year that Bitcoin emerged), Uber, a mobile application which revolutionised the taxi business, was developed.
The easy to use, fast and comfortable service made Uber a worldwide company with $1.5 billion in revenue.
Uber removes the middleman – in its case, the taxi dispatcher - from the buyer/seller equation, allowing each driver to be his boss and work independently of a central company[ 1 ].

Similarly, LaborX aims to revolutionise the labour hiring industry by providing an open and decentralised ecosystem.
It has the potential to benefit both highly skilled workers, who prefer independence or a more flexible work schedule, as well as low-skilled labourers who will be able to find flexible part-time work when it is convenient for them.
LaborX targets offline workers providing real-life services which cannot be done remotely or supervised by special software.

The Problem.
Currently, numerous agencies are providing centralised services which offer to hire workers listed in their internal databases.
The reputation of such a system is fundamentally linked to the centralised agency which verifies and endorses the workers within the system.
Further, such systems often fail to disclose employee’s experience, reputation, or past jobs.
The situation is complicated even more by inflated agency fees and a plethora of agencies to choose from for any particular job.

Proposed Solution.
The LaborX Platform is a decentralised system that not only provides a labour hire marketplace but also is capable of automating (at least in part) the process of hiring individual workers given specific contract work.
This includes the selection and vetting of workers based on the main attributes, such as availability, location, a field of work, skills, and reputation.
This system leverages blockchain technology, specifically Ethereum, for its core systems and can therefore significantly lower operational and maintenance costs relative to competitors in the labour-hire industry.
Moreover, the public nature of Ethereum will allow participants to view all worker’s previous experience and recommendations.
The system will also utilise the commercial side of blockchain enabling immediate payments for completed work.
In addition, decentralisation allows the system to be global, autonomous, and versatile in the sense that workers and clients can accept a variety of location-independent currencies, in the form of any ERC20[ 2 ] compatible tokens (such as Labour Hour tokens[ 3 ]).

Contributions.
This paper provides a high-level overview of a blockchain-based decentralised labour hiring system and its conceptual realisation in real world applications.
Section 3 provides an overview of the base system components and processes including minor technical details.
Section 4 provides economic considerations in brief, regarding the real-world deployment of this system and its feasibility.
Section 5 describes the rating system that allows the community to have control over LaborX.
Section 6 is focused on interface features.
Section 7 details how privacy issues are handled.

2. Design goals

We aim to make short-term employment as accessible and rewarding as long-term employment, giving workers the flexibility to determine their schedules while being paid a fair rate for their time, expertise, and reputation.
We plan to achieve this through the LaborX platform, which will enable trading of labour time at market rates.
A decentralised reputation system will facilitate feedback for each entity, allowing employers to hire the most competent professionals.
It will also enable individual workers to secure payment in line with their training, skills, and experience.

LaborX system is designed specifically to target workers in the labour industry (areas such as cleaning, plumbing, gardening, etc.).
The system is intended to be distributed and have no central controlling authority.
This means that it wouldn’t be controlled by any single individual or company, but by a set of publicly verifiable predefined rules.
Anyone can fork, modify and redeploy the system, like it can be done with the Ethereum network itself[ 4 ].

The system has to satisfy the following usage requirements:
(1) The client should be offered a selection from the most competent workers based on their search preferences.
(2) Workers that have higher ratings should have higher compensations.
(3) A worker can set their own rate.
(4) Both the client and the worker should have a rating.
(5) Both the client and the worker can reject a given sealed job contract (see more at Section 3.2).
(6) The worker always receives money for the time they spent on labour.
(7) The client should be able to stop work at any time.
(8) The system should vet clients and workers that have bad ratings.
(9) The client could pay with any ERC20 cryptocurrency, should the worker accept these tokens.

3. System overview

The decentralised nature of this system allows clients to hire workers using the Ethereum blockchain.
Thus the core features of the system will run as a set of smart contracts[ 5 ], making the system available for use independently of any particular user interface realisation.
These contracts will govern the behaviour of the system, dictate the agreements between parties, and serve as a public ledger containing profiles of clients and workers.

imgChblxwFig1.png
Figure 1. Sequence diagram

3.1. Actors

This section defines the six most important entities
within the system: the client, worker, evaluator, verificator,
provider, and the LaborX core (whose functionalities
are depicted in Figure 1).

The client - a person or party that requires work to be completed.
They create job(s) with key attributes (such as field of work, skills required, etc( 1 )) which gets posted to the ledger.
The client then retrieves a list of available and qualified workers which they can select based on preference.
The worker(s) may then accept the job and provide approximate estimates for the amount of time required to complete it.
At this point, the system will allow the client and worker(s) to begin direct communication, should it be desired.
Then the client has to agree on the estimations given by the worker.
Upon agreement, a smart contract will facilitate the withdrawal of funds (equivalent to the value of the estimated hours of work) from the client’s account to an escrow-like smart contract on the blockchain.
The funds will then be released on a per-hour basis to the worker as work is completed.
To ensure correct hours are paid, a stop-start timer is used.
As a worker arrives, they seek approval from the client to begin the timer and commence the paid work period.
The same is done at the end of the period or work segment.
The client can revoke the job before it begins and can withdraw the deducted funds from the escrow-like smart contract.
The client may give a rating to the worker upon job completion/termination and optionally a recommendation.

The worker - any person or party seeking jobs who is capable of working and getting paid.
A worker creates a public profile containing labour scopes, working hours, and other relevant information.
Based on this profile, a worker would be offered by LaborX to clients for jobs matching their labour scopes.
If selected, a worker will be notified and asked to provide time estimates to complete the specific job.
The worker is then able to contact the client to finalise details (if needed) before finalising the agreement.
The worker should then arrive at the negotiated time to begin the work.
The approval to start/stop the timer for paid work can then be given by the client, as described above.
Upon completion/termination of a job, the worker can rate the client and optionally provide additional comments.

The evaluator.
The highest ranked members of a community will be able to evaluate and confirm corresponding skills of workers, building a chain of trust.
In this way, clients will be sure that the assigned worker has all the required skills for completing the job.
Workers will be required to have a high rating and enough activity points to become an evaluator.
Evaluators may verify and endorse skills of other workers ensuring clients have a more accurate description of their potential workforce.
Workers with endorsed skills will typically have a greater chance to be selected for any given job by the LaborX core.
After performing worker’s skill assessment the evaluator publishes a record in blockchain.
Evaluator’s profile displays statistics of appraised workers and evaluator’s reputation among LaborX users depends on it.

The verifier - a worker who offers services to verify clients and workers in a particular region (See the functionality in Figure 1).
The fundamental role of verifiers is to check required documents for their respective areas, such as work permit, certificate, injury insurance or other types of insurance.
These entities are essential to adhere to local laws, enhance security, and potentially minimise spam issues.
Both parties (clients and workers) may choose a single or many verifiers to review their documents, based on their rating and popularity.
Each worker has a public profile and private data.
The public profile is available in the blockchain and is accessible to everyone.
The private data is verified and electronically signed by a verifier.
It is only available to a client after they enter into a contract with the worker (more information is given in Section 7).

The provider - an entity who has created a job board.
The nature of the blockchain means that participants are pseudonymous by default.
This opens wide opportunities for spammers, marketing bots and other parties whose behaviour would be disruptive for LaborX.
The decentralisation of the system means that there is no single authority who can ban these entities.
A proposed solution is to give participants ability to create job boards, where the creator is also the moderator.
Each board would have a rating from other participants and each participant having a threshold of activity points would be able to vote up or down on boards.
The job board creator will be able to appoint other members as moderators.
Each board member having sufficient activity points would be able to flag any suspicious entry for review and receive activity points for helpful reports.
The boards would be filtered by tags and sorted by rating in the client application to easily remove/filter all junk boards.
The job board creators also can enforce requirements for the clients and workers that want to use the board.
They could include a requirement to pass verification by one of the listed verifiers, to have at least specified minimal rating, to perform a job in defined fields of work, to accept payment in selected cryptocurrency, to be located in specified area etc.

LaborX core - a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic.
This system provides the mechanisms that allow jobs, profiles, and other public data to be stored in the blockchain.
It is capable of searching for available workers in job boards based on location, field of work, and skills thus giving clients a choice to pick worker(s) that best suits their needs.
After a client makes this selection, LaborX core provides the functionality that sends notifications to the worker to accept/decline a specific job via Ethereum events.
LaborX core is also responsible for calculating, storing, and retrieval of rating on the blockchain.
Every client and worker will have a rating which increases/decreases as recommendations accrue after jobs are completed.

3.2. LaborX core functionality

LaborX core is a complex system powered by the Ethereum network.
It contains all users’ public profiles, completed jobs with description, executor, status, and mutual ratings.
However, considering the system complexity, we have chosen to distinguish LaborX core from LaborX DApp.
LaborX DApp functionality will include interface for creating profiles, verification, evaluation, searching workers, concluding contracts etc (see Section 6 for full description of features).
This section will provide a more specific description of the key parts of LaborX core and we will postpone further discussion of LaborX DApp to Section 6.

A job object (the programmatic object relating to a real-world job) will contain a location, provider used and work description.
The work description includes attributes such as field of work, job due date, address of ERC20 token contract (that will be used for payment), required skills, and further optional job-specific requirements.
A client would be capable of searching through the list of workers in job boards or choosing a familiar worker.
Fields of work and required skills can be selected from a list offered by the smart contract.
A location is also a selectable parameter that will typically represent a city/region.
If a city/region is large, then a district/sub-region may be specified.
A city/region includes all of its districts/sub-regions.
A location is used to map workers to nearby clients.
Precise addresses (for job locations) will be revealed to workers once the job has been mutually agreed on and solidified by the smart contract.
A job due date can be a present or future time.
If the current time is selected, then LaborX returns all currently available workers ready to start a work now.
If instead a future time was chosen, then the system will find workers available to work at the chosen time.
Once the worker accepts the job, the smart contract will publicly mark the worker as busy, preventing further bookings in that period.

imgChblxwTbl1.png
Table 1. Responsibilities distribution of LaborX core and LaborX DApp

3.3. Billing and penalties

Billing will be governed by the following scheme:
Once a worker’s estimates have been approved by the client, a smart contract withdraws the required tokens/currency from the client’s account.
If the work takes more time than initially estimated and approved by the client, then the smart contract verifies the client’s balance and automatically withdraws additional funds to account for the overtime.
As this is an automatic process, the worker can continue to work freely and be sure that their overtime will be paid.
This procedure repeats hourly.
The process stops if either the job is paused, or marked as finished, or the client runs out of money, or the smart contract reaches a maximum withdraw limit( 2 ).
If this limit is reached, the smart contract may ask the client to increase the maximum withdrawal limit.
If the client declines, the job is considered finished, and any remaining funds are released to the worker.
If the worker works less than the estimated time, the difference is transferred back to the client.
Part of the tokens paid for the job is automatically withdrawn as a fee (see more at Section 4).
Worker has an ability to pause and continue job timer at any time.
If the client is not satisfied with the worker, their accountability, or their work they can cancel the job at any time.
Nevertheless, the client is required to pay a minimum of one hour (which is a minimal time unit that can be paid).
The client may then leave a negative recommendation and rating that will negatively flag the worker for future clients.
A negative rating will also adversely affect evaluator’s reputation.
If the worker doesn’t start work within the agreed time, the client will not be charged but is still able to rate the worker and leave a comment.
It should be noted that client does not pay the worker’s transportation time and expenses.
Instead, they should be included in the worker’s individual rates.

3.4. Scalability and contract upgrades

The implementation of LaborX DApp, specifically the search and worker selection, will allow the system to be easily scalable.
Yet, due to the systems complexity, it is probable that software bugs will be discovered.
Therefore, a mechanism to upgrade smart contracts and core system functionality will be required.
LaborX will use the following approach:
(1) Application data will be stored in contracts that are separated from business logic.
(2) Each record will contain a version number.
(3) Each contract will have a constant external interface.
(4) No migration can happen without a user’s consent.

In this way, contracts can be upgraded without the need to migrate data. Switching to a new contract version is the smart contract equivalent of accepting terms of service, updated by a service provider.
Each user will have an option to either migrate to a new contract version or to continue using the current one.

imgChblxwFig2.png
Figure 2. Relationships between different parties inside decentralised LaborX system.

4. Economic model

LaborX is a multi-currency service that will support any token that complies with the ERC20 standard[ 2 ] including, but not limited to, Labor Hour tokens.
A simple multi-currency wallet capable of receiving and sending any supported ERC20 token will be integrated into the LaborX platform.
Users will be able to pay and get paid by tokens they choose from a list of supported on job boards tokens.
Providers may list local currencies, allowing communities to pay for jobs in unusual digital assets, should both the client and the worker accept the currency by selecting the job board.

As mentioned in the previous section, the LaborX system will deduct 1%( 3 ) from each completed job part of which will go as a revenue to TIME token holders and other part to providers for their services.
Provider receives payment only for completed jobs posted on provider’s job board.

4.1. Benefits

For clients.
There are numerous benefits for clients.
Because of smaller mediator fees than in traditional labour hiring companies, the resulting work price will be lower.
Decentralisation of the service makes it fast, reliable, secure, and permanently available.
A public worker rating system ensures that clients are seeing profiles of real workers along with their unique histories and therefore genuine ratings.
The ability to pay with a variety of digital tokens makes the system universal and not tied to any particular country/region.
Furthermore, LaborX will implement an easy to use interface, paying serious attention to UX.

For workers.
Benefits for workers are also significant.
Due to lower fees than in traditional labour hiring companies workers may ask for higher hourly rates.
The most skilled and responsible workers with the best ratings will be highly sought after and may, therefore, demand a higher hourly fee than their not-so-amazing colleagues.
For the first time in the labour hire industry, diligent and attentive workers will be rewarded for providing better services.
The decentralised nature of LaborX will not only guarantee that workers will get paid, but will enable real-time payment to the worker as the work is completed.
Since the system is fully automated, the workers will be able to plan their schedules corresponding to their preferences.

5. Rating and activity points system

For every worker and client there are two metrics called rating and activity points.
The first describes how well a client or worker performs their duties and is dictated by their partners.
The second is a point system based on all LaborX activity.

The better the individuals rating (based on previous work), the higher the price they are be able to demand for an hour of work.
After a job is completed, both the client and worker are asked to rate to each other.
The rating is in the range between 1 and 10, where 1 corresponds to a total disaster and 10 represents exceptional work.

The rating system will be time and quantity aware.
By this, we mean that older ratings should contribute less to the current rating than recent ratings (i.e., the ratings are recency-weighted).
This means, for example, a bad rating accrued a year ago by a worker, can be redeemed by a series of recent good ratings, thus restoring the reputation of the worker.

Activity points are used only in the LaborX DApp and have a crucial security role by limiting the amount of available functionality to newcomers.
This limits threats such as spamming, posting advertisements with ambiguous links, or evildoers trying to overload the system with an infinite job posting.

Every new user begins with a single activity point which will automatically increase when performing various actions inside the app (see Table 2).
An alternative way to gain activity points is by verifying one’s identity with various verificators or by passing skill assessment with an evaluators.
The activity points count will always be greater than or equal to 1.

An example of activity point elevators are given in Table 2.
Some of the proposed features that will require some amount of activity points is given in Table 3.
The listed values in these tables are examples only and may change during the implementation and system testing period.

imgChblxwFig3.png
Figure 3. Contract interaction diagram

imgChblxwTbl2.png
Table 2. Actions that affect activity points.

imgChblxwTbl3.png
Table 3. Actions that require activity points.

5.1. Rating and activity points growth

imgChblxwTbl4.png
Table 4. Rating and activity points growth example.

6. LaborX DApp features

6.1. Verification and evaluation

One of the top priorities of the LaborX platform is to ensure that every client is comfortable letting workers into their house/workplace and every worker is provided with a safe workplace environment.
To this end, LaborX is designed with specific focus on worker/client confidence.
This is achieved through decentralised verification and evaluation features.
They will offer a range of verification possibilities allowing workers to choose those that suits them best.
The following gives a non-exhaustive list of possible options( 4 ):

Verification.
Entities with high reputation could serve as verification hubs and be paid for their services by workers.
They will check that worker’s documents correspond to the worker’s identity, scan documents, publish document hashes[ 6 ] in the blockchain and confirm this action by signing the hashes with their digital signature (see Section 7 for more information).

Evaluation.
The highest ranked members of a community will be able to evaluate and confirm corresponding skills of workers, building a chain of trust.
In this way, clients will be sure that the assigned worker has all the required skills for completing the job.

Evaluation by Clients.
Any verified client may advertise individual worker’s skills after completing the job if some of them are exceptional.
This information would be used to separately promote the workers who are constantly rated 10/10.

6.2. Workers selection

According to the current model, the governing smart contract returns a selection of workers that fit the criteria of a given job posted by a client.
The LaborX DApp takes preference of workers who have more completed jobs and higher ratings.
The system may grow such that the ratio of workers to jobs becomes quite large.
It is therefore important that the LaborX DApp does some advanced filtering.
This means that the application should not show all workers capable of performing a given job, instead select only several of the available best workers with varying rates and ratings.
In this way, the most competent workers will get more work and will be paid more for their reputation.
Clients may also use different custom filters that will help them to find the most fitting worker to suit their needs.
They may also pick specific workers they are already familiar with.
The application will also utilise smart filtering to minimise the worker intersection between clients.
This is crucial for the system, especially when considering similar jobs.

6.3. Multi-currency support

The LaborX platform will include multi-currency support, making sure users can use different ERC20 tokens to purchase labour.
Each LaborX provider will be able to set cryptocurrencies that will be permitted for payments on their job boards.
Clients and workers who choose a job board, agree to use one of the supported methods of payment.

6.4. Search

High load testing and analysis would be performed while developing LaborX to determine exact implementation and architecture of the search system.
The main part of a search logic should be performed in the LaborX LaborX core.
Only Ethereum transactions that write to blockchain have gas limit and cost Ether.
The search operation is read-only, therefore it would perform computations on user’s Ethereum node and will not require paying Ether.
A worker-to-job matching will include complex queries and therefore require a significant amount of computational power of the machine where Ethereum node software is running.
Therefore LaborX DApp could handle part of the filtering and caching logic on client’s side.
This approach will significantly improve the user experience.

6.5. Messaging

LaborX will use a messaging system with an underlying protocol like Whisper[ 7 ], enabling client and worker to establish an encrypted connection.
These messages could be used to exchange job details, address, confidential instructions, etc.
The exact realisation will be decided at the time of development (specified in the LaborX road map), taking into account the potential research and new possibilities that will be available in 2017.

6.6. Features to be developed

Other features that are planned for LaborX but not described in this white paper include moderation and arbitration system powered by providers, usage of IPFS for data storage, and the Truffle framework for smart contracts on Solidity.
The LaborX DApp will have a modern responsive interface (see, for example, the ’Post new job’ and ’Edit worker profile’ wireframes in the appendix A).

7. Privacy

It is truly unsafe to publish sensitive, private data in a blockchain.
However, we have to eliminate the possibility of a worker re-registering to reset their profile.
Therefore, we have to maintain a balance between anonymity and notoriety.
To achieve this, each worker will have a publicly available blockchain profile containing their nickname (first name and the first letter of their surname), small photo, field(s) of work, skills, rating, rate, activity points, approximate location, a list of completed jobs and payments.
Optionally, a worker may apply for a document verification or a skill evaluation (see Sections 3, 6) which will be reflected in his public profile and confirmed by the electronic signature of the governing party.
There will be a data set which will never appear on the blockchain.
This includes, but is not limited to, the exact geolocation of the client and the worker, additional private instructions for the worker, document scans.

Hashes[ 6 ] of private data blocks will be published on the blockchain to prove that they have not been altered.
These hashes should also be electronically signed by submitter of the stored information and linked to the worker’s public profile.
In this way, only the signature and hash of the sensitive information will be publicly available, and any confidential data may be stored without revealing it to the public.
An entity which gains authorised access to the information will also be able to check the signature to prove the origin of information.

imgChblxwFig4.png
Figure 4. Verification of documents

8. Conclusions

This white paper proposes a decentralised system designed to revolutionise the labour-hire industry.
It will be capable of automatically matching available workers to corresponding jobs according to their location, field of work, skills, and reputation.
Using the Ethereum blockchain as a basis, this system can significantly lower fees for system maintenance, relative to traditional systems offering a similar service.
Moreover, decentralisation makes the system autonomous and global as it runs on Ethereum and is capable of using any currently existing ERC20[ 2 ] tokens.
This innovative system is only made possible by recent advancements in blockchain and cryptographic technologies.
Leveraging these technologies this system allows people to trade human labour - the most fundamental unit of economic value.

References

[1] The Huffington Post. ’uberization’ of everything is happening, but not every ’uber’ will succeed. http://www.huffingtonpost.ca/2015/04/01/uberization-uber-of-everything_n_6971752.html, 2015.

[2] Ethereum Foundation. Erc20: Ethereum token standard. https://github.com/ethereum/EIPs/issues/20, 2015.

[3] The ChronoBank Team. Chronobank - phase 1: A non-volatile digital token backed by labour-hours. https://chronobank.io/files/whitepaper.pdf, 2016.

[4] Ethereum Classic. Website. https://ethereumclassic.github.io/, 2016.

[5] D. Tapscott and A. Tapscott. Blockchain Revolution: The Brilliant Technology Changing Money, Business and the World. Penguin Books Canada, 2016.

[6] Wikipedia. Cryptographic hash function. https://simple.wikipedia.org/wiki/Cryptographic_hash_function.

[7] Ethereum Foundation. Whisper wiki article. https://github.com/ethereum/wiki/wiki/Whisper, 2016.

Notes

(1) Additional requirements are detailed in section 3.2.

(2) This is typically double the estimated total price, but can be adjusted on a per-job basis.

(3) Percentage may change during the implementation and system testing period.

(4) This list has not yet been finalized.

Glossary

activity points:
is an integer in a range of 1 to infinity which measures positive contribution to LaborX ecosystem.
The more activity points the user has, the more advanced actions they can perform.
See the full list in Table 2. 2, 3, 5

client:
is a person that has some work and needs to get it done.
Client posts a job and pays for it. 2

DApp:
is an abbreviated form for decentralised application.
A DApp has its back-end code running on a decentralised peer-to-peer network.
Contrast this with an app where the back-end code is running on centralised servers. 3–7

evaluator:
a highly rated worker with lots of experience and reputation which prove they are a master in their field of work and thus can verify skills of other workers. 2, 5

job:
is some work or task to get done.
Job can be a list of tasks but all within one field of work. 2

job board:
is a publicly available database managed by the creator.
It will be implemented as a smart contract in Ethereum network.
More information in Section 6. 3, 5, 6

LaborX core:
this is a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic. 2, 3, 6

ledger:
is a publicly available database that holds information.
It will be implemented as a smart contract in Ethereum network. 2

provider:
is an entity which offers its services to connect clients and workers through a job board because of legal, security, or spam issues.
Anyone can become a provider, and both parties (a client and a worker) could choose which providers they trust.
Providers get paid for their services by receiving a percentage of job payment fees. 2, 3, 5–7

rate:
amount of money that will be paid hourly to a worker. 1, 2, 6, 7

rating:
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures
the quality of work done by a worker.
LaborX uses rating to select workers for a job. 2–6

verificator:
a worker with flawless reputation who offers services of verification for documents and
identity of other entities. 2, 5

worker:
is a person that is assigned to fulfil client’s job and get paid for it. 2

Appendix A. LaborX Wireframes

imgChblxwFig5.png
Figure 5. Client’s jobs screen10

imgChblxwFig6.png
Figure 6. Worker’s profile editing

chbprl'Business-outline (chbbon)

Name::
* cpt.chbbusiness-outline,
* cpt.chronobank-business-outline,

AddressWpg::
* https://chronobank.io/files/business_outline.pdf,

chbsvc'Blockchain

Description::
ChronoBank.io is a blockchain project aimed to disrupt HR/recruitment/finance industry similar way as Uber revolutionised taxi business.
{2017-01-19}
Why ChronoBank will use multiple blockchains
ChronoBank will use several different blockchains to issue and trade LH tokens, likely including Waves, Ethereum and NEM. The reasons are financial, cultural and ideological.
Many new crypto projects launch their own blockchain and have a single, dedicated token to represent value on their network. ChronoBank is taking the approach of issuing both its native asset, TIME, and Labour Hour (LH) tokens on multiple blockchains. As time goes on and popular new protocols arise, we will issue tokens on those as well. There are several reasons for this, both practical and ideological.
1. Sustainability
Our priority is to create a long-term blockchain-based solution for the labour-hire industry. Cryptocurrency is still in its infancy and we currently don’t know which protocols will survive. Technical problems may become evident in due course, rendering one or more blockchains non-viable. Others may be impacted in ways we cannot foresee. In the past, for example, different cryptocurrencies have fallen from favour due to a large number of factors: the loss of one or more core developers; poor distribution, which led to large quantities of coins being sold and loss of wider confidence; unpopular changes or forks; inadequate funding for promotion and development. All of these and more have hamstrung otherwise healthy blockchain projects.
Therefore we are decentralising our issuance across many blockchains; should popular new platforms arise in the future, we will use these too. That way, ChronoBank will never be rendered obsolete in the way that some other projects that launched on blockchains the market eventually deemed wanting have been.
2. Synergy
We want to engage many different communities to achieve our aims. This means not only seeking investment from several of the major blockchain ecosystems in order to give us the funding to launch ChronoBank, but working with them for their expertise and to build business relationships. As a cross-blockchain project, we think that ChronoBank has the ability to bring together the best elements of these protocols and communities under one roof. That will inevitably bring benefits for our own project, but to each of the others, too.
3. Success
The priority is crypto adoption, the creation of fair money and a more just economy. Using many blockchains is simply the best way to do this. The crypto world is fragmented, with tribal loyalties to specific blockchains often taking precedence over broader ideals like disintermediation and the redistribution of financial power. We know that restricting ourselves to a single blockchain will very likely hamper our overall chances of making the impression we need to in the crypto world and bringing about meaningful change in the recruitment sector. The more communities we work with, the more liquid and better traded our tokens will be; the higher profile our project will have; the more people will have a reason to help us succeed. We’re pleased to be blockchain-agnostic in order to prioritise the success of ChronoBank.
[https://blog.chronobank.io/why-chronobank-will-use-multiple-blockchains-9da5a70eaaea]

chbsvc'Program (chbpgm)

chbpgm'Doing

chbpgm'Developing

Description::
Two Week Software Cycle
We are pleased to announce that we will be switching from a feature-based versioning and release model to a continuous release model with a two-week, two-phase software cycle.
The first phase is a one week merge period. In this week any stable Pull Requests will be accepted into the development branch. The second phase is a one week test/regression and release period. During this stage we will branch a new release/version, then test, patch or undo any PRs that are unstable.
This will allow a process of continual deployment and incremental improvement for LaborX, while also allowing features to develop and mature before being included into the release version. The approach also allows us to ‘roll back’ or regress certain changes, should they become problematic. Hopefully this will enable us to release a new version of LaborX consistently every two weeks .
[https://blog.chronobank.io/chronobank-dev-update-7-49b387396b2c#.odbp6hdr9 {2017-03-26}]

chbpgm.SPECIFIC

Specific::
* Smart-contract,
* LaborX-dApp,
* ChronoMint-dApp,
* ChronoWallet-dApp,
* ChronoWaves-dApp,
* Wallet-dApp,

chbsvc.Smart-Contract (chbctp)

Description::
ChronoMint, Labour Hours and Time contracts.
ChronoBankPlatform.sol acts as a base for all tokens operation (like issuing, balance storage, transfer).
ChronoBankAsset.sol adds interface layout (described in ChronoBankAssetInterface.sol)
ChronoBankAssetWithFee.sol extends ChronoBankAsset.sol with operations fees logic.
ChronoBankAssetProxy.sol acts as a transaction proxy, provide an ERC20 interface (described in ERC20Interface.sol) and allows additional logic insertions and wallet access recovery in case of key loss.
EventsHistory.sol holds all operations events to avoid events lost in case of contract replacement during upgrade or extension.
ChronoBankPlatformEmitter.sol provides platform events definition.
[https://github.com/ChronoBank/SmartContracts]

Name::
* cpt.chbctp,
* cpt.chronobank-smart-contract,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts,

Specific::
* ChronoBankAsset.sol,
* ChronoBankAssetInterface.sol,
* ChronoBankAssetProxy.sol,
* ChronoBankAssetProxyInterface.sol,
* ChronoBankAssetWithFee.sol,
* ChronoBankAssetWithFeeProxy.sol,
* ChronoBankPlatform.sol,
* ChronoBankPlatformEmitter.sol,
* ChronoBankPlatformInterface.sol,
* ChronoMint.sol,
* Configurable.sol,
* ContractsManager.sol,
* ERC20Interface.sol,
* EternalStorage.sol,
* EventsHistory.sol,
* Exchange.sol,
* ExchangeInterface.sol,
* LHT.sol,
* LOC.sol,
* Managed.sol,
* Migrations.sol,
* Owned.sol,
* Rewards.sol,
* Rooted.sol,
* Shareable.sol,
* TIME.sol,
* Vote.sol,

chbctp.ChronoBankPlatform.sol

Description::
ChronoBankPlatform.sol acts as a base for all tokens operation (like issuing, balance storage, transfer).
- keep balances,
- manage transfers,
- manage asset issuance,

Name::
* cpt.ChronoBankPlatform.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankPlatform.sol,

chbctp.ChronoBankAsset.sol

Description::
ChronoBankAsset.sol adds interface layout (described in ChronoBankAssetInterface.sol)
[https://github.com/ChronoBank/SmartContracts]

Name::
* cpt.ChronoBankAsset.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankAsset.sol,

Specific::
* ChronoBankAssetWithFee.sol,
* TIME.sol,

chbctp.ChronoBankAssetWithFee.sol

Description::
ChronoBankAssetWithFee.sol extends ChronoBankAsset.sol with operations fees logic.
[https://github.com/ChronoBank/SmartContracts]

Name::
* cpt.ChronoBankAssetWithFee.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankAssetWithFee.sol,

Generic::
* ChronoBankAsset.sol,
* Owned.sol,

chbctp.TIME.sol

Name::
* cpt.TIME.sol,

Generic::
* ChronoBankAsset.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/TIME.sol,

CodeChbctp::


pragma solidity ^0.4.8;

import "./ChronoBankAsset.sol";

/**
 * @title ChronoBank TIME tokens contract.
 *
 * The official ChronoBank TIME implementation.
 */
contract TIME is ChronoBankAsset {

}
    

chbctp.ChronoBankAssetProxy.sol

Description::
ChronoBankAssetProxy.sol acts as a transaction proxy, provide an ERC20 interface (described in ERC20Interface.sol) and allows additional logic insertions and wallet access recovery in case of key loss.
[https://github.com/ChronoBank/SmartContracts]

Name::
* cpt.ChronoBankAssetProxy.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankAssetProxy.sol,

chbctp.ChronoBankAssetWithFeeProxy.sol

Name::
* cpt.ChronoBankAssetWithFeeProxy.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankAssetWithFeeProxy.sol,

chbctp.EventsHistory.sol

Description::
EventsHistory.sol holds all operations events to avoid events lost in case of contract replacement during upgrade or extension.
[https://github.com/ChronoBank/SmartContracts]

Name::
* cpt.EventsHistory.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/EventsHistory.sol,

chbctp.ChronoBankPlatformEmitter.sol

Description::
ChronoBankPlatformEmitter.sol provides platform events definition.
[https://github.com/ChronoBank/SmartContracts]

Name::
* cpt.ChronoBankPlatformEmitter.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankPlatformEmitter.sol,

chbctp.LHT.sol

Name::
* cpt.LHT.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/LHT.sol,

CodeChbctp::


pragma solidity ^0.4.8;

import "./ChronoBankAssetWithFee.sol";

/**
 * @title ChronoBank LHT tokens contract.
 *
 * The official ChronoBank Labour-Hours implementation.
 */
contract LHT is ChronoBankAssetWithFee {

}
    

chbctp.Owned.sol

Name::
* cpt.Owned.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/Owned.sol,

Specific::
* ChronoBankPlatform.sol,
* Configurable.sol,

chbctp.Configurable.sol

Name::
* cpt.Configurable.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/Configurable.sol,

Generic::
* Owned.sol,

chbctp.Rewards.sol

Name::
* cpt.Rewards.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/Rewards.sol,

chbctp.INTERFACE

Specific::
* ChronoBankAssetInterface.sol,
* ChronoBankAssetProxyInterface.sol,
* ChronoBankPlatformInterface.sol,
* ERC20Interface.sol,
* ExchangeInterface.sol,

chbctp.ChronoBankAssetInterface.sol

Name::
* cpt.ChronoBankAssetInterface.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankAssetInterface.sol,

CodeChbctp::


contract ChronoBankAssetInterface {
    function __transferWithReference(address _to, uint _value, string _reference, address _sender) returns(bool);
    function __transferFromWithReference(address _from, address _to, uint _value, string _reference, address _sender) returns(bool);
    function __approve(address _spender, uint _value, address _sender) returns(bool);
    function __process(bytes _data, address _sender) payable {
        throw;
    }
}
    
chbctp.ChronoBankAssetProxyInterface.sol

Name::
* cpt.ChronoBankAssetProxyInterface.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankAssetProxyInterface.sol,

CodeChbctp::


contract ChronoBankAssetProxyInterface {
    function __transferWithReference(address _to, uint _value, string _reference, address _sender) returns(bool);
    function __transferFromWithReference(address _from, address _to, uint _value, string _reference, address _sender) returns(bool);
    function __approve(address _spender, uint _value, address _sender) returns(bool);
}
    
chbctp.ChronoBankPlatformInterface.sol

Name::
* cpt.ChronoBankPlatformInterface.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ChronoBankPlatformInterface.sol,

CodeChbctp::


contract ChronoBankPlatformInterface {
    /**
     * Returns asset balance for a particular holder id.
     *
     * @param _holderId holder id.
     * @param _symbol asset symbol.
     *
     * @return holder balance.
     */
    function _balanceOf(uint _holderId, bytes32 _symbol) returns(uint);

    /**
     * Returns current address for a particular holder id.
     *
     * @param _holderId holder id.
     *
     * @return holder address.
     */
    function _address(uint _holderId) returns(address);

    function reissueAsset(bytes32 _symbol, uint _value) returns(bool);
}
    
chbctp.ERC20Interface.sol

Name::
* cpt.ERC20Interface.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ERC20Interface.sol,

CodeChbctp::


contract ERC20Interface {
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed from, address indexed spender, uint256 value);

    function totalSupply() constant returns (uint256 supply);
    function balanceOf(address _owner) constant returns (uint256 balance);
    function transfer(address _to, uint256 _value) returns (bool success);
    function transferFrom(address _from, address _to, uint256 _value) returns (bool success);
    function approve(address _spender, uint256 _value) returns (bool success);
    function allowance(address _owner, address _spender) constant returns (uint256 remaining);
}
    
chbctp.ExchangeInterface.sol

Name::
* cpt.ExchangeInterface.sol,

AddressWpg::
* https://github.com/ChronoBank/SmartContracts/blob/master/contracts/ExchangeInterface.sol,

CodeChbctp::


contract ExchangeInterface {
  function setPrices(uint _buyPrice, uint _sellPrice) returns(bool);
}
    

chbpgm.ChronoMint-dApp

Description::
Control panel for ChronoBank and Labour-Offering Companies.
[https://github.com/ChronoBank/ChronoMint]

Name::
* cpt.ChronoMint,

chbpgm.ChronoWallet-dApp

Description::
Secure wallet for storing tokens
[https://github.com/ChronoBank/ChronoWallet]

Name::
* cpt.ChronoWallet,

chbpgm.ChronoWAVES-dApp

Description::
Waves is a natural partner for ChronoBank due to its straightforward and user-friendly token-creation facilities. ‘We consider every blockchain with CATs (Custom Application Tokens) functionality as a potential infrastructure for LH tokens,’ comments ChronoBank’s lead developer. ‘We have recently started development of ChronoWAVES and have been in touch with Waves’ developers from the beginning, familiarising ourselves with all the technical details of the platform. ChronoWAVES will be an advanced lite wallet implemented in Javascript and fully compatible with the original Waves GUI.’
In addition to basic features such as blockchain data validation on the client side and multi-address accounts, the Waves version of the ChronoWallet will be tightly integrated with ChronoBank’s services, natively supporting LH tokens issued on the Waves blockchain. A key feature to be used by the wallet is Waves’ decentralised exchange (DEX), soon to be released on mainnet.
‘After release it will allow trades to be settled on the blockchain and we are going to utilise this fully for the exchange of Labour Hours. Additionally, a token-swap feature will offer potential integration of Ethereum tokens with the Waves blockchain. We definitely plan to share our contribution in the JavaScript infrastructure for Waves Platform with the community. We see it as an advanced JavaScript framework similar to the web3.js one that exists for the Ethereum project.’
[https://blog.chronobank.io/chronobank-partners-with-waves-to-create-chronowaves-wallet-c6e24be533a4?goal=0_c14d97ba45-da6d178ca4-32550077#.v6d9i1dc5]

chbsvc'Exchange-Value-Token (chbevt)

Name::
* cpt.chbevtkn,
* cpt.chbtoken,
* cpt.chronobank-exval-token,

Specific::
* LH-evtoken,
* TIME-evtoken,

chbevt.LH-token (chblht)

Description::
One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC in our case) defaulting on their contractual obligations.
[idChbwpr232]
===
The first stage of our project is to create the financial backbone of ChronoBank.io: national Labour-Hour (LH) tokens.
LH are linked to average hourly wages in the host country and are backed by a real labour force from big recruitment and labour-hire companies.
Labour is abundant enough for everyone to have access to it, yet scarce enough to be valuable. It is the most tradeable resource in the real economy.
LH tokens will tokenise this resource. Because they are backed by real labour, they are absolutely inflation-proof and have next to zero volatility – in comparison to bitcoin and other cryptocurrencies.
This solution is far more sustainable than any of the fiat-pegged or backed coins that currently exist in the crypto market. LH tokens will be hyper-liquid and accessible 24/7 via the LH debit card.
[https://chronobank.io/]

Name::
* cpt.chblht,
* cpt.mnyLh,
* cpt.labour-hours-cryptocurrency,
* cpt.money.blockchain.labour-hours,
* cpt.money.cryptocurrency.LH,
* cpt.money.LH,

chblht'Baker

Description::
One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC in our case) defaulting on their contractual obligations.
[idChbwpr232]

chblht'Smart-contract (link)

chblht'Issuance

Q: Who are the issuing labour-hire companies?
A: Chronobank selects labour hire/recruitment and HR companies based on their credibility, size, and financial performance, among other factors.
Please refer to our company selection methodology in our business description document, available on our website.
Initial list of companies who agreed to issue LH tokens:
Anderson Recruitment and Training Pty Ltd
http://www.andersonrecruitment.com.au
canderson@andersonrecruitment.com.au
Host Group/Host Labour Hire
http://www.hostaustralia.com.au
john.allery@hostaustralia.com.au
AES Labour Hire Pty Ltd
http://www.aesau.com.au
jammiek@aesau.com.au
Edway Labour Hire
http://www.edwaylabourhire.com.au
stan@edway.com.au
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

chblht'Exchange-rate

Q: What will guarantee that LH value will stay stable relative to fiat, in the case of a massive short-sale attack by speculators?
A: To stop a possible short-sale attack by speculators, Labour Hour tokens will always be refundable at a small discount less the issuance fee. That will remove any motivation for any short-sale attack.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

chblht.AGGREGATE

Q: What are the total number of LH tokens?
A: The total number of coins will always depend on the number of companies in the system and labour hours available in those companies that companies are able to fulfill.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

chbevt.TIME-token (link)

chbsvc'Human

Description::
The team features Luke Anderson, a PhD candidate in blockchains, and Adrian Manning, one of the developers of Zcash GPU miners.
[https://www.cryptocoinsnews.com/lifetime-might-become-money-ethereum-blockchain-thanks-startup/]
===
Q: Who is actually programming the smart contracts and wallets?
A: Smart contract architecture by Sigma Prime, Ethereum wallet by in-house developers, smart contract security audit by Mikko Ohtamaa (CTO at Revoltra).
Q: Could you tell us more about the ChronoBank staff and where the headquarters of the company is located?
A: Chronobank core team is based in Sydney, Australia. There are a few members of our team that are based all over the world.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

Name::
* cpt.ChronoBank-human,

AddressWpg::
* https://chronobank.io/#team,

Specific::
* Sergenko.Sergei: Chronobank CEO, Australia,
* Glover.Paul, Ideologist, USA, creator of Ithaca HOURS, the first modern time-based currency,

chbsvc'LaborX-dApp (chblrx)

Description::
The heart of the ChronoBank project is the LaborX exchange: a decentralised marketplace for work opportunities.
Freelancers and businesses will be able to trade labour on a peer-to-peer basis, without the costs and frictions of using a traditional recruitment company.
The efficiencies this brings can be passed on to both parties, raising pay and lowering costs whilst simultaneously increasing quality of work.
[https://blog.chronobank.io/laborx-core-and-laborx-dapp-c4088a01f12#.5ctlxxa1z]
===
The second stage is to create LaborX, a decentralised marketplace where people in real-world professions will be able to sell labour-hours to anyone.
[https://chronobank.io/]
===
LaborX also introduces a decentralized reputation system that enables workers to be rewarded in line with their talent and experience.
[https://cointelegraph.com/news/how-ethereum-based-uber-of-time-chronobank-could-boost-cryptocurrency-adoption? {2017-01-22}]

Name::
* cpt.laborX,
* cpt.laborX-exchange,
* cpt.laborX-dApp,
* cpt.chblrx, {2017-03-20}

chblrx'Attribute

chblrx'ledger:
is a publicly available database that holds information.
It will be implemented as a smart contract in Ethereum network.. 2
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]

chblrx'LaborX-Core (chblxc)

Description::
LaborX core is a complex system powered by the Ethereum network.
It contains all users’ public profiles, completed jobs with description, executor, status, and mutual ratings.
However, considering the system complexity, we have chosen to distinguish LaborX core from LaborX DApp.
[#idChblxw32P1]
===
LaborX core: this is a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic. 2, 3, 6, 7
[#idChblxwglrP3]
===
Contains all ratings and recommendations
Contains full job history
Contains all payment logic
Contains all profiles
Stores public profile data
Needs time for transactions to be mined
Is based on smart contracts
[lxwp]

Name::
* cpt.chblrx'core,
* cpt.chblxc, {2017-03-22}
* cpt.laborX-backend,
* cpt.laborX-core,

chblrx'LaborX-DApp-frontend (chblxd)

Description::
LaborX dapp, meanwhile, can be considered the ‘frontend’ of the ChronoBank project or the front desk of the recruitment agency. Whereas LaborX core is based on Ethereum’s smart contracts, LaborX dapp is a client-side application written in Javascript. Its job is to communicate with the LaborX core and provide a user interface for workers and businesses seeking to post or accept jobs -- in the same way that a regular cryptocurrency wallet provides the functionality to interface conveniently with the blockchain.
Employers and employees, as well as TIME investors, will use the LaborX dapp. Employers will create jobs to their required specifications and filter prospective employees by their availability and skill set, whilst freelancers can use the dapp to view their profiles and ratings, and search the database for tasks they may wish to undertake (based on sector, location, pay and so on). TIME holders can use the dapp to lock their tokens to a mining contract, thereby receiving rewards.
It is therefore the LaborX dapp’s task to parse the information held in the Ethereum blockchain, return it in a useful format, and facilitate interaction with LaborX core -- enabling users to make the best choices with regards to the employment opportunities offered by ChronoBank.
[https://blog.chronobank.io/laborx-core-and-laborx-dapp-c4088a01f12#.5ctlxxa1z]
===
DApp is an abbreviated form for decentralised application.
A DApp has its back-end code running on a decentralised peer-to-peer network.
Contrast this with an app where the back-end code is running on centralised servers.. 3–7
[#idChblxwdapp]
===
However, considering the system complexity, we have chosen to distinguish LaborX core from LaborX DApp.
LaborX DApp functionality will include interface for creating profiles, verification, evaluation, searching workers, concluding contracts etc (see Section 6 for full description of features). [#idChblxw32P1]
===
Calculates and displays rating
Performs search over all completed jobs
Provides a user-friendly payment interface
Shows profile data in an informative way
Handles public and private data
Compensates LaborX response time by reactive and fast user interface
Is a client-side application written in JavaScript
[lxwp]

Name::
* cpt.chblrx'DApp,
* cpt.chblxd, {2017-03-22}
* cpt.laborX-DApp-frontend,
* cpt.laborX-frontend,

chblrx'Canceling-job

Description:
If the client is not satisfied with the worker or their work they can cancel the job at any time.
Nevertheless, the client is required to pay a minimum of one hour (which is a minimal time unit that can be paid).
The client may then leave a negative recommendation and rating that will negatively flag the worker for future clients.
[#idChblxw33P1]

Name::
* cpt.chblrx'canceling-job,
* cpt.laborX-canceling-job,

chblrx'Worker (employee)

Description::
is a person that is assigned to fulfil client’s job and get paid for it. 2
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]

Name::
* cpt.chbworker,
* cpt.chronobank-worker,
* cpt.chblrxwkr,
* cpt.chblrx'employee,
* cpt.chblrx'worker,
* cpt.chbwkr,
* cpt.laborX-worker,

chblrxwkr'Compensation-per-hour (rate)

Description::
rate: amount of money that will be paid hourly to a worker. 1, 2, 6, 7
[#idChblxwrate]
===
It should be noted that client does not pay the worker’s transportation time and expenses.
Instead, they should be included in the worker’s individual rates.
[#idChblxw33P1]

Name::
* cpt.chblrx'rate,
* cpt.laborX-rate,

chblrxwkr'Evaluation

Description::
For workers.
Benefits for workers are also significant.
Due to lower fees than in traditional labour hiring companies workers may ask for higher hourly rates.
The most skilled and responsible workers with the best ratings will be highly sought after and may, therefore, demand a higher hourly fee than their not-so-amazing colleagues.
For the first time in the labour hire industry, diligent and attentive workers will be rewarded for providing better services.
The decentralised nature of LaborX will not only guarantee that workers will get paid, but will enable real-time payment to the worker as the work is completed.
Since the system is fully automated, the workers will be able to plan their schedules corresponding to their preferences.
[#idChblxw41P2]

Name::
* cpt.chblrxwkr'evaluation,
* cpt.laborX-worker-evaluation,

chblrxwkr'Profile

Description::
To achieve this, each worker will have a publicly available blockchain profile containing their nickname (first name and the first letter of their surname), small photo, field(s) of work, skills, rating, rate, activity points, approximate location, a list of completed jobs and payments. Optionally, a worker may apply for a document verification or a skill evaluation (see Sections 3, 6) which will be reflected in his public profile and confirmed by the electronic signature of the governing party. There will be a data set which will never appear on the blockchain. This includes, but is not limited to, the exact geolocation of the client and the worker, additional private instructions for the worker, document scans.
[#idChblxw7P1]

chblrxwkr'Rating

Description::
rating: is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures the quality of work done by a worker.
LaborX uses rating to select workers for a job.. 2–6
[#idChblxwrating]
===
A negative rating will also adversely affect evaluator’s reputation.
[#idChblxw33P1]

Name::
* cpt.chblrxwkr'rating,
* cpt.laborX-worker-rating,

chblrxwkr.EVALUATOR

Description::
evaluator: a highly rated worker with lots of experience and reputation which prove they are a master in their field of work and thus can verify skills of other workers. 2, 5
[#idChblxwglrP2]

Name::
* cpt.chblrxwkr.evaluator,
* cpt.laborX-evaluator,

Description::
Evaluation by Clients. Any verified client may advertise individual worker’s skills after completing the job if some of them are exceptional. This information would be used to separately promote the workers who are constantly rated 10/10.
[#idChblxw61P4]

chblrxwkr.VERIFICATOR

Description:
verificator: a worker with flawless reputation who offers services of verification for documents and identity of other entities. 2, 5
[#idChblxwglrP5]
===
Verification. Entities with high reputation could serve as verification hubs and be paid for their services by workers. They will check that worker’s documents correspond to the worker’s identity, scan documents, publish document LaborX core in the blockchain and confirm this action by signing the hashes with their digital signature (see Section 7 for more information).
[#idChblxw61P2]

Name::
* cpt.chblrxwkr.verificator,
* cpt.laborX-worker-verificator,

chblrx'Employer (client)

Description::
client: is a person that has some work and needs to get it done.
Client posts a job and pays for it. 2
[#idChblxwclient]

Name::
* cpt.chbemployer,
* cpt.chronobank-employer,
* cpt.chblrxemr,
* cpt.chblrx'employer,
* cpt.chblrx'client,
* cpt.laborX-employer,

chbemr'Evaluation

Description:
For clients.
There are numerous benefits for clients.
Because of smaller mediator fees than in traditional labour hiring companies, the resulting work price will be lower.
Decentralisation of the service makes it fast, reliable, secure, and permanently available.
A public worker rating system ensures that clients are seeing profiles of real workers along with their unique histories and therefore genuine ratings.
The ability to pay with a variety of digital tokens makes the system universal and not tied to any particular country/region.
Furthermore, LaborX will implement an easy to use interface, paying serious attention to UX.

Name::
* cpt.chbemr'evaluation,
* cpt.laborX-employer-evaluation,

chbemr'Searching-for-worker

Description::
6.2. Workers selection
According to the current model, the governing smart contract returns a selection of workers that fit the criteria of a given job posted by a client. The LaborX DApp takes preference of workers who have more completed jobs and higher ratings. The system may grow such that the ratio of workers to jobs becomes quite large. It is therefore important that the LaborX DApp does some advanced filtering. This means that the application should not show all workers capable of performing a given job, instead select only several of the available best workers with varying rates and ratings. In this way, the most competent workers will get more work and will be paid more for their reputation. Clients may also use different custom filters that will help them to find the most fitting worker to suit their needs. They may also pick specific workers they are already familiar with. The application will also utilise smart filtering to minimise the worker intersection between clients. This is crucial for the system, especially when considering similar jobs.

Name::
* cpt.chbemr'searching-for-worker,
* cpt.laborX-searching-for-worker,

chbemr'Protection

Description::
However, protections are also built in for the client in the case of poor performance on the part of the worker. Clients can cancel work at any time, though they will always have to pay for time so far worked. If it turns out that a worker has not spent the time well and has been bad value for money, the employer can end the contract and leave negative feedback for the worker. They will need to pay for a minimum of one hour of the worker’s time before doing this, to prevent malicious individuals from trying to ruin a worker’s reputation at no cost to themselves.
[https://blog.chronobank.io/laborx-getting-paid-on-time-every-time-364700e3709#.fa8sj2r0p]

Name::
* cpt.chbemr'protection,

chblrx'Trust-system

Description::
Trust, in such community services, mainly addresses whether a remote user -- called a trustee -- behaves as expected by an interested user (the trustor), through the activity of other users called recommenders. A ‘trust graph’ consists of a trustor, a trustee, recommenders, and the trust relationships among them.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]

Name::
* cpt.chblrx'trust-system,
* cpt.laborX-trust-system,

chblrx'Recommender

Description::
In LaborX, in addition to the commonly-used roles of Worker and Client, we have introduced another three roles -- Evaluator, Verifier and Provider. Together, these will serve the purpose of recommenders.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]

Name::
* cpt.chblrx'recommender,
* cpt.laborX-recommender,

chblrx'Evaluator (chblrxevr)

Description::
The Evaluator. The highest-ranked members of a community will be able to evaluate and confirm relevant skills of workers, building a chain of trust. In this way, clients can be sure that the assigned worker has all the required skills for completing the job. Workers will be required to have a high rating and sufficient activity points in order to become an Evaluator. Evaluators may verify and endorse skills of other workers, ensuring clients have a more accurate description of their potential workforce. Workers with skills endorsements will typically have a greater chance of being selected for any given job by the LaborX core. After performing a worker’s skill assessment, the Evaluator publishes a record on the blockchain. The Evaluator’s profile displays statistics of appraised workers, and the Evaluator’s reputation among LaborX users will depend on this.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]

Name::
* cpt.chblrx'evaluator,
* cpt.laborX-evaluator,

chblrx'Verifier (chblrxvfr)

Description::
The Verifier. This is a worker who offers services to verify clients and workers in a particular region. The fundamental role of a Verifier is to check required documents for their respective areas, such as work permits, certificates, injury insurance or other types of relevant cover. These entities are essential for ensuring local laws are observed, enhancing security, and potentially minimising spam issues. Both parties (clients and workers) may choose either a single Verifier or multiple Verifiers to review their documents, based on their rating and popularity. Each worker has a public profile and private data. The public profile is readily available on the blockchain and is accessible to everyone. Private data is verified and electronically signed by a Verifier. It is only available to a client after they enter into a contract with the worker.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]

Name::
* cpt.chblrx'verifier,
* cpt.laborX-verifier,

chblrx'Provider (mediator)

Description::
is an entity which offers its services to connect clients and workers through a job board because of legal, security, or spam issues.
Anyone can become a provider, and both parties (a client and a worker) could choose which providers they trust.
Providers get paid for their services by receiving a percentage of job payment fees. 2, 3, 5–7
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]

Name::
* cpt.chbmediator,
* cpt.chbprovider,
* cpt.chblrx'mediator,
* cpt.chblrx'provider,
* cpt.labor-hiring-company,
* cpt.laborX-mediator,
* cpt.laborX-provider,

Compensation

Description::
Provider receives payment only for completed jobs posted on provider’s job board.
[#idChblxw4P2]

chblrx'Job-board

Description::
job-board: is a publicly available database managed by the creator.
It will be implemented as a smart contract in Ethereum network.
More information in Section 6. 3, 5, 6
[#idChblxwjobboard]
===
Each LaborX provider will be able to set cryptocurrencies that will be permitted for payments on their job boards.
Clients and workers who choose a job board, agree to use one of the supported methods of payment.
[#idChblxw63P1]

Name::
* cpt.chblrx'job-board,
* cpt.laborX-job-board,

Searching

Description::
A client would be capable of searching through the list of workers in job boards or choosing a familiar worker.
[#idChblxw32P2]

Name::
* cpt.laborX-job-board-searching,

chblrx'Job

Description::
job: is some work or task to get done.
Job can be a list of tasks but all within one field of work. 2
[#idChblxwjob]
===
A job object (the programmatic object relating to a real-world job) will contain a location, provider used and work description.
The work description includes attributes such as field of work, job due date, address of ERC20 token contract (that will be used for payment), required skills, and further optional job-specific requirements.
[#idChblxw32P2]

Name::
* cpt.chblrx'job,
* cpt.chblrxjob,
* cpt.laborX-job,

chblrxjob'Work-description

Name::
* cpt.chblrxjob'description,
* cpt.chblrxjob'work-description,
* cpt.laborX-job-description,

chblrxjob'Field-of-work
chblrxjob'Skills
chblrxjob'Time-due

Description::
A job due date can be a present or future time. If the current time is selected, then LaborX returns all currently available workers ready to start a work now. If instead a future time was chosen, then the system will find workers available to work at the chosen time. If several clients wish to book one particular worker for the same period, the system prioritises clients based on the time when clients offered the work. Once the worker accepts the job, the smart contract will publicly mark the worker as busy, preventing further bookings in that period.
[#idChblxw32P2]

chblrxjob'Money-used (token)

chblrxjob'Location

Description::
A location is also a selectable parameter that will typically represent a city/region.
If a city/region is large, then a district/sub-region may be specified.
A city/region includes all of its districts/sub-regions.
A location is used to map workers to nearby clients.
Precise addresses (for job locations) will be revealed to workers once the job has been mutually agreed on and solidified by the smart contract.
[#idChblxw32P2]

Name::
* cpt.chblrxjob'location,
* cpt.laborX-job-location,

chblrxjob'Provider-used

chblrx'Rating-system

Description::
For every worker and client there are two metrics called rating and activity points.
The first describes how well a worker performs their duties and is dictated by clients.
The second is a point system based on all LaborX activity.
[https://blog.chronobank.io/how-laborxs-reputation-system-will-work-478cdd7aab8e#.vd7xhx1px]

Name::
* cpt.chblrx'metrics,
* cpt.chblrx'rating-system,

chblrx'Activity-points

Description::
is an integer in a range of 1 to infinity which measures positive contribution to LaborX ecosystem.
The more activity points the user has, the more advanced actions they can perform.
[#idChblxwactivitypoint]

Name::
* cpt.chblrx'activity-points,
* cpt.laborX-activity-points,

Description::
Activity points are used only in the LaborX DApp and have a crucial security role by limiting the amount of available functionality to newcomers.
This limits threats such as spamming, posting advertisements with ambiguous links, or evildoers trying to overload the system with an infinite job posting.
Every new user begins with a single activity point which will automatically increase when performing various actions inside the app (see Table 2).
An alternative way to gain activity points is by verifying one’s identity with various verificators or by passing skill assessment with an evaluators.
The activity points count will always be greater
than or equal to 1.
An example of activity point elevators are given in Table 2.
Some of the proposed features that will require some amount of activity points is given in Table 3.
The listed values in these tables are examples only and may change during the implementation and system testing period.
[#idChblxw5]

chblrx'Rating

Description::
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures the quality of work done by a worker.
LaborX uses rating to select workers for a job.. 2–6
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
A negative rating will also affect evaluator’s reputation.

Name::
* cpt.chblrx'rating,
* cpt.laborX-rating,

chblrx'Wallet

Description::
LaborX is a multi-currency service that will support any token that complies with the ERC20 standard[2] including, but not limited to, Labor Hour tokens.
A simple multi-currency wallet capable of receiving and sending any supported ERC20 token will be integrated into the LaborX platform.
Users will be able to pay and get paid by tokens they choose from a list of supported on job board tokens.
Providers may list local currencies, allowing communities to pay for jobs in unusual digital assets, should both the client and the worker accept the currency by selecting the job board.
As mentioned in the previous section, the LaborX system will deduct 1%2 from each completed job part of which will go as a revenue to TIME token holders and other part to providers for their services.
Provider receives payment only for completed jobs posted on provider’s job board. [#idChblxw4]

Name::
* cpt.chblrx'wallet,
* cpt.laborX-wallet,

chblrx'Resource

AddressWpg::
* https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf,

chblrx'White-paper (link)

chblrx'DOING

chblrx'Messaging

Description::
6.5. Messaging
LaborX will use a messaging system with an underlying protocol like Whisper[6], enabling client and worker to establish an encrypted connection. These messages could be used to exchange job details, address, confidential instructions, etc. The exact realisation will be decided at the time of development (specified in the LaborX road map) taking into account the potential research and new possibilities that will be available in 2017. [#idChblxw65]

Name::
* cpt.chblrx'messaging,
* cpt.laborX-messaging,

chblrx'Searching

Description::
6.4. Search
High load testing and analysis would be performed while developing LaborX to determine exact implementation and architecture of the search system.
The main part of a search logic should be performed in the LaborX LaborX core.
Only Ethereum transactions that write to blockchain have gas limit and cost Ether.
The search operation is read-only, therefore it would perform computations on user’s Ethereum node and will not require paying Ether.
A worker-to-job matching will include complex queries and therefore require a significant amount of computational power of the machine where Ethereum node software is running.
Therefore LaborX DApp could handle part of the filtering and caching logic on client’s side.
This approach will significantly improve the user experience.
[#idChblxw64]

Name::
* cpt.chblrx'Searching,
* cpt.laborX-Searching,

chblrx'Matching

Description::
It will be capable of automatically matching available workers to corresponding jobs according to their location, field of work, skills, and reputation.
[#idChblxw8P1]

Name::
* cpt.chblrx'Matching,
* cpt.laborX-Matching,

chblrx.EVOLUTING

chbsvc'Organization (chbogn)

chbogn.Exchange

FAQ:
Q: Can I redeem LH tokens to USD or EUR if so how?
A: Redeeming will be either from an ATM or at any exchange that will trade LH
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

chbogn.Merchant

FAQ:
Q: What will I be able to buy with LH tokens? Which firms will accept them in exchange of (physical) goods?
A: We will issue LH denominated visa/mastercard cards, will work similar to bitcoin cards. We will be converting LH directly into fiat at the start with a small spread. So technically, you will be able to buy anything you buy now, at any organisation you buy it from now.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

chbogn.Edway-Group

Description::
Edway Group
Co-founder
Australia
edwaygroup.com.au
Edway Group Pty. Ltd. is a consolidated group of Australian companies and industry leader in vocational training and labour supply. The company has multiple divisions in the fields of HR, recruitment, training, technology and auxiliary services to these industries.
[https://chronobank.io/]

Name::
* cpt.chbogn.Edway-Group,
* cpt.Edway-Group,

chbsvc'Resource (chbrsc)

Name::
* cpt.chbresource,

AddressWpg::
* https://github.com/ChronoBank,
===
* {2017-05-14} https://blog.chronobank.io/the-dapps-revolution-70e6ed4ec5cf,
* {2017-03-13} https://blog.chronobank.io/laborx-getting-paid-on-time-every-time-364700e3709#.fa8sj2r0p
* {2017-03-08} ChronoBank’s TIME launches on four exchanges: https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a,
* {2017-03-04} TIME token reward model: https://blog.chronobank.io/time-token-reward-model-1c3508208791,

=== COMMUNITY:
* https://chronobank.slack.com/
* https://blog.chronobank.io/

chbrsc'ChronoBank.io-website

Description::
ChronoBank.io is an ambitious and wide-ranging blockchain project, aimed at disrupting the HR/recruitment/finance industries in a similar way to how Uber disrupted the taxi business and how Upwork represented an evolution in freelancing.
[https://chronobank.io/]

Name::
* cpt.ChronoBank.io,
* cpt.ChronoBank-website,

chbsvc.EVOLUTING

{time.2016-12-15-2017-02-14}
=== CROWDSALE:
- 5,416 BTC
- 2,985 participants
[https://chronobank.io/]

Q: How long will it take to go from where Chronobank is now to where it needs to be to start challenging Labour Hire and Recruitment companies?
A: We anticipate this time period to be between a year and year and a half from February 2017
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

SPECIFIC

Name::
* bcnnet.specific,
* cpt.bcnnet.specific,
* cpt.bcnnetSpc,

Specific::
=== GENERIC:
* Blockchain-as-a-Service,
* Blockchain-curency-network,
* Builtin-governance-network,
* Depedent-blockchain-network,
* DepedentNo-blockchain-network,
* One-blockchain-network,
* OneNo-blockchain-network,
* Service.Exchange-value-unit-network,
* Service.Program-network,
* Public-blockchain-network,
* PublicNo-blockchain-network,
=== INSTANCE:
* Aeternity-AE-network,
* Akasha-network,
* Bitcoin-BTC-network {2009},
* Bitshares2-BTS-network {2015},
* BOScoin-network,
* Cosmos-network,
* Dash-DASH-network {2014},
* Decred-DCR-network {2016},
* Dfinity-network,
* Emercoin-EMC-network {2013},
* Ethereum-ETH-network {2015},
* FairCoop-FAIR-network {2014},
* Gnosis-network,
* Humaniq-network,
* IBM-blockchain-network,
* KSI-network,
* Lisk-LSK-network {2016},
* Litecoin-LTC-network {2011},
* Namecoin-NMC-network {2011},
* NEM-XEM-network {2015},
* Nxt-NXT-network {2013},
* Peercoin-PPC-network {2012},
* PIVX-network {2016},
* Qtum-network,
* Ripple-XRP-network {2012},
* RSK-network,
* Synereo,
* Tezos-network,
* Zcash-ZEC-network {2016},
* Waves-WAVES-network {2016},
* Wings-network,

Specific::
Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]

bcnnet.SPECIFIC-DIVISION.builtin-governance

Specific::
* builtin-goverance,
* builtinNo-goverance,

bcnnet.BUILTIN-GOVERNANCE

Description::
Blockchain-network with builtin project decentralized governance.
Not centralized governance.
Not governance only written in a-smart-contract-program.
Decentralized governance of the-people of the-project.
[hmnSgm.2017-04-04]

Name::
* cpt.bcnnetBig,
* cpt.bcnnet.builtin-governance,
* cpt.blockchain-network-with-builtin-decentralized-governance,

Specific::
* Decred-network {2016},
* BitShares-network {2015},
* Dash-network {2014},
* BOScoin-network,
* Dfinity-network,

bcnnet.SPECIFIC-DIVISION.consensus-algorithm

Specific::
* proof-of-stake-bcnnet,
* proof-of-work-bcnnet,
* hybrid-stake-work-bcnnet,

bcnnet.PROOF-OF-WORK

Description::
Proof-of-stake-blockchain-network is a-blockchain-network with proof-of-work consensus-algorithm.

Name::
* cpt.bcnnetPow,
* cpt.bcnnet.proof-of-work,
* cpt.proof-of-work-blockchain-network,

Specific::
* Zcash-ZEC-network {2016},
* Ethereum-ETH-network {2015},
* Bitcoin-BTC-network {2009},

bcnnet.PROOF-OF-STAKE

Description::
Proof-of-stake-blockchain-network is a-blockchain-network with proof-of-stake consensus-algorithm.

Name::
* cpt.bcnnetPos,
* cpt.bcnnet.proof-of-stake,
* cpt.pos-blockchain-network,
* cpt.proof-of-stake-blockchain-network,

Specific::
* Lisk-LSK-network {2016},
* NAV-Coin-NAV-network {2016},
* PIVX-network {2016},
* Waves-WAVES-network {2016},
* BitShares-network {2015},
* BlackCoin-BLK-network {2014},
* Nxt-NXT-network {2013},
* Peercoin-PPC-network {2012} first,

bcnnet.HYBRID-POS-POW

Description::
Hybrid-pos-pow-blockchain-network is a-blockchain-network with both proof-of-stake and proof-of-work, consensus-algorithm.

Name::
* cpt.bcnnetHsw,
* cpt.bcnnet.hybrid-pos-pow,
* cpt.hybrid-pos-pow-blockchain-network,

Specific::
* Decred-DCR-network {2016},

bcnevu.SPECIFIC-DIVISION.number-of-blockchains

Specific::
* one-blockchain-bcnnet,
* many-blockchains-bcnnet,

bcnnet.MANY-BLOCKCHAINS

Description::
Multiblockchain-blockchain-network is a-blockchain-network with many blockchains.

Name::
* cpt.bcnnetOneNo,
* cpt.bcnnet.many-blockchains,
* cpt.bcnnet.multi-blockchain,
* cpt.oneNo-blockchain-blockchain-network,
* cpt.many-blockchain-blockchain-network,
* cpt.multi-blockchain-blockchain-network,

Specific::
* Cosmos-network,

bcnnet.SPECIFIC-DIVISION.dependance

Specific::
* dependent-bcnnet,
* dependentNo-bcnnet,

bcnnet.SPECIFIC-DIVISION.time-of-genesis

Specific::
=== {2017}
*
=== {2016}
* Zcash-network,
* Lisk-network,
* Waves-network,
* Decred-network,
* PIVX-network,
=== {2015}
* Bitshares2-network,
* Ethereum-network,
* NEM-network,
=== {2014}
* Dash-network,
* FairCoop-network,
=== {2013}
* Emercoin-network,
* Nxt-network,
=== {2012}
* Peercoin-network,
* Ripple-network,
=== {2011}
* Litecoin-network,
* Namecoin-network,
=== {2010}
*
=== {2009}
* Bitcoin-network,

bcnnet.SPECIFIC-DIVISION.user

Specific::
* public-bcnnet,
* publicNo-bcnnet,

bcnnet.SPECIFIC-DIVISION.service

Specific::
* app-service,
* government-service,
* exval-token-service,
* record-keeping-service,

bcnnet.SPECIFIC-DIVISION.evoluting

Specific::
* announcement-stage|phase,
* ico-stage,
* planning-stage,
* development-stage,
* experimental-stage,
* testing-stage,
* working|production-stage,
* working.stableNo-stage,
* working.stable-stage,
* working.mature-stage,
===
* conceptual-stage,
* development-stage,
* production-stage,

bcnnet.dependance.DEPENDENT (bcnnetDpt)

Description::
Dependent-bcnnet is a-bcnnet that does-NOT-operate autonomously.
It works as another layer on another bcnnet.
[hmnSgm.2017-03-27]

Name::
* cpt.bcnnet.dependent,
* cpt.bcnnetDpt,

Specific::
* Humaniq, (Ethereum)
* Omni_layer, (Bitcoin)

bcnnetDpt.Lykke-exchange (link)

bcnnetDpt.Omni-layer

Description::
Omni is a platform for creating and trading custom digital assets and currencies.
It is a software layer built on top of the most popular, most audited, most secure blockchain -- Bitcoin.
Omni transactions are Bitcoin transactions that enable next-generation features on the Bitcoin Blockchain.
Our reference implementation, Omni Core is an enhanced Bitcoin Core that provides all the features of Bitcoin as well as advanced Omni Layer features.
[http://www.omnilayer.org/]

Name::
* cpt.Omni-layer,

bcnnetDpt.Raiden-network (rdnnet)

Cpt-created: {2017-03-27}

Description::
Raiden Network
High speed asset transfers for Ethereum
Payment-Channel Network for Ethereum
Raiden is a technology that leverages off-chain state networks to extend Ethereum with some nice properties for asset transfers:
Scalable: it scales linearly with the number of participants (1,000,000+ transfers per second possible)
Fast: Transfers are confirmed and final within the fraction of a second
Confidential: Single transfers don’t show up in the global shared ledger
Interoperable: Works with any token that follows Ethereum’s standardized token API
Low Fees: Transaction fees can be 7 orders of magnitude lower than on the blockchain
Micro-payments: Low transaction fees allow to efficiently transfer tiny values
Technology
The technology enabling this is similar to the proposed Bitcoin Lightning Network.
The basic idea is to switch from a model where all transactions hit the shared ledger on the blockchain (which is the bottleneck) to a model where users can privately exchange messages which sign the transfer of value.
Raiden uses a network of p2p payment channels and deposits in Ethereum to preserve the guarantees expected from a blockchain system.
Raiden is implemented as an extension to Ethereum. A Raiden node runs alongside an Ethereum node and communicates with other Raiden nodes to facilitate transfers and with the Ethereum blockchain to manage deposits. It offers a simple API which makes it easy to use Raiden in DApps.
Applications
Micropayments for content distribution: Alternative to Paywalls, Ads and Subscriptions. (Figure a decentralized youtube where the creators of a video are paid for every second watched)
Decentralized M2M markets: especially in IoT where tiny chunks of bandwidth, storage, cpu time, energy, sensor data, etc. can be traded.
Frictionless Token Systems: Game Tokens, Reward Tokens, Private Currencies
API Access: Accessing and monetizing APIs on a per use basis is at the core of the upcoming Machine-to-Machine economy
Fast Decentralized Exchanges
Complementary to Ethereum
Vitalik Buterin: “State channels are an important technology that has the potential to greatly improve the scalability and privacy of many categories of blockchain applications; in conjunction with sharding and other privacy-preserving cryptographic technologies, they are an important ingredient in helping decentralized systems to achieve the properties that mainstream individual and institutional users expect and deserve.”
Links
Coindesk feature on Raiden: “Will Ethereum Beat Bitcoin to Mainstream Microtransactions?”
Robert McCone’s blogpost about a lightning style network on Ethereum
Oktahedron Podcast with Augusto from the core team, explaining the Raiden Network
Raiden Network IoT Demo - Enabling High Speed Asset Transfers
Development
The Raiden Network is currently under development. Release of an MVP is planned for the end of March 2017. See our GitHub repository and read our latest blog post on development progress for the latest updates.
[http://raiden.network/]

Name::
* cpt.raiden-network,
* cpt.rdnnet,

bcnnetDpt.SIDECHAIN

Cpt-created: {2017-03-19}

Description:: We propose a new technology, pegged sidechains, which enables bitcoins and other ledger assets to be transferred between multiple blockchains.
This gives users access to new and innovative cryptocurrency systems using the assets they already own.
By reusing Bitcoin’s currency, these systems can more easily interoperate with each other and with Bitcoin, avoiding the liquidity shortages and market fluctuations associated with new currencies.
Since sidechains are separate systems, technical and economic innovation is not hindered.
Despite bidirectional transferability between Bitcoin and pegged sidechains, they are isolated: in the case of a cryptographic break (or malicious design) in a sidechain, the damage is entirely confined to the sidechain itself.
[https://blockstream.com/sidechains.pdf, ]

Name::
* cpt.bcnnet.sidechain,
* cpt.sidechain-network,

scnet'Resource

AddressWpg::
* {2014-10-26} https://gendal.me/2014/10/26/a-simple-explanation-of-bitcoin-sidechains/
* {2014-10-22} https://blockstream.com/sidechains.pdf,

bcnnet.dependance.DEPENDENT.NO

Description::
A-blockchain-network with an-independent blockchain.

Name::
* cpt.bcnnet.independent,

bcnnet.service.BLOCKCHAIN-PROGRAM

Description::
Program-blockchain-network is a-blockchain-network that stores blockchain-programs[1] in its blockchain that[1] process arbitrary transitions of the-blockchain's-information.

Name::
* cpt.bcnnetPgm,
* cpt.bcnnet.application,
* cpt.bcnnet.program,
* cpt.bcnnet.smart-contract,
* cpt.blockchain-program-bcnnet,
* cpt.blockchain-program-blockchain-network,
* cpt.program-blockchain-network,

Specific::
* Lisk-LSK-network {2016},
* Ethereum-ETH-network {2015},

* BOScoin-BOS-network,
* Dfinity-DFN-network,
* Qtem-network,
* Rootstock-RSK-network,
* Tezos-network,

bcnnet.service.EXCHANGE-VALUE-UNIT (evunet)

Description::
Exchange-value-token-blockchain-networks were the first networks created, when Satoshi solved the-double-spending-problem without a central authority.
[hmnSgm.2017-03-31]

Name::
* cpt.evtnet, {2017-04-14}
* cpt.exchange-value-token-bcnnet, {2017-04-14}
===
* cpt.bcnnetEvtkn, {2017-03-31}
* cpt.bcnnet.currency-application,
* cpt.bcnnet.evu,
* cpt.bcnnet.exchange-value-unit,
* cpt.bcnnet.money,
* cpt.bcnnet.value-transfer,
* cpt.bcnnetMny,
* cpt.money-bcnnet,
* cpt.net.blockchain.currency,
* cpt.net.currency.blockcain,
* cpt.satoshi-based-blockchain,
* cpt.stmIthMny.currency.crypto,
* cpt.stmIthMny.currency.cryptocurrency,
* cpt.cryptocurrency-network, cptIt51.12,
* cpt.cryptocurrency-platform, cptIt51.12,
* cpt.netBcnMny,
* cpt.netCbc,
* cpt.netCcc, {2016-04-03}
* cpt.sihCcc,
* cpt.sihCcc,
* cpt.sihCrypto,
* cpt.sihCrypto, cptIt51.12,
* cpt.stmIthCrypto,

Generic::
* blockchain-network,

evunet'whole.DAO

Generic::
* Bcnnet-DAO,

evunet'Protocol

Generic::
* Bcnnet-protocol,

evuprl'White-paper

Generic::
* Bcnnet-white-paper,

evuprl'Implementation-language

Generic::
* Bcnnet-protocol-implementation-language,

evunet'Node

Generic::
* Bcnnet-node,

evunet'Blockchain

Generic::
* Bcnnet-blockchain,

Name::
* cpt.blockchain-of-evunet,

evubcn'Block

Generic::
* Bcnnet-block,

evubcn'Block-explorer

Generic::
* Bcnnet-block-explorer,

evubcn'Consensus-algorithm

Generic::
* Bcnnet-consensus-algorithm,

evubcn'Address

Generic::
* Bcnnet-address,

evubcn'Transaction

Generic::
* Bcnnet-transaction,

evubcn'Hash-rate

Generic::
* Bcnnet-hash-rate,

evunet'Exchange-value-unit.Consensus

Generic::
* Bcnnet-consensus-exchange-value-unit,

evunet'Statistics

Generic::
* Bcnnet-statistics,

evunet'Governance-system

Generic::
* Bcnnet-governance-system,

evunet'Program

Generic::
* Bcnnet-program,

evunet'Wallet

Generic::
* Bcnnet-wallet,

evunet'Problem

Generic::
* Bcnnet-problem,

evunet'Human

Generic::
* Bcnnet-human,

evunet'Organization

Generic::
* Bcnnet-organization,

evunet'Evaluation

Generic::
* Bcnnet-evaluation,

evunet'Law

Generic::
* Bcnnet-law,

evunet'Conference

Generic::
* Bcnnet-conference,

evunet'Resource

Generic::
* Bcnnet-resource,

AddressWpg:
* {2017-05-13} Monero 2.0? Why INTCoin Claims to Be Next Generation Decentralized Currency: https://cointelegraph.com/news/monero-20-why-intcoin-claims-to-be-next-generation-decentralized-currency,

evunet'DOING

Generic::
* Bcnnet-doing,

SPECIFIC

Name::
* evunet.specific,
* cpt.evunet.specific,

Specific::
* Bitcoin-BTC-network {2009},
* Bitshares2-BTS-network {2015},
* Dash-DASH-network {2014},
* Decred-DCR-network {2016},
* FairCoop-FAIR-network {2014},
* Humaniq-network,
* Litecoin-LTC-network {2011},
* Namecoin-NMC-network {2011},
* NEM-XEM-network {2015},
* Nxt-NXT-network {2013},
* Peercoin-PPC-network {2012},
* PIVX-network {2016},
* Zcash-ZEC-network {2016},
* Waves-WAVES-network {2016},

bcnnet.BLOCKCHAIN-AS-A-SERVICE

Description::
Microsoft Azure already features a wide range of Blockchain solutions, including Ethereum, Chain Core, Corda, Nxt, Lisk, and Waves.
Together, they form an elaborate ecosystem known as Blockchain as a Service, which supports the creation of all kinds of Blockchain projects for all kinds of purposes and for companies of any size.
[https://cointelegraph.com/news/why-microsoft-azure-integrates-blockchain-crowdfunding-platform-waves]

Name::
* cpt.BaaS,
* cpt.Blockchain-as-a-Service,

bcnnet.time.Zcash (ZECnet {2016-10-28})

Description::
Internet money
Zcash is the first open, permissionless cryptocurrency that can fully protect the privacy of transactions using zero-knowledge cryptography.
[https://z.cash/]

Name::
* cpt.zcash-network,
* cpt.zecnet,

Generic::
* Exchange-value-unit-network,
* Proof-of-work-network,

zecnet'Blockchain (zecbcn)

zecnet'Block-explorer (zecber)

AddressWpg::
* https://explorer.zcha.in/
* BlockH0 https://explorer.zcha.in/blocks/00040fe8ec84719...a8a5c453883c000b031973dce08,

zecnet'Consensus-algorithm

Description::
* Is Zcash proof-of-work? What mining algorithm do you use? Is it ASIC resistant?—
Yes, since launch, Zcash has been based on proof-of-work. Maybe the community will choose to change it to proof-of-stake or something someday. We cannot predict what the community or communities will ultimately decide about such things but are very much open to improvement and evolution. We are currently using Equihash as the proof-of-work for block mining in Zcash. Equihash is a proof-of-work algorithm devised by Alex Biryukov and Dmitry Khovratovich. It is based on a computer science and cryptography concept called the Generalized Birthday Problem. Please read the Why Equihash blog post for more details. The algorithm is currently not economically implementable in ASIC. We’re still evaluating whether we think it will resist custom hardware (“ASIC”) implementation long-term.
[https://z.cash/support/faq.html#mining-algorithm]

zecnet'Exchange-value-unit.Consensus (ZECevuC)

Description::
Zcash ZEC
Zcash is a totally private decentralized crypto using a new cryptographic algorithm for payments using a zero-knowledge proof of construction, providing safe encryption of a sender, a recipient and an amount sent. Zcash has a view key for users to see and control the content.
[https://changelly.com/supported-currencies]
===
Privacy technology for blockchains
Zcash is the first open, permissionless financial system employing zero-knowledge security.
The Zcash genesis block will launch in 7 days. Zcash is currently in testnet (testnet coins have no value and will never hold monetary value); our engineering roadmap is publicly available here. If anyone says that they will pay you Zcash before October 28, 2016, then there must be some mistake, because Zcash will not exist until then.
WHAT IS ZCASH?
Zcash offers total payment confidentiality, while still maintaining a decentralized network using a public blockchain. Unlike Bitcoin, Zcash transactions automatically hide the sender, recipient, and value of all transactions on the blockchain. Only those with the correct view key can see the contents. Users have complete control and can opt-in to provide others with their view key at their discretion.
Zcash transactions do not depend on the cooperation of other parties.
[https://z.cash/] {2016-10-20}

Name::
* cpt.mnyZcash,
* cpt.mnyZEC,
* cpt.Zcash,
* cpt.Zcash-currency,
* cpt.ZEC-token,
* cpt.zecevuC,

zecnet'Resource

AddressWpg::
* https://z.cash/,
* https://z.cash/support/faq.html#what-is-a-zero-knowledge-proof,
* {2016-10-20} https://cointelegraph.com/news/with-launch-of-zcash-approaching-mining-companies-get-prepared,

bcnnet.time.Lisk (LSKnet {2016-05-24})

Cpt-created: {2017-01-29}

Description::
Lisk is a public blockchain platform that provides decentralized blockchain apps.
It was forked from Crypti by Max Kordek and Olivier Beddows in early 2016.
[https://en.wikipedia.org/wiki/Lisk]

Name::
* cpt.lisk-network,
* cpt.lsknet,
* cpt.netLisk,
* cpt.netLsk,

lsknet'Protocol

AddressWpg::
* https://github.com/LiskHQ/lisk-wiki/wiki/Technical-Protocol-Reference,

lsknet'Node

lsknode.MINER

lsknodeMnr'Mining

Description::
Forging
Lisk utilizes an inflationary forging rewards system which creates new LSK for every successful block.
During year 1, the forging rewards are set at 5 LSK per block.
Every 3,000,000 blocks (~1 year) forging rewards are reduced by 1 LSK, ending at 1 LSK per block after 5 years.
The forging rewards will then stay at 1 LSK per block indefinitely.[12]
The Forging Rewards will be equally distributed through all active (top 101) delegates, same as any network fees.
[https://en.wikipedia.org/wiki/Lisk#Forging]

Name::
* cpt.lskmining,
* cpt.lskmng,

lsknet'Blockchain

lskbcn'Block-Explorer (lskbex)

AddressWpg::
* https://explorer.lisk.io/
* BlockH1 https://explorer.lisk.io/block/13658550407518916215,

lskbcn'Consensus-algorithm (lskcsa)

Description::
Lisk uses Delegated-Proof-of-Stake, a highly secured and flexible consensus model, which elects 101 delegates to create blocks.
[https://changelly.com/supported-currencies]

lsknet'Exchange-value-unit.Consensus (LSKevuC {2016})

Description::
Lisk LSK
Lisk is a new decentralized application platform with its own cryptocurrency.
The platform is based on JavaScript and allows to create and distribute decentralised applications (DApps) and so-called sidechains.
These are custom blockchains integrated into the Lisk’s one.
Lisk uses Delegated-Proof-of-Stake, a highly secured and flexible consensus model, which elects 101 delegates to create blocks.
[https://changelly.com/supported-currencies]

Name::
* cpt.lisk-Consensus-Exval-Token,
* cpt.lskcevt,
* cpt.lsknet'cevt,
* cpt.mnyLsk,

Generic::
* Consensus-exchange-value-token,

lskevuC'Exchange-rate

AddressWpg::
* https://coinmarketcap.com/currencies/lisk/

{time.2017-01-30}
1 BTC = 005,749.10888812 LSK,

lsknet'Bapp

Description::
Bapp (Dapp, Blockchain App, App)
A decentralized application, which is running in a sidechain of Lisk. If you add a bapp to Lisk, an entry will be made on the blockchain. This will "register" it and makes it visible to everyone.
[https://github.com/LiskHQ/lisk-wiki/wiki/Glossary]

Name::
* cpt.lisk'Bapp,
* cpt.lisk'Blockchain-App,
* cpt.lisk'Dapp,
* cpt.lskBapp,

lsknet'Problem

AddressWpg::
* {2017-05-09} Beddows: https://blog.lisk.io/what-happened-with-block-2731040-and-how-we-fixed-it-1c397f692d36,

lsknet'Human

Who created Lisk?
Lisk is a more open alternative to Crypti created by former members of the Crypti Foundation, namely Max Kordek and Olivier Beddows.
[https://github.com/LiskHQ/lisk-wiki/wiki/FAQ#who-created-lisk]

lsknet'Relation-to-ethereum

Description::
Differences from Ethereum
- Lisk and Ethereum both try to provide a platform for a similar idea: Decentralized Applications (Lisk calls them Blockchain Applications[13])
- Lisk is an all-around Blockchain (Decentralized) Application platform, that allows for endless possibilities on the developers and/or entities end to build and create, while Ethereum is a platform that only allows for Smart Contract based projects to be created, which in the end limits the overall potential of a set-goal that individuals project can reach or obtain.
- Lisk uses DPoS, while Ethereum currently uses PoW (they have stated they plan to switch to PoS eventually).[14]
- Applications language: Lisk uses Javascript, while Ethereum currently uses Solidity.[15]
- Applications location: Lisk uses sidechains, while Ethereum currently stores it on the main chain.[16]
- Error handling: In Lisk, if your application has an issue it will be contained to only your chain, but require a hard fork to fix. In Ethereum, applications are run in a virtual machine on the main chain so any error should just result in the waste of transaction fees, but be contained to the VM (as long as there is no bug in the VM).
- Applications VM: Ethereum applications are run in the Ethereum Virtual Machine (EVM). Lisks does not have a VM, but it is in development.
[https://en.wikipedia.org/wiki/Lisk#Differences_from_Ethereum]

lsknet'Resource

AddressWpg::
* https://lisk.io/
* https://github.com/LiskHQ/lisk-wiki/wiki,
* https://explorer.lisk.io/delegateMonitor,
* https://blog.lisk.io/what-is-lisk-and-what-it-isnt-e7b6b6188211, (Max Kordek)

lsknet.EVOLUTING

{time.2016-05-24}:
=== mainnet live:
On May 24, 2016, the main network for Lisk went live and it became available for trading on major exchanges.
[https://github.com/LiskHQ/lisk-wiki/wiki]

bcnnet.time.Waves (WAVESnet {2016-04-15})

Description::
WAVES is a decentralized blockchain platform focusing on custom blockchain tokens operations.
National currencies transfer is maintained on the WAVES blockchain through compliant gateway operators.
Decentralized token exchange facilitates fundraising, crowdfunding, and trading of financial instruments on the blockchain.
Lightweight clients provide an easy installation procedure and a flat learning curve for end users.
[https://wavesplatform.com/whitepaper_v0.pdf]

Name::
* cpt.bcnnet.waves,
* cpt.netWaves,
* cpt.waves-network,
* cpt.wavesnet,

wavesnet'Protocol (wavprl)

wavprl'White-paper

AddressWpg::
* {2016-04-01} https://blog.wavesplatform.com/waves-whitepaper-164dd6ca6a23#.4b9dzixu9,

WAVES whitepaper.

Abstract

WAVES is a decentralized blockchain platform focusing on custom blockchain tokens operations.
National currencies transfer is maintained on the WAVES blockchain through compliant gateway operators.
Decentralized token exchange facilitates fundraising, crowdfunding, and trading of financial instruments on the blockchain.
Lightweight clients provide an easy installation procedure and a flat learning curve for end users.

Introduction

‘Hypothesis: Every conceivable application of blockchain technology will be tried, but p2p digital cash will remain most used application’.
Ryan X Charles

‘The killer application of blockchain technology is the blockchain itself.’
Common wisdom

Since its inception, blockchain technology has been fraught with controversy over its most natural application -- value transfer using the network token.
Decentralized money is a ground-breaking development, but blockchain technology cannot be reduced to this alone.
Being essentially a distributed database, the blockchain allows for various types of distributed ledger entries, the nature of which depends on their interpretation by the blockchain’s users.

Introducing the blockchain as a foundation for digital cash attracted a great deal of attention to the technology, putting regulators and governments worldwide on high alert in the process.
There is no doubt that Bitcoin will establish itself as a valid monetary system.
But it is also obvious that there should not be too many blockchain tokens in use as money at the present time, since the low liquidity and high volatility this causes prevent the use of emerging blockchains as a secure store of value.

We propose to focus on other uses of blockchain tokens -- those which are often overlooked in favor of the low-level opportunities which blockchain technology might provide, such as smart contracts.
There is very strong untapped potential in a classical colored coins approach, and the WAVES platform is designed to realize this to its fullest extent.

Smart contracts, being a natural development of Bitcoin scripting, are inevitable and will be one of the cornerstones of blockchain technology.
On the other hand, certain features are much easier to implement using other approaches.
Custom tokens operations realized as an attachment to blockchain transactions are very flexible and can be used in a variety of applications, from national currencies transfer over the blockchain to decentralized trading.
A focus on such operations might well complement the approach introduced by Ethereum.[1]

In the following sections we will describe the technical motivation for WAVES platform’s features and illustrate them with use cases.
We intend to determine the most “production-ready” aspects of current blockchain technology and apply them to the real-world problems.

Custom blockchain tokens and their usage.

Technical motivation.

Blockchain assets and colored coins approaches emerged around 2013, when several protocols utilizing Bitcoin’s blockchain were implemented. [4] [5] [6]
Besides this, there were several attempts to build custom blockchain tokens platform from scratch, of which the most notable is Nxt. [7]

We develop the approach which Nxt implemented, realizing custom tokens creation and transfer through attachments added to blockchain transactions.
This approach has clear merits, such as the ability to implement new transaction types easily, but from practical point of view it is fraught with the problem of mandatory hard forks -- when adding a new transaction type, network client software has to be updated, since old clients cannot support new transaction types.

WAVES approaches this problem by offering an extensible solution, in which new transaction types are introduced through plug-ins that are not included in the core software module, but are instead installed as an extension on top of it.
Clients that do not have the relevant plug-in installed can still relay these custom transactions.
This approach allows third-party developers to introduce new transaction types, and creates an Appstore-like ecosystem.

Only the most basic transaction types are supported at the core level, including:
- Custom token creation, deletion and transfer
- Decentralized token exchange, realized as a distributed order-matching engine, where Bid and Ask network transactions are matched against each other
- Anonymity features -- anonymous order books are a must for an industry-grade trading platform

It should be noted that WAVES makes a crucial step ahead with decentralized blockchain trading by offering trading of one custom token against another (asset-to-asset trading).
This opens up a whole new range of opportunities, including trading against tokens tied to national currencies, thus replicating traditional trading infrastructures.

Use cases
National currencies on the blockchain.

Although using the main network token for value transfer is quite natural, it nevertheless raises several issues. Use of low-liquidity and highly volatile tokens for value transfer has obvious drawbacks for merchants, and creates tension with regulatory bodies. Still, fully decentralized money is viable, which is demonstrated by the slow but steady adoption of Bitcoin as a currency.

However, in order to provide sufficient liquidity and mitigate the volatility that prevents decentralized money usage as a store of value, the overall number of tokens used as currency should be limited (at least in the initial stages of the development of the technology). We strongly advocate using only Bitcoin as a currency for this reason.

Our approach to handling external value transfer tokens and currencies stems from the ‘Multigateway’ approach.[2] In the case of Bitcoin there is a party (or multi-sig parties) that maintains an in-and-out exchange procedure for Bitcoin, swapping it for its corresponding network token. Thus we facilitate Bitcoin transfers using the WAVES blockchain.

This approach is obviously centralized, due to limitations inherent in Bitcoin itself. It is opposed to a “market peg” approach, which relies on providing a dynamic peg though certain market-making procedures. At first sight the market peg approach may seem to be an adequate way of mirroring financial assets on decentralised platform, but with further consideration hidden centralization invariably surfaces.

By explicitly introducing centralization into supporting blockchain national currencies and BTC we are able to open new horizons for existing financial institutions. Their role can be reduced to providing liquidity for their fiat assets and KYC/AML procedures. Maintaining payment infrastructure is fully outsourced to decentralized blockchains.

This approach to providing national currencies on the blockchain was pioneered with the CoinoUSD token on Nxt’s blockchain. It is also similar to Ripple’s gateways approach. We believe that such a strategy can compete with the emerging permissioned blockchains approach and attract financial institutions willing to work on open blockchains.

Crowdfunding, decentralized financial instruments and beyond.

We believe that blockchains are an effective means for managing most aspects of community-based projects, from financial to organizational elements. Blockchain technology, due to its innate latency, cannot support high-frequency trading. Most probably centralized solutions will always be preferable for high-volume transactions with milliseconds execution times. But for applications in which instant transactions are not required, blockchains provide a very natural environment -- for example, for issuing crowdfunding tokens and managing financial flows within a community. This is an area in which using decentralized solutions is beneficial and centralization brings little to the table.

If we consider a Kickstarter-like model of pledging certain amounts of money in exchange for a product to be released in the future, we can see its obvious limitations. A project backer cannot exit her “investment” in the project by selling it another user. On the other hand such a use case is very natural using a blockchain-based system, where custom tokens can be swapped and transferred by design.

Issuing securities is highly regulated in most jurisdictions. Tokens can be associated with securities, especially if some projections about future token price are made or a token issuer promises to pay certain dividend. However, the blockchain is a regulation-agnostic instrument. If a legal entity wishing to utilize the blockchain for a securities issue is compliant with local laws and regulations then issuing securities on a blockchain is as legitimate as conducting a stock exchange listing.

Start-up fundraising, private investment placements and venture-stage investments seem to be the most appropriate areas for blockchain-powered financial instruments. On the other hand it can be used by a larger businesses for specific financial operations too, such as clearing and settlement, so long as these do not entail overly taxing speed requirements.

In most jurisdictions (notably excluding the US), blockchain-based fundraising that does not exceed a given limit can be carried out perfectly legally. Equity crowdfunding laws in the US allow fundraising with a simplified SEC registration procedure.

Strict US securities laws are intended to prevent fraud, and for this a strong centralized watchdog, such as US Securities and Exchange Commission, is needed. But the advance of decentralized technology can introduce some form of community and decentralized issuer vetting, which might eventually replace centralized regulators.

Having crowdfunding as one of WAVES platform’s main use cases means that some form of decentralized KYC/AML must be integrated into the system core. To that end we are realizing a decentralized reputation system, which should eliminate unscrupulous actors on the WAVES blockchain.

Lightweight clients, two-tier architecture, Proof of Stake, and usability.

Technical motivation.

Two-tier architecture and lightweight clients.

The classic Bitcoin approach is essentially a way to synchronize a distributed system through common transaction logs.
It requires that each network node store the full copy of the transaction history.
Obviously this does not scale well, since eventually not every node will be able to store the full history.
There are different ways to mitigate this -- a simplified payment verification procedure that allows storage of only that data essential for a given node; off-chain transactions; bidirectional payment tunnels; reducing blockchain bloat; working directly with the system state [8].
With the simplest approach, where all nodes are equal at Genesis block, centralization may emerge as low-capacity nodes have to rely on full, high-capacity nodes that can afford to store the full blockchain.
Effectively, a two-tier architecture emerges.

Does this make the system inherently centralized?
No, since a new node can always enter the network and become a full node if it has sufficient resources.

Of course, emerging centralization brings trust issues, since lightweight nodes have to trust the full nodes and can become a victim of a rogue full node.
However, there are ways to mitigate this, such as polling several nodes, maintaining trusted nodes lists, and so on.

WAVES platform enforces an approach that might at first seem extreme to a classic cryptocurrency advocate.
Lightweight nodes do not download the blockchain at all, instead relying on full nodes for payment verification and network interaction.
The approach is based on the SuperNET lite client[3] that has successfully been run on the Nxt platform for over a year.

WAVES is built on the Scorex platform,[8] which develops an approach based on using current network state as an alternative to full transaction history.
A simplified payment verification procedure will be realized for the lightweight node, adding another security layer.
System state can be downloaded by a lightweight node, and simplified payment verification procedures based on this.

Proof-of-stake consensus, stake leasing.

We have chosen the Proof-of-Stake protocol as a consensus algorithm for WAVES. This choice is based on its successful use in Nxt, as well as on certain theoretical considerations. At the same time we propose an enhancement to the PoS protocol, which should provide for reduced transaction times and increased transaction throughput -- Leased PoS (LPoS).

In a PoS system each node that holds a balance in the main network token has a chance (proportional to its balance) to produce a block.
In the two-tier architecture it is logical to move payment processing onto the full nodes alone.
At the same time, all nodes with non-zero balances still have to be eligible for staking rewards.

The theoretical issue of reduced security caused by fewer nodes staking can be addressed through explicit balance leasing from lightweight nodes to full nodes.
By leasing their balance to a trusted full node a lightweight node actually increases its chance of collecting transaction fees, since it does not have to stay online, and the full node has an increased chance of producing a block due to its increased balance.

Account leasing is not equivalent to balance transfer; a lightweight node can still transfer its balance to another node and conduct other operations.
By leasing out their balance, lightweight nodes effectively select which full nodes will carry out most of the network’s payment processing.
Reducing the number of nodes that can potentially produce blocks allows for faster confirmation times, lower latency, and a higher system throughput.

Lightweight nodes realization and browser plugins.

The lightweight node is realized as a browser plugin written in JavaScript. It interacts with Scorex-based full nodes. The plugin is installed from browser app-stores. Since no blockchain download is needed a user obtains a fully-fledged blockchain-powered wallet immediately following a simple installation procedure.

The wallet interface resembles traditional online banking/brokerage interfaces. Integrated national currencies allow for native value transfer denominated in fiat. Exchange of national currencies into and out of the blockchain is carried out by a trusted provider. Once a user has completed the national currency token purchase she can transfer it to another user or trade with it on a decentralized exchange.

Asset-to-asset trading makes it possible to provide a stock market-like trading interface, by allowing trading against USD, EUR, CNY, and so on. All in all, the platform interface is closer to traditional financial interfaces than to a normal cryptocurrency client. We find it important to provide an interface to which most users are already well accustomed, at the same time as empowering it with blockchain technology. Users can do things they were unable to do with traditional financial platforms, but the learning curve remains flat, which is a key to mass-market adoption.

Additional key WAVES features.

WAVES targets in the first place community-based development and projects.
To that end decentralized voting and messaging are implemented.
It will allow for a DAO-like experience in managing community projects, whilst remaining straightforward from a technical point of view.
WAVES will allow payment of network transaction fees in custom tokens (assets).
Along with the transaction in question, an order to exchange the asset into the main network token is sent to the decentralized exchange, and the transaction can be included in the next block only after that order has been executed.

Conclusion.

WAVES platform is being built with mass adoption in mind from the start.
In this general overview we have attempted to show the technical solutions that may be used to give the end-user previously unseen opportunities, and to pave the way for the rapid adoption of blockchain technology.

References.

[1] https://github.com/ethereum/wiki/wiki/White-Paper

[2] http://multigateway.org/

[3] https://github.com/Tosch110/SuperNet-Lite

[4] https://github.com/CounterpartyXCP

[5] https://github.com/OpenAssets/open-assets-protocol

[6] https://github.com/OmniLayer/spec

[7] http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt

[8] http://arxiv.org/abs/1603.07926

wavesnet'Blockchain (wavbcn)

wavbcn'Block-Explorer (wavbex)

AddressWpg::
* http://wavesexplorer.com/
* http://wavesexplorer.com/blocks/1,

wavbcn'Consenus-algorithm

Description::
Q: Why are you using PoS rather than PoW?
A: Proof of work might be more secure in theory, but I still consider it to be an inelegant solution to the problem of consensus due to the wasted computational resource. Something better will come in time. Meanwhile, PoS is the way to go.
Q: Is the PoS consensus system the same as in the Nxt system?
A: At launch we will use a ‘plain vanilla’ PoS. Classical PoS is good enough for all intents and purposes. (‘Nothing-at-stake’ arguments are of a purely theoretical nature.) There will be improvements later, possibly including an entirely new kind of PoS system.
[https://wavestalk.org/general-discussion/waves-faq/]

wavesnet'Exchange-value-unit.Consensus (WAVESevuC)

Description::
Waves (WAVES)
$0.443330 (3.29%)
0.00037363 BTC (2.02%)
Market Cap
$44,333,000
37,364 BTC
Volume (24h)
$169,417
142.78 BTC
Circulating Supply
100,000,000 WAVES
[https://coinmarketcap.com/currencies/waves/] {2017-04-15}

Name::
* cpt.wavesnet'cevt,
* cpt.WAVEScevt,

wavesnet'Funding

Description::
Q: How much funding did Waves receive?
A: 29,636 bitcoins were crowdfunded from 5,790 participants in April and May 2016, with a market value of around $16 million at the time the ICO ended.
[https://wavestalk.org/general-discussion/waves-faq/]

wavesnet'Reletion-to-ethereum

Description::
Q: What is the difference between Waves and Ethereum?
A: Ethereum is developing bitcoin scripting for smart contracts. It’s powerful but makes certain things very complicated.
We took another road where things are simpler: it’s very easy to add all the functionality you need using plug-ins, so you don’t have to code complicated contracts.
Also, our focus is on mass adoption.
We’re specifically targeting two markets: fiat transfers on the blockchain and crowdfunding on the blockchain.
They are ripe for disruption, and we’ll be offering a product for a very general audience.
[https://wavestalk.org/general-discussion/waves-faq/]

wavesnet'Resource

AddressWpg::
* http://wavesexplorer.com/
* https://waveswallet.io/
* http://assets.wavesplatform.com/

wavesnet'Service (wavsvc)

Description::
We’re specifically targeting two markets: fiat transfers on the blockchain and crowdfunding on the blockchain. They are ripe for disruption, and we’ll be offering a product for a very general audience.
[https://wavestalk.org/general-discussion/waves-faq/]
===
A universe of tokens
WAVES is a decentralized platform that allows any user to issue, transfer, swap and trade custom tokens directly on the blockchain.
Decentralized trading
WAVES uses blockchain technology to offer an integrated exchange which does not depend on a central authority, server, or static infrastructure.
Your gateway to the world
The gateways partnered with WAVES make it a breeze to swap digital assets for traditional money right in your bank account, and vice versa.
Blockchain voting
WAVES also includes an innovative means of decentralized voting, with no single authority or the risk of manipulation this carries.
Decentralized crowdfunding
WAVES integrates its own crowdfunding platform, Crowdstarter, which allows entrepreneurs to launch their projects easily and in a decentralized manner.
Innovative reputation system
Absence of governance carries its own risks. WAVES' decentralized reputation system will play a key role in bringing confidence to the assets ecosystem.
[https://wavesplatform.com/]

wavsvc.DEX

Description::
The Blockchain platform Waves has announced the release of its own decentralized exchange, DEX, on its mainnet.
The exchange, which Waves hopes will improve on previous attempts at decentralized trading with new features, is available via a full node or through the API. Later, the resource will become available to all users.
[https://cointelegraph.com/news/waves-debuts-dex-decentralized-exchange-mining-power-leasing {2017-03-30}]

wavesnet.EVOLUTING

{time.2016}:
=== Genesis:
[https://blog.wavesplatform.com/wavesplatform-mainnet-launched-22f65b46d6af#.sxfb1vnjr, {2016-06-10}]
===
Q: Do you have a rough timeline for development?
A: There is a strong emphasis on fast development. Full launch will be in late summer 2016. [https://wavestalk.org/general-discussion/waves-faq/]

bcnnet.time.Decred (DCRnet {2016-02-08})

Description::
An open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain.
[https://github.com/decred]
===
Decred is a cryptocurrency, similar to Bitcoin, with a strong focus on community input, open governance and sustainable funding and development.
It utilizes a hybrid “proof-of-work” and “proof-of-stake” mining system to ensure that a small group cannot dominate the flow of transactions or make changes to Decred without the input of the community.
A unit of currency is called a ‘decred’ (DCR).
To ensure the integrity of the currency and prevent people from making fraudulent transactions or creating their own coins, Decred uses a method of recording transactions known as a blockchain.
[https://docs.decred.org/]

Name::
* cpt.bcnnet.Decred,
* cpt.dcrnet,
* cpt.netDcr,
* cpt.netDecred,
* cpt.Decred-network,
===
DEcentralized-CREDit,

Generic::
* Blockchain-network-with-builtin-decentralized-governance,
* Exchange-value-unit-blockchain-network,

dcrnet'Protocol

dcrprl'Constitution (dcrcttn)

AddressWpg::
* https://docs.decred.org/getting-started/constitution/,

Decred Constitution
Decred (/ˈdi:ˈkred/, /dɪˈkred/, dee-cred) is an open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain. The project mission is to develop technology for the public benefit, with a primary focus on cryptocurrency technology. Decred, as a currency and as a project, is bound by the following set of rules, which include guiding principles, a system of governance, and a funding mechanism. These rules have been established in an effort to create an equitable and sustainable framework within which to achieve Decred's goals.

Principles

Free and Open-Source Software - All software developed as part of Decred shall be free and open source-software.

Free Speech and Consideration - Everyone has the right to communicate opinions and ideas without fear of censorship. Consideration shall be given to all constructive speech that is based in fact and reason.

Multi-Stakeholder Inclusivity - Inclusivity represents a multi-stakeholder system and an active effort shall be maintained to include a diverse set of views and users. While it would be ideal to include everyone, Decred shall comply with all relevant bodies of law in the jurisdictions where applicable, such as embargoes and other trade sanctions.

Incremental Privacy and Security - Privacy and security are priorities and shall be balanced with the complexity of their implementations. Additional privacy and security technology shall be implemented on a continuing and incremental basis, both proactively and on-demand in response to attacks.

Fixed Finite Supply - Issuance is finite and the total maximum number of coins in Decred shall not change. The total maximum supply for Decred is 20,999,999.99800912 coins, with a per-block subsidy that adjusts every 6,144 blocks (approximately 21.33 days) by reducing by a factor of 100/101. The genesis block subsidy starts at 31.19582664 coins.

Universal Fungibility - Universal fungibility is fundamental to Decred being a store of value and attacks against it shall be actively monitored and countermeasures pursued as necessary.

Blockchain Governance

Governance of the network occurs directly through the blockchain via hybridization of a block's proof-of-work ("PoW") with its proof-of-stake ("PoS"). PoS contributors, known as stakeholders, can effectively override PoW contributors, known as miners, if 60% or more of the stakeholders vote against a particular block created by a miner.

A lottery system is used to determine which stakeholders vote on each block and collect a subsidy.

To be a stakeholder, one must purchase one or more tickets, which entails locking a specified amount of coins for approximately 1 day (256 blocks).

After waiting for the ticket to mature, the ticket is entered into a lottery that runs once per block where the winning tickets gain the ability to vote on the previous block.

Stakeholders must wait an average of 28 days (8,192 blocks) to vote their tickets, and during this time the coins used to purchase the ticket remain locked. The wait may be much longer or shorter than the average of 28 days because the ticket selection process is pseudorandom. Tickets expire after approximately 142 days (40,960 blocks).

Stakeholder votes recorded in the blockchain are rewarded with 6% of each block subsidy, and each block can have up to 5 votes for a total of 30% of each block subsidy.

PoW receives 60% of each block subsidy, subject to the constraint that their subsidy scales linearly with the number of PoS votes included, e.g. including 3 of 5 votes reduces PoW subsidy by 60%.

The votes themselves decide by majority decision whether the general transaction tree of the previous block, including the PoW subsidy, is valid. Thus, if PoS voters vote against a particular PoW block, it destroys the PoW subsidy (and development subsidy) and invalidates any regular transactions within that block.

Additional vote bits may be set when stakeholders submit votes, allowing stakeholders to vote on matters besides the previous block.

Project Governance

Off-chain decision-making shall be used to resolve disputes related to development and voted on by the Decred Assembly as they arise, as an effective proof-of-assembly ("PoA"), until such time PoA is integrated into the blockchain.

The Decred Assembly shall be composed of diverse Assembly members who are selected for membership by the Admission Council from the project ecosystem for representation.

Councils that are composed of Assembly members shall be formed to address ongoing and episodic matters. The initial Councils shall serve the separate functions of admission (Admission Council), creation (Creation Council), and attrition (Attrition Council).

The Admission Council shall vote on the inclusion of new members into the Assembly. All additional Councils shall be created by the Creation Council. The Attrition Council shall be responsible for deactivating both Councils and Assembly members as necessary.

Membership of the Decred Assembly shall consist of Assembly members who have been confirmed by a 60% or greater affirmative vote by the Admission Council. There is no restriction on the age or nationality of Assembly members, the only requirement is that of merit as judged by the Admission Council. Merit is judged on the basis of two characteristics: (1) the amount of time over which one has been involved with the project, and (2) one's body of work and its impact in the context of the project.

Attrition is embraced by temporarily deactivating or actively expelling Assembly members by a 60% or greater affirmative vote by the Attrition Council on the basis of: (1) substantial non-fulfillment of duties for one or more Councils or the Assembly, and/or (2) counterproductive behaviour that goes against the framework set forth in the Constitution without constructive action toward solutions.

All matters formally presented to a Council shall be resolved by a vote in 365 days or less.

Funding

Sustainability and longevity require that a subsidy of 10% of all block rewards be given to a development organization on an ongoing basis. The initial development organization shall be Decred Holdings Group LLC ("DHG"), a Nevis LLC that is responsible for funding work related to the development of the project, such as software development, infrastructure, and awareness.

DHG shall only fund work that adheres to the guiding principles.

DHG shall issue public financial statements every six months, starting March 8th, 2016. The frequency of financial statements may increase with activity, but it shall not occur more often than quarterly.

DHG shall put forth a budget proposal each year on March 8th, after the corresponding public financial statement has been issued.

The Funding Council shall review, propose changes, make changes, and ultimately approve the proposal by April 8th, one month from the initial budget proposal.

Final approval of the budget via PoA vote shall occur after Funding Council approval by April 18th, two months from the initial proposal.

DHG shall make public requests for proposals ("RFPs") for projects that are to be completed by parties on a contractual basis. RFPs shall include a scope and an explanation of how the work shall benefit the project. Parties that submit proposals shall be required to include: (1) a detailed description of the work to be performed, (2) a series of milestones that can be verified as work is completed, and (3) a quote for the work, itemized by milestone, in U.S. Dollars ("USD").

All proposals, both submitted and accepted, shall be made public one week after a proposal has been selected. Once the selection occurs, the associated RFP shall be removed. Contracted parties shall be paid exclusively in decred ("DCR") at the current effective DCR/USD rate at the time of payment, unless specifically noted otherwise.

In the future, the development organization may need to change from DHG to another entity that serves an identical function. If and when this occurs, DHG shall transfer all assets to the new entity and the development subsidy shall be directed to the new entity.

dcrnet'Node (dcrnod)

Name::
* cpt.dcrnet'computer-in-the-Decred-network,
* cpt.dcrnod,

Generic::
* Blockchain-network-node,

dcrnod'Peer

FAQ.5. Why am I connecting to only 8 outbound peers?
There is an intentional unconfigurable limit of 8 outbound peers. More outbound peers than that does not help you in any way and is actually worse for both you and the network. This has been tested extremely thoroughly in Bitcoin, including btcsuite (the upstream project for Decred). All you would do by upping your outbound connections is waste valuable slots of the relatively few public peers there are (there are always a much higher number of “leechers” than there are “seeders”).

On the other hand, increasing your maximum connections, which really just increases the number of allowed inbound connections, helps the network by ensuring there are more slots available for new nodes and SPV clients which Decred does not have yet, but it will.
[https://docs.decred.org/faq/configuration/#5-why-am-i-connecting-to-only-8-outbound-peers]

dcrnod.MINER

dcrnet'Mining

dcrnet'mining.POOL

AddressWpg::
* https://docs.decred.org/mining/proof-of-work/solo-mining/cgminer/windows/

Mining-pool

Sign up for a mining pool
These mining pools are known to support Decred:
http://yiimp.ccminer.org
http://coinmine.pl/dcr
https://dcr.maxminers.net
https://dcr.suprnova.cc
https://pool.mn/dcr
https://zpool.ca
Mining pools all work more or less the same but you may wish to sign up at multiple pools and see which one suits you the best.
[https://docs.decred.org/mining/proof-of-work/#sign-up-for-a-mining-pool]

PoW-Mining
PoS-Mining

dcrnet'mining.SOLO

AddressWpg::
* https://docs.decred.org/mining/proof-of-work/solo-mining/cgminer/windows/

PoW-Mining

Description::
Solo mining is not recommended and is not covered by this documentation! The Decred network regularly sees a network hash rate of up to 10,000Gh/s. Solo mining is generally only done by advanced individuals or organized groups with a large cluster of GPUs so it is not addressed here.
[https://docs.decred.org/mining/proof-of-work/]

PoS-Mining

Description::
When you mine in a pool, your hashrate is combined with all the other pool miners’ hashrates to look for the correct solution for a block. You will receive a reward based on the amount of work your miner performs in the pool. Pool mining distributes shares based on blocks found so you can earn a steady amount of Decred rather than the “all or none” of solo mining.
[https://docs.decred.org/mining/proof-of-work/]

dcrnet'Blockchain (dcrbcn)

dcrbcn'Block (dcrblk)

Name::
* cpt.dcrblk,

dcrblk'Hash

block 00000000000004ffcf24b4a7ba827766cdd7bd1f31a42b6c8b83584a068eb154

dcrblk'Header

Block header format
Decred block headers occupy 180 bytes when serialized. The serialization format for a block header is displayed below:

Field    Description    Size
* dcrblk'Version        Block header version    4 bytes
* dcrblk'Previous_block    Hash of the previous block    32 bytes
* dcrblk'Merkle_root    Merkle tree hash calculated using all transactions in the block    32 bytes
* dcrblk'Stake_root    Merkle tree hash calculated using all stake transactions in the block    32 bytes
* dcrblk'Vote_bits    Bit flags. Currently only used to signify votes on the previous merkle root    2 bytes
* dcrblk'Final_state    Commitment to the final state of the PRNG (for lottery purposes)    6 bytes
* dcrblk'Voters        Number of participating voters in the block    2 bytes
* dcrblk'Fresh_stake    Number of new tickets in the block    1 byte
* dcrblk'Revocations    Number of revocations present in the block    1 byte
* dcrblk'Pool_size    Size of the ticket pool    4 bytes
* dcrblk'Bits        Difficulty target for the block    4 bytes
* dcrblk'SBits        Stake difficulty target for the block    8 bytes
* dcrblk'Height        The number of blocks that precede the block in the blockchain    4 bytes
* dcrblk'Size        Number of bytes that the serialized block occupies    4 bytes
* dcrblk'Timestamp    Time that the block was created    4 bytes
* dcrblk'Extra_data    The nonce and any other data that may be used later for consensus purposes    40 bytes
Example encoded block header
0x01, 0x00, 0x00, 0x00, // Version 1
0x6f, 0xe2, 0x8c, 0x0a, 0xb6, 0xf1, 0xb3, 0x72, // PrevBlock
0xc1, 0xa6, 0xa2, 0x46, 0xae, 0x63, 0xf7, 0x4f,
0x93, 0x1e, 0x83, 0x65, 0xe1, 0x5a, 0x08, 0x9c,
0x68, 0xd6, 0x19, 0x00, 0x00, 0x00, 0x00, 0x00,
0x3b, 0xa3, 0xed, 0xfd, 0x7a, 0x7b, 0x12, 0xb2, // MerkleRoot
0x7a, 0xc7, 0x2c, 0x3e, 0x67, 0x76, 0x8f, 0x61,
0x7f, 0xc8, 0x1b, 0xc3, 0x88, 0x8a, 0x51, 0x32,
0x3a, 0x9f, 0xb8, 0xaa, 0x4b, 0x1e, 0x5e, 0x4a,
0x3b, 0xa3, 0xed, 0xfd, 0x7a, 0x7b, 0x12, 0xb2, // StakeRoot
0x7a, 0xc7, 0x2c, 0x3e, 0x67, 0x76, 0x8f, 0x61,
0x7f, 0xc8, 0x1b, 0xc3, 0x88, 0x8a, 0x51, 0x32,
0x3a, 0x9f, 0xb8, 0xaa, 0x4b, 0x1e, 0x5e, 0x4a,
0x00, 0x00, // VoteBits
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // FinalState
0x00, 0x00, // Voters
0x00, // FreshStake
0x00, // Revocations
0x00, 0x00, 0x00, 0x00, //Poolsize
0xff, 0xff, 0x00, 0x1d, // Bits
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // SBits
0x00, 0x00, 0x00, 0x00, // Height
0x00, 0x00, 0x00, 0x00, // Size
0x29, 0xab, 0x5f, 0x49, // Timestamp
0xf3, 0xe0, 0x01, 0x00, // Nonce
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // ExtraData
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
[https://docs.decred.org/advanced/block-header-specifications/]

dcrblk.Block1

Block #1
BlockHash 000000000000437482b6d47f82f374cde539440ddb108b0a76886f0d87d126b9
Summary
Number Of Transactions    1
Height    1 (Mainchain)
Block Reward    1680000.00000000 DCR
Timestamp    Mon, 08 Feb 2016 18:02:15 GMT
Merkle Root   
b4895fb9d0b54822550828f2ba07a68ddb1894796800917f8672e65067696347
Stake Root   
0000000000000000000000000000000000000000000000000000000000000000
Previous Block    0
VoteBits    1
Final State    000000000000
Voters    0
FreshStake    0
Revocations    0
PoolSize    0
Difficulty    32767.74999809
SBits    2
Bits    1b01ffff
Size (bytes)    113521
Version    1
Stake Version    0
Nonce    3671491438
Next Block    2
[https://mainnet.decred.org/block-index/1]

dcrblk.Block0

Description::

Block #0
BlockHash 298e5cc3d985bfe7f81dc135f360abe089edd4396b86d2de66b0cef42b21d980
Summary
Number Of Transactions    1
Height    0 (Mainchain)
Block Reward    0 DCR
Timestamp    Mon, 08 Feb 2016 18:00:00 GMT
Merkle Root   
66aa7491b9adce110585ccab7e3fb5fe280de174530cca10eba2c6c3df01c10d
Stake Root   
0000000000000000000000000000000000000000000000000000000000000000
VoteBits    0
Final State    000000000000
Voters    0
FreshStake    0
Revocations    0
PoolSize    0
Difficulty    32767.74999809
SBits    2
Bits    1b01ffff
Size (bytes)    0
Version    1
Stake Version    0
Nonce    0
Next Block    1
[https://mainnet.decred.org/block-index/0]

dcrbcn'Block-Explorer (dcrbex)

AddressWpg::
* https://mainnet.decred.org/
* blockH0: https://mainnet.decred.org/block/298e5cc3d98...86d2de66b0cef42b21d980,

dcrbcn'Consensus-algorithm

Description::
Each block in the blockchain is a record of transactions that have occurred since the last block (about 5 minutes).
Every computer (node) in the Decred network shares this blockchain.
Nodes in the network run an algorithm many times over a block looking for a solution with a known difficulty.
This process is known as “proof-of-work” mining.
Once the solution is found it is broadcast to the network.
The network then verifies the solution (finding the solution is very hard, but verifying it is easy).
Decred uses an extra step of verification known as “proof-of-stake” mining.
Stakeholders who have purchased tickets now have the chance to vote on the block.
5 tickets are chosen randomly from the ticket pool and if at least 3 of them vote ‘yes’ the block is permanently added to the blockchain and the transactions are cleared.
Both PoS and PoW miners are compensated with DCR for the resources used to mine the block.
[https://docs.decred.org/]

Name::
* cpt.dcrnet'consensus-algorithm,
* cpt.dcrnet'block-verification,
* cpt.dcrnet'transaction-verification,

Overview
Decred has two methods of transaction verification proof-of-work (PoW) and proof-of-stake (PoS).

1. Proof-of-work (PoW) Mining
Proof-of-work mining, more commonly referred to as PoW mining, is the activity of committing your computer’s hardware and resources to process network transactions and build the blocks that make up the blockchain in the Decred network. Each time a block is created (by a miner), about 30 new Decred coins are made. These coins are then split up as follows:
Subsidy    Party
60%    PoW Miners
30%    PoS Voters
10%    Decred development subsidy
You will, on average, receive a reward that is roughly proportional to the hashrate of your miner and the overall hashrate of the network when you commit your computer to PoW mining. To get started, you must have a computer with a video card. Most video cards can be used for mining (including the “mobile” types found in some laptops). In general, higher end video cards perform at higher hashrates and therefore receive higher rewards.

2. Proof-of-stake (PoS) Mining
Proof of Stake mining is the second method of block verification in Decred. It is computationally cheap but it requires you to already have some DCR in your wallet. In the Decred network, PoW miners solve blocks then turn those blocks over to PoS miners to vote on them. When a block is completed, 5 tickets are chosen at random from the ticket pool to vote on the block. If at least 3 votes are ‘Yes’ then the block is validated, included in the block chain and both PoW and PoS miners are paid.
If the vote fails, the block is discarded and the transactions return to be included in another block. The PoW miners are not paid, however the PoS miners are.

This is to incentivize PoW miners to mine according to the wishes of PoS miners.
For example, if the rules of the network change in the future any PoW miners who don’t follow them will not be paid.
It also helps stop large mining pools getting too much influence over the network.
In cryptocurrencies that don’t use PoS, the large groups of PoW miners who effectively control the network can collude to block transactions, stop network changes or even force faked transactions (although this would take a huge amount of resources).
Collusion between PoW and PoS miners is not possible as tickets are not chosen until the time of the vote.
Collusion between PoS miners is likewise remote as the ticket pool is kept at around 40,960 active tickets at any time.
The chance of three tickets belonging to the same individual or group being chosen for the same block is very small.
Even if this did happen every transaction is validated at least twice so the chance of anyone manipulating the blockchain is effectively zero.
[https://docs.decred.org/mining/overview/]

dcrbcn'Address

Description::
9. What are the different types of addresses?
A Decred address is actually just a representation of a public key (which itself could be a script hash) along with a 2-byte prefix which identifies the network and type and a checksum suffix in order to detect improperly entered addresses.

Consequently, you can always tell what type of address it is based on the 2-byte prefix.

The first byte of the prefix identifies the network. This is why all mainnet addresses start with “D”, testnet addresses start with “T”, and simnet addresses start with “S”. The second byte of the prefix identifies the type of address it is.

The most common addresses used at the moment are secp256k1 pubkey hashes, which are identified by a lowercase “s”. It represents a single public key and therefore only has a single associated private key which can be used to redeem it.

The stake pool, however, uses a pay-to-script-hash address, which is identified by the second byte being a lowercase “c” (again that is shown in the linked params). The specific flavor of script it generates is a multi-signature 1-of-2, which is how it allows either the pool, or you, to vote. Both you and the stake pool have your own private keys and since the script only requires one signature of the possible two, that is how it allows delegation of voting rights to the pool without you giving up your voting rights completely.
[https://docs.decred.org/faq/wallets-and-seeds/#9-what-are-the-different-types-of-addresses]

Name::
* cpt.decred-address,

dcrbcn'Hash-rate

Description::
network hash rate of up to 10,000Gh/s.
[https://docs.decred.org/mining/proof-of-work/]

Name::
* cpt.decreed-blockchain-hashing-power,
* cpt.decreed-blockchain-hashing-rate,
* cpt.dcrnet'hash-rate,
* cpt.dcrnet'hashing-power,
* cpt.blockchain-hash-rate,

dcrnet'Exchange-value-unit.Consensus (DCRcevu)

Description::
A unit of currency is called a ‘decred’ (DCR).
[https://docs.decred.org/]

Name::
* cpt.dcrcevt,
* cpt.decret-consensus-exval-token,

Generic::
* consensus-exval-token,

dcrnet'Governance-system (dcrgov)

Description::
Governance
Layered form of transparent meritocratic governance that extends beyond proof-of-work and proof-of-stake mechanisms to bring forward and represent insider and outsider voices in the community [9]
Bottom-up decision-making through the Decred Assembly - an evolving and inclusive list of community members who make non-financial contributions to the project through their work and effort [10]
Project bound by the Decred Constitution on the core principles of finite issuance, privacy, security, fungibility, inclusivity, and progressive development of the technology that keeps these principles together [11]
[https://wiki.decred.org/Main_Page]

Name::
* cpt.dcrgov,
* cpt.dcrnet'governance-system,
* cpt.Decred-governance-system,

dcrgov'Decred-Assembly (dcrasl)

Description::
Off-chain decision-making shall be used to resolve disputes related to development and voted on by the Decred Assembly as they arise, as an effective proof-of-assembly ("PoA"), until such time PoA is integrated into the blockchain.

The Decred Assembly shall be composed of diverse Assembly members who are selected for membership by the Admission Council from the project ecosystem for representation.

Councils that are composed of Assembly members shall be formed to address ongoing and episodic matters. The initial Councils shall serve the separate functions of admission (Admission Council), creation (Creation Council), and attrition (Attrition Council).

The Admission Council shall vote on the inclusion of new members into the Assembly. All additional Councils shall be created by the Creation Council. The Attrition Council shall be responsible for deactivating both Councils and Assembly members as necessary.

Membership of the Decred Assembly shall consist of Assembly members who have been confirmed by a 60% or greater affirmative vote by the Admission Council. There is no restriction on the age or nationality of Assembly members, the only requirement is that of merit as judged by the Admission Council. Merit is judged on the basis of two characteristics: (1) the amount of time over which one has been involved with the project, and (2) one's body of work and its impact in the context of the project.

Attrition is embraced by temporarily deactivating or actively expelling Assembly members by a 60% or greater affirmative vote by the Attrition Council on the basis of: (1) substantial non-fulfillment of duties for one or more Councils or the Assembly, and/or (2) counterproductive behaviour that goes against the framework set forth in the Constitution without constructive action toward solutions.

All matters formally presented to a Council shall be resolved by a vote in 365 days or less.
[idDcrcttnpgov]
===
Decred Assembly
The first of the groups in the layered governance system is the Decred Assembly, a rolling list of the most meritorious members of the Decred community who will be expected to vote episodically on Assembly-wide issues (creating an effective proof-of-assembly) and participate in committees. The Assembly is a threshold meritocracy with rolling appointments for no fixed length of time, where members are admitted on the basis of what they have actually done for Decred not what they promise to do. Assemblypersons will contribute to the advancement of Decred through discussion and voting in various committees that may be long- or short-lived. Proof-of-assembly, in the form of Assembly-wide votes, will be included in the blockchain in the future, but is not included currently.
Additional layers of governance are planned, e.g., proof-of-developers, and will be formalized in conjunction with the community as Decred development progresses.
[https://wiki.decred.org/Introduction]

Name::
* cpt.dcrasl,
* cpt.Decred-Assembly,

dcrnet'Program (dcrpgm)

dcrpgm'Dcrnet-development

Description::
Self-Funded Development
Decred includes a mechanism for self-funding development to ensure the project is and remains sustainable. A major sticking point for many open-source projects is that they require funding to survive, meaning they typically need to ask for donations and are limited by the funding they receive. To ensure that Decred remains free from the problems related to lack of funding, Decred's consensus rules include a 10% development subsidy in each block that is paid to a development organization on an ongoing basis.
The current development organization is Decred Holdings Group, LLC (DHG), a Nevis-based organization. The development organization will be open to anyone who makes contributions to develop Decred, will remain transparent and issue regular financial statements biannually, and will publicly account for how funds are spent. This entity is built to be adaptable and open to community feedback and guidance, and may therefore change in the future if circumstances require adaptation for it to continue serving its goal to make and keep Decred development sustainable as the project and network scale upward.
[https://wiki.decred.org/Introduction]

Name::
* cpt.dcrnet'development,
* cpt.dcrpgm'Dcrnet-development,

dcrpgm'API

Name::
* cpt.dcrapi,
* cpt.Decred-API,

dcrapi'blocks": 105258,

dcrapi'connections": 8,

dcrapi'difficulty": 1.64511796510149e+06,

dcrapi'errors": ""

dcrapi'protocolversion": 2,

dcrapi'proxy": "",

dcrapi'relayfee": 0.01,

dcrapi'testnet": false,

dcrapi'timeoffset": 3,

dcrapi'version": 70000,

dcrpgm'File

Location::
The files and file content are the same on all platforms. The only difference is the file location. Each program (dcrd, dcrwallet, and dcrctl has a directory of its own to store the configuration files.
On Windows they are located in %LOCALAPPDATA% (C:\Users\username\AppData\Local\ you can type that into the Windows explorer location bar to go straight to the folder).
On Linux and other properly behaving UNIX they are in ~/.dcrd/, ~/.dcrwallet/, and ~/.dcrctl/ respectively. These are hidden directories and will not show up with ls, but are accessible using cd .dcrd, cd .dcrwallet, and cd .dcrctl from the home directory.
OS X does not follow the proper UNIX way and puts them in ~/Libraries/Application Support/Dcrd, ~/Libraries/Application Support/Dcrwallet, and ~/Libraries/Application Support/Dcrctl.
Only the dcrd and dcrwallet folders are created by default. If you want to store the login information for dcrctl you will need to manually create the directory for it.
[https://docs.decred.org/advanced/storing-login-details/]

SPECIFIC

Name::
* dcrpgm.specific,
* cpt.dcrpgm.specific,

Specific::
* cgminer,
* dcrctl,
* dcrd,
* dcrwallet,

dcrpgm.cgminer

Name::
* cpt.cgminer,
* cpt.cgminer-program,

AddressWpg::
* https://github.com/ckolivas/cgminer,
* https://docs.decred.org/mining/proof-of-work/solo-mining/cgminer/windows/

dcrpgm.dcrd

Description::
dcrd: The node daemon, this command-line application handles block management and consensus.
[https://docs.decred.org/getting-started/beginner-guide/]

Name::
* cpt.dcrd,

dcrd'Option

Application options
Option    Description
-A or --appdata=    Path to dcrd home directory ($HOME/.dcrd)
-V or --version    Display version information and exit
-C or --configfile=    Path to configuration file
-b or --datadir=    Directory to store data
--logdir=    Directory to log output. ($HOME/.dcrd/logs)
-a or --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: 9108, testnet: 19108)
--maxpeers=    Max number of inbound and outbound peers (125)
--banduration=    How long to ban misbehaving peers. Valid time units are {s, m, h}. Minimum 1 second (24h0m0s)
-u or --rpcuser=    Username for RPC connections
-P or --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: 8334, testnet: 18334)
--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 clients for standard connections (25)
--norpc    Disable built-in RPC server – NOTE: The RPC server is disabled by default if no rpcuser/rpcpass 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 (leveldb)
--profile=    Enable HTTP profiling on given port – NOTE port must be between 1024 and 65536 (6060)
--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 or --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
--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) decreds 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
--addrindex=    Build and maintain a full address index. Currently only supported by leveldb.
--dropaddrindex=    Deletes the address-based transaction index from the database on start up, and the exits.
--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
[https://docs.decred.org/advanced/program-options/]

dcrpgm.dcrctl

Description::
dcrctl Usage
dcrctl provides a way to control both the daemon dcrd and the wallet dcrwallet using the json rpc interface without actually writing json.

To simplify the examples we will assume that you have all password stored in the config files.

Stopping the programs
To cleanly shut down the programs:
dcrctl --wallet stop
dcrctl stop
Finding the current block height
dcrctl getblockcount
See your balance
dcrctl --wallet getbalance
Get a new address
dcrctl --wallet getnewaddress
Send funds to an address
dcrctl --wallet sendtoaddress TseGH6Xfq9k8Co6txJbY3kiiM7vpaYzXD4T 13
[https://docs.decred.org/advanced/dcrctl-usage/]

Name::
* cpt.dcrctl,

dcrctl'Command (dcrctl [command])

You can always see all commands with dcrctl -l:

* dcrctl'getbestblock
Get the most recent block and hash in the chain.
{
"hash": "00000000000004c5c0bcd4f35c4d194bfe240f8003dfc97db29eeacc3aeeb4a0",
"height": 105057
}

* dcrctl'getbestblockhash
Get the hash of the most recent block in the chain.

* dcrctl'getblockcount
Get the current number of blocks in the chain.

* dcrctl'getdifficulty
Get the current PoW mining difficulty.
1.83210056947851e+06

* dcrctl'gethashespersec
Get the network hash rate.

* dcrctl'getinfo
Displays some basic info about the network including current block number and network difficulty.
{
"version": 70000,
"protocolversion": 2,
"blocks": 105063,
"timeoffset": 2,
"connections": 8,
"proxy": "",
"difficulty": 1.83210056947851e+06,
"testnet": false,
"relayfee": 0.01,
"errors": ""
}

* dcrctl'getmininginfo
Probably the most useful PoW command. Shows the current block, size and difficulty, as well as the total network hash rate per second.
{
"blocks": 105063,
"currentblocksize": 9482,
"currentblocktx": 6,
"difficulty": 1.83210056947851e+06,
"stakedifficulty": 11938483761,
"errors": "",
"generate": false,
"genproclimit": 1,
"hashespersec": 0,
"networkhashps": 22452086771892,
"pooledtx": 270,
"testnet": false
}

* dcrctl'getnettotals
Gets the amount of data sent and received by the daemon.
{
"totalbytesrecv": 670119,
"totalbytessent": 341359,
"timemillis": 1486387877568
}

* dcrctl'getpeerinfo
Similar to getnettoals, includes network data transfer, time connected, block height when daemon was started and current block height.
[
{
"id": 10,
"addr": "92.222-84-111:9108",
"services": "00000003",
"lastsend": 1486387854,
"lastrecv": 1486387854,
"bytessent": 25517,
"bytesrecv": 63555,
"conntime": 1486382573,
"timeoffset": 2,
"pingtime": 84412,
"version": 2,
"subver": "/dcrwire:0.2.0/dcrd:0.3.0/",
"inbound": false,
"startingheight": 105047,
"currentheight": 105054,
"banscore": 0,
"syncnode": false
},
...
{
"id": 12,
"addr": "[2001:41d0:2:b57f::9]:9108",
"services": "00000003",
"lastsend": 1486387929,
"lastrecv": 1486387929,
"bytessent": 19671,
"bytesrecv": 69002,
"conntime": 1486383848,
"timeoffset": 2,
"pingtime": 113461,
"version": 3,
"subver": "/dcrwire:0.2.0/dcrd:0.7.0/",
"inbound": false,
"startingheight": 105053,
"currentheight": 105063,
"banscore": 0,
"syncnode": true
}
]

* dcrctl'getstakedifficulty
Returns current PoS difficulty.
{
"current": 119.38483761,
"next": 119.38483761
}

* dcrctl'getticketpoolvalue Gets the DCR value of all tickets in the pool.
1.53768733078834e+06

* dcrctl'help ("command")
Show the help for a command.

* dcrctl'missedtickets
Show all of your tickets that missed voting.
{
"tickets": [
"1921eaed456da8352d6735d17881d4b817b01b0acdc2b8547b07c360d3072800",
"281fb62fca76881935c0eed73ead93bccd13b1690fed6f2cdb1299d013012e00",

* dcrctl'rebroadcastmissed
Rebroadcast missed tickets to the network. This is done automatically on starting the wallet.

* dcrctl'rebroadcastwinners
As above, but for voted tickets.

* dcrctl'stop
Stop the daemon.
[https://docs.decred.org/advanced/program-options/]

dcrctl'Command.wallet (dcrctl --wallet [command])

Name::
* cpt.dcrctlCmdWlt,

Wallet server commands (--wallet)
* dcrctl'addmultisigaddress nrequired ["key",...] ("account")
Adds an address that requires multiple signatures to use.

* dcrctl'consolidate inputs ("account") Cleans up funds in multiple addresses in an account and puts it in a single address. Note there is a transaction fee to use this command.

* dcrctl'createmultisig nrequired ["key",...]
Used for multi signature wallets.

* dcrctl'createnewaccount "account"
Create a new account. Note, this makes a new account within the current wallet, NOT a new wallet.

* dcrctl'dumpprivkey "address"
Disabled on mainnet for security reasons.

* dcrctl'encryptwallet "passphrase"
Encrypt the wallet with the given phrase

* dcrctl'getaccount "address"
This command will tell you what account the given address belongs to.

* dcrctl'getaccountaddress "account"
Return the first address in the given account (default is ‘default’).

* dcrctl'getaddressesbyaccount "account"
Get all the addresses in the given account.

* dcrctl'getbalance ("account" minconf=1 "balancetype")
Get the spendable balance in the given account. To get the entire balance in the wallet, use ‘getbalance * 0 all’.

* dcrctl'getbalancetomaintain This is the minimum balance to maintain in the wallet when using auto stake buying.

* dcrctl'getmasterpubkey
Get the public key for your wallet. This will allow people to view, but not spend funds in your wallet. It is safe to provide to others.

* dcrctl'getnewaddress ("account" verbose=false)
Get a new address in the given account.

* dcrctl'getreceivedbyaccount "account" (minconf=1)
Gets the total amount of DCR ever received by this wallet. This includes stake returns so it could be quite large if you’re PoS mining.

* dcrctl'getreceivedbyaddress "address" (minconf=1)
Get funds received by the given address.

* dcrctl'getseed
Disabled on mainnet for security.

* dcrctl'getstakeinfo
Retreive useful information on the current status of the PoS pool. See PoS Commands.
{
"blockheight": 105683,
"poolsize": 44597,
"difficulty": 137.79580711,
"allmempooltix": 0,
"ownmempooltix": 0,
"immature": 0,
"live": 0,
"proportionlive": 0,
"voted": 0,
"totalsubsidy": 0,
"missed": 0,
"proportionmissed": 0,
"revoked": 0,
"expired": 0
}

* dcrctl'getticketfee
Get the average fee being paid for tickets.

* dcrctl'getticketmaxprice
Get the maximum price that your wallet will auto purchase tickets for.

* dcrctl'gettickets includeimmature
Get all your current tickets. Second argument should be true if you want to see immature tickets too.

* dcrctl'gettransaction "txid" (includewatchonly=false) Get the transaction associated with the given id.

* dcrctl'listaccounts (minconf=1)
See all accounts and their spendable balance in your wallet.
{
"default": 0,
"imported": 0
}

* dcrctl'listreceivedbyaccount (minconf=1 includeempty=false includewatchonly=false)
Get a list of all your accounts and the amount of DCR that has been received by them.

* dcrctl'listreceivedbyaddress (minconf=1 includeempty=false includewatchonly=false) Get a list of all your addresses and the amount of DCR that has been received by them.

* dcrctl'listsinceblock ("blockhash" targetconfirmations=1 includewatchonly=false)
List transactions that occurred since the given block hash.

* dcrctl'listtransactions ("account" count=10 from=0 includewatchonly=false)
List the number of transactions as specified by ‘count’ in the given account.

* dcrctl'move "fromaccount" "toaccount" amount (minconf=1 "comment")
Move funds between accounts in the same wallet.

* dcrctl'purchaseticket "fromaccount" spendlimit (minconf=1 "ticketaddress" "comment")
Manually purchase PoS tickets. ‘fromaccount’ will usually be “default”. ‘spendlimit’ is the amount you want to spend on tickets in total, not per ticket.

* dcrctl'renameaccount "oldaccount" "newaccount"
Rename an account in your wallet.

* dcrctl'sendfrom "fromaccount" "toaddress" amount (minconf=1 "comment" "commentto") Send DCR from the given account to the given address. You can add an optional comment.

* dcrctl'sendtoaddress "address" amount ("comment" "commentto") Similar to above but uses the default account to send from.

* dcrctl'setbalancetomaintain balance Used for auto staking. The wallet will auto buy tickets until it reaches this threshold.

* dcrctl'setticketfee fee Set the (non-refunable) fee for purchasing stake tickets. See FAQ#Ticket fee

* dcrctl'setticketmaxprice max Set the maximum price the wallet will pay when auto buying tickets.

* dcrctl'setticketvotebits "txhash" votebits ("votebitsext") Sets the given ticket to vote ‘yes’ or ‘no’ (default yes)

* dcrctl'settxfee amount
Sets the fee per kB of transaction data you are willing to pay. Note this is NOT the same as setticketfee above.

* dcrctl'walletlock
Lock the wallet (no funds can be sent).

* dcrctl'walletpassphrase "passphrase" timeout
Unlock the wallet using the given pass phrase for the given time period in seconds. 0 will unlock the wallet until it is restarted.

* dcrctlc'walletpassphrasechange "oldpassphrase" "newpassphrase"
Change your wallet passphrase.
[https://docs.decred.org/advanced/program-options/]

dcrpgm.dcrwallet (link)

dcrpgm.AMGR (address_manager)

dcrpgm.BMGR (block_manager)

dcrpgm.SRVR (server)

dcrpgm.RPCS (RPC_server)

dcrpgm.Web-client (link)

dcrnet'Wallet (dcrwlt)

Description::
Decred uses a wallet to store, transfer and receive DCR. This wallet signs every transaction in and out with a special public key that is unique to you. This is how the network knows that the address sending the transaction is the correct one. Think of your bank account and PIN. When you use your card (wallet) you also enter your PIN (public key) so the bank knows it was you that authorized the transaction. The main difference here is that the public key is known by everyone on the network whereas your PIN is not. When you start using Decred, you will generate a private key that you must not give to anyone.
[https://docs.decred.org/]
===
Now that you are connected to the network, the next thing you need to do is create a wallet that will hold your account addresses and DCR balance.
If you participate in mining or stake mining, this is where your payments will go.
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]

Name::
* cpt.dcrwallet,

dcrwlt'Account

Description::
Decred-account is a-collection of addresses.

Name::
* cpt.Decred-account,

dcrctl --wallet createnewaccount "account"
Create a new account. Note, this makes a new account within the current wallet, NOT a new wallet.

dcrctl --wallet listaccounts (minconf=1)
See all accounts and their spendable balance in your wallet.
{
"default": 0,
"imported": 0
}

dcrctl --wallet renameaccount "oldaccount" "newaccount"
Rename an account in your wallet.

dcrctl --wallet getaddressesbyaccount "account"
Get all the addresses in the given account.

dcrwlt.dcrwallet-cli-program (dcrwltCli)

Description::
dcrwallet is a-cli-program to manage addresses.

Name::
* cpt.dcrwallet-cli-program,

dcrwltCli'Directory

dcrwltCli'File

dcrwltCli'wallet.db

4. Can someone steal my coins if they access wallet.db?
Nobody can steal your coins if they get access to the wallet.db4 file unless they also have your private passphrase. If you chose to use public encryption, they also cannot get access to any of your extended public keys or addresses.
[https://docs.decred.org/faq/wallets-and-seeds/#4-can-someone-steal-my-coins-if-they-access-walletdb]

dcrwltCli'Key.PUBLIC

dcrctl --wallet getmasterpubkey
dpubZFWfp7u3a952Txva4yTCJGUZkNmvwF9uVuZxo1a52ya7QqMSWJwKuqmR8vAQ3dmuhFkKuG3Qam92CC8axLo98aeaYi8QmsqYFse8Tx2GHix

dcrwltCli'Key.PRIVATE (Seed)

Description::
This is the list of words that make up your private key
[https://docs.decred.org/getting-started/user-guides/windows/]

Name::
* cpt.dcrwltCli'seed,

dcrctl --wallet getseed
Disabled on mainnet for security.

5. Can someone use a brute-force attack on a random wallet to regenerate its seed words (the words are not salted)?
All the seed words are is a direct mapping of English words to hex digits. The seed is nothing more than a 256-bit (32-byte) cryptographically random number. Salt does not apply here at all. It has nothing to do with brute-forcing5 random cryptographic numbers.

In other words, since each word can be 256 possibilities and there are 32 words, that yields 256^32 (or 2^256 depending on how you want to look at it, but it is the same number) possibilities. That number is larger than the entire number of hydrogen atoms in the known universe. In fact, it is almost more than the number of atoms total in the known universe.

To put this in perspective, assuming there are 7 billion people on the planet and each person owned 10 computers and each one of those computers could test a billion possibilities a second and that you could find the solution on average after testing only 50% of the total possibilities, it would still take 26x10^48 (that’s 26 trillion trillion trillion trillion) years to brute-force a single seed.
[https://docs.decred.org/faq/wallets-and-seeds/#5-can-someone-use-a-brute-force-attack-on-a-random-wallet-to-regenerate-its-seed-words-the-words-are-not-salted]

dcrseedhextowords

Description::
Simple utility to convert a Decred seed hex to seed words needed for importing into wallets.
[https://github.com/davecgh/dcrseedhextowords]

dcrwltCli'Money

dcrwltCli'Sending-to-address

dcrctl --wallet sendfrom "fromaccount" "toaddress" amount (minconf=1 "comment" "commentto")
Send DCR from the given account to the given address. You can add an optional comment.

dcrctl --wallet sendtoaddress "address" amount ("comment" "commentto")
Similar to above but uses the default account to send from.
dcrctl --wallet sendtoaddress TseGH6Xfq9k8Co6txJbY3kiiM7vpaYzXD4T 13

dcrwltCli'Ballance

dcrctl --wallet getbalance
See your balance

dcrwltCli'Passphrase

* dcrctl -wallet walletpassphrase "passphrase" timeout
Unlock the wallet using the given pass phrase for the given time period in seconds. 0 will unlock the wallet until it is restarted.

dcrctlc --wallet walletpassphrasechange "oldpassphrase" "newpassphrase"
Change your wallet passphrase.

dcrwltCli'Creating

Description::
> dcrwallet --create
Enter the private passphrase for your new wallet:
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]

dcrwltCli'Connecting-to-network

Description::
Now that you have created your wallet and connected to the Decred network, you need to link your wallet to the network so it can send and receive coins and participate in mining.
[https://docs.decred.org/getting-started/user-guides/windows/#create-your-wallet]

dcrwltCli'Deleting

Deleting Your Wallet
There are a few reasons you might need to delete your wallet.
- You need to restore your wallet from seed.
- You do not have the seed any more and want to make a new wallet.
- You want to remove the wallet from a particular computer.
First you need to find the wallet directory which varies by platform. You can find information for each opperating system here.

In that directory, you need to delete the file mainnet/wallet.db. That will completely remove your wallet from that computer. To access it again you will need to restore from the original seed.

It is important to note that it is possible (but not certain) that a deleted file may be recovered using file recovery tools. If you are deleting this for security reasons you probably need to use a secure deletion tool such as GNU shred.
[https://docs.decred.org/advanced/deleting-your-wallet/]

dcrwlt.WEB

Name::
* cpt.dcrnet'browser-wallet,

FAQ::
1. How secure is the web client?
The web client is a fork of Copay, so it is as secure as that1. The seed (and hence private keys) are kept and computed locally in your browser’s local storage and everything is run client-side. The server never has access to any of the private data needed to spend coins.

2. Can you solo stake mine with the web client?
No, recall that the browser wallet runs locally on your machine. That would not lend itself well to running 24/7. As a result, the browser wallet will never be able to solo stake2. It would however be possible to support stake pooling with it. Stake pools provide you with the ability to not have a wallet running 24/7 since it will be the pool’s responsibility to be online and cast a vote on your behalf at that point.

3. Is it safe to delete the wallet and start over?
It is safe3. The only difference is you will need to go to Import Wallet this time instead of creating a new one.
[https://docs.decred.org/faq/web-client/]

dcrnet'Security

FAQ.4. What are the security implications of using the same RPC server authentication passwords with dcrd and dcrwallet?
There is a lot less you can do with access to dcrd than you can to dcrwallet. The key point is that RPC access to dcrwallet, when the wallet is unlocked, can be used to spend coins.

When they are both on the same machine, it probably does not matter all that much, but when you are running more secure setups where the wallet is on a separate machine than dcrd, you would pretty clearly not want to use the same credentials for both. Remember that dcrd has to be on an Internet-facing machine in order to stay synced to the network (download the block chain data, broadcast transactions, and so on).

On the other hand, the dcrwallet that contains your funds, for best security, should really not be on a system that has Internet access as it is significantly more difficult for someone to steal your coins if the wallet that contains them is not even on a machine that is accessible via the Internet. Obviously, if you are staking your coins, you will need at least one Internet-facing dcrwallet instance. Thus, the most secure setup involves having one “cold” dcrwallet instance that is on a machine that is not Internet-accessible, and a second “hot” dcrwallet instance (using a different seed of course) to which the cold dcrwallet instance delegates voting right via the --ticketaddress parameter, both of which use different credentials.
[https://docs.decred.org/faq/configuration/#4-what-are-the-security-implications-of-using-the-same-rpc-server-authentication-passwords-with-dcrd-and-dcrwallet]

dcrnet'Resource

AddressWpg::
* https://decred.org/
* docs: https://docs.decred.org/
* https://wiki.decred.org/Main_Page,
* download: https://github.com/decred/decred-release/releases,
* source: https://github.com/decred,
* https://stats.decred.org/

dcrnet.MAIN

Name::
* cpt.dcrnet.mainnet,

dcrnet.TEST

Description::
3. Can I run mainnet and testnet daemons and wallets at the same time and on the same machine?¶
Yes3, just add --testnet to the appropriate spots (dcrd, dcrwallet, dcrctl) and everything will work. This is why they use different ports and data/log directories!
[https://docs.decred.org/faq/configuration/#3-can-i-run-mainnet-and-testnet-daemons-and-wallets-at-the-same-time-and-on-the-same-machine]

Name::
* cpt.dcrnet.testnet,

bcnnet.time.PIVX (PIVXnet {2016-01-29})

Cpt-created: {2017-04-16}

Description::
PIVX, Private Instant Verified Transaction, is a privacy-focused, decentralized, open source cryptocurrency run by a global community run by creators, innovators, and technology enthusiasts.
[https://pivx.org/]

Name::
* cpt.PIVX,
* cpt.PIVXnet,
* cpt.PIVX-network,
* cpt.Private-Instant-Verified-Transaction,

Generic::
* Exchange-value-unit-network,
* Proof-of-Stake-network,
* cpt.PIVX-network,
* cpt.Private-Instant-Verified-Transaction,

Description::
People often ask why they should choose PIVX above other crypto currency, here is a short list of features that make PIVX stand out from the crowd.
- PIVX is an anonymous Peer-To-Peer currency.
- PIVX is working towards Private Instant Verified Transactions as its default transaction.
- PIVX is Community Driven
- PIVX uses Blackcoin’s improved Proof of Stake 3.0 protocol instead of Proof of Work. So it is more efficient in keeping the network secure than PoW.
- PIVX has incredibly low transaction fees that are typically a fraction of a penny due to the PoS efficiency. This means it is perfect for micro-transaction business pricing models that previously existed using Bitcoin.
- PIVX had no ICO. Pre-mined coins to start the chain were publicly burned.
- PIVX is based on Bitcoin 0.10.x core which means it is more up to date than most other PoS digital currencies that commonly use a lower Bitcoin core version.
- PIVX uses an innovative variable Seesaw Reward Balance System that dynamically adjusts its reward to masternodes and staking nodes. (See white-paper section.)
- PIVX has a very large and growing active community on multiple social networking sites such as BCT, Slack, Reddit, Twitter, Riot, Gitter, Facebook etc.
- PIVX community also uses Trello for publicly accessible task planning and management.
- PIVX has a highly active, accessible and responsive development team.
- PIVX is available to trade on multiple exchanges including Bittrex with plans to be added to larger exchanges.
- PIVX currently has a monthly decreasing block reward inflation with it reaching its final low inflationary rate of approx. 4.8% pa beginning mid-May 2017.
- PIVX has a repository of guides with more planned including video guides and materials.
- PIVX has had consistently higher profitability percentage compared to other digital currencies utilizing masternodes such as DASH since launch and even now.
[https://pivx.org/features/]

pivxnet'Exchange-value-unit.Consensus (PIVXevuC)

Description::
PIVX (PIVX)
$2.10 (16.06%)
0.00178412 BTC (17.03%)
Rank 10
Currency
Market Cap
$111,236,380
94,560 BTC
Volume (24h)
$2,698,460
2,294 BTC
Circulating Supply
53,000,748 PIVX
[https://coinmarketcap.com/currencies/pivx/] {2017-04-16}

pivxnet'Governance

Description::
Governance:
Our goal for the PIVX Governance system is to involve the community. We’ve got a long way to get there, but soon we expect to be making huge initial steps. This process will take a long time, and we call it Community Designed Governance.
This page explains the 3 areas of the Governance system and how voting is managed.
All areas of DAO Governance follow the same process in terms of submitting a proposal, and Master Node Owners voting to accept/reject the proposal. Such voting can only happen at each Super Block. (Roughly once per month.)
There are 3 types of Proposals:
Manifesto Governance:
This will very rarely – almost never – happen, and will require a high amount of participation (Metric not yet defined) by Master Node Owners (MNOs) during the voting process. Key is to make sure that even MNOs that typically don’t involve themselves with voting for proposals, are made aware a Manifesto Proposal has been submitted, and that they have been well informed of the issue(s) involved in a factual and unbiased way.
Treasury Governance:
These proposals are the most common and are for allocating funds in the monthly treasury budget. These funds can be used for anything related to support PIVX. It may be overhead costs for servers, or Google Apps etc., or it may be for advertising, or to help launch a business that could not be justified otherwise.
Protocol Governance:
These proposals are zero cost and are to make decisions to change the code base – the protocol – of the PIVX system. If such a decision requires funding, then that funding portion would be a separate Treasury Governance proposal submitted after the Protocol Governance proposal has been accepted.
[https://pivx.org/governance/]

pivxnet'Resource

AddressWpg::
* https://pivx.org/
* BlockH0: http://www.presstab.pw/phpexplorer/PIVX/block.php?blockhash=000...80ef818,

bcnnet.time.BitShares2 (BTSnet {2015-10-13})

Cpt-created: {2017-03-28}

Description::
BitShares - Your share in the Decentralized Exchange
Built using the latest in industry research, BitShares 2.0 offers a stack of financial services including exchange and banking on a blockchain.
[https://bitshares.org/]

Name::
* cpt.BitShares-network,
* cpt.btsnet,

Generic::
* Blockchain-network-with-builtin-decentralized-governance,
* Exchange-value-unit-blockchain-network,

btsnet'whole.DAO (btsdac)

Description::
BitShares is a decentralized autonomous company, and as such offers products to earn their shareholders a profit.
As we have seen in the previous section, it also offers a way to pay for expense, such as development and administration but earns a profit by burnning (i.e. reducing supply).
Of course, the company can only be profitable if the income exceeds the expenses.
Thus, we will now discuss both in detail.
[idBtswpr4]

Name::
* cpt.BitShares-Decentralized-autonomous-company,
* cpt.btsdac,

Generic::
* blockchain-DAO,

btsnet'Protocol (btsprl)

btsprl'White-paper.2015-12-18 (btswpr)

AddressWpg::
* http://docs.bitshares.eu/_downloads/bitshares-general.pdf,

BITSHARES 2.0: GENERAL OVERVIEW
Fabian Schuh, Daniel Larimer
Cryptonomex, Cryptonomex.com( * )
Blacksburg (VA), USA
{ fabian, dan}@cryptonomex.com

Release: financial-platform/1.0-rc2-2-gb5c3ca7 (2015-12-18)

Abstract

BitShares 2.0 is an industrial-grade decentralized platform built for high-performance financial smart contracts.
The decentralized exchange that allows for trading of arbitrary pairs without counterparty risk facilitates only one out of many available features.
Market-pegged assets, such as the bitUSD, are crypto tokens that come with all the advantages of traditional cryptocurrencies like bitcoin but trade for at least the value of their underlying asset, e.g. $1.
Furthermore, BitShares represents the first decentralized autonomous company that lets its shareholders decide on its future direction and products.
This paper gives a brief overview over the whole BitShares platform, recapitulates known blockchain technologies and redefines state-of-the-art.

1 Introduction

BitShares is a technology supported by next generation entrepreneurs, investors, and developers with a common interest in finding free market solutions by leveraging the power of globally decentralized consensus and decision making.
Consensus technology has the power to do for economics what the internet did for information.
It can harness the combined power of all humanity to coordinate the discovery and aggregation of realtime knowledge, previously unobtainable.
This knowledge can be used to more effectively coordinate the allocation of resources toward their most productive and valuable use.

Bitcoin is the first fully autonomous system to utilize distributed consensus technology to create a more efficient and reliable global payment network.
The core innovation of Bitcoin is the Blockchain, a cryptographically secured public ledger of all accounts on the Bitcoin network that facilitates the transfer of value from one individual directly to another.
For the first time in history, financial transactions over the internet no longer require a middle man to act as a trustworthy, confidential fiduciary.

BitShares looks to extend the innovation of the blockchain to more industries that rely upon the internet to provide their services.
Whether its banking, stock exchanges [ 1 ], lotteries [ 2 ], voting [ 3 ], music [ 4 ], auctions or many others, a digital public ledger allows for the creation of distributed autonomous companies (or DACs) that provide better quality services at a fraction of the cost incurred by their more traditional, centralized counterparts.
The advent of DACs ushers in a new paradigm in organizational structure in which companies can run without any human management and under the control of an incorruptible set of business rules.
These rules are encoded in publicly auditable open source software distributed across the computers of the companies’ shareholders, who effortlessly secure the company from arbitrary control.

BitShares does for business what bitcoin did for money by utilizing distributed consensus technology to create companies that are inherently global, transparent, trustworthy, efficient and most importantly profitable.
Why and how BitShares achieves a decentralized but profitable business is described in more detail in a distinct paper [?].

BitShares has went through many changes and has done its best to stay on top of blockchain technology.
Towards the end of 2014 some of the DACs were merged and the X was dropped from ”BitShares X” to become simply BitShares (BTS).

The next step in the evolution of BitShares was named Bitshares 2.0, and incorporates all of the feedback and lessons learned from the BitShares stakeholders, partners, developers, marketers, and other community leaders throughout a full year of research and development.

With the former BitShares 1.0, the core development team has closely controlled the development and direction of BitShares.
With BitShares reaching maturity at version 2.0, the team is ready to remove the training wheels, and let the direction of all future development be decided completely by stakeholder vote.

By utilizing a new worker voting system that will be included in BitShares 2.0, the development will continue in whatever direction is approved by its stakeholders.
With this new structure, BitShares will be more robust, and sustainable while being agile, flexible and adaptive to overcome unforeseen hurdles of the future.

This paper is intended as an introduction to BitShares 2.0 and presents the basic concepts of the peer-to-peer nature, the distributed public ledger in form of a blockchain, and give a brief overview of the decentral consensus mechanism applied to reach blockchain state consensus.
We further discuss the basic blockchain tokens (BTS), its distribution and usage in BitShares.
We also describe the wallet and operations with the network as well as outline the functionalities of BitShares accounts.

2 Base Token

In the BitShares network the base token is called a BitShare and carries the abbreviation BTS.
It is dividable into 105 = 100,000 sub-units.

In general, all properties of Bitcoin also apply to BTS, namely, they have value, can be transfered on the blockchain and are secured by an Elliptic Curve Digital Signature Algorithm (ECDSA) on the curve secp256k1.

In contrast to most crypto-currencies, BitShares does not claim to be a currency but rather an equity in a decentral autonomous company (DAC).
As a result, the market valuation of BitShares is free floating and may be as volatile as any other equity (e.g. of traditional companies).

Nonetheless, BTS tokens can be used as collateral in financial smart contracts [ 5 ] such as market pegged assets and thus back every existing smartcoin such as the bitUSD.

The following subsection recapitulate the initial distribution and supply of BTS.

2.1 Distribution of BTS

BitShares has set an example of a social agreement by establishing its own sharedropping standards.
The idea behind sharedropping is that any future chain will always benefit by choosing to align itself with the ones who worked hard at making the technology possible.

The base tokens of BitShares 2.0 will be distributed on a 1:1 basis fully honoring the BTS tokens in the BitShares 1.0 network.
For the sake of completeness, the following paragraphs will describe the initial distribution of BTS tokens in the aforementioned BitShares 1.0 network from PTS and AGS.

2.1.1 Bitshares PTS

The original grandfather prototype, formerly called proto-shares (PTS), BitShares PTS was a simple minable cryptocurrency (similar to Bitcoin) that was created to allow people to advertise their interest in receiving free token samples in future DACs.
PTS functions as a high-tech mailing list for distributing free sample bitshares from many developers of decentral autonomous companies (DACs).
The only people who tended to own PTS tokens were those who understand DACs, so DAC developers prefer to target them with free samples rather than air dropping their samples onto a much less interested general population.

The industry recommendation was that when a DAC is launched, at least 10% of the DAC’s total tokens are given proportionally to holders of PTS.
This was not a contract or a guarantee; it was a social consensus of those in the DAC community about what percentage of a new DAC’s tokens should be distributed to those who have supported the BitShares industry by owning its PTS tokens.

The BitShares DAC honored this social consensus and even sharedropped 47% of its ever existing supply onto BitShares PTS holders.

2.1.2 Bitshares AGS

The original grandmother prototype formerly called angel-shares (AGS) in reference to the patron angels who once funded the performing arts.
That’s why AGS are not liquid. (No one can trade the proof that you were the once willing to donate to this cause.)

The donations have been recorded in the public blockchain of bitcoin which now acts as a book of honorable donors.
The bitcoin address used as donation address was
1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc
Note, that the donation period for AGS lasting 200 days has ended already and that donations to this address never resulted nor will result in any obligations whatsoever.

Since the social consensus includes AGS, the industry recommendation again is to give at least 10% to holders of AGS.
Similar to BitShares PTS, the 47% of the total BTS supply have been sharedropped onto members of the AGS mailing-list proportionally.

2.2 Bitshares Genesis Distribution

We see that the seed allocation (initial distribution) of BitShares, which took place over a 1 year period, from November 2013 to November 2014, was achieved by sharedropping 47% to BitShares PTS and another 47% to BitShares AGS.
This way, the full, fairness was defined by equal opportunity and in the case of BTS we have distributed fairly by CPU mining of PTS while, alternatively, everyone had an additional equal opportunity by contribute to AGS.

Having attracted two different groups of investors with a mined crypto token via PTS and a donation based book of donors via AGS, everyone had a chance to participate and be rewarded with stake in the genesis block of BitShares 1.0.
This genesis block solely consisted of AGS and PTS holders on a 50%/50% ratio such that the BTS tokens initially issued by this genesis can be considered well distributed.

The other 6% are set aside to secure the future of BitShares and funds its development and operational costs.
In practice, they are put into the so called reserves pool that no one has control over except the BitShares protocol.
In contrast to many other cryptocurrencies, every shareholder has a say as to how these funds are spend (see section 4.2).

3 Business Units

Let us discuss the organization structure of the BitShares network when interpreted as a company.
Some of these entities are associated with a cost for the business and need to be accounted for in profit calculations.

3.1 BitShares Witnesses

In BitShares, the witnesses’ job is to collect transactions, bundle them into a block, sign the block and broadcast it to the network.
They essentially are the block producers for the underlying consensus mechanism (see section 5.4).

For each successfully constructed block, a witness is payed in shares that are taken from the limited reserves pool at a rate that is defined by the shareholders by means of approval voting.

3.2 BitShares Committee

Since Bitcoin struggled to reach a consensus about the size of their blocks, the people in the cryptocurrency space realized that the governance of a DAC should not be ignored.
Hence, BitShares offers a tools to reach on-chain consensus about business management decisions.

The BitShares blockchain has a set of parameters available that are subject of shareholder approval.
Shareholders can define their preferred set of parameters and thereby create a so called committee member or alternatively vote for an existing committee member.
The BitShares committee consists of C active committee members.

For each business parameter the protocol will calculate the difference between up- and down-votes (vpro - vcon) for each active committee member and then take the median of the top C active members:

imgBtswprFigAlg.png

Since, C is a parameter as any other, the shareholders decide for the size of the committee.

The BitShares ecosystem has a set of parameters available that are subject of shareholder approval.
Initially, BitShares has the following blockchain parameters:

fee structure:
fees that have to be paid by customers for individual transactions

block interval:
i.e. block interval, max size of block/transaction

expiration parameters:
i.e. maximum expiration interval

witness parameters:
i.e. maximum amount of witnesses (block producers)

committee parameters:
i.e. maximum amount of committee members

witness pay:
payment for each witnesses per signed block

worker budget:
available budget available for budget items (e.g. development)

Please note that the given set of parameters serves as an example and that the network’s parameters are subject to change over time.

Additionally to defining the parameters any active witness can propose a protocol or business upgrade (i.e. hard fork) which can be voted on (or against) by shareholders.
When the total votes for the hard fork are greater than the median witness weight w then the hard fork takes effect.

3.3 BitShares Budget Items/Workers

Thanks to the funds stored in the reserve pool, BitShares can offer to not only pay for its own development and protocol improvement but also support and encourage growth of an ecosystem.

In order to be get paid by BitShares, a proposal containing
(a) the date of work begin,
(b) the date of work end,
(c) a daily pay (denoted in BTS),
(d) the worker’s name, and
(e) an internet address
has to be publish on the blockchain and approved by shareholders.
A worker can also choose on of the following properties:
• vesting: pay to the worker’s account
• refund: return the pay back to the reserve pool to be used for future projects
• burn: destroys the pay thus reducing share supply, equivalent to share buy-back of a company stock.

A blockchain parameter (defined by shareholders through the committee) defines the daily available budget.
No more than that can be paid at any time to all so called workers combined.
The daily budget is distributed as illustrated in fig. 1:
(1) The available budget is taken out of reserves pool.
(2) The budget items are sorted according to their approval rate (vpro - vcon) in a descending order.
(3) Starting at the worker with the highest approval rate, the requested daily pay is payed until the daily budget is depleted.
(4) The worker with the least approval rate that was paid may receive less than the requested pay

Hence, in order to be successfully funded by the BitShares ecosystem, the shareholder approval for your budget item needs to be highly ranked.

Since the payments for workers from the non-liquid reserve pool result in an increased supply of BTS, these payments are vesting over a period of time defined by shareholders.

3.4 Proxy Voting

Proxy Voting denotes the process of handing out ones voting power to someone else.
This process can be reverted to reclaim ones voting power.

The motivation behind proxy voting is to reduce voting apathy and allow active shareholders to react more quickly to business and security concerns.
That way, misbehaving witnesses can be fired more rapidly.

That is centralizing in some respects, but it’s controlled centralization in the sense that nothing can happen too quickly and if shareholders don’t like which way it is going, still have the ability to switch courses.
Compared to classical crypto currencies (e.g. Bitcoin), this process is somewhat similar to pooled mining with the exception that every shareholder can participate and only voting power is handed over.
Furthermore, this allows for independent non-profit oriented decisions because there is no profit variance but purely political influence.

imgBtswprFig1.png
Figure 1: Illustration of budget item payments.

4 BitShares: A profitable DAC

BitShares is a decentralized autonomous company, and as such offers products to earn their shareholders a profit.
As we have seen in the previous section, it also offers a way to pay for expense, such as development and administration but earns a profit by burnning (i.e. reducing supply).
Of course, the company can only be profitable if the income exceeds the expenses.
Thus, we will now discuss both in detail.

4.1 The Products

The BitShares DAC offers their private customers several products and in this paper we would like to briefly highlight some of them.
Of course, all of these come with the properties of cryptocurrencies, namely
(a) global accessibility,
(b) customizable anonymity,
(c) industry-grade security,
(d) freedom from counterparty-risk,
(e) flexible account Control,
(f) low transaction delays, and
(g) world-wide decentralized network.

Keep in mind that, as BitShares has the technical possibilities to upgrade itself with shareholder approval, new products and properties can be added in a timely manner.

4.1.1 Price-stable SmartCoins

The core product of BitShares is a class of assets referred to as Market-Pegged Assets (MPA), BitAssets, or SmartCoins and represent a crypto-token that has at least the value of the underlying asset.
For instance, a bitUSD can always be sold for $1, either to a merchant at face-value, or to the network (by means of settlement of a contract) in return for BitShares’ core currency (BTS) worth $1.

In practice, a SmartCoin always has 100% or more of its value backed by means of a contract for difference (CFD) between two parties with BTS as collateral.
What makes these CFDs unique is that they are free from counterparty risk.
This is achievable by letting the network itself (implemented as a software protocol) be responsible for securing the collateral and performing (forced) settlements if required as is described in more detail in [ 5 ].

Applications for SmartCoins are obvious:
With the aforementioned properties, a bitUSD qualifies for regular and instant payments, for example with a smartphone or a modern browser application.
In contrast, a bitGOLD (with one ounce of gold as underlying asset) would fit those people’s needs that see gold as long-term store of value.
As long as an asset has a unique global price, a SmartCoin could track its value.
This allows for even more sophisticated applications, such as tracking a stock market index, or the price of a liter of gasoline.

4.1.2 Customizable Assets

In addition to market-pegged assets, the BitShares network also offers to register customizable assets on the public ledger.
For instance, a BitShares customer may create the asset FREE and distribute them to friends for free.
Another customer may want his company shares to be traded in the BitShares network.
Yet another use-case would be event tickets that can be sold at a fixed price and allow the holder to enter a concert.

Since the use-cases of these User-Issued Assets (UIA) are manifold and space is limited in this paper, we discuss them in depth in [ 5 ].

4.1.3 Decentralized Exchange

As we have seen in the previous section, the BitShares network offers to register different types of assets.
It also allows for trading between almost( 1 ) any two pairs in an instant, trust-less and secure manner by means of the BitShares Decentralized Exchange (DEX).

In traditional trading, a clearing house is necessary because trades are made much faster than the cycle time for completing the underlying transaction.
Since in BitShares trades between two parties are performed on a global scale in a decentralized network and no middlemen are required, there is no need for settlement or clearing delays.
If a trade in the DEX executes, the bought asset instantly (T+0 [ 6 ]) appears in the customers wallet.

In combinations with SmartCoins, a startup could easily perform a dollar-denominated crowd-funding without legal or tax implications due to the velocity of cryptocurrency tokens.
Furthermore, as all order-books are shared on a global scale, the markets will become more efficient because no different prices existing on different locations on earth.
Of course, the DEX is open 24/7 and does not apply any limits to customers.
A more detailed discussion about the DEX can be found in a distinct paper [ 5 ].

4.1.4 Flexible Identity Management

In BitShares, each account is separated into
• Active Permission which has control over its funds and
• Owner Permission which controls the account itself.

Furthermore, BitShares uses authorities consisting of one or many entities that authorize an action, such as transfers, trades or account modifications.
An authority consists of one or several pairs of an account name with a weight.
In order to obtain a valid transaction, the sum of the weights from signing the parties has to exceed the threshold as defined in the permissions.

Let’s discuss some examples to shed some light on the used terminology and the use-cases.
We assume that a new account is created with it’s active permissions set as described below.
Note that the same scheme also works for the owner permissions!

A flat multi-signature scheme is composed of M entities of which N entities must sign in order for the transaction to be valid.
Now, in BitShares, we have weights and a threshold instead of M and N.
Still we can achieve the very same thing with even more flexibility as we will see now.

Let’s assume, Alice, Bob, Charlie and Dennis have common funds.
We want to be able to construct a valid transaction if only two of those agree.
Hence a 2-of-4 (N-of-M) scheme can look as follows:
Account Weight
Alice 33%
Bob 33%
Charlie 33%
Dennis 33%
Threshold: 51%

All four participants have a weight of 33% but the threshold is set to 51%.
Hence only two out of the four need to agree to validate the transaction.
Alternatively, to construct a 3-of-4 scheme, we can either decrease the weights to 17 or increase the threshold to 99%.

With the threshold and weights, we now have more flexibility over our funds, or more precisely, we have more control.
For instance, we can have separate weights for different people.
Let’s assume Alice wants to secure here funds against theft by a multisignature scheme but she does not want to hand over too much control to her friends.
Hence, we create an authority similar to:
Account Weight
Alice 49%
Bob 25%
Charlie 25%
Dennis 10%
Threshold: 51%

Now the funds can either be accessed by Alice and a single friend or by all three friends together.

Let’s take a look at a simple multi-hierarchical corporate account setup.
We are looking at a company that has a Chief of Financial Officer (CFO) and a some departments working for him, such as the Treasurer, Controller, Tax Manager, Accounting, etc.
The company also has a CEO that wants to have spending privileges.
Hence we construct an authority for the funds according to:
Account Weight
CEO.COMPANY 51%
CFO.COMPANY 51%
Threshold: 51%
whereas CEO.COMPANY and CFO.COMPANY have their own authorities.
For instance, the CFO.COMPANY account could look like:
CFO.COMPANY Weight
Chief.COMPANY 51%
Treasurer.COMPANY 33%
Controller.COMPANY 33%
Tax Manager.COMPANY 10%
Accounting.COMPANY 10%
Threshold: 51%

This scheme allows:
• the CEO to spend funds
• the Chief of Finance Officer to spend funds
• Treasurer together with Controller to spend funds
• Controller or Treasurer together with wither the Tax Manager or Accounting to spend funds.

Hence, a try of arbitrary depth can be spanned in order to construct a flexible authority to reflect mostly any business usecase.

4.1.5 Variable and Flexible Fees

In the BitShares ecosystem every operation is assigned an individual fee that has to be payed in the core asset (BTS) the end user.
These fees are subject to change and are defined by the elected committee members.
Thus each and every shareholder of the BitShares core asset (BTS) has a say as to what the fees should be.
If shareholders can be convinced to reduce a certain fee and consensus is reached, the fee will be reduced automatically by the blockchain.
This allows the ecosystem, to stay flexible and adept the price for the usage of its products over time.

Since the network expects the fees to be payed on the the core asset (BTS) but many users may not want to hold any, the protocol allows to trade an arbitrary asset into BTS from the asset-specific *fee pool* at the *core exchange rate* which is defined by the issuer (or the witnesses in the case of a market pegged asset).

4.2 Revenue and Expenses

Revenue streams are essentially caused by fees that have to be payed when using the DACs products, such as market pegged assets, user-issued assets, or the decentralized exchange [ 5 ].
These fees are variable, can be changed by shareholder approval and include
(a) transfers,
(b) order operations,
(c) account operations,
(d) asset operations,
(e) witness creations
(f) proposal operations
(g) withdraw permission operations
(h) committee member operations,
(i) worker creation, and more.

In contrast to bitcoin, where newly created coins in each block are distributed solely among countless miners that immensely overpay for the network security [ 7 ], the BitShares ecosystem achieves a better security at lower costs by means of an adjustable number of approved and trusted witnesses in DPOS.
Additionally, the BitShares ecosystem has the capability to pay for its own development through budget items.
Both, the payment for witnesses, as well as the budget items are required to be approved by the shareholders.

imgBtswprFig2.png
Figure 2: Cash flow of BitShares 2.0

As an example, an entrepreneur may approach the shareholders and offer to launch a business in the BitShares space that would greatly benefit the ecosystem.
If he succeeds and convinces the shareholders to vote for and not against his plan, he could get an initial funding by the DAC.

Another use-case would be the improvement of the blockchain’s protocol.
A developer could propose a change or extension of the existing software implementation and be payed by the DAC to do so (after shareholder approval).
Hence, as long as the average shareholders acts rational, the BitShares blockchain can be seen as a self-funded but profitable business

4.3 Memberships

Accounts in BitShares are separated into three groups.
We decided to give users the option to upgrade their accounts into a VIP-like status if they desire and profit from reduced fees and additional features.

A regular account is a non-member.

Lifetime Members get a percentage cashback on every transaction fee they pay and qualify to earn referral income (see below) from users they register with or refer to the network.
A Lifetime membership is associated with a certain one-time fee that is defined by the committee and qualifies for reduced transaction fees.

If a lifetime membership is too much you can still get the same cashback for the next year by becoming an annual subscriber for a smaller one-time fee which lasts for only one year and qualifies for reduced transactions fee during that time.

4.4 Referral Program

Every time an account you referred pays a transaction fee, that fee is divided among several different accounts.
The network takes a cut, and the Lifetime Member who referred the account gets a cut.

The registrar is the account that paid the transaction fee to register the account with the network.
The registrar gets to decide how to divide the remaining fee between themselves and their own affiliate.

Fees paid are only divided among the network, referrers, and registrars once every maintenance interval.
The paid fees are divided among two or three parties, depending on the parameter d that can be set by the registrar:

total fee = network fee(20%)
+ registrar(80% · (100% - d%)) (1)
+ referrer(80% · (d%))

Most fees are made available immediately, but fees over the vesting threshold (such as those paid to upgrade your membership or register a premium account name) must vest for some days as defined by the committee.

5 Architecture of BitShares

Before describing how BitShares can be used to secure financial freedom, we first discuss the technical specifications briefly.
Among these is the public ledger (also referred to as the blockchain), the peer-to-peer network, the distributed consensus finding mechanism and the system parameters available to BitShares.

5.1 Public Ledger

As in other crypto-currencies, the public ledger of BitShares is built and stored in a linked series of blocks, known as a blockchain.

The ledger provides a permanent record of transactions that have taken place, and also establishes an order in which transactions have occurred.
Hence, every content of the blockchain can be assigned an permanent and unique identifier in form of a scalar number.

Every full node in the BitShares network stores a full copy of this blockchain and can verify its validity and the evaluate new blocks.

Every block contains
• a reference to the previous block,
• a timestamp,
• a hash of a secret,
• the secret of the previous hash,
• a set of transactions, and
• a signature by the block producing authority

As will be discussed in section 5.4, the consensus mechanism allows for synchronous block production with constant block confirmation times, e.g., one block every 5 s.

Since the blocks mainly embrace customer transactions but has to perform time intensive tasks, or execute rare events from time to time, some actions such as reenumeration of blockchainbased votes and rare events such as newly registered block producers (witnesses) are carried out more rarely but still on a frequent so called maintenance interval.

5.2 Irreversibility of Transactions

Historically we have stated that a blockchain becomes irreversible after one round of block production with greater than 51% participation.
It turns out that this metric is too fuzzy because of noise in how witnesses are ordered.
In an effort to provide stronger/absolute guarantees a new metric has been derived that determines the exact point at which a particular block becomes irreversible.
The algorithm to define the metric goes as follows:

Sort N witnesses by the last block number they signed, then take the highest block number that is lower than 66% of all other witnesses.
This will indicate that said block has been confirmed by 66% of all witnesses and is clearly irreversible.

This particular metric is dynamic and can respond to changes in the order of witnesses and is immune to situations where the network fragments into more than two pieces.
In the event of a major disruption users are guaranteed that no block older than that number can ever be undone.

If we had only 17 witnesses and 3 second block confirmation interval, then this will take an average of 34 seconds.
If we had 101 witnesses and 3 second blocks then this will take an average of 3.3 minutes for block to be irreversible,

Having this metric is important to give everyone in the network peace of mind in the unlikely event that a software bug or network issue causes all witnesses to fall out of sync and gives a clear measure of when they are considered back in sync.

Anyone accepting transactions as final prior to the most recent irreversible block is choosing to take some extra risk on their transaction.

5.3 Low Latency Peer-to-Peer Network

The peer-to-peer network distributes the full blockchain database across the world.
It consists of public and private nodes as well as seed nodes that are used for initial connection to the peer-to-peer network.
Anybody may connect to any known node and download the current global and unique state (i.e. the blockchain).

Once a node is in sync with the peer-to-peer network it received and applies newly created blocks, and assists new network nodes by further distribution of the blockchain.
Additionally, new blocks are broadcast to all connected nodes.

Furthermore, network nodes receive transaction from participants and forward them to the rest of the network until they reach the witness that is in charge of constructing the next block.
Hence, new transaction broadcasts do not necessarily need to reach all nodes.

Building a low-latency network requires P2P nodes that have low-latency connections and a protocol designed to minimize latency.
For the purpose of this document we will assume that two nodes are located on opposite sides of the globe with a ping round-trip time of 250 ms.

In the Bitcoin network architecture, transactions and blocks were broadcast in a following manner: inventory messages notify peers of transactions and blocks, then peers fetch the transaction or block from one peer.
After validating the item a node will broadcast an inventory message to its peers.

Under this model it will take approximately 0.75 s for a peer to communicate a transaction or block to another peer even if their size was 0 and there was no processing overhead.
This level of performance is unacceptable for a network attempting to produce one block every second.

This prior protocol also sent every transaction twice: initial broadcast, and again as part of a block.

To minimize latency each node needs to immediately broadcast the data it receives to its peers after validating it.
Given the average transaction size is less than 100 bytes, it is almost as efficient to send the transaction as it is to send the notice (assuming a 20 byte transaction id).

5.4 Distributed Consensus Mechanism

Consensus is the mechanism by which a subset of people decide upon unitary rational action.
The process of consensus decisionmaking allows for all participants to consent upon a resolution of action even if not the favored course of action for each individual participant.
Bitcoin was the first system to integrate a fully decentralized consensus method with the modern technology of the internet and peer-to-peer networks in order to more efficiently facilitate the transfer of value through electronic communication.
The proof-of-work structure that secures and maintains the Bitcoin network is one manner of organizing individuals who do not necessarily trust one another to act in the best interest of all participants of the network.

It is of importance to distinguish a democratic voting process in which every citizen of a community has one and only one vote from a distributed consensus mechanism in crypto-currencies hand over voting power either in relation to hashing power (e.g. proof-of-work) or on a per stake basis (e.g. proof-of-stake).
In both cases, those that invest in the required infrastructure to increase their voting percentage (i.e. by buying mining hardware or stake) act as shareholder in a distributed community.

The BitShares community employs Delegated Proof-of-Stake (DPOS) in order to find efficient solutions to distributed consensus decision making.
DPOS attempts to solve the problems of both Bitcoin’s traditional proof-of-work system, and the proofof-stake system of Peercoin and NXT by implementing a layer of technological democracy to offset the negative effects of centralization.
For historical reasons, the technology is still called delegated proof-of-stake even though what have been delegates in BitShares 1.0 are now so called witnesses.

In DPOS set of N witnesses (formerly known as delegates) sign the blocks and are voted on by those using the network with every transaction that gets made.
By using a decentralized voting process, DPOS is by design more democratic than comparable systems.
Rather than eliminating the need for trust all together, DPOS has safeguards in place the ensure that those trusted with signing blocks on behalf of the network are doing so correctly and without bias.
A more detailed description about the distributed consensus mechanism as well as a discussion how blockchain forking is prevented during attacks is given in a separate paper [ 8 ].

Additionally, each block signed must have a verification that the block before it was signed by a trusted node.
DPOS eliminates the need to wait until a certain number of untrusted nodes have verified a transaction before it can be confirmed.

This reduced need for confirmation produces an increase in speed of transaction times.
By intentionally placing trust with the most trustworthy of potential block signers, as decided by the network, no artificial encumbrance need be imposed to slow down the block signing process.
DPOS allows for many more transactions to be included in a block than either proof of work or proof of stake systems.

In a delegated proof-of-stake system, centralization still occurs, but it is controlled.
Unlike other methods of securing cryptocurrency networks, every client in a DPOS system has the ability to decide who is trusted rather than trust concentrating in the hands of those with the most resources.
DPOS allows the network to reap some of the major advantages of centralization, while still maintaining some calculated measure of decentralization.
Furthermore, once a witness has reached approval by shareholders, surpasses the threshold of the most N active witnesses, and, hence, is elected to actively participate in the block production procedure, its power is equivalent to all other active witnesses.
This system is enforced by a fair election process where anyone could potentially become a delegated representative (witness) of the majority of users.

Please note that DPOS has a recommended 1 - 2 block confirmation versus bitcoin’s 6 block recommendation.
DPOS is much more resistant against forks for the following reasons:
• When a fork is produced it is very likely that all witnesses have seen and processed your transaction and thus no alternative transactions can be broadcast and the next witness is almost certain to include your transaction.
All witnesses are much more trusted than miners.
• The probability of a fork after a block has been produced is very low (΅ 0.01%) where as Bitcoin has 25 orphans in the last 22 days (about 1 per day in Dec 3, 2014) which translates into 0.7% of blocks are orphaned.
• On normal operations, DPOS achieves a 100% witness participation rate and when we are less than that it is more often because a witness went offline and didn’t produce a block than because they produced a fork.
• In BitShares 1.0 forks have almost always been resolved within 30 seconds.

Assuming a 10 second block interval, Bitshares is mathematically over 70x less likely to orphan after 1 block than Bitcoin after 1 block (10 minutes).
After 3 blocks (30 seconds) any random orphan will have been resolved and the probability of alternative chains is much lower than the 0.000001% of Bitcoin.
By the time Bitcoin gets to .7% orphan probability, BitShares has 60 blocks which would have a probability of being orphaned of less than 10-120.

5.5 Operations

Similar to most crypto-currencies, there is a set of predefined operations that can be performed on the blockchain.
In contrast to Bitcoin, which uses a technique called script to describe operations that shall be performed in a programmatic way using OP codes, the BitShares network has a predefined (but extensible) set of operations that a user may perform.

All operations end up on the blockchain eventually.
Once they are validated and confirmed by a witness by being included into a block, they are executed and update the state of the blockchain accordingly.

The release version of BitShares 2.0 comes with
(a) transfer ops,
(b) trading order ops,
(c) account ops,
(d) asset ops,
(e) witness ops,
(f) committee ops,
(g) worker ops, and
(h) vesting ops,
However, since BitShares allows for shareholder approved, live protocol upgrades, the set of operations can be extended and modified.

On the blockchain level, each operation is assigned an individual id with a custom set of parameters for performance and latency reasons.

5.6 Transactions

Having defined operations, we can now put these into a list of operations and construct a transaction.
In addition to its operations, a transaction also consists of
(a) an expiration date,
(b) a reference block number,
(c) a reference block prefix,
(d) a set of extensions, and
(e) a set of signatures to authorize each operation.

Each node (including witnesses) verifies that all requires signatures to perform the given operations are present and valid prior to propagating the transactions to the rest of the network and hence to the witness node constructing the next block.
If the transaction is included into a block it is considered finally valid or executed.

5.7 Proposed Transactions

Additionally, the Graphene technology allows users to propose a transaction which requires approval of multiple accounts in order to execute.
These transactions are only partially valid and do not execute until they are completely valid.

The user proposes a transaction, then signatory accounts add or remove their approvals from this operation.
When a sufficient number of approvals have been granted, the operations in the proposal are used to create a virtual transaction which is subsequently evaluated.
Even if the transaction fails, the proposal will be kept until the expiration time, at which point, if sufficient approval is granted, the transaction will be evaluated a final time.
This allows transactions which will not execute successfully until a given time to still be executed through the proposal mechanism.
The first time the proposed transaction succeeds, the proposal will be regarded as resolved, and all future updates will be invalid.

The common use-case would be similar to so called multisignature transactions which must be signed by two parties.
Classical crypto currencies had the issue that such proposed transaction had to be communicated on separated channels until all required signatures have been collected.
With BitShares, it is no possible to propose a transaction on the blockchain and have the required signatures be added by the respective parties.

The proposal system in combination with corporate accounts allows for arbitrarily complex or recursively nested authorities.
If a recursive authority (i.e. an authority which requires approval of nested authorities on other accounts) is required for a proposal, then a second proposal can be used to grant the nested authority’s approval.
That is, a second proposal can be created which, when sufficiently approved, adds the approval of a nested authority to the first proposal.
This multiple-proposal scheme can be used to acquire approval for an arbitrarily deep authority tree.

6 Discussion

In general, BitShares has similarities and differences to most known crypto-currencies.
As many others, BitShares is based on a blockchain that stores and propagates transactions, i.e. user operations.
Since, with DPOS, computational resources are used solely for the purpose of transaction propagation and confirmation, rather than wasteful computational work, the block production interval has been reduced to a few seconds.
Eventually, this improves the over-all profitability of the DAC.

Additionally, we make use of named accounts that can be registered on the blockchain.
Users no longer need to send money to an alphanumeric string that can be copied incorrectly.
Rather, funds can be sent as easily as sending an email, and in the same fashion.
Name registration allows for the identification of who transactions are originating with no need to manually create a contact account for a given address.
Transactions may contain a memo field that allow users to describe the nature of the transaction or broadcast secure messages about the price of the current transaction fee.
Since BitShares 2.0 implements confidential transaction, there is no longer a need for mixing or master nodes.
Transactions can be more private in BitShares than in Bitcoin, for example, with no additional work needed from the user.

BitShares is a 100% proof-of-stake system.
This means it is a lot more efficient (cost per security) than proof-of-work and therefore does not have to dilute stakeholders/coinholders (there is a 10% yearly dilution of Bitcoin-holders as per 2015 with Bitcoin and lowering this dilution would mean to lower the security).
Hence, the cost of securing the BitShares network is merely a fraction of all transaction fees accumulated by the network.

The job of the block producers is simple: include as many valid transactions in your given block as possible and sign a single block.
These Block producers compete for the most approval in order to be allowed to produce blocks.
Shareholder votes are proportionate to the relative number of shares they own.
The BitShares DAC is completely shareholder run.
Now people can be hired by the blockchain.
Where coins like Bitcoin dilute to pay for network security, BitShares takes these fees and directs them towards continual improvement of the network and community.
This helps insure BitShares will stay competitive in its feature set.
More details about the consensus scheme of BitShares will be made available in a separated whitepaper.

Recalling the initial distribution of BTS, it seem convincing to assume that most alternative distributions are way more unfair and some disproportionately favor their respective core developers.
Since BitShares is a self-funded DAC, it can pay for its future development autonomously by dilution, if shareholders reach an on-blockchain consensus by approval voting.

Furthermore, it becomes clear from the descriptions that BitShares is governed by its shareholders and the committee whose members have shareholder approval.
This allows for flexible adjustment of blockchain parameters, such as transaction fees, block interval, and more, as well as protocol upgrades to include new features.

Since the BitShares is a self-funded blockchain, that can pay its workers by protocol, a healthy competition for new improvements, upgrades and additional features can be expected.

7 Conclusion

The properties and features mentioned in this paper make clear that the BitShares DAC is well-prepared for its own features.
It was shown that, due to on-blockchain voting, a decentralized development and funding can be achieved.
The consensus mechanism DPOS reaches a trade-off between efficiency and required trust while keeping a better decentralization that mostly every other blockchain consensus scheme.

Release: financial-platform/1.0-rc2-2-gb5c3ca7 (2015-12-18)

References

[1] Daniel Larimer, “Creating a Fiat/Bitcoin Exchange without Fiat Deposits.” https://bitcointalk.org/index.php?topic=223747.0.

[2] “DACPlay,” http://dacPLAY.org.

[3] Adam Ernest, “Follow My Vote,” http://followmyvote.com.

[4] Cedric Cobban, “Follow My Vote,” http://peertracks.com.

[5] “BitShares 2.0: Financial Smart Contract Platform,” BitShares Whitepapers, 2015.

[6] “The trade is the settlement,” http://t0.com/.

[7] Daniel Larimer, “Overpaying for Security,” http://letstalkbitcoin.com/is-bitcoin-overpaying-for-falsesecurity/#.Ui-p9WTFT7s.

[8] “BitShares 2.0: Distributed Consensus,” BitShares Whitepapers, 2015.

(*) This work was supported by Cryptonomex and honorable members of the bitsharestalk.org community.

(1) The issuer of an asset may white-/or black-list trading partners.

btsnet'Blockchain (btsbcn)

btsbcn'Block (btsblk)

btsblk.GENESIS

Description::
Block 1
0 transactions in this block, produced at 2015-10-13 14:12 (UTC)
[https://cryptofresh.com/b/1]

btsbcn'Block-Explorer (btsbex)

AddressWpg::
* http://cryptofresh.com/

btsnet'Exchange-value-unit.Consensus (BTScevu)

Cpt-created: {2017-03-28}

Name::
* cpt.bitshares-token,
* cpt.btscevt,

btsnet'Governance-system (btsgov)

Name::
* cpt.btsgov,
* cpt.btsnet'builin-governance-system,
* cpt.btsnet'Decentralized-Governance-By-Blockchain,

btsnet'Commitee

Description::
Decentralized Committee:
Decisions that can effect the BitShares ecosystem are made using a on-chain committee voted upon by shareholders.
Hence, no single entity can change the deal retroactively.
[http://docs.bitshares.eu/bitshares/user/you-should-know.html]

btsnet'Human (btshmn)

btshmn.SHAREHOLDER (btshsh)

Description::
Become Shareholder: If you buy BTS either from a partner exchange or from the DEX, you become a shareholder of the BitShares decentralized business and as such can take a cut of its profits and participate in votes for future directions.
[http://docs.bitshares.eu/bitshares/user/you-should-know.html#the-investors]

btshmn.DEVELOPER (btshdr)

btsnet'Organization (btsogn)

Name::
* cpt.bitshares'organization,
* cpt.btsogn,

btsogn.Cryptonomex-Inc

Description::
Cryptonomex Inc. is an independent blockchain development company founded by the core developers of the BitShares blockchain. Our mission is to faciliate the growth and adoption of industrial blockchain technology.
[https://cryptonomex.com/]

Name::
* cpt.Cryptonomex-Inc,

btsnet'Resource (btsrsc)

Name::
* cpt.bitshares'resource,
* cpt.btsresource,
* cpt.btsrsc,

AddressWpg::
* https://bitshares.org/

=== DOCS:
* http://docs.bitshares.eu/
* FIRST STEPS FOR END-USERS http://docs.bitshares.eu/bitshares/user/first-steps-users.html,
=== COMMUNITY:
* https://www.bitsharestalk.org/

btsnet.EVOLUTING

{time.2014}
Towards the end of 2014 some of the DACs were merged and the X was dropped from ”BitShares X” to become simply BitShares (BTS).
[White-paper]

bcnnet.time.Ethereum (ETHnet {2015-07-30})

Description::
Ethereum is a programmable blockchain.
Rather than give users a set of pre-defined operations (e.g. bitcoin transactions), Ethereum allows users to create their own operations of any complexity they wish. In this way, it serves as a platform for many different types of decentralized blockchain applications, including but not limited to cryptocurrencies.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]

Name::
* cpt.bcnnet.ethereum,
* cpt.ethereum,
* cpt.ethereum-network,
* cpt.ethnet,
* cpt.ethereum-ecosystem,
* cpt.ethereum-network,
* cpt.ethereum-platform,
* cpt.ethereum-project,
* cpt.ethereum-space,
* cpt.ethnet,
* cpt.net.ethereum,
* cpt.netEth, {2017-01-28}

Generic::
* Blockchain-program-blockchain-network,
* Proof-of-work-blockchain-network,

Description::
Ethereum is a peer to peer network where every peer stores the same copy of a blockchain database and runs an Ethereum virtual machine to maintain and alter it’s state. Proof of work is integrated into the blockchain technology by making the creation of a new block require all members of the network undertake the proof of work. Consensus is achieved via incentivization for peers to always accept the longest chain of blocks in the blockchain by distribution of a cryptographic token of value: ‘ether’.

This leaves us with a new piece of technology that does not fit within the client-server model nor does it qualify as a traditional peer-to-peer network as its existence is incentivised meaning it can be relied upon to provide a consistent deterministic service.

Because of its distributed nature and built in cryptographic security it can act as a third party, capable of arbitrating trustlessly, and without interference from outside parties. Through the use of cryptocurrencies decisions made by software can have financial consequences for people, organisations or even other software.
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
Ether is a necessary element -- a fuel -- for operating the distributed application platform Ethereum. [https://ethereum.org/ether]
===
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

Ethereum is how the Internet was supposed to work.

Ethereum was crowdfunded during August 2014 by fans all around the world. It is developed by ETHDEV with contributions from great minds across the globe.
[https://www.ethereum.org/]
Original author(s)     Vitalik Buterin, Gavin Wood
Developer(s)     Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in     C++, Go, JavaScript, Python, Java, node.js
Operating system     Linux, POSIX, Windows, OS X
Type     Decentralized computing
License     GPL3, MIT, LGPL, et al
Website     www.ethereum.org

Ethereum Software ETHEREUM-YOUTUBE-PROFILE-PIC.png
Original author(s)     Vitalik Buterin, Gavin Wood
Developer(s)     Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in     C++, Go, JavaScript, Python, Java, node.js
Operating system     Linux, POSIX, Windows, OS X
Type     Decentralized computing
License     GPL3, MIT, LGPL, et al
Website     www.ethereum.org

Ethereum is a blockchain-based cryptocurrency that includes a virtual machine featuring stateful user-created smart contracts and a Turing-complete contract language. Ethereum uses its currency unit, Ether, as payment to incentivise a network of peers to provide computational services defined by the smart contracts deployed on the blockchain.

Ethereum was initially described by Vitalik Buterin in late 2013,[1] formally described by Gavin Wood in early 2014 in the so-called Yellow Paper[2] and launched 30 July 2015.[3] It is among a group of "next generation" (or "Bitcoin 2.0") platforms.[4]
[https://en.wikipedia.org/wiki/Ethereum]
===
Ethereum was designed as a smart contract platform.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
===
Ethereum – a Decentralised Consensus Network
[https://dappsforbeginners.wordpress.com/tutorials/introduction-to-development-on-ethereum/]
===
Ethereum is the world's first publicly accessible computer. Situated on the Internet, anyone may pay a small fee to its open group of maintainers in order to use it. Secured and authenticated through cryptography, it provides a unprecedented opportunity for use as the cornerstone of IoT, Internet-law, smart contracts and the next digital economy.
[https://ethcore.io/]
===
The basis for decentralised consensus is the peer-to-peer network of participating nodes which maintain and secure the blockchain.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-ecosystem/infrastructure.html#the-ethereum-network]
===
Ethereum is a programmable blockchain. Rather than give users a set of pre-defined operations (e.g. bitcoin transactions), Ethereum allows users to create their own operations of any complexity they wish. In this way, it serves as a platform for many different types of decentralized blockchain applications, including but not limited to cryptocurrencies.
Ethereum in the narrow sense refers to a suite of protocols that define a platform for decentralised applications. At the heart of it is the Ethereum Virtual Machine (“EVM”), which can execute code of arbitrary algorithmic complexity. In computer science terms, Ethereum is “Turing complete”. Developers can create applications that run on the EVM using friendly programming languages modelled on existing languages like javascript and python.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#what-is-ethereum]
===
Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

Ethereum is how the Internet was supposed to work.

Ethereum was crowdfunded during August 2014 by fans all around the world. It is developed by ETHDEV with contributions from great minds across the globe.
[https://www.ethereum.org/]
Original author(s)     Vitalik Buterin, Gavin Wood
Developer(s)     Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in     C++, Go, JavaScript, Python, Java, node.js
Operating system     Linux, POSIX, Windows, OS X
Type     Decentralized computing
License     GPL3, MIT, LGPL, et al
Website     www.ethereum.org

Ethereum Software ETHEREUM-YOUTUBE-PROFILE-PIC.png
Original author(s)     Vitalik Buterin, Gavin Wood
Developer(s)     Gavin Wood, Jeffrey Wilcke, Vitalik Buterin, et al
Written in     C++, Go, JavaScript, Python, Java, node.js
Operating system     Linux, POSIX, Windows, OS X
Type     Decentralized computing
License     GPL3, MIT, LGPL, et al
Website     www.ethereum.org

Ethereum is a blockchain-based cryptocurrency that includes a virtual machine featuring stateful user-created smart contracts and a Turing-complete contract language. Ethereum uses its currency unit, Ether, as payment to incentivise a network of peers to provide computational services defined by the smart contracts deployed on the blockchain.

Ethereum was initially described by Vitalik Buterin in late 2013,[1] formally described by Gavin Wood in early 2014 in the so-called Yellow Paper[2] and launched 30 July 2015.[3] It is among a group of "next generation" (or "Bitcoin 2.0") platforms.[4]
[https://en.wikipedia.org/wiki/Ethereum]

ethnet'ATTRIBUTE

AddressWpg::
* http://gavwood.com/Paper.pdf,

External Actor:
A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum.
It can interact with Ethereum through depositing signed Transactions and inspecting the blockchain and associated state.
Has one (or more) intrinsic Accounts.

Address:
A 160-bit code used for identifying Accounts.

Account:
Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state.
They also have some (possibly empty) EVM Code and a (possibly empty) Storage State associated with them.
Though homogenous, it makes sense to distinguish between two practical types of account: those with empty associated EVM Code (thus the account balance is controlled, if at all, by some external entity) and those with non-empty associated EVM Code (thus the account represents an Autonomous Object). Each Account has a single Address that identifies it.

Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object. Transactions are recorded into each block of the blockchain.

Autonomous Object: A notional object existent only within the hypothetical state of Ethereum. Has an intrinsic address and thus an associated account; the account will have non-empty associated EVM Code. Incorporated only as the Storage State of that account.

Storage State: The information particular to a given Account that is maintained between the times that the
Account’s associated EVM Code runs.

Message: Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts, either
through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction.

Message Call: The act of passing a message from one Account to another. If the destination account is associated with non-empty EVM Code, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation.

Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.

Contract: Informal term used to mean both a piece of EVM Code that may be associated with an Account or an Autonomous Object.

Object: Synonym for Autonomous Object.

App: An end-user-visible application hosted in the Ethereum Browser.

Ethereum Browser: (aka Ethereum Reference Client) A cross-platform GUI of an interface similar to a simplified browser (a la Chrome) that is able to host sandboxed applications whose backend is purely on the Ethereum protocol.

Ethereum Virtual Machine: (aka EVM) The virtual machine that forms the key part of the execution model for an Account’s associated EVM Code.

Ethereum Runtime Environment: (aka ERE) The environment which is provided to an Autonomous Object executing in the EVM. Includes the EVM but also the structure of the world state on which the EVM relies for certain I/O instructions including CALL & CREATE.

EVM Code: The bytecode that the EVM can natively execute. Used to formally specify the meaning and ramifications of a message to an Account.

EVM Assembly: The human-readable form of EVM-code.

LLL: The Lisp-like Low-level Language, a human-writable language used for authoring simple contracts and general low-level language toolkit for trans-compiling to.

ethnet'trustless

This is why you might have heard people call Ethereum ‘trustless’ – there’s no need for users to trust into a central authority to ‘do the right thing’.
[https://dappsforbeginners.wordpress.com/tutorials/your-first-dapp/]

ethnet'STATE

Description::
The state in Ethereum essentially consists of a key-value map, where the keys are addresses and the values are account declarations, listing the balance, nonce, code and storage for each account (where the storage is itself a tree).
For example, the Morden testnet genesis state looks as follows:
{
"0000000000000000000000000000000000000001": {
"balance": "1"
},
"0000000000000000000000000000000000000002": {
"balance": "1"
},
"0000000000000000000000000000000000000003": {
"balance": "1"
},
"0000000000000000000000000000000000000004": {
"balance": "1"
},
"102e61f5d8f9bc71d0ad4a084df4e65e05ce0e1c": {
"balance": "1606938044258990275541962092341162602522202993782792835301376"
}
}
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
===
The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethnet'state,
* cpt.ethstate,

ethstate'Updating

Description::
Unlike transaction history, however, the state needs to be frequently updated: the balance and nonce of accounts is often changed, and what’s more, new accounts are frequently inserted, and keys in storage are frequently inserted and deleted. What is thus desired is a data structure where we can quickly calculate the new tree root after an insert, update edit or delete operation, without recomputing the entire tree. There are also two highly desirable secondary properties:

The depth of the tree is bounded, even given an attacker that is deliberately crafting transactions to make the tree as deep as possible. Otherwise, an attacker could perform a denial of service attack by manipulating the tree to be so deep that each individual update becomes extremely slow.
The root of the tree depends only on the data, not on the order in which updates are made. Making updates in a different order and even recomputing the tree from scratch should not change the root.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]

ethstate.FINAL

ethstate.GENESIS

ethnet'Protocol (ethprl)

ethprl'NAME.ENGLISH:
* cpt.ethnet'protocol,
* cpt.ethprl,

ethprl'GENERIC:
* blockchain-protocol,

ethprl'Implementation-language

Description::
Contrast this to the Ethereum ecosystem which today has no less than 6 implementations of consensus: C++, Go, Python, Java, JavaScript, and Haskell.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]

Name::
* cpt.ethnet'coding-language,
* cpt.ethnet'source-code-language,
* cpt.ethprl'implementation-language,

ethprl'White-paper (ethwpr)

NAME.ENGLISH:
* cpt.ethereum-white-paper,
* cpt.ethnet'white-paper,
* cpt.ethprl'white-paper,
* cpt.ethwpr,

ADDRESS.WPG:
* {2017-03-12} 36-revision: https://github.com/ethereum/wiki/wiki/White-Paper/307f463132be1878013196695ef82ca19eee4693,

A Next-Generation Smart Contract and Decentralized Application Platform

Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller.
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physical device ("smart property"), non-fungible assets such as domain names ("Namecoin"), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules ("smart contracts") or even blockchain-based "decentralized autonomous organizations" (DAOs).
What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.

Introduction-to-Bitcoin-and-Existing-Concepts

History

The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades.
The anonymous e-cash protocols of the 1980s and the 1990s were mostly reliant on a cryptographic primitive known as Chaumian Blinding.
Chaumian Blinding provided these new currencies with high degrees of privacy, but their underlying protocols largely failed to gain traction because of their reliance on a centralized intermediary.
In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented.
In 2005, Hal Finney introduced a concept of "reusable proofs of work", a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as "proof of work."

The mechanism behind proof of work was a breakthrough because it simultaneously solved two problems.
First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of updates to the state of the Bitcoin ledger.
Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing Sybil attacks.
It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings.
Since then, an alternative approach has been proposed called proof of stake, calculating the weight of a node as being proportional to its currency holdings and not its computational resources.
The discussion concerning the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.

Bitcoin-As-A-State-Transition-System

From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result.
In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value of A's account by $X and increases the value of B's account by $X.
If A's account has less than $X in the first place, the state transition function returns an error.
Hence, one can formally define:

APPLY(S,TX) -> S' or ERROR

In the banking system defined above:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

But:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

The "state" in Bitcoin is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key[ 1 ]).
A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO for addition to the state.

The state transition function APPLY(S,TX) -> S' can be defined roughly as follows:

1. For each input in TX:
* If the referenced UTXO is not in S, return an error.
* If the provided signature does not match the owner of the UTXO, return an error.
2. If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
3. Return S' with all input UTXO removed and all output UTXO added.

The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value.
In order to use this for payment, the protocol is as follows.
Suppose Alice wants to send 11.7 BTC to Bob.
First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC.
Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12.
She then creates a transaction with those three inputs and two outputs.
The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC "change".
If Alice does not claim this change by sending it to an address owned by herself, the miner will be able to claim it.

Mining

If we had access to a trustworthy centralized service, this system would be trivial to implement; it could be coded exactly as described, using a centralized server's hard drive to keep track of the state.
However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transition system with a consensus system in order to ensure that everyone agrees on the order of transactions.
Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks".
The network is intended to create one block approximately every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block.
Over time, this creates a persistent, ever-growing, "blockchain" that continually updates to represent the latest state of the Bitcoin ledger.

The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:

1. Check if the previous block referenced by the block exists and is valid.
2. Check that the timestamp of the block is greater than that of the previous block[ 2 ] and less than 2 hours into the future
3. Check that the proof of work on the block is valid.
4. Let S[0] be the state at the end of the previous block.
5. Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.
6. Return true, and register S[n] as the state at the end of this block.

Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state.
Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block.
Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.

The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work".
The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187.
The purpose of this is to make block creation computationally "hard", thereby preventing Sybil attackers from remaking the entire blockchain in their favor.
Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.

At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes.
In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere.
Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee".
Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.

In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker.
Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions.
The attacker's strategy is simple:

1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
2. Wait for the delivery of the product
3. Produce another transaction sending the same 100 BTC to himself
4. Try to convince the network that his transaction to himself was the one that came first.

Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000.
After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it.
At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant.
Now, the attacker creates another transaction sending the 100 BTC to himself.
If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state.
So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one.
Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate.
The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain.
In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").

Merkle-Trees


01: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.


02: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.

An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure.
The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block.
A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree.
The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct.
The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work).

The Merkle tree protocol is arguably essential to long-term sustainability.
A "full node" in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month.
Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate.
A protocol known as "simplified payment verification" (SPV) allows for another class of nodes to exist, called "light nodes", which download the block headers, verify the proof of work on the block headers, and then download only the "branches" associated with transactions that are relevant to them.
This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.

Alternative-Blockchain-Applications

The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history.
In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax.
However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice.
After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.

* Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database.
In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy.
Ideally, one would like to be able to have an account with a name like "george".
However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them.
The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol.
Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.

* Colored coins - the purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies - or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain.
In the colored coins protocol, one "issues" a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs).
This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.

* Metacoins - the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY'.
Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX) returns an error, the protocol defaults to APPLY'(S,TX) = S.
This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol.
Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.

Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin.
The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code.
Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.

The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin.
SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state.
Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols.
Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid.
Currently, all "light" implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.

Scripting

Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts".
UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language.
In this paradigm, a transaction spending that UTXO must provide data that satisfies the script.
Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise.
Other, more complicated, scripts exist for various additional use cases.
For example, one can construct a script that requires signatures from two out of a given three private keys to validate ("multisig"), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations.
Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like "this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me", essentially allowing decentralized cross-cryptocurrency exchange.

However, the scripting language as implemented in Bitcoin has several important limitations:

* Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything.
The main category that is missing is loops.
This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient.
For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.

* Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn.
For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B.
This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now.
However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.

* Lack of state - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that.
This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties).
It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement.
Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.

* Blockchain-blindness - UTXO are blind to certain blockchain data such as the nonce and previous block hash.
This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.

Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin.
Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security.
Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability.
With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.

Ethereum

The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important.
Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions.
A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty.
Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.

Ethereum-Accounts

In Ethereum, the state is made up of objects called "accounts", with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts.
An Ethereum account contains four fields:

* The nonce, a counter used to make sure each transaction can only be processed once
* The account's current ether balance
* The account's contract code, if present
* The account's storage (empty by default)

"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees.
In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code.
An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.

Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.

Messages-and-Transactions

The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.
Transactions contain:

* The recipient of the message
* A signature identifying the sender
* The amount of ether to transfer from the sender to the recipient
* An optional data field
* A STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take
* A GASPRICE value, representing the fee the sender pays per computational step

The first three are standard fields expected in any cryptocurrency.
The data field has no function by default, but the virtual machine has an opcode with which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it to.
The contract would read these values from the message data and appropriately place them in storage.

The STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial of service model.
In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use.
The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state.
There is also a fee of 5 gas for every byte in the transaction data.
The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.

Messages

Contracts have the ability to send "messages" to other contracts.
Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment.
A message contains:

* The sender of the message (implicit)
* The recipient of the message
* The amount of ether to transfer alongside the message
* An optional data field
* A STARTGAS value

Essentially, a message is like a transaction, except it is produced by a contract and not an external actor.
A message is produced when a contract currently executing code executes the CALL opcode, which produces and executes a message.
Like a transaction, a message leads to the recipient account running its code.
Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.

Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions.
For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.

Ethereum-State-Transition-Function

The Ethereum state transition function, APPLY(S,TX) -> S' can be defined as follows:

1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.
2. Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.
3. Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.
4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.
5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.
6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.

For example, suppose that the contract's code is:

if !self.storage[calldataload(0)]:
 self.storage[calldataload(0)] = calldataload(32)

Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code.
Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and 64 bytes of data, with bytes 0-31 representing the number 2 and bytes 32-63 representing the string CHARLIE.
The process for the state transition function in this case is as follows:

1. Check that the transaction is valid and well formed.
2. Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.
3. Initialize gas = 2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left.
3. Subtract 10 more ether from the sender's account, and add it to the contract's account.
4. Run the code. In this case, this is simple: it checks if the contract's storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963
5. Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.

If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.

Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert.
This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas.
Finally, note that there is an opcode, CREATE, that creates a contract; its execution mechanics are generally similar to CALL, with the exception that the output of the execution determines the code of a newly created contract.

Code-Execution

The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code".
The code consists of a series of bytes, where each byte represents an operation.
In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected.
The operations have access to three types of space in which to store data:

* The stack, a last-in-first-out container to which values can be pushed and popped
* Memory, an infinitely expandable byte array
* The contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term.

The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.

The formal execution model of EVM code is surprisingly simple.
While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage.
At the start of every round of execution, the current instruction is found by taking the pcth (Program Counter) byte of code (or 0 if pc >= len(code)), and each instruction has its own definition in terms of how it affects the tuple.
For example, ADD pops two items off the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SSTORE pops the top two items off the stack and inserts the second item into the contract's storage at the index specified by the first item.
Although there are many ways to optimize Ethereum virtual machine execution via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.

Blockchain-and-Mining

The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences.
The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
Aside from that, two other values, the block number and the difficulty, are also stored in the block.
The basic block validation algorithm in Ethereum is as follows:

1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
4. Check that the proof of work on the block is valid.
5. Let S[0] be the state at the end of the previous block.
6. Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
7. Let S_FINAL be S[n], but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.

The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin.
The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed.
Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees).
A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently.
Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.

A commonly asked question is "where" contract code is executed, in terms of physical hardware.
This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.

Applications

In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.

Token Systems

On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.
Token systems are surprisingly easy to implement in Ethereum.
The key point to understand is that all a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (ii) the transaction is approved by A.
All that it takes to implement a token system is to implement this logic into a contract.

The basic code for implementing a token system in Serpent looks as follows:


def send(to, value):
    if self.storage[msg.sender] >= value:
        self.storage[msg.sender] = self.storage[msg.sender] - value
        self.storage[to] = self.storage[to] + value
    

This is essentially a literal implementation of the "banking system" state transition function described further above in this document.
A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address.
But that's all there is to it.
Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency.
The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction.
Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.

Financial-derivatives-and-Stable-Value-Currencies

Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code.
The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is.
The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.

Given that critical ingredient, the hedging contract would look as follows:

1. Wait for party A to input 1000 ether.
2. Wait for party B to input 1000 ether.
3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.
4. After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.

Such a contract would have significant potential in crypto-commerce.
One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day.
Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD).
The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset.
This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.

In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist.
Financial derivatives provide an alternative.
Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role.
Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow.
Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.

Identity-and-Reputation-Systems

The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data.
The major cited use case is for a DNS system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address.
Other use cases include email authentication and potentially more advanced reputation systems.
Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:


def register(name, value):
    if !self.storage[name]:
        self.storage[name] = value
    

The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from.
Anyone can register a name with some value, and that registration then sticks forever.
A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership.
One can even add reputation and web-of-trust functionality on top.

Decentralized-File-Storage

Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee.
However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month.
Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.

The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract".
This contract works as follows.
First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it.
One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree.
When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.

An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession.
If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.

Decentralized-Autonomous-Organizations

The general concept of a "decentralized autonomous organization" is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code.
The members would collectively decide on how the organization should allocate its funds.
Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work.
This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement.
So far much of the talk around DAOs has been around the "capitalist" model of a "decentralized autonomous corporation" (DAC) with dividend-receiving shareholders and tradable shares; an alternative, perhaps described as a "decentralized autonomous community", would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member.
The requirement that one person can only have one membership would then need to be enforced collectively by the group.

A general outline for how to code a DAO is as follows.
The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change.
Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage.
In a simple implementation of such a DAO contract, there would be three transaction types, distinquished by the data provided in the transaction:

* [0,i,K,V] to register a proposal with index i to change the address at storage index K to value V
* [0,i] to register a vote in favor of proposal i
* [2,i] to finalize proposal i if enough votes have been made

The contract would then have clauses for each of these.
It would maintain a record of all open storage changes, along with a list of who voted for them.
It would also have a list of all members.
When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change.
A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote).
This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.

An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision.
A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract).
Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors".

Further-Applications

1. Savings wallets.
Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key.
She puts ether into a contract with Bob, a bank, as follows:

* Alice alone can withdraw a maximum of 1% of the funds per day.
* Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting off this ability.
* Alice and Bob together can withdraw anything.

Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help.
If Alice's key gets hacked, she runs to Bob to move the funds to a new contract.
If she loses her key, Bob will get the funds out eventually.
If Bob turns out to be malicious, then she can turn off his ability to withdraw.

2. Crop insurance.
One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index.
If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well.
This can be expanded to natural disaster insurance generally.

3. A decentralized data feed.
For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "SchellingCoin".
SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward.
Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth.
This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.

4. Smart multisignature escrow.
Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds.
Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day.
Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.

5. Cloud computing.
The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly.
This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat).
Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes.
Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform.

6. Peer-to-peer gambling.
Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice, can be implemented on the Ethereum blockchain.
The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.

7. Prediction markets.
Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy as a governance protocol for decentralized organizations.

8. On-chain decentralized marketplaces,
using the identity and reputation system as a base.

Miscellanea-And-Concerns

Modified-GHOST-Implementation

The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013.
The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security.
Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time.
Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size.
With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process.

As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the "longest"; that is to say, not just the parent and further ancestors of a block, but also the stale descendants of the block's ancestor (in Ethereum jargon, "uncles") are added to the calculation of which block has the largest total proof of work backing it.
To solve the second issue of centralization bias, we go beyond the protocol described by Sompolinsky and Zohar, and also provide block rewards to stales: a stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%.
Transaction fees, however, are not awarded to uncles.

Ethereum implements a simplified version of GHOST which only goes down seven levels.
Specifically, it is defined as follows:

* A block must specify a parent, and it must specify 0 or more uncles
* An uncle included in block B must have the following properties:
 o It must be a direct child of the kth generation ancestor of B, where 2 <= k <= 7.
 o It cannot be an ancestor of B
 o An uncle must be a valid block header, but does not need to be a previously verified or even valid block
 o An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)
* For every uncle U in block B, the miner of B gets an additional 3.125% added to its coinbase reward and the miner of U gets 93.75% of a standard coinbase reward.

This limited version of GHOST, with uncles includable only up to 7 generations, was used for two reasons.
First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid.
Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.

Fees

Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse.
The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums.
This approach has been received very favorably in the Bitcoin community particularly because it is "market-based", allowing supply and demand between miners and transaction senders determine the price.
The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it.
Hence, tragedy-of-the-commons problems are very likely to occur.

However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out.
The argument is as follows.
Suppose that:

1. A transaction leads to k operations, offering the reward kR to any miner that includes it where R is set by the sender and k and R are (roughly) visible to the miner beforehand.
2. An operation has a processing cost of C to any node (ie. all nodes have equal efficiency)
3. There are N mining nodes, each with exactly equal processing power (ie. 1/N of total)
4. No non-mining full nodes exist.

A miner would be willing to process a transaction if the expected reward is greater than the cost.
Thus, the expected reward is kR/N since the miner has a 1/N chance of processing the next block, and the processing cost for the miner is simply kC.
Hence, miners will include transactions where kR/N > kC, or R > NC.
Note that R is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC is the cost to the entire network together of processing an operation.
Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost.

However, there are several important deviations from those assumptions in reality:

1. The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale.
2. There do exist nonmining full nodes.
3. The mining power distribution may end up radically inegalitarian in practice.
4. Speculators, political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts where their cost is much lower than the cost paid by other verifying nodes.

(1) provides a tendency for the miner to include fewer transactions, and (2) increases NC; hence, these two effects at least partially cancel each other out.
(3) and (4) are the major issue; to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR times the long-term exponential moving average.
Specifically:

blk.oplimit = floor((blk.parent.oplimit * (EMA_FACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

BLK_LIMIT_FACTOR and EMA_FACTOR are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis.

There is another factor disincentivizing large block sizes in Bitcoin: blocks that are large will take longer to propagate, and thus have a higher probability of becoming stales.
In Ethereum, highly gas-consuming blocks can also take longer to propagate both because they are physically larger and because they take longer to process the transaction state transitions to validate.
This delay disincentive is a significant consideration in Bitcoin, but less so in Ethereum because of the GHOST protocol; hence, relying on regulated block limits provides a more stable baseline.

Computation-And-Turing-Completeness

An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops.
EVM code allows looping in two ways.
First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2.
Second, contracts can call other contracts, potentially allowing for looping through recursion.
This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop?
The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.

As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid.
Messages work in the same way.
To show the motivation behind our solution, consider the following examples:

* An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner.
The miner will process the transaction, running the infinite loop, and wait for it to run out of gas.
Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step.

* An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee.
However, the attacker will be required to submit a value for STARTGAS limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps.

* An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A] = 0, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down).
The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted.

* A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk.
An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas.
However, the financial contract can set a gas limit on the message to prevent this problem.

The alternative to Turing-completeness is Turing-incompleteness, where JUMP and JUMPI do not exist and only one copy of each contract is allowed to exist in the call stack at any given time.
With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size.
Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code.
Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language?
In reality, however, Turing-incompleteness is far from a neat solution to the problem.
To see why, consider the following contracts:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

Now, send a transaction to A.
Thus, in 51 transactions, we have a contract that takes up 250 computational steps.
Miners could try to detect such logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all 26 contracts above could easily be rolled into a single contract).
Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time.
Hence, all in all, we have a surprising conclusion: Turing-completeness is surprisingly easy to manage, and the lack of Turing-completeness is equally surprisingly difficult to manage unless the exact same controls are in place - but in that case why not just let the protocol be Turing-complete?

Currency-And-Issuance

The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labeled:

* 1: wei
* 1012: szabo
* 1015: finney
* 1018: ether

This should be taken as an expanded version of the concept of "dollars" and "cents" or "BTC" and "satoshi". In the near future, we expect "ether" to be used for ordinary transactions, "finney" for microtransactions and "szabo" and "wei" for technical discussions around fees and protocol implementation; the remaining denominations may become useful later and should not be included in clients at this point.

The issuance model will be as follows:

* Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem.
* 0.099x the total amount sold (60102216 ETH) will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block.
* 0.099x the total amount sold will be maintained as a long-term reserve.
* 0.26x the total amount sold will be allocated to miners per year forever after that point.

Group At launch After 1 year After 5 years
Currency units 1.198X 1.458X 2.498X
Purchasers 83.5% 68.6% 40.0%
Reserve spent pre-sale 8.26% 6.79% 3.96%
Reserve used post-sale 8.26% 6.79% 3.96%
Miners 0% 17.8% 52.0%

Long-Term Supply Growth Rate (percent):


Despite the linear currency issuance, just like with Bitcoin over time the supply growth rate nevertheless tends to zero

The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin.
The justification of the endowment pool is as follows.
If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable.
Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before.
The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x.
Hence, this situation is exactly equivalent to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit.

The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time.
We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium).

Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year.
In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to 60102216 * (1.198 + 0.26 * n) where n is the number of years after the genesis block.
Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development.
Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions.

Mining-Centralization

The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192).
However, this mining algorithm is vulnerable to two forms of centralization.
First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining.
This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in.
Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers.
This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.

The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result.
This has two important benefits.
First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU.
Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction.
This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.

This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm.
However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs.
The economic incentives exist for ASIC manufacturers to use such a trick to attack each other.
Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.

Scalability

One common concern about Ethereum is the issue of scalability.
Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network.
With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour.
If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year).
Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history.

The problem with such a large blockchain size is centralization risk.
If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes.
In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC).
Light nodes would have no way of detecting this immediately.
Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack.
In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd which will alleviate this issue.

In the near term, Ethereum will use two additional strategies to cope with this problem.
First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes.
Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction.
Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol.
If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n] is incorrect.
Since S[0] is known to be correct, there must be some first state S[i] that is incorrect where S[i-1] is correct.
The verifying node would provide the index i, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process APPLY(S[i-1],TX[i]) -> S[i].
Nodes would be able to use those nodes to run that part of the computation, and see that the S[i] generated does not match the S[i] provided.

Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks, so the full information does not even exist to determine whether or not blocks are valid.
The solution to this is a challenge-response protocol: verification nodes issue "challenges" in the form of target transaction indices, and upon receiving a node a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.

Conclusion

The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language.
The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application.
What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency.
Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
Finally, there is also a substantial array of applications that have nothing to do with money at all.

The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.

Notes-and-Further-Reading

Notes

1. A sophisticated reader may notice that in fact a Bitcoin address is the hash of the elliptic curve public key, and not the public key itself.
However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself.
This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the ECC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.

2. Technically, the median of the 11 previous blocks.

3. Internally, 2 and "CHARLIE" are both numbers, with the latter being in big-endian base 256 representation. Numbers can be at least 0 and at most 2256-1.

Further-Reading

1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/

2. Smart property: https://en.bitcoin.it/wiki/Smart_Property

3. Smart contracts: https://en.bitcoin.it/wiki/Contracts

4. B-money: http://www.weidai.com/bmoney.txt

5. Reusable proofs of work: http://www.finney.org/~hal/rpow/

6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html

7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf

8. Namecoin: https://namecoin.org/

9. Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangle

10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit

11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec

12. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/

13. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification

14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree

15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree

16. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf

17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html

18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y

19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP

20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree

21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/

ethprl'Yellow-paper

AddressWpg::
* http://gavwood.com/Paper.pdf,

ethprl'Whisper

Description::
In a nutshell whisper is a communication protocol for DApps to communicate with each other.
[https://github.com/ethereum/wiki/wiki/Whisper]
===
Whisper is a part of the Ethereum P2P protocol suite that allows for messaging between users via the same network that the blockchain runs on.

There are many uses, some of which are listed on the wiki

The protocol is seperate from the blockchain, so smart contracts do not have access.

Whisper has existed in a sort of alpha, working-prototype state for some time now. It can be enabled by using the -shh flag in geth, but nodes do not relay the messages by default, so chances are that messages won't get through unless you are directly connected to the recipient. API documentation can be found on github.
[http://ethereum.stackexchange.com/a/134]

Name::
* cpt.Whisper,

ethnet'Node (ethnod)

Description::
Nodes are COMPUTERS that run the-client-programs
- stores a full or light copy of the-blockchain
- interacts with the-blockchain.
[hmnSgm.2017-03-16]

Name::
* cpt.ethereum-node,
* cpt.ethnet'node,
* cpt.ethnod,

Generic::
* blockchain-network-node,

AddressWpg::
* https://www.ethernodes.org/network/1,

Description::
Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
===
Node overview
Id    000c157e3fdc04c299fcf1c433c51e7d079d33c4c9175275299c834f1fef355f
791741ae23ca387018320038caa90fc5e243bec3992d9a6d789b771dfea42f0f
Host    94.242-61-32
Port    46897
Client id    Parity/v1.5.4-beta-74b850e-20170223/x86_64-linux-gnu/rustc1.15.1
Client    Parity
Client version    v1.5.4-beta-74b850e-20170223
OS    x86_64-linux-gnu
Capabilities    [par/1 par/2 eth/62 eth/63]
Protocol version    63
Network id    1
Total difficulty    204795435708956
Best hash    c8268e06bf48ff52c6ce9be4f2b3560b5a881133b55f4a1e5d44a401a67477ad
Genesis hash    41941023680923e0fe4d74a34bdac8141f2540e3ae90623718e47d66d1ca4a2d
Last seen    Thu Mar 16 2017 13:54:29 GMT+0100 (CET)
Country    Russian Federation
City   
[https://www.ethernodes.org/node/000c157e3fdc04c299fcf1c433c51e7d079d33c4c9175275299c834f1fef355f791741ae23ca387018320038caa90fc5e243bec3992d9a6d789b771dfea42f0f]

ethnod'Client-program (link)

ethnod'OS

ethnod'Computer

Description::
Thanks to Merkle trees, it is possible to build Ethereum nodes that run on all computers and laptops large and small, smart phones, and even internet of things devices such as those that will be produced by Slock.it.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]

ethnod'EVM (link)

ethnod.AGGREGATE

{time.2017-03-16}

Total 10789 (100%)
United States 3175 (29.43%)
Germany 942 (8.73%)
United Kingdom 595 (5.51%)
Canada 496 (4.60%)
Russian Federation 484 (4.49%)
China 479 (4.44%)
Netherlands 459 (4.25%)
France 344 (3.19%)
Australia 275 (2.55%)
Switzerland 200 (1.85%)

[https://www.ethernodes.org/network/1]

{time.2017-02-03}
Total  6176 (100%)
United States  1826 (29.57%)
Germany  481 (7.79%)
Russian Federation  368 (5.96%)
United Kingdom  299 (4.84%)
China  286 (4.63%)
Canada  258 (4.18%)
Netherlands  256 (4.15%)
France  228 (3.69%)
Australia  125 (2.02%)
Switzerland  125 (2.02%)
[https://www.ethernodes.org/network/1]

ethnod.FULL

Description::
Full nodes on the Bitcoin blockchain store every transaction made going back to the zero block; full nodes on the Ethereum blockchain additionally store the static code (if any) associated with a given account and that code’s current state in storage.
[https://medium.com/@ConsenSys/ethereum-bitcoin-plus-everything-a506dc780106#.izxhgdxdt]

Name::
* cpt.ethnet'full-node,
* cpt.ethnod.full,

ethnod.MINER (ethnodMnr)

Description::
Miner. A node on the network that mines, i.e., works to process blocks on the blockchain. You can see a partial list of live Ethereum miners here: stats.ethdev.com.
[https://medium.com/@ConsenSys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4#.5x9da12dp]
===
These transaction fees are collected by the nodes that validate the network. These “miners” are nodes in the Ethereum network that receive, propogate, verify, and execute transactions. The miners then group the transactions – which include many updates to the “state” of accounts in the Ethereum blockchain – into what are called “blocks”, and miners then compete with one another for their block to be the next one to be added to the blockchain. Miners are rewarded with ether for each successful block they mine. This provides the economic incentive for people to dedicate hardware and electricity to the Ethereum network.
...
Just as in the Bitcoin network, miners are tasked with solving a complex mathematical problem in order to successfully “mine” a block. This is known as a “Proof of Work”. Any computational problem that requires orders of magnitude more resources to solve algorithmically than it takes to verify the solution is a good candidate for proof of work. In order to discourage centralisation due to the use of specialised hardware (e.g. ASICs), as has occurred in the Bitcoin network, Ethereum chose a memory-hard computational problem. If the problem requires memory as well as CPU, the ideal hardware is in fact the general computer. This makes Ethereum’s Proof of Work ASIC-resistant, allowing a more decentralized distribution of security than blockchains whose mining is dominated by specialized hardware, like Bitcoin.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]

Name::
* cpt.ethnodMnr,
* cpt.ethminer,
* cpt.ethminer-node,

ethnodMnr'Hardware

Description::
To mine Ethereum you need a GPU, 4+GB RAM, Etherum account and GPU miner.
The GPU must have at least 2GB memory.
Recomended AMD GPU driver 15.12.
[https://eth.nanopool.org/help]

Radeon Rx 480 GPU

ethnodMnr'Mining (ethmining)

Description::
Mining is the process of dedicating effort (working) to bolster one series of transactions (a block) over any other potential competitor block.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethereum-mining,
* cpt.ethnet'mining,
* cpt.ethmining,
* cpt.ethmng,

Description::
The Ethereum network is kept running by computers all over the world.
In order to reward the computational costs of both processing the contracts and securing the network, there is a reward that is given to the computer that was able to create the latest block on the chain.
Every 12 seconds, on average, a new block is added to the blockchain with the latest transactions processed by the network and the computer that generated this block will be awarded 5 ether.
Due to the nature of the algorithm for block generation, this process (generating a proof of work) is guaranteed to be random and rewards are given in proportion to the computational power of each machine.
This process is usually called mining in the crypto-currency lingo.
[https://ethereum.org/ether]
===
Mining ether = Securing the Network = Verifying Computation
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#introduction]

ethmining'Resource

AddressWpg::
* {2016.07} Amazon AWS Ethereum Cloud Mining Tutorial-12 Step Guide to Generating ETC! https://steemit.com/ethereum/@coininstant/amazon-aws-ethereum-cloud-mining-tutorial...etc,

ethnet'Blockchain (ethbcn)

Description::
The Ethereum blockchain (or "ledger") is the decentralized, massively replicated database in which the current state of all accounts is stored.
The blockchain uses a database called a Patricia tree (or "trie") to store all accounts; this is essentially a specialized kind of Merkle tree that acts as a generic key/value store.
[https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial#basics-of-the-ethereum-blockchain]
===
the blockchain, where all the EVM state is represented.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
===
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008. While the use of blockchains for more general uses was already discussed in the original paper, it was not until a few years later that blockchain technology emerged as a generic term. A blockchain is a distributed computing architecture where every network node executes and records the same transactions, which are grouped into blocks. Only one block can be added at a time, and every block contains a mathematical proof that verifies that it follows in sequence from the previous block. In this way, the blockchain’s “distributed database” is kept in consensus across the whole network. Individual user interactions with the ledger (transactions) are secured by strong cryptography. Nodes that maintain and verify the network are incentivized by mathematically enforced economic incentives coded into the protocol.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]

Name::
* cpt.blockchain.ethereum,
* cpt.blockchain-of-ethereum,
* cpt.ethbcn,
* cpt.ethblockchain,
* cpt.ethdistributed-database,
* cpt.ethereum-blockchain,
* cpt.ethledger,
* cpt.ethnet'blockchain,

ethbcn'Block (ethblk)

Description::
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
The blocks on the blockchain represent units of time, the blockchain itself is a temporal dimension and represents the entire of history of states at the discrete time points designated by the blocks on the chain.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#eoa-vs-contract-accounts]

Name::
* cpt.ethblk,
* cpt.ethblock,
* cpt.ethereum-block,
* cpt.ethnet'block,

ethblk'part.Header (ethblkH)

Description::
4.4. The Block.
The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
The block header contains several pieces of information:
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc.
stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr.
transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with
each transaction in the transactions list portion of the block; formally Ht.
receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally He.
logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
difficulty: A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
number: A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; formally Hi.
gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl.
gasUsed: A scalar value equal to the total gas used in transactions in this block; formally Hg.
timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
extraData: An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer; formally Hx.
mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally Hm.
nonce: A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally Hn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'header,
* cpt.ethblkH,

ethblk'parentHash (ethblkHp)

Description::
parentHash: The Keccak 256-bit hash of the parent block’s header, in its entirety; formally Hp.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'parentHash,
* cpt.ethblk'parent-hash,
* cpt.ehtblkHp,

ethblk'ommersHash (ethblkHo)

Description::
ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'ommersHash,
* cpt.ethblk'ommers-hash,
* cpt.ehtblkHo,

ethblk'beneficiary (ethblkHc)

Description::
beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; formally Hc.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
20-bytes, 40-hexs,
===
Miner    bb7b8287f3f0a933474a79eae42cbca977791171
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'beneficiary,
* cpt.ethblk'miner,
* cpt.ehtblkHc,

Generic::
* eth-address,

ethblk'stateRoot (ethblkHr)

Description::
stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied; formally Hr.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'stateRoot,
* cpt.ehtblkHr,

ethblk'transactionsRoot (ethblkHt)

Description::
transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; formally Ht.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'transactionsRoot,
* cpt.ehtblkHt,

ethblk'receiptsRoot (ethblkHe)

Description::
receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; formally He.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'receiptsRoot,
* cpt.ehtblkHe,

ethblk'logsBloom (ethblkHb)

Description::
logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; formally Hb.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'logsBloom,
* cpt.ehtblkHb,

ethblk'difficulty (ethblkHd)

Description::
difficulty: A scalar value corresponding to the difficulty level of this block.
This can be calculated from the previous block’s difficulty level and the timestamp; formally Hd.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Difficulty    17561410778
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'difficulty,
* cpt.ehtblkHd,

ethblk'number (ethblkHi)

Description::
number: A scalar value equal to the number of ancestor blocks.
The genesis block has a number of zero; formally Hi.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Block #3000059
Hash    55bf7cf28ef891df9683fe80de1f7a985d803f8f21755a7977e76916b6dd78a3
Prev Hash    d232b55f0b77a22fbc40ceea7ab9b9ba592034b5c9a71e2dca57c2912054bd72
Next Hash   
Transactions    0
Uncle Hash    55bf7cf28ef891df9683fe80de1f7a985d803f8f21755a7977e76916b6dd78a3
Nonce    c09eea000f9a5886
State Root    0920e25b921c1b518ce5ccbbada31fcec225f118a364d9c271d0bb3c591fa229
Tx Trie Root    56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421
Timestamp    a month ago [1484475724]
Gas Limit    4000881
Gas Used    0
Miner    c0ea08a2d404d3172d2add29a45be56da40e2949
Difficulty    104754858920035
Extra Data    www.bw.com [7777772e62772e636f6d]
Bloom Filter   
00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00
[https://live.ether.camp/block/3000059]

Name::
* cpt.ethblk'height,
* cpt.ethblk'number,
* cpt.ehtblkHi,

ethblkHi.Homestead

Description::
4.2. Homestead. A significant block number for compatibility with the public network is the block marking the transition between the Frontier and Homestead phases of the platform, which we denote with the symbol NH, defined thus
(13) NH = 1,150,000
The protocol was upgraded at this block, so this symbol appears in some equations to account for the changes.

ethblk'gasLimit (ethblkHl)

Description::
gasLimit: A scalar value equal to the current limit of gas expenditure per block; formally Hl.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'gasLimit,
* cpt.ehtblkHl,

ethblk'gasUsed (ethblkHg)

Description::
gasUsed: A scalar value equal to the total gas used in transactions in this block; formally Hg.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'gasUsed,
* cpt.ehtblkHg,

ethblk'timestamp (ethblkHs)

Description::
timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Timestamp    2 years ago [1438270327]
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'timestamp,
* cpt.ehtblkHs,

ethblk'extraData (ethblkHx)

Description::
extraData: An arbitrary byte array containing data relevant to this block.
This must be 32 bytes or fewer; formally Hx.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Extra Data    Geth/LVIV/v1.0.0/linux/go1.4.2 [476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32]
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'extraData,
* cpt.ehtblkHx,

ethblk'mixHash (ethblkHm)

Description::
mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; formally Hm.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'mixHash,
* cpt.ethblk'mix-hash,
* cpt.ehtblkHm,

ethblk'nonce (ethblkHn)

Description::
nonce: A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block; formally Hn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
Nonce: a meaningless value in a block which can be adjusted in order to try to satisfy the proof of work condition
[https://github.com/ethereum/wiki/wiki/Glossary]
===
Nonce    4ce04218c05e8275
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'nance,
* cpt.ehtblkHn,

ethblk'part.Transaction-list

Description::
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
...The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'transaction-list,
* cpt.ethblkT,

ethblk'part.Ommer-list

Description::
4.4. The Block. The block in Ethereum is the collection of relevant pieces of information (known as the block header ), H, together with information corresponding to the comprised transactions, T, and a set of other block headers U that are known to have a parent equal to the present block’s parent’s parent (such blocks are known as ommers2).
...The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk'ommer-list,
* cpt.ethblkU,

Ommers-hash (link)

ethblk'Hash

Description::
Hash    4d9423080290a650eaf6db19c87c76dff83d1b4ab64aefe6e5c5aa2d1f4b6623
Prev Hash    cd5b5c4cecd7f18a13fe974255badffd58e737dc67596d56bc01f063dd282e9e
Next Hash    3cd0324c7ba14ba7cf6e4b664dea0360681458d76bd25dfc0d2207ce4e9abed4
Transactions    0
Uncle Hash    4d9423080290a650eaf6db19c87c76dff83d1b4ab64aefe6e5c5aa2d1f4b6623
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'hash,

ethblk'Gas

Description::
Gas Limit    5000
Gas Used    0
[https://live.ether.camp/block/59]

Name::
* cpt.ethblk'gas,

ethblk'Merkle-tree

Description::
First, the basics. A Merkle tree, in the most general sense, is a way of hashing a large number of “chunks” of data together which relies on splitting the chunks into buckets, where each bucket contains only a few chunks, then taking the hash of each bucket and repeating the same process, continuing to do so until the total number of hashes remaining becomes only one: the root hash.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]

Name::
* cpt.ethblk'Merkle-tree,
* cpt.ethblk'Merkle-tree-hashing-algorithm,
* cpt.ethblk'Merkle-trie,
* cpt.ethnet'Merkle-tree,
* cpt.Merkle-tree,

Merkle-root-hash
Merkle-proof

Description::
A Merkle proof consists of a chunk, the root hash of the tree, and the “branch” consisting of all of the hashes going up along the path from the chunk to the root. Someone reading the proof can verify that the hashing, at least for that branch, is consistent going all the way up the tree, and therefore that the given chunk actually is at that position in the tree. The application is simple: suppose that there is a large database, and that the entire contents of the database are stored in a Merkle tree where the root of the Merkle tree is publicly known and trusted (eg. it was digitally signed by enough trusted parties, or there is a lot of proof of work on it). Then, a user who wants to do a key-value lookup on the database (eg. “tell me the object in position 85273”) can ask for a Merkle proof, and upon receiving the proof verify that it is correct, and therefore that the value received actually is at position 85273 in the database with that particular root. It allows a mechanism for authenticating a small amount of data, like a hash, to be extended to also authenticate large databases of potentially unbounded size.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]

Merkle-application

Description::
The original application of Merkle proofs was in Bitcoin, as described and created by Satoshi Nakamoto in 2009. The Bitcoin blockchain uses Merkle proofs in order to store the transactions in every block:

The benefit that this provides is the concept that Satoshi described as “simplified payment verification”: instead of downloading every transaction and every block, a “light client” can only download the chain of block headers, 80-byte chunks of data for each block that contain only five things:
A hash of the previous header
A timestamp
A mining difficulty value
A proof of work nonce
A root hash for the Merkle tree containing the transactions for that block.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]

Ethereum-application

Description::
Every block header in Ethereum contains not just one Merkle tree, but three trees for three kinds of objects:
- Transactions
- Receipts (essentially, pieces of data showing the effect of each transaction)
- State
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]

ethblk'Time

Name::
* cpt.ethblk'time,

ethblk'Age
ethblk'Timestamp (link)
ethblk'Generation (Time-between-blocks)

Description::
The-time between block creation.
===
As dictated by the protocol, the difficulty dynamically adjusts in such a way that on average one block is produced by the entire network every 15 seconds. We say that the network produces a blockchain with a 15 second block time
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]

Name::
* cpt.ethnet'blocktime,

ethblk'Explorer (link)

ethblk'Relation-to-bitcoin-block

Description::
The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
Aside from that, two other values, the block number and the difficulty, are also stored in the block.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]

Name::
* cpt.ethblk'relation-to-bitcoin-block,

ethblk'Resource

AddressWpg::
* https://etherchain.org/blocks,
* https://etherchain.org/block/3270980,

SPECIFIC

ethblk.GENESIS

Description::
First, to initialize a new private blockchain, we will need what is called a Genesis block, which is going to be the first block in our blockchain.
This first block sets a few fundamental parameters for our blockchain, captured in a genesis.json file:
{
"nonce": "0x0000000000000042",
"mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"difficulty": "0x4000",
"alloc": {},
"coinbase": "0x0000000000000000000000000000000000000000",
"timestamp": "0x00",
"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "Custom Ethereum Genesis Block",
"gasLimit": "0xffffffff"
}
[http://hypernephelist.com/2016/05/30/deploying-a-private-Ethereum-blockchain.html]
===
The genesis block has a number of zero; formally Hi.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethblk.first,
* cpt.ethblk.genesis,
* cpt.ethnet'genesis-block,

AddressWpg::
* BlockH0 https://etherscan.io/block/0,
* http://ethdocs.org/en/latest/network/test-networks.html#the-genesis-file,

ethblk.LAST

Name::
* cpt.ethnet'best-block,
* cpt.ethnet'last-block,
* cpt.ethblk.last,

ethblk.UNCLE

Description::
Uncles are stale blocks i.e. with parents that are ancestors (max 6 blocks back) of the including block.
Valid uncles are rewarded in order to neutralise the effect of network lag on the dispersion of mining rewards, thereby increasing security (this is called the GHOST protocol).
Uncles included in a block formed by the successful PoW miner receive 7/8 of the static block reward (=4.375 ether).
A maximum of 2 uncles are allowed per block.
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]

Name::
* cpt.ethblk.uncle,
* cpt.ethnet'uncle,

ethblk.PARENT

Name::
* cpt.ethblk.parent,

ethblk.ANCESTOR

Name::
* cpt.ethblk.ancestor,

ethbcn'Block-Explorer (ethbex)

Name::
* cpt.ethereum-block-explorer,
* cpt.ethereum-explorer,
* cpt.ethblk'explorer,
* cpt.ethnet'explorer,

Specific::
* https://etherscan.io/
* https://etherchain.org/
* https://live.ether.camp/

ethbcn'Consensus-algorithm (ethcsa)

Description::
Consensus is based on choosing the block with the highest total difficulty.
... Note that in the Ethereum Serenity milestone, this is likely going to be replaced by a (see proof of stake model ).
[https://ethereum-homestead.readthedocs.io/en/latest/mining.html#what-is-mining]
===
a system such that we can reasonably expect that an agreement will be thus enforced autonomously,
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
The basic block validation algorithm in Ethereum is as follows:
1. Check if the previous block referenced exists and is valid.
2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
4. Check that the proof of work on the block is valid.
5. Let S[0] be the state at the end of the previous block.
6. Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
7. Let S_FINAL be S[n], but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
[https://github.com/ethereum/wiki/wiki/White-Paper#blockchain-and-mining]

Name::
* cpt.block-validation-algorithm-of-ethereum,
* cpt.ethereum-block-validation-algorithm,
* cpt.ethconsensus-algorithm,
* cpt.ethcsa,
* cpt.ethnet'consensus-algorithm,

Generic::
* bcnnet-consensus-algorithm,

ethcsa.Proof-of-Authority (ethpoa)

Description::
Fortunately, the next version of the Ethereum testnet, Kovan, has been announced by the Parity community. Although this new testnet is incompatible with geth nodes, it uses the PoA (Proof of Authority) consensus, which should improve its resilience to spam attacks. ChronoBank has also made an application to become a trusted validator for the new testnet.
PoA is a replacement for PoW and can be used for both public and private chain setups. There is no mining involved to secure the network with PoA. Instead, it relies on trusted ‘Validators’ to ensure that legitimate transactions are added to blocks, and are processed and executed by the EVM faithfully.
Because mining does not occur on our proposed public testnet, malicious actors are prevented from acquiring testnet Ether -- solving the spam attack that Ropsten currently faces. There is no difference in the way that contracts are executed on PoA and PoW chains, so developers can test their contracts and user interfaces before deploying to the mainnet in a more reliable and convenient environment.
[https://blog.chronobank.io/chronobank-dev-update-7-49b387396b2c#.odbp6hdr9]

Name::
* cpt.ethpoa,
* cpt.proof-of-authority,

ethbcn'Size

{time.2016-03-16}:
Top News - Bitcoin Retweeted
Tuur Demeester ?@TuurDemeester 5h5 hours ago
8 months in, #Ethereum blockchain size is 10GB — some estimate growth rate of up to 1TB/yr. Thoughts on network scalability vs. security?
[https://twitter.com/TuurDemeester/status/710101175610286081]

How will Ethereum deal with ever increasing blockchain size?
There are many discussions around blockchain scalability. This questioned has been partially answered on this Ethereum StackExchange post and this blog post from Vitalik Buterin.
[https://ethereum-homestead.readthedocs.org/en/latest/frequently-asked-questions/frequently-asked-questions.html#how-will-ethereum-deal-with-ever-increasing-blockchain-size]

ethbcn'Transaction (ethtx)

Description::
Transactions fundamentally change the state of the network.
A transaction can be
- as simple as sending Ether to another account, or
- as complicated as executing a contract function or
- adding a new contract to the network.
The defining characteristic of a transaction is that it writes (or changes) data.
Transactions cost Ether to run, known as "gas", and transactions take time to process.
When you execute a contract's function via a transaction, you cannot receive that function's return value because the transaction isn't processed immediately.
In general, functions meant to be executed via a transaction will not return a value; they will return a transaction id instead.
So in summary, transactions:
- Cost gas (Ether)
- Change the state of the network
- Aren't processed immediately
- Won't expose a return value (only a transaction id).
[http://truffleframework.com/docs/getting_started/contracts#transactions]

Name::
* cpt.ethereum-message,
* cpt.ethereum-transaction,
* cpt.ethnet'Transaction,
* cpt.ethtransaction,
* cpt.ethtsn,
* cpt.ethtx,

Generic::
* blockchain-transaction,

Description::
The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.
images/chapter1/1-4.png
Transactions contain:
- recipient: The account the transaction is intended for.
- sender: A signature representing the originator of the transaction.
- amount: The amount of ETH to transfer from the sender to the recipient.
- data: An optional field to pass data to the smart contract.
- startgas: A value representing the maximum number of computational steps the transaction execution is allowed to take.
- gasprice: A value representing the fee the sender pays per computational step.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below). It can include binary data (its payload) and Ether.

If the target account contains code, that code is executed and the payload is provided as input data.

If the target account is the zero-account (the account with the address 0), the transaction creates a new contract. As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”). The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
===
A blockchain is a globally shared, transactional database.
This means that everyone can read entries in the database just by participating in the network.
If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others.
The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied.
Furthermore, while your transaction is applied to the database, no other transaction can alter it.

As an example, imagine a table that lists the balances of all accounts in an electronic currency. If a transfer from one account to another is requested, the transactional nature of the database ensures that if the amount is subtracted from one account, it is always added to the other account. If due to whatever reason, adding the amount to the target account is not possible, the source account is also not modified.

Furthermore, a transaction is always cryptographically signed by the sender (creator). This makes it straightforward to guard access to specific modifications of the database. In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#transactions]
===
The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account to another account on the blockchain.
Transactions contain:
the recipient of the message,
a signature identifying the sender and proving their intention to send the message to the blockchain to the reciptient,
VALUE field - The amount of wei to transfer from the sender to the recipient,
an optional data field, which can contain the message sent to a contract,
a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take,
a GASPRICE value, representing the fee the sender is willing to pay for gas. One unit of gas corresponds to the execution of one atomic instrucion, i.e., a computational step.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#what-is-a-transaction]
===
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]

ethtx'part.nonce (ethtxTn)

Description::
nonce: A scalar value equal to the number of transactions sent by the sender; formally Tn.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx'nonce,
* cpt.ethtxTn,

ethtx'part.gasPrice (ethtxTp)

Description::
gasPrice: A scalar value equal to the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction; formally Tp.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx'gasPrice,
* cpt.ethtxTp,

ethtx'part.gasLimit (ethtxTg)

Description::
gasLimit:
A scalar value equal to the maximum amount of gas that should be used in executing this transaction.
This is paid up-front, before any computation is done and may not be increased later; formally Tg.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx'gasLimit,
* cpt.ethtxTg,

ethtx'part.to (ethtxTt)

Description::
to: The 160-bit address of the message call’s recipient or, for a contract creation transaction, Ø, used here to denote the only member of B0 ; formally Tt.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
If the destination of the transaction is another EOA, then the transaction may transfer some ether but otherwise does nothing.
However, if the destination is a contract, then the contract in turn activates, and automatically runs its code.
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#account-interactions-example-betting-contract]
===
If the target account contains code, that code is executed and the payload is provided as input data.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]

Name::
* cpt.ethtx'destination,
* cpt.ethtx'recipient,
* cpt.ethtx'recipient-account,
* cpt.ethtx'target-account,
* cpt.ethtx'to,
* cpt.ethtxTt,

ethtx'part.value (ethtxTv)

Description::
value: A scalar value equal to the number of Wei to be transferred to the message call’s recipient or, in the case of contract creation, as an endowment to the newly created account; formally Tv.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below).
It can include binary data (its payload) and Ether.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]

Name::
* cpt.ethtx'ether,
* cpt.ethtx'value,
* cpt.ethtxTv,

ethtx'part.v (ethtxTw)

Description::
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx'v,
* cpt.ethtxTw,

ethtx'part.r (ethtxTr)

Description::
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx'r,
* cpt.ethtxTr,

ethtx'part.s (ethtxTs)

Description::
v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction; formally Tw, Tr and Ts. This is expanded in Appendix F.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx's,
* cpt.ethtxTs,

ethtx'Hash

TxHash:    0xbe5070a938fa049d360e881fbbb1f3e4e0f71344f07921a9e167b5f49fe5f28b (64 hexsymbols)

ethtx'Block

Description::
The-block which stores the-transaction.

Name::
* cpt.ethtx'block-height,

ethtx'Age

Name::
* cpt.ethtx'timestamp,

ethtx'Sender-account

Description::
Furthermore, a transaction is always cryptographically signed by the sender (creator).
This makes it straightforward to guard access to specific modifications of the database.
In the example of the electronic currency, a simple check ensures that only the person holding the keys to the account can transfer money from it.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html]
===
An Ethereum transaction contract code can trigger data reads and writes, do expensive computations like using cryptographic primitives, make calls (send messages) to other contracts, etc. Each of these operations have a cost measured in gas, and each gas unit consumed by a transaction must be paid for in Ether, based on a gas/Ether price which changes dynamically.
This price is deducted from the Ethereum account sending the transaction.
Transactions also have a gas limit parameter that is an upper bound on how much gas the transaction can consume, and is used as a safe-guard against programming errors that could deplete an account’s funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]

Name::
* cpt.ethtx'creator,
* cpt.ethtx'from,

ethtx'Fee

Description::
The total ether cost of a transaction is based on 2 factors:
gasUsed is the total gas that is consumed by the transaction
gasPrice price (in ether) of one unit of gas specified in the transaction
Total cost = gasUsed * gasPrice
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#estimating-transaction-costs]
===
Fees applied to transaction go to support the networks that run the coin/token - so, for instance, every standard (non-contract) ETH transaction currently applies a fee of .000441 ETH.
This fee does not go to us; it goes to reward miners (thereby ensuring that the transaction is logged into the blockchain in a timely fashion) and support the Ethereum network itself.
Note that transactions that interact with a contract address will be more costly.
[https://decentral.zendesk.com/hc/en-us/articles/225024248-What-are-transaction-fees-and-what-fees-does-Jaxx-apply-]
===
Like in Bitcoin, users must pay small transaction fees to the network. This protects the Ethereum blockchain from frivolous or malicious computational tasks, like DDoS attacks or infinite loops. The sender of a transaction must pay for each step of the “program” they activated, including computation and memory storage. These fees are paid in amounts of Ethereum’s native value-token, ether.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]

Name::
* cpt.ethtx'cost,
* cpt.ethtx'fee,

ethtx'Gas-limit

Description::
Transactions also have a gas limit parameter that is an upper bound on how much gas the transaction can consume, and is used as a safe-guard against programming errors that could deplete an account’s funds.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]

Name::
* cpt.ethtx'gas-limit,

ethtx'Log

Description::
Next we specify an event, which is how in Solidity we use the logging facility of the Ethereum Virtual Machine.
When called, events cause the arguments to be stored in the transaction’s log.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]

Name::
* cpt.ethtx'log,

Example::
* https://etherscan.io/tx/0x3238a040c9ff9c06067401b366b804ad4f3824186336eae4f1a8f43c8c981b78#eventlog,

ethtx'Security

Name::
* cpt.ethtx'security,

AddressWpg::
* http://tap.dappbench.com/
* https://github.com/dob/tap,

ethtx'Resource

AddressWpg::
* https://etherscan.io/txs,
* https://etherchain.org/txs,
* https://etherchain.org/tx/ 0xfaee6da035c0a943002d2f4f65b7714d92f11a6465ca69595719f2707f134557,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-transaction-info,

ethtx'DOING

Description::
ether transfer or trigger contract code
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html#externally-owned-accounts-eoas]

ethtx'Creating

Name::
* cpt.ethtx'signing,

ethtx'Submitting

Name::
* cpt.ethtx'processing,

SPECIFIC

Name::
* ethtx.specific,
* cpt.ethtx.specific,

Specific::
Broadly speaking there are three types transactions supported on Ethereum:
- Transfer of Ether from one party to another
- Creation of a smart contract
- Transacting with a smart contract
[https://docs.web3j.io/transactions.html]
===
There are two types of transactions: a sending transaction and a contract creating transaction.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
===
There are two types of transactions:
those which result in message calls and
those which result in the creation of new accounts with associated code (known informally as ‘contract creation’).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

ethtx.MESSAGE-CALL (ethtxmc)

Description::
There are two types of transactions:
those which result in message calls and
those which result in the creation of new accounts with associated code (known informally as ‘contract creation’).
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethnet'message-call,
* cpt.ethtx.message-call,
* cpt.ethtxmc,

ethtxmc'part.data (ethtxTd)

Description::
In contrast, a message call transaction contains:
data: An unlimited size byte array specifying the input data of the message call, formally Td.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
===
A transaction is a message that is sent from one account to another account (which might be the same or the special zero-account, see below).
It can include binary data (its payload) and Ether.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]

Name::
* cpt.ethnet'payload-of-tx,
* cpt.ethtx'data,
* cpt.ethtx'binary-data,
* cpt.ethtx'payload,
* cpt.ethtxTd,

ethtxmc.ETHER-TRANSFER

Description::
The simplest transactions are ether transfer transactions.
[https://ethereum.gitbooks.io/frontier-guide/content/account_types.html]
===
A sending transaction is a standard transaction, containing a receiving address, an ether amount, a data bytearray and some other parameters, and a signature from the private key associated with the sender account.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]
===
All code execution in the Ethreum Virtual Machine, or EVM must be triggered by a private key based account. This is done by sending a transaction, which may do something simple like transfering ether, or it may do something more complex like calling a function on a contract account.
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]

Name::
* cpt.ethtx.sending,
* cpt.ethtx.standard,

ethtxmc.CONTRACT-PROGRAM-CALLING

Description::
your transactions are also of two types:
- those sent to normal accounts are ether transfers,
- while the rest are communication with smart contracts.
[https://www.ethereum.org/ether]

Name::
* cpt.ethtx.interacting-with-contract,
* cpt.ethtx.transacting-with-contract,
* cpt.ethtx.transacting-with-contract,
* cpt.ethtx.contract-calling,
* cpt.ethtx.contract-invocating,

ethtx.CONTRACT-ACOUNT-CREATION (ethtxcac)

Description::
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”).
The payload of such a contract creation transaction is taken to be EVM bytecode and executed.
The output of this execution is permanently stored as the code of the contract.
This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]
===
A contract creating transaction looks like a standard transaction, except the receiving address is blank. When a contract creating transaction makes its way into the blockchain, the data bytearray in the transaction is interpreted as EVM code, and the value returned by that EVM execution is taken to be the code of the new contract; hence, you can have a transaction do certain things during initialization. The address of the new contract is deterministically calculated based on the sending address and the number of times that the sending account has made a transaction before (this value, called the account nonce, is also kept for unrelated security reasons). Thus, the full code that you need to put onto the blockchain to produce the above name registry is as follows:
PUSH1 16 DUP PUSH1 12 PUSH1 0 CODECOPY PUSH1 0 RETURN STOP PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI STOP PUSH1 32 CALLDATALOAD PUSH1 0 CALLDATALOAD SSTORE
The key opcodes are CODECOPY, copying the 16 bytes of code starting from byte 12 into memory starting at index 0, and RETURN, returning memory bytes 0-16, ie. code byes 12-28 (feel free to "run" the execution manually on paper to verify that those parts of the code and memory actually get copied and returned). Code bytes 12-28 are, of course, the actual code as we saw above.
[https://ethereum.gitbooks.io/frontier-guide/content/opcodes,_costs,_and_gas.html]

Name::
* cpt.ethtx.contract-acount-creation,
* cpt.ethtx.contract-creating-transaction,
* cpt.ethtxcac,

ethtxcac'part.init (ethtxTi)

Description::
Additionally, a contract creation transaction contains:
init: An unlimited size byte array specifying the EVM-code for the account initialisation procedure, formally Ti.
init is an EVM-code fragment; it returns the body, a second fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code). init is executed only once at account creation and gets discarded immediately thereafter.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]

Name::
* cpt.ethtx'init,
* cpt.ethtxTi,

ethtx.GENESIS

Description::
GENESIS_2b241f037337eb4acc61849bd272ac133f7cdf4b    block:0    age:580 days 32 mins ago (2015-07-30-03.26.13pm)    from:GENESIS    IN     to:0x2b241f037337eb4acc61849bd272ac133f7cdf4b    378,000 Ether    0 Ether
[https://etherscan.io/address/0x2b241f037337eb4acc61849bd272ac133f7cdf4b]

Name::
* cpt.ethtx.genesis,

ethbcn.SPECIFIC

Name::
* cpt.ethbcn.specific,
* cpt.ethnet'blockchain.specific,

Specific::
Public blockchains: a public blockchain is a blockchain that anyone in the world can read, anyone in the world can send transactions to and expect to see them included if they are valid, and anyone in the world can participate in the consensus process – the process for determining what blocks get added to the chain and what the current state is. As a substitute for centralized or quasi-centralized trust, public blockchains are secured by cryptoeconomics – the combination of economic incentives and cryptographic verification using mechanisms such as proof of work or proof of stake, following a general principle that the degree to which someone can have an influence in the consensus process is proportional to the quantity of economic resources that they can bring to bear. These blockchains are generally considered to be “fully decentralized”.
Consortium blockchains: a consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered “partially decentralized”.
Private blockchains: a fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc internal to a single company, and so public readability may not be necessary in many cases at all, though in other cases public auditability is desired.
[https://ethereum-homestead.readthedocs.org/en/latest/network/connecting-to-the-network.html#public-private-and-consortium-blockchains]

ethnet'Account (ethact)

Description::
Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account. The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
===
There are two types of accounts on the Ethereum blockchain.
- Accounts that have a private key.
- Contracts (which do not have a private key)
Private key accounts are the accounts that humans operate, where as contract accounts are deployed pieces of code capable of executing some computer program.
[http://docs.ethereum-alarm-clock.com/en/latest/introduction.html]
===
There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.

The address of an external account is determined from the public key while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).

Apart from the fact whether an account stores code or not, the EVM treats the two types equally, though.

Every account has a persistent key-value store mapping 256 bit words to 256 bit words called storage.

Furthermore, every account has a balance in Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether.
[https://solidity.readthedocs.org/en/latest/introduction-to-smart-contracts.html#accounts]
===
Accounts are a central part of the Ethereum network and are an essential part of any transaction or contract. In Ethereum, there are two types of accounts: Externally Owned accounts (EOA) and Contract accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/glossary.html]

Name::
* cpt.ethact,
* cpt.ethaccount,
* cpt.ethnet'account,

ethact'Keypair

Description::
Every account is defined by a pair of keys, a private key and public key.
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]

Name::
* cpt.ethact'key,
* cpt.ethact'keypair,
* cpt.ethkeypair,

ethact'Keyfile

Description::
Every account is defined by a pair of keys, a private key and public key.
Accounts are indexed by their address which is derived from the public key by taking the last 20 bytes.
Every private key/address pair is encoded in a keyfile.
Keyfiles are JSON text files which you can open and view in any text editor.
The critical component of the keyfile, your account’s private key, is always encrypted, and it is encrypted with the password you enter when you create the account.
Keyfiles are found in the keystore subdirectory of your Ethereum node’s data directory.
Make sure you backup your keyfiles regularly!
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]

ethact'keystore

Description::
The default data directory locations are platform specific:
Windows: C:\Users\username\%appdata%\Roaming\Ethereum\keystore
Linux: ~/.ethereum/keystore
Mac: ~/Library/Ethereum/keystore
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]

Name::
* cpt.ethkeystore,

ethact'Address (ethads 20-byte|40-hex|160-bit)

Description::
0x0998c9a0c7224Ec4ED782A4Ecfef53A0e25fA9FC
0x573383aFc6cd5eEc4114C8edA98D1915FE15425C
===
Every account is defined by a pair of keys, a private key and public key.
Accounts are indexed by their address which is derived from the public key by taking the last 20 bytes.
[https://ethereum-homestead.readthedocs.io/en/latest/account-management.html]
===
There are two kinds of accounts in Ethereum which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]
===
address
An Ethereum address represents an account. For EOA, the address is derived as the last 20 bytes of the public key controlling the account, e.g., cd2a3d9f938e13cd947ec05abc7fe734df8dd826.
This is a hexadecimal format (base 16 notation), which is often indicated explicitly by appending 0x to the address.
Web3.js and console functions accept addresses with or without this prefix but for transparency we encourage their use.
Since each byte of the address is represented by 2 hex characters, a prefixed address is 42 characters long.
Several apps and APIs are also meant to implement the new checksum-enabled address scheme introduced in the Mist Ethereum wallet as of version 0.5.0.
hexadecimal
Common representation format for byte sequencing. Its advantage is that values are represented in a compact format using two characters per byte (the characters [0-9][a-f]).
[https://ethereum-homestead.readthedocs.io/en/latest/glossary.html]

Name::
* cpt.ethact'address,
* cpt.ethaddress,
* cpt.ethads,
* cpt.ethereum-address,
* cpt.ethnet'address,

ethads'Builtin-check

Description::
ATTENTION: Ethereum addresses don't have built-in checks on them yet. That means that if you mistype an address, your ether will be lost forever, without a secondary confirmation window. If you are moving a significant amount, start with smaller quantities that you can afford to lose, until you feel comfortable enough.
[https://www.ethereum.org/ether]

ethads'Resource

AddressWpg::
* https://etherscan.io/address/0x53d284357ec70ce289d6d64134dfac8e511c8a3d,
* https://etherchain.org/account/0x007abbe8057433641acb791d966d33a12cf82d01,
* https://github.com/EverexIO/Ethplorer/wiki/ethplorer-api#get-address-info,

ethads.zero

Description::
If the target account is the zero-account (the account with the address 0), the transaction creates a new contract.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#index-8]

Name::
* cpt.ethads.zero,
* cpt.ethzero_address,

ethact'Balance

Description::
Furthermore, every account has a balance in Ether (in “Wei” to be exact) which can be modified by sending transactions that include Ether.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#accounts]

Name::
* cpt.ethact'balance,
* cpt.ethact'ether,

ethact'Balance.Subtoken

Name::
* cpt.ethact'subtoken-balance,

ethact'Nonce

Description::
Account nonce: a transaction counter in each account.
This prevents replay attacks where a transaction sending eg. 20 coins from A to B can be replayed by B over and over to continually drain A's balance.
[https://github.com/ethereum/wiki/wiki/Glossary]

Name::
* cpt.ethact'nonce,
* cpt.ethnonce-of-account,

ethact'Code (link)

ethact'Location

Description::
All accounts in ethereum are stored in a merkle radix tree.
[https://github.com/ebuchman/evm-tools/blob/master/analysis/guide.md#contracts]

Name::
* cpt.ethact'location,

ethact'Store-of-data

Name::
* cpt.ethact'store-of-data,

ethact'Stack-area (link)

ethact'Storage-area (link)

ethact'Memory-area (link)

ethact'Structure

Structure::
Ethereum accounts contain the following four fields:
- nonce: A counter which ensures a transaction may only be processed exactly once.
- balance: The current ETH balance of the account.
- code: The account’s contract code (if there is any).
- storage: The account’s storage (if there is any).
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]

ethact'Transaction

Description::
The-transactions of a specific account.

ethact'transaction.IN

Transaction Information
TxHash:    0x01406301bd25b21c16d6a2a47dbbc64f1cb9231f5b26c3a084ad2161c34a2a69
Block Height:    2757949 (526943 block confirmations)
TimeStamp :    87 days 2 hrs ago (Dec-06-2016 11:52:02 AM +UTC)
From:    0x53b148c3650d248ea740439e268d07dcd27ddac4
To:    0xfbddda2a82ccab13b60b4488e87362959578ca15
Value:    4 Ether ($77.80)
Gas:    300000
Gas Price:    0.00000004 Ether
Gas Used By Transaction:    21000
Actual Tx Cost/Fee:    0.00084 Ether ($0.02)
Cumulative Gas Used:    21000
Nonce:    1
Input Data:

ethact'transaction.OUT

Transaction Information
TxHash:    0x7fdc591cd1a4e97e0623cded49cda5222714b7e321ecdae137a79fd38f618a28
Block Height:    2813266 (471621 block confirmations)
TimeStamp :    78 days 7 mins ago (Dec-15-2016 02:28:28 PM +UTC)
From:    0xfbddda2a82ccab13b60b4488e87362959578ca15
To:    0xb60508e4617c98131a36bbd46fb189e0efc8932c
Value:    3.5 Ether ($68.08)
Gas:    21000
Gas Price:    0.00000002 Ether
Gas Used By Transaction:    21000
Actual Tx Cost/Fee:    0.00042 Ether ($0.0082)
Cumulative Gas Used:    42000
Nonce:    0
Input Data:

ethact'Resource

AddressWpg::
* https://etherscan.io/accounts, A total of 1095602 accounts found (89,342,484.874 Ether) {2017-03-01}

ethact'State

Description::
Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account.
The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]

Name::
* cpt.ethact'state,

ethact'DOING

ethact'Controling