Bitcoin Wiki - User contributions [en]

Staking

2019-09-23T08:07:55Z

ChallengeAccepted: /* Staking Principle */

Staking is the consensus algorithm in [[delegated proof of stake]] coins, which is essentially a process of pooling (delegating) the validation stakes with one wallet, called a staking pool. Like with [[mining]], each delegator gets a share of the rewards, corresponding to their share in the delegate’s staking balance.

== PoS Validation ==

With [[Proof of Stake|proof of stake]] coins, the principle of validation is applied instead of mining. Whereas the possibility of finding a new block in PoW coins depends on the miner’s computing power, in PoS it depends on how many coins the validator is holding. The first coin to introduce PoS validation was [https://en.wikipedia.org/wiki/Peercoin Peercoin].<ref>[https://www.forbes.com/sites/ginaclarke/2018/10/16/proof-of-stake-guru-sunny-king-blockchain-is-easy-we-just-need-to-use-it-like-a-database/#39e83a7e1c04 https://www.forbes.com/sites/ginaclarke/2018/10/16/proof-of-stake-guru-sunny-king-blockchain-is-easy-we-just-need-to-use-it-like-a-database/#39e83a7e1c04]</ref>

Unlike PoW, proof of stake validation doesn’t require large processing power to be allocated for hashing, and requires only large amounts of coins (stakes) to be held on the validator’s wallet. Although PoS doesn’t improve decentralization, it makes the 51% problem insignificant, as collecting 51% of all issued coins is merely impossible on a free market.<ref>[https://www.forbes.com/sites/forbestechcouncil/2019/01/28/proof-of-work-and-proof-of-stake-how-blockchain-reaches-consensus/#4676a25368c8 https://www.forbes.com/sites/forbestechcouncil/2019/01/28/proof-of-work-and-proof-of-stake-how-blockchain-reaches-consensus/#4676a25368c8]</ref>

‘Clean’ PoS allows pooling of resources for validation, however it requires transacting the funds to someone’s wallet and losing control over them, which requires more confidence and trust than in other consensus algorithms. Thus, pooling in PoS is very rare and unusual.<ref>[https://medium.com/the-mission/staking-pools-how-they-work-6fa6f3cbb329 https://medium.com/the-mission/staking-pools-how-they-work-6fa6f3cbb329]</ref>

== Staking Principle ==

Unlike PoS, the delegated proof of stake (DPoS) '''requires''' pooling of resources, but without physically transferring them to another wallet. Usually, pooling is provided by staking service providers, companies that operate [[node|nodes]] built specifically for staking. Each blockchain has its own staking service providers, but several companies exist that provide staking services in multiple blockchains, for example, [[Figment Networks]], [[Everstake]] and [[Mythos]].

DPoS was developed in 2014 and first implemented in 2015, by Bitshares,<ref>[https://bitshares.org/technology/delegated-proof-of-stake-consensus/ https://bitshares.org/technology/delegated-proof-of-stake-consensus/]</ref> and is now used by multiple blockchains, with slight differences in the process and terminology.<ref>[https://kryptomoney.com/dpos-coins/ https://kryptomoney.com/dpos-coins/]</ref>

Delegated proof of stake (DPoS) is an extension of PoS distributed consensus. With DPoS, the holders of assets don't validate new blocks. Instead, they delegate their ''stake'' to a block validator of their choice, who and shares the rewards with the delegators (stakers), according to the size of their deposits. The delegates are chosen by combining random selection and staked wealth, like in the PoS blockchains.

The number of validators is voted by network users and varies between 20 and 100. For each period, the network forms a pseudo-random queue of validators, who are given a short time interval (usually one second) to process new transactions and form a new block. If a validator fails to do so, the next one is allowed to take the work and reward for it. For the next period, the validators are sorted randomly again.

== Staking Glossary ==

=== Stake ===

The amount of coins, delegated by a user to the staking balance of a pool. These coins physically remain on the delegator’s wallet, but can’t be sent until they get unstaked.

=== Staking balance ===

Combined balance of all stakes delegated to a staking pool. This balance is used by the consensus algorithm to select top nodes that will be allowed to stake in the next period.

=== Missed block ===

A set of transactions, that a staking pool has failed to verify and confirm in the given time (less than a few seconds). Missed blocks don’t provide rewards to the pool and its delegators.

=== Stolen block ===

A set of transactions, that should have been verified and confirmed by the previous pool, but is verified by the current pool instead. Such a block will generate the usual amount of rewards, but high amount of block steals in a pool signal for fast and up-to-date hardware and good Internet connection.

== References ==
<references />

Delegated proof of stake

2019-09-23T08:07:16Z

ChallengeAccepted:

Delegated proof of stake is a [[consensus]] protocol, which provides dependable verification and approval of [[Transaction|transactions]] in a [[blockchain]]. Being an extension of the [[Proof of Stake|proof of stake]] protocol, DPoS allows blockchains to change network parameters, such as fee schedules, block intervals, transaction sizes, on the fly, without creating a [[Hardfork|hard fork]], if the elected delegates vote for such a change.<ref>[https://bitshares.org/technology/delegated-proof-of-stake-consensus/ https://bitshares.org/technology/delegated-proof-of-stake-consensus/]</ref>

Deterministic selection of block producers allow DPoS blockchains to confirm transactions in as fast as 1 second.

== Block Production ==

Under DPoS, network users elect witnesses, or delegates, to generate blocks. A [[block]] is a group of transactions containing a set of updates to the state of the distributed ledger. Each network user (i.e. a wallet) is allowed to certify their trust in one of the witnesses, who will be validating transactions and generating blocks with them. A certain amount of witnesses is selected by the network to obtain enough decentralization. Usually this amount is determined by voting and is between 20 and 100 for the most DPoS blockchains.<ref>[https://medium.com/loom-network/understanding-blockchain-fundamentals-part-3-delegated-proof-of-stake-b385a6b92ef https://medium.com/loom-network/understanding-blockchain-fundamentals-part-3-delegated-proof-of-stake-b385a6b92ef]</ref>

The selected witnesses are allowed to produce blocks by verifying all transactions collected for the last block time (usually around few seconds), in the order of their selection. If they verify and sign all the transactions in a block, they receive a reward, which is usually shared with those who have voted for the witness. If a witness fails to verify all transactions in the given time, the block is missed, all the transactions are left unverified, and the witness is left without a reward. Usually, such transactions are collected in an extra block by the subsequent witness, and such a block is called stolen.<ref>[https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper]</ref>

This consensus mechanism also detects severe discrepancies in the network, for example, separation of its parts due to problems with Internet connection, and protects the network from possible [[double-spending]]. Due to the order of witness work and small timespans allocated to their work, major network outage can be detected in less than a minute. This security mechanism allows building blockchains which support independent side chains, synchronized only when needed, a network of which will support even more transactions and faster block production times.<ref>[https://www.forbes.com/sites/shermanlee/2018/02/07/explaining-side-chains-the-next-breakthrough-in-blockchain/#5185d7f052eb https://www.forbes.com/sites/shermanlee/2018/02/07/explaining-side-chains-the-next-breakthrough-in-blockchain/#5185d7f052eb]</ref>

== Protocol Changes ==

DPoS supports two tiers of changes into protocol. Changes to settings of the current work scheme can be implemented after a voting led by witnesses, and can be deployed on the fly. Changes to the protocol itself have a much complex mechanism to protect the network from jeopardizing. Once a proposal for a change is designed in code, one of the witnesses can propose it for implementation, and sign the changes with a special genesis wallet key. After a two-week audit period, during which any network user can study the proposition, a voting is held. If a quorum is achieved, the network applies the changes automatically, which may create a hard fork.<ref>[https://cryptomaniaks.com/latest-cryptocurrency-news/blockchain/is-dpos-an-improvement-over-pos https://cryptomaniaks.com/latest-cryptocurrency-news/blockchain/is-dpos-an-improvement-over-pos]</ref>

== Advantages ==

# Transaction bandwidth of DPoS blockchain is independent from computing power required to run the network, hence such blockchains are more scalable than PoW, which is used in [[Bitcoin]].
# DPoS requires less financial input from users wishing to partake in block production than standard PoS blockchains, which makes DPoS more democratic and financially inclusive.
# Thanks to the low entry threshold, DPoS provides more decentralization as more people take part in the consensus.
# DPoS doesn’t require lots of power to run the network, which makes it more sustainable.
# DPoS blockchains have good protection from double-spending.

== Disadvantages ==

# Effective operation of the network requires large numbers of interested and well-informed delegators to select suitable witnesses and provide decentralization.
# Limited number of witnesses can lead to centralization of the network.
# DPoS blockchain is susceptible to problems of weighted voting. Users with smaller stake can refuse from taking part in votings after considering that their vote is insignificant.

== History and Use of DPoS ==

DPoS was developed by Daniel Larimer, founder of BitShares, Steemit and EOS. The first implementation of DPoS, BitShared, went live on October 13th, 2015. Currently, DPoS is also used by TRON, [[Tezos]], Cardano, Lisk, Elastos, [[ARK|Ark]], Rise, Credits, Aunite.

== Staking Pools ==

Pooling of stakes is required in the DPoS. There are several companies that provide staking services for multiple blockchains, such as [[Everstake]], [[Figment Networks]] and [[Mythos]], and more providers offer stake pooling for one or a few blockchains only.

== References ==
<references />

Proof of Stake

2019-09-20T13:34:44Z

ChallengeAccepted:

Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake attempts to provide consensus and [[Double-spending|doublespend]] prevention (see [https://bitcointalk.org/index.php?topic=68213.0 "main" bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]). Because creating forks is costless when you aren't burning an external resource Proof of Stake alone is considered to an unworkable consensus mechanism.<ref>https://download.wpsoftware.net/bitcoin/pos.pdf</ref>

It was probably first proposed [https://bitcointalk.org/index.php?topic=27787.0 here] by a member named [https://bitcointalk.org/index.php?action=profile;u=241 QuantumMechanic]. With Proof of Work, the probability of mining a block depends on the work done by the miner (e.g. CPU/GPU cycles spent checking hashes). With Proof of Stake, the resource that's compared is the amount of Bitcoin a miner holds - someone holding 1% of the Bitcoin can mine 1% of the "Proof of Stake blocks".

Some argue that methods based on Proof of Work alone might lead to a low network security in a cryptocurrency with block incentives that decline over time (like bitcoin) due to [[Tragedy of the Commons]], and Proof of Stake is one way of changing the miner's incentives in favor of higher network security.

= Motivation For Proof of Stake =

* A proof-of-stake system might provide increased protection from a malicious attack on the network. Additional protection comes from two sources:
*# Executing an attack would be much more expensive.
*# Reduced incentives for attack. The attacker would need to own a near majority of all bitcoin. Therefore, the attacker suffer severely from his own attack.

* When block rewards are produced through txn fees, a proof of stake system would result in lower equilibrium txn fees. Lower long-run fees would increase the competitiveness of bitcoin relative to alternative payments systems. Intuitively reduced fees are due to vast reductions in the scale of wastage of resources.
== The Monopoly Problem ==

If a single entity (hereafter a monopolist) took control of the majority of txn verification resources, he could use these resources to impose conditions on the rest of the network. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying service. If the monopolist chose a malicious strategy and maintained his control for a long period, confidence in bitcoin would be undermined and bitcoin purchasing power would collapse. Alternatively, the monopolist could choose to act benevolently. A benevolent monopolist would exclude all other txn verifiers from fee collection and currency generation, but would not try to exploit currency holders in any way. In order to maintain a good reputation, he would refrain from double spends and maintain service provision. In this case, confidence in Bitcoin could be maintained under monopoly since all of its basic functionality would not be affected.

Both benevolent and malevolent monopoly are potentially profitable, so there are reasons to suspect that an entrepreneurial miner might attempt to become a monopolist at some point. Due to the [[Tragedy of the Commons]] effect, attempts at monopoly become increasingly likely over time.

== How Proof of Stake Addresses Monopoly Problems ==

Monopoly is still possible under proof-of-stake. However, proof-of-stake would be more secure against malicious attacks for two reasons.

Firstly, proof-of-stake makes establishing a verification monopoly more difficult. At the time of writing, an entrepreneur could achieve monopoly over proof-of-work by investing at most 10 million USD in computing hardware. The actual investment necessary might be less than this because other miners will exit as difficulty increases, but it is difficult to predict exactly how much exit will occur. If price remained constant in the face of extremely large purchases (unlikely), such an entrepreneur would need to invest at least 20 million USD to obtain monopoly under proof-of-stake. Since such a large purchase would dramatically increase bitcoin price, the entrepreneur would likely need to invest several times this amount. Thus, even now proof-of-stake monopoly would be several-fold more costly to achieve than proof-of-work monopoly. Over time the comparison of monopoly costs will become more and more dramatic. The ratio of bitcoin's mining rewards to market value is programmed to decline exponentially. As this happens, proof-of-work monopoly will become easier and easier to obtain, whereas obtaining proof-of-stake monopoly will become progressively more difficult as more of the total money supply is released into circulation.

Secondly, and perhaps more importantly, a proof-of-stake monopolist is more likely to behave benevolently exactly because of his stake in Bitcoin. In a benevolent monopoly, the currency txn continue as usual, but the monopolist earns all txn fees and coin generations. Other txn verifiers are shut out of the system, however. Since mining is not source of demand for bitcoin, bitcoin might retain most of its value in the event of a benevolent attack. Earnings from a benevolent attack are similar regardless of whether the attack occurs under proof-of-stake or proof-of-work. In a malicious attack, the attacker has some outside opportunity which allows profit from bitcoin's destruction (simple double-spends are not a plausible motivation; ownership of a competing payment platform is). At the same time, the attacker faces costs related to losses on bitcoin-specific investments which are necessary for the attack. It can be assumed that a malicious attack causes the purchasing power of bitcoin to fall to zero. Under such an attack, the proof-of-stake monopolist will lose his entire investment. By contrast, a malicious proof-of-work monopolist will be able to recover much of their hardware investment through resale. Recall also, that the necessary proof-of-work investment is much smaller than the proof-of-stake investment. Thus, the costs of a malicious attack are several-fold lower under proof-of-work. The low costs associated with malicious attack make a malicious attack more likely to occur.

== Why Proof of Stake Would Likely Decrease Long-run Txn Fees Considerably ==
In a competitive market equilibrium, the total volume of txn fees must be equal to opportunity cost of all resources used to verify txns. Under proof-of-work mining, opportunity cost can be calculated as the total sum spent on mining electricity, mining equipment depreciation, mining labor, and a market rate of return on mining capital. Electricity costs, returns on mining equipment, and equipment depreciation costs are likely to dominate here. If these costs are not substantial, then it will be exceptionally easy to monopolize the mining network. The fees necessary to prevent monopolization will be onerous, possibly in excess of the 3% fee currently charged for credit card purchases. Under pure proof-of-stake, opportunity cost can be calculated as the total sum spent on mining labor and the market interest rate for risk-free bitcoin lending (hardware-related costs will be negligible). Since bitcoins are designed to appreciate over time due to hard-coded supply limitations, interest rates on risk-free bitcoin-denominated loans are likely to be negligible. Therefore, the total volume of txn fees under pure proof-of-stake will just need to be just sufficient to compensate labor involved in maintaining bandwidth and storage space. The associated txn fees will be exceptionally low. Despite these exceptionally low fees, a proof-of-stake network will be many times more costly to exploit than the proof-of-work network. Approximately, a proof-of-work network can be exploited using expenditure equal to about one years worth of currency generation and txn fees. By contrast, exploitation of a proof-of-stake network requires purchase of a majority or near majority of all extant coins.

= Implementation =
There are currently a few distinct proposals on how to implement PoS

== Cunicula's Implementation of Mixed Proof-of-Work and Proof-of-Stake ==

This suggestion is of a mixed Proof-of-Work / Proof-of-Stake system.

=== Cunicula's Note ===
Check the page history for the older implementation. I am replacing my description with a new system which I believe to be much more secure. The new system is a greatly improved version of Coblee's Proof of Activity [https://bitcointalk.org/index.php?topic=102355.0 proposal]. It provides extremely strong protection against PoW attacks, both double-spends and denials of service. It is not vulnerable even if PoW attackers also have substantial (but non majority) stake. It provides strong incentives to maintain full nodes. The system is supported through taxes on coin owners who fail to maintain full nodes. Tax revenue is redistributed to coin owners who maintain full nodes. The maintenance of full nodes is the key element providing security in the system.

The discussion focuses on long-term maintenance of the system. Initial distribution of coins could occur through PoW mining, an IPO mechanism, or a more complex scheme that allows initial coins to be distributed to both PoW miners and businesses voted for by coin owners. The issue of initial distribution is separate from long-term maintenance and it is confusing to discuss the two together.

=== Glossary ===
Voluntary Signatures - Voluntary signatures result from a random auditing processes. As blocks are mined, keys are selected for auditing based on random selection. The signatures provide public evidence that a public key owner is running a full node. Passing the audit allows a private key to remain active.

Active Keys - By default, public keys that appear in the blockchain are active if they have a balance of at least one full coin. Public keys that provide voluntary signatures when randomly audited remain active. Active public keys are eligible to participate in lotteries to sign PoW blocks and mine PoS blocks. This is remunerative. Public keys that fail to provide signatures become dead private keys.

Dead Keys - Keys that have failed to provide signatures lose lottery eligibility. Keys that have balances of less than 1 coin are considered dead by default. Dead keys can no longer mine PoS blocks. However, these dead keys can still be used to generate txns. Network maintenance is supported primarily through mandatory fees levied on coins sent by dead keys. After coins are sent using a dead key, the key becomes active provided that it retains a balance of at least 1 coin.

Mandatory Signature Sequence - In order for a PoW block to be valid and enter the blockchain, it must be signed by a sequence of 5 randomly selected active keys. The fifth signatory in the sequence mines a PoS block.

PoS block - The fifth signatory of a PoW block must mint his own block without any PoW submission at all. This block is called a PoS block.

Coin-age - Coin age refers to the age of txn inputs. Coin age is equal to the number of coins sent times the average age on these coins. Age is measured in blocks. Age is reset to 1 block whenever a coin is sent AND whenever a coin provides a signature (both mandatory and voluntary signatures count). Coin-age is used to calculate mandatory fees.

Demurrage Fee - Chain Security is supported primarily through a demurrage tax on sent inputs. This tax proportional to average input age as measured in coin-years. I suggest 5% per coin-year as a reasonable fee. Active keys can avoid demurrage fees simply by remaining active. Thus the actual fee generation will be much lower than 5% per year. Dead keys must pay demurrage. The opportunity to evade demurrage motivates activity.

Optional Fee - Fees are used to ration block space. Blocks select prioritize txns with high fees. If demurrage fees alone are insufficient to motivate txn inclusion, the user can add an optional fee to his txn.

Fee Fund - Both optional fees and demurrage fees enter a fund, rather than being distributed directly to miners. Fees are added to the fund immediately, so there is a weak incentive to include high fee txns in blocks. The PoW miner receives a distribution equal to 0.01% of the accumulated fund. The first four mandatory signatories also receive 0.1% each. The PoS block miner receives 0.1% as well, but his takings will differ slightly because the fund is updated based on txns included in his block. Use of a fund reduces volatility in mining reward.

Root Private Key - The root private key has full spending and signing authority. When significant balances are held, this key should be kept as an offline backup to guard against theft.

Stake Signing Key - Private Key can delegate signing and sending authority to one other private key. The delegated key can sign blocks and has limited authority to send coins. Authority to send coins is determined by two positive constants, t and k. The following txn rule limits the stake signing keys' spending authority:

Change Returned to Public Key >= all coins sent to other addresses * {max(k,k*(t/coin-years on public key)}
k=9 and t=1/12 are suggested as possible parameters. These parameters allows the stake signing key to spend up to 10% of the total key balance per month. The max value at risk in event of theft of
this key is 10%. Holders of large balances 'zero-out' their coin-age frequently via mining and face less theft risk. If this occurs once per week, for example, the large balance holder will only
risk be able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once theft is detected, all remaining coins can be moved to a secure computer using the
root private key.

=== Mining Process ===

1) Block meeting work difficulty target is mined. Difficulty target periodically adjusted so that 1 PoW block arrives every 10 minutes.

2) Work submission is hashed 10 times consecutively. Each consecutive hash maps to an individual unspent output in the blockchain. This is essentially a lottery drawing two sets of five winners. The first five hashes map to mandatory signatures, the final five hashses map to voluntary signatures.

3) If the mandatory signatures map to active public keys [see glossary], the block can potentially be valid. Otherwise, the block is invalid and must be discarded.

4) If PoW miner finds a potentially valid block, he transmits the following hash to the network: {work submission;hash(his block, the previous valid block)}

5) If the work submission meets the difficulty target and maps to active signatories, then the block is relayed through the network. Otherwise, the message is dropped as spam.

5) The first five selected signatories sequentially sign this hash and transmit it onwards as {work submission; hash; sig 1; sig 2; sig 3; sig 4; sig 5}

6) After the mandatory signature sequence is complete, the final signatory publishes the PoW block and also his own PoS block.

7) The final five hashes map to voluntary signatures. These voluntary signatures can be inserted into any block within the next 6 blocks as special txns. These txns do not require fees.

9) Go to step 1

Note: This process is simultaneous so that multiple block hashes can circulate in the network attempting to collect five signatures and generate PoW/PoS block pairs. Block pairs that lose this race
are orphaned.

=== Infeasability of standard attack vectors ===

Unless attackers own a large share of stake, all types of PoW attacks are computationally infeasible. I think there are two types of known attacks: 1) Double-Spend 2) Denial of Service
I consider approximations below. The numbers are so favorable that consideration of exact statistics is not particularly interesting.

1) Double Spend.

Double spends rely on secrecy. In order to mine blocks in secret a PoW miner must select his 5 of his own public keys in the lottery. If the PoW miner owns a share 0<s<1 of all coins,
the probability of doing that a block meeting the difficulty target will select the miner's coins is (1/s)^5. For s=0.01, 1 out of 10 billion blocks will satisfy this criteria.
Even for extremely small hash aggregate rates, it is not practical to privately mine at a rate 10 billion times faster than all other miners combined. For s=0.1, 1 out of 100,000 blocks will
satisfy this criteria. (i.e. the attack still requires approximately 99.999% of all hashing power). For s=0.5, the attacker will succeed if he controls 51% of the aggregate hash rate.

2) Denial of Service

An attacker who mines publicly could simply produce empty PoW blocks. However, this would fail to deny service. 50% of all blocks are randomly mined via PoS. The attacker cannot
force the PoS miners to produce empty blocks. Therefore he cannot deny service regardless of how much hash rate he controls.

=== Long-term Chain Evaluation ===
1) Comparison of two long chains is based on a simple sum of block difficulty, just as in bitcoin.

2) A criticism of PoS is that there is no reason not to sign attack chains. However, in a long secret chain, many stakeholders will have dead signatures. These dead stakeholders will not be able to sign the main chain, but not the attack chain. They will have a strong incentive to make sure the main chain wins because the attack chain will impose demurrage fees on them.

=== Incentives to maintain full nodes ===

This system introduces powerful incentives to maintain full nodes. Many people argue that the lack of an incentive to maintain a full node is a problem in the bitcoin system.

1) a steady flow of txns will generate some fees even if all public keys remain active. Active keys must be maintaining full nodes. Otherwise they could not provide the voluntary signatures which prove their activity. Even very weak incentives are sufficient in this case. If almost all keys are associated with active nodes, then it is not necessary to motivate additional participation.

2) Some public keys may decide to become inactive. This is costly for them. They will suffer a loss of 5% of their balance per year for as long as they remain inactive.

3) The active public keys constantly capture revenue from inactive public keys. This means that the incentives to remain increase dramatically as participation falls. Suppose that 50% of public keys maintain full nodes, then this 50% will capture 2.5% of coins per annum. This is equal to an annual of return of 2.0%. The alternative, inactivity, yields an annual return of -5.0% as discussed in point 2. I consider this a reasonable incentive level and participation rate. Suppose that I am wrong, and only 10% of public keys maintain full nodes. Then these 10% will capture 4.5% of all extant coins per annum. This implies an annual return on participation equal to 45% per annum. This is a very strong incentive and is almost certain to be sufficient, even if nodes are quite costly to maintain. If only 1% of coins participate, then 4.95% of all extant coins will be distributed to this 1% each year. This implies a weekly return on participation of 3%, a pirate ponzi scheme level return. If these incentive are inadequate to support a healthy network of full nodes (which seems unlikely to me), then the levy on dead coins could be increased to exceed 5% per annum.

4) Many people will not have enough coins to justify running their own node. Such individuals will likely use an online banking service which could store their limited spend key. The service could return interest to users in exchange for managing their keys.

5) Other individuals may prefer the privacy associated with dropping out of participation. These individuals are still welcome to use the network, but must face a wealth tax of 5% per annum to compensate for the security risk created by their behavior.

=== Storage of Blockchain Metadata ===
To facilitate the system, data should be extracted from the block chain in a readily accessible database that is updated with each block. The database only needs to incorporate
public keys which control at least 1 coin. Keys with balances less than 1 coin are considered dead by default. These low-value public keys
are not allowed to create limited stake public keys. If a public key balance drops below 1 coin, the limited stake public key associated with the root key is invalidated.

The database would look like this:

{| class="wikitable"
|-
! Public Key (ordered list) !! Linked Stake Public key (if any) !! Balance !! Cumulative Balance !! Active? !! Coin-age (in years)
|-
| A || As || 1 || 1 || 1 || 0.03
|-
| B || Bs || 2.5 || 3.5 || 0 || 0.1
|-
| C || Cs || 3 || 6.5 || 1 || 0.2
|-
| ... || ... || ... || ... || ... || ...
|}
The block chain must maintain records of links between public keys and delegated limited stake public keys. These should be put in a simple database for easy access.

Cumulative balance can be used to determine the winners of the lottery. (i.e. the lottery is a uniform draw on the support [0,total issued coins]) This indicates a unique lottery winner,
whose chance of winning is proportional to his ownership share.

Coin-age is updated as follows.
If no send, Coin-age_t = Coin-age_t-1 + 1.
If send, Coin_age_t = 1.
If send and receipt of coins, Coin_age_t = 1.
If receipt of coins but no send, Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)

Coin-age is necessary to determine mandatory demurrage fees and to calculate spending limits for limited stake public keys.

Active is 1 by default and becomes 0 if a key fails to provide a requested voluntary signature. 0 is an absorbing state.

=== Beneficiaries and Lossers from Txn Fees ===
The total amount of demurrage fees collected annually varies between 0% and 5% of the total money supply.

The most burdensome fee in the system is the fee paid to PoW miners. This fee imposes a demurrage tax of between 0% and 0.1% per annum on all users of the system. In addition to the demurrage tax, PoW miners receive a 2% share of any optional fees paid to access scarce block space. All coin owners are net losers as a result of PoW mining fees. To minimize costs to coin owners, PoW fee payments are kept as low as possible. Since large hash rates play only a tiny role in security, larger fees for PoW miners are unnecessary.

Other demurrage fees are transfers of revenue from one private key to another. Some keys are net beneficiaries of these transfers, while other keys are net losers. Collectively, these fees do not make coin owners better or worse off. Their effects are neutral. However, individually, the fees do create winners and losers. ''Active'' users that spend infrequently gain from the system. An ''active'' user with average spend frequency is likely to gain from the system as well, but only by a small amount. An ''active'' user that spends very frequently will probably lose from the system. ''Dead'' users will certainly lose from the system. This loss serves as a punishment for failure to maintain an ''active'' node.

== Meni's implementation ==
This proposal is for a proof-of-work (PoW) skeleton on which occasional checkpoints set by stakeholders are placed. In one variant, double-spending is prevented by waiting for a transaction to be included in a checkpoint; the variant described here uses cementing to prevent double-spending, and checkpoints to resolve cementing conflicts.

=== Proof of work ===
Miners use their hashrate to find blocks and build the blockchain exactly as with the pure PoW system. They receive any new generated coins from the block; there will be two kinds of transaction fees, one of which is a mining fee given to the miner who finds the block, just like the PoW transaction fees.

=== Signatures ===
One block every 100 blocks (a different number can be used instead) is a signature block. When a signature block is found and confirmed with several subsequent blocks, stakeholders (people who have bitcoins) are expected to sign it by using a private key associated with their address which contains coins to sign the block hash. If there are several blocks of the same height, an address should not sign more than one of them. The signatures are broadcast on the network and included in a future block. For every candidate block, the total weight of all signatures is tallied (the weight of an address is determined mostly by the number of coins in it, as of the last signature block). Stakeholders will be able to collect signature fees when providing a signature, proportionally to their weight.

At the basic level, there are no rules to choosing which of several conflicting blocks to sign, stakeholders should just choose one.

=== Cementing ===
Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.

In a pure PoW system this is problematic to do because a node could be stuck on "the wrong version" - if an attacker isolates the node and feeds him bogus data, it will not embrace the true, longer chain when he learns of it. However, using PoS to have the final say in such situations makes this possible.

=== Branch selection ===
When a node needs to select which of several branches is valid, it chooses one based on the following criteria in increasing importance (each one is overridden by the next):

#Branch length (total difficulty of all blocks), as in a PoW system.
#Cementing - an already cemented block will not be replaced by a longer branch.
#Signatures - even a cemented block will be overridden by a signature block with signature weight more than half the total possible weight by some margin.

If the conflict is so long that it contains more than one spot for a signature block, the conflicting signature blocks will be traversed earliest to latest, each time choosing the branch with the majority vote. After the newest uncontested signature block it proceeds to use cementing and branch length.

A signature block with no clear majority will be considered tied, and will not override the other criteria. Signature fees will not be given out but instead carried over to the next signature spot, to encourage stakeholders to participate then.

=== [[Double-spending]] prevention ===
A good level of security can be achieved by waiting for a block to be cemented. By that time it is safe to assume that the network recognizes this block and will not easily switch to a different block, even if a longer branch is presented.

A more authoritative confirmation is enabled by waiting for a signature block. Once a block achieves a majority (and some more time is allowed for this majority to spread in the network), it is extremely unlikely that the network will ever switch away from this block.

=== Weights ===
The weight of every address starts at 0. When an address provides a signature, its weight increases so that after several signatures, the weight approaches the number of coins in the address as of the last signature block. For example,
New weight = 0.9 * Old weight + 0.1 * Balance
If a signature is not provided by the address in a signature block, its weight decreases:
New weight = 0.9 * Old weight
This way, addresses whose owners do not wish to participate in signing do not hamper the ability to reach a majority.

If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.

If coins move to a new address, weight is proportionally taken away from the addressed, but is not transferred to the new address. The new stakeholder will have to build up his weight.

=== Malicious stakeholders ===
The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored. This will cause the current majority block to become tied, but the network is already cemented on it and will vote for this branch in the next signature block. The weight of the attacker will by then reduce to 0 so he will be unable to create more disruption.

Another attack is refusing to sign blocks to keep them tied. Since this causes a decay of the weight, they can only stand in the way of a majority for a short time.

=== Denial of service ===
The method as described does not solve a denial of service scenario. A majority miner could create only blocks with no transactions (or with many transactions missing) and reject all other blocks.

This may be solvable by adding some measure of the transaction in a block to the selection criteria, such as Bitcoin days destroyed.

Also, proposals to replace the block chain with a directed acyclic graph have been made, and could be used to make it easier to include transactions.

== Key difference between the two proposals ==
In Cunicula's system, voting power is determined by combining (multiplicatively) your hashrate and stake. This would be problematic if small players could not compete effectively with large players. Though we are waiting on a formal mathematical proof, evidence to date suggests that small and large players would have an equal competitive footing. Simulations described in this thread [https://bitcointalk.org/index.php?topic=68213.msg801253#msg801253] indicate that small players are competitive with large players because the multiplicative combination of hashrate and stake exhibits constant returns. Evidence in the thread suggests that these simulation results are accepted by both Cunicula and Meni.)

In Meni's, there's a skeleton based purely on hashrate, and superimposed on it are occasional checkpoints set by stakeholders. You can contribute PoW without having stake, and you can contribute PoS without having work, and in both cases your voting power and reward is linearly proportional to the resources you have.

= Delegated Proof of Stake =

The [[Delegated proof of stake]] closely resembles pooling of stakes in a manner, similar to PoW [[mining]]. According to the proof of share principle, instead of computing powers, the partaking users are pooling their stakes, certain amounts of money, blocked on their wallets and delegated to the pool’s staking balance.

The network periodically selects a pre-defined number of top staking pools (usually between 20 and 100), based on their staking balances, and allows them to validate transactions in order to get a reward. The rewards are then shared with the delegators, according to their stakes with the pool.

This principle allows increasing the decentralization, and minimizing the possibility of attaining of 51% of staking power by any of the pools, as such pool will be considered insecure by the users, and they would withdraw their stakes.

= See also =
*[[Proof_of_work|Proof of work]]
*[[Proof_of_burn|Proof of burn]]
*[http://www.reddit.com/r/reddCoin/comments/249dnl/major_announcement_reddcoin_to_implement_new/ Proof of Stake Velocity by Reddcoin]

[[category:mining]]
[[category:Proof-of-x]]

Proof of Stake

2019-09-20T13:34:18Z

ChallengeAccepted:

Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake attempts to provide consensus and [[Double-spending|doublespend]] prevention (see [https://bitcointalk.org/index.php?topic=68213.0 "main" bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]). Because creating forks is costless when you aren't burning an external resource Proof of Stake alone is considered to an unworkable consensus mechanism.<ref>https://download.wpsoftware.net/bitcoin/pos.pdf</ref>

It was probably first proposed [https://bitcointalk.org/index.php?topic=27787.0 here] by a member named [https://bitcointalk.org/index.php?action=profile;u=241 QuantumMechanic]. With Proof of Work, the probability of mining a block depends on the work done by the miner (e.g. CPU/GPU cycles spent checking hashes). With Proof of Stake, the resource that's compared is the amount of Bitcoin a miner holds - someone holding 1% of the Bitcoin can mine 1% of the "Proof of Stake blocks".

Some argue that methods based on Proof of Work alone might lead to a low network security in a cryptocurrency with block incentives that decline over time (like bitcoin) due to [[Tragedy of the Commons]], and Proof of Stake is one way of changing the miner's incentives in favor of higher network security.

= Motivation For Proof of Stake =

* A proof-of-stake system might provide increased protection from a malicious attack on the network. Additional protection comes from two sources:
*# Executing an attack would be much more expensive.
*# Reduced incentives for attack. The attacker would need to own a near majority of all bitcoin. Therefore, the attacker suffer severely from his own attack.

* When block rewards are produced through txn fees, a proof of stake system would result in lower equilibrium txn fees. Lower long-run fees would increase the competitiveness of bitcoin relative to alternative payments systems. Intuitively reduced fees are due to vast reductions in the scale of wastage of resources.
== The Monopoly Problem ==

If a single entity (hereafter a monopolist) took control of the majority of txn verification resources, he could use these resources to impose conditions on the rest of the network. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying service. If the monopolist chose a malicious strategy and maintained his control for a long period, confidence in bitcoin would be undermined and bitcoin purchasing power would collapse. Alternatively, the monopolist could choose to act benevolently. A benevolent monopolist would exclude all other txn verifiers from fee collection and currency generation, but would not try to exploit currency holders in any way. In order to maintain a good reputation, he would refrain from double spends and maintain service provision. In this case, confidence in Bitcoin could be maintained under monopoly since all of its basic functionality would not be affected.

Both benevolent and malevolent monopoly are potentially profitable, so there are reasons to suspect that an entrepreneurial miner might attempt to become a monopolist at some point. Due to the [[Tragedy of the Commons]] effect, attempts at monopoly become increasingly likely over time.

== How Proof of Stake Addresses Monopoly Problems ==

Monopoly is still possible under proof-of-stake. However, proof-of-stake would be more secure against malicious attacks for two reasons.

Firstly, proof-of-stake makes establishing a verification monopoly more difficult. At the time of writing, an entrepreneur could achieve monopoly over proof-of-work by investing at most 10 million USD in computing hardware. The actual investment necessary might be less than this because other miners will exit as difficulty increases, but it is difficult to predict exactly how much exit will occur. If price remained constant in the face of extremely large purchases (unlikely), such an entrepreneur would need to invest at least 20 million USD to obtain monopoly under proof-of-stake. Since such a large purchase would dramatically increase bitcoin price, the entrepreneur would likely need to invest several times this amount. Thus, even now proof-of-stake monopoly would be several-fold more costly to achieve than proof-of-work monopoly. Over time the comparison of monopoly costs will become more and more dramatic. The ratio of bitcoin's mining rewards to market value is programmed to decline exponentially. As this happens, proof-of-work monopoly will become easier and easier to obtain, whereas obtaining proof-of-stake monopoly will become progressively more difficult as more of the total money supply is released into circulation.

Secondly, and perhaps more importantly, a proof-of-stake monopolist is more likely to behave benevolently exactly because of his stake in Bitcoin. In a benevolent monopoly, the currency txn continue as usual, but the monopolist earns all txn fees and coin generations. Other txn verifiers are shut out of the system, however. Since mining is not source of demand for bitcoin, bitcoin might retain most of its value in the event of a benevolent attack. Earnings from a benevolent attack are similar regardless of whether the attack occurs under proof-of-stake or proof-of-work. In a malicious attack, the attacker has some outside opportunity which allows profit from bitcoin's destruction (simple double-spends are not a plausible motivation; ownership of a competing payment platform is). At the same time, the attacker faces costs related to losses on bitcoin-specific investments which are necessary for the attack. It can be assumed that a malicious attack causes the purchasing power of bitcoin to fall to zero. Under such an attack, the proof-of-stake monopolist will lose his entire investment. By contrast, a malicious proof-of-work monopolist will be able to recover much of their hardware investment through resale. Recall also, that the necessary proof-of-work investment is much smaller than the proof-of-stake investment. Thus, the costs of a malicious attack are several-fold lower under proof-of-work. The low costs associated with malicious attack make a malicious attack more likely to occur.

== Why Proof of Stake Would Likely Decrease Long-run Txn Fees Considerably ==
In a competitive market equilibrium, the total volume of txn fees must be equal to opportunity cost of all resources used to verify txns. Under proof-of-work mining, opportunity cost can be calculated as the total sum spent on mining electricity, mining equipment depreciation, mining labor, and a market rate of return on mining capital. Electricity costs, returns on mining equipment, and equipment depreciation costs are likely to dominate here. If these costs are not substantial, then it will be exceptionally easy to monopolize the mining network. The fees necessary to prevent monopolization will be onerous, possibly in excess of the 3% fee currently charged for credit card purchases. Under pure proof-of-stake, opportunity cost can be calculated as the total sum spent on mining labor and the market interest rate for risk-free bitcoin lending (hardware-related costs will be negligible). Since bitcoins are designed to appreciate over time due to hard-coded supply limitations, interest rates on risk-free bitcoin-denominated loans are likely to be negligible. Therefore, the total volume of txn fees under pure proof-of-stake will just need to be just sufficient to compensate labor involved in maintaining bandwidth and storage space. The associated txn fees will be exceptionally low. Despite these exceptionally low fees, a proof-of-stake network will be many times more costly to exploit than the proof-of-work network. Approximately, a proof-of-work network can be exploited using expenditure equal to about one years worth of currency generation and txn fees. By contrast, exploitation of a proof-of-stake network requires purchase of a majority or near majority of all extant coins.

= Implementation =
There are currently a few distinct proposals on how to implement PoS

== Cunicula's Implementation of Mixed Proof-of-Work and Proof-of-Stake ==

This suggestion is of a mixed Proof-of-Work / Proof-of-Stake system.

=== Cunicula's Note ===
Check the page history for the older implementation. I am replacing my description with a new system which I believe to be much more secure. The new system is a greatly improved version of Coblee's Proof of Activity [https://bitcointalk.org/index.php?topic=102355.0 proposal]. It provides extremely strong protection against PoW attacks, both double-spends and denials of service. It is not vulnerable even if PoW attackers also have substantial (but non majority) stake. It provides strong incentives to maintain full nodes. The system is supported through taxes on coin owners who fail to maintain full nodes. Tax revenue is redistributed to coin owners who maintain full nodes. The maintenance of full nodes is the key element providing security in the system.

The discussion focuses on long-term maintenance of the system. Initial distribution of coins could occur through PoW mining, an IPO mechanism, or a more complex scheme that allows initial coins to be distributed to both PoW miners and businesses voted for by coin owners. The issue of initial distribution is separate from long-term maintenance and it is confusing to discuss the two together.

=== Glossary ===
Voluntary Signatures - Voluntary signatures result from a random auditing processes. As blocks are mined, keys are selected for auditing based on random selection. The signatures provide public evidence that a public key owner is running a full node. Passing the audit allows a private key to remain active.

Active Keys - By default, public keys that appear in the blockchain are active if they have a balance of at least one full coin. Public keys that provide voluntary signatures when randomly audited remain active. Active public keys are eligible to participate in lotteries to sign PoW blocks and mine PoS blocks. This is remunerative. Public keys that fail to provide signatures become dead private keys.

Dead Keys - Keys that have failed to provide signatures lose lottery eligibility. Keys that have balances of less than 1 coin are considered dead by default. Dead keys can no longer mine PoS blocks. However, these dead keys can still be used to generate txns. Network maintenance is supported primarily through mandatory fees levied on coins sent by dead keys. After coins are sent using a dead key, the key becomes active provided that it retains a balance of at least 1 coin.

Mandatory Signature Sequence - In order for a PoW block to be valid and enter the blockchain, it must be signed by a sequence of 5 randomly selected active keys. The fifth signatory in the sequence mines a PoS block.

PoS block - The fifth signatory of a PoW block must mint his own block without any PoW submission at all. This block is called a PoS block.

Coin-age - Coin age refers to the age of txn inputs. Coin age is equal to the number of coins sent times the average age on these coins. Age is measured in blocks. Age is reset to 1 block whenever a coin is sent AND whenever a coin provides a signature (both mandatory and voluntary signatures count). Coin-age is used to calculate mandatory fees.

Demurrage Fee - Chain Security is supported primarily through a demurrage tax on sent inputs. This tax proportional to average input age as measured in coin-years. I suggest 5% per coin-year as a reasonable fee. Active keys can avoid demurrage fees simply by remaining active. Thus the actual fee generation will be much lower than 5% per year. Dead keys must pay demurrage. The opportunity to evade demurrage motivates activity.

Optional Fee - Fees are used to ration block space. Blocks select prioritize txns with high fees. If demurrage fees alone are insufficient to motivate txn inclusion, the user can add an optional fee to his txn.

Fee Fund - Both optional fees and demurrage fees enter a fund, rather than being distributed directly to miners. Fees are added to the fund immediately, so there is a weak incentive to include high fee txns in blocks. The PoW miner receives a distribution equal to 0.01% of the accumulated fund. The first four mandatory signatories also receive 0.1% each. The PoS block miner receives 0.1% as well, but his takings will differ slightly because the fund is updated based on txns included in his block. Use of a fund reduces volatility in mining reward.

Root Private Key - The root private key has full spending and signing authority. When significant balances are held, this key should be kept as an offline backup to guard against theft.

Stake Signing Key - Private Key can delegate signing and sending authority to one other private key. The delegated key can sign blocks and has limited authority to send coins. Authority to send coins is determined by two positive constants, t and k. The following txn rule limits the stake signing keys' spending authority:

Change Returned to Public Key >= all coins sent to other addresses * {max(k,k*(t/coin-years on public key)}
k=9 and t=1/12 are suggested as possible parameters. These parameters allows the stake signing key to spend up to 10% of the total key balance per month. The max value at risk in event of theft of
this key is 10%. Holders of large balances 'zero-out' their coin-age frequently via mining and face less theft risk. If this occurs once per week, for example, the large balance holder will only
risk be able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once theft is detected, all remaining coins can be moved to a secure computer using the
root private key.

=== Mining Process ===

1) Block meeting work difficulty target is mined. Difficulty target periodically adjusted so that 1 PoW block arrives every 10 minutes.

2) Work submission is hashed 10 times consecutively. Each consecutive hash maps to an individual unspent output in the blockchain. This is essentially a lottery drawing two sets of five winners. The first five hashes map to mandatory signatures, the final five hashses map to voluntary signatures.

3) If the mandatory signatures map to active public keys [see glossary], the block can potentially be valid. Otherwise, the block is invalid and must be discarded.

4) If PoW miner finds a potentially valid block, he transmits the following hash to the network: {work submission;hash(his block, the previous valid block)}

5) If the work submission meets the difficulty target and maps to active signatories, then the block is relayed through the network. Otherwise, the message is dropped as spam.

5) The first five selected signatories sequentially sign this hash and transmit it onwards as {work submission; hash; sig 1; sig 2; sig 3; sig 4; sig 5}

6) After the mandatory signature sequence is complete, the final signatory publishes the PoW block and also his own PoS block.

7) The final five hashes map to voluntary signatures. These voluntary signatures can be inserted into any block within the next 6 blocks as special txns. These txns do not require fees.

9) Go to step 1

Note: This process is simultaneous so that multiple block hashes can circulate in the network attempting to collect five signatures and generate PoW/PoS block pairs. Block pairs that lose this race
are orphaned.

=== Infeasability of standard attack vectors ===

Unless attackers own a large share of stake, all types of PoW attacks are computationally infeasible. I think there are two types of known attacks: 1) Double-Spend 2) Denial of Service
I consider approximations below. The numbers are so favorable that consideration of exact statistics is not particularly interesting.

1) Double Spend.

Double spends rely on secrecy. In order to mine blocks in secret a PoW miner must select his 5 of his own public keys in the lottery. If the PoW miner owns a share 0<s<1 of all coins,
the probability of doing that a block meeting the difficulty target will select the miner's coins is (1/s)^5. For s=0.01, 1 out of 10 billion blocks will satisfy this criteria.
Even for extremely small hash aggregate rates, it is not practical to privately mine at a rate 10 billion times faster than all other miners combined. For s=0.1, 1 out of 100,000 blocks will
satisfy this criteria. (i.e. the attack still requires approximately 99.999% of all hashing power). For s=0.5, the attacker will succeed if he controls 51% of the aggregate hash rate.

2) Denial of Service

An attacker who mines publicly could simply produce empty PoW blocks. However, this would fail to deny service. 50% of all blocks are randomly mined via PoS. The attacker cannot
force the PoS miners to produce empty blocks. Therefore he cannot deny service regardless of how much hash rate he controls.

=== Long-term Chain Evaluation ===
1) Comparison of two long chains is based on a simple sum of block difficulty, just as in bitcoin.

2) A criticism of PoS is that there is no reason not to sign attack chains. However, in a long secret chain, many stakeholders will have dead signatures. These dead stakeholders will not be able to sign the main chain, but not the attack chain. They will have a strong incentive to make sure the main chain wins because the attack chain will impose demurrage fees on them.

=== Incentives to maintain full nodes ===

This system introduces powerful incentives to maintain full nodes. Many people argue that the lack of an incentive to maintain a full node is a problem in the bitcoin system.

1) a steady flow of txns will generate some fees even if all public keys remain active. Active keys must be maintaining full nodes. Otherwise they could not provide the voluntary signatures which prove their activity. Even very weak incentives are sufficient in this case. If almost all keys are associated with active nodes, then it is not necessary to motivate additional participation.

2) Some public keys may decide to become inactive. This is costly for them. They will suffer a loss of 5% of their balance per year for as long as they remain inactive.

3) The active public keys constantly capture revenue from inactive public keys. This means that the incentives to remain increase dramatically as participation falls. Suppose that 50% of public keys maintain full nodes, then this 50% will capture 2.5% of coins per annum. This is equal to an annual of return of 2.0%. The alternative, inactivity, yields an annual return of -5.0% as discussed in point 2. I consider this a reasonable incentive level and participation rate. Suppose that I am wrong, and only 10% of public keys maintain full nodes. Then these 10% will capture 4.5% of all extant coins per annum. This implies an annual return on participation equal to 45% per annum. This is a very strong incentive and is almost certain to be sufficient, even if nodes are quite costly to maintain. If only 1% of coins participate, then 4.95% of all extant coins will be distributed to this 1% each year. This implies a weekly return on participation of 3%, a pirate ponzi scheme level return. If these incentive are inadequate to support a healthy network of full nodes (which seems unlikely to me), then the levy on dead coins could be increased to exceed 5% per annum.

4) Many people will not have enough coins to justify running their own node. Such individuals will likely use an online banking service which could store their limited spend key. The service could return interest to users in exchange for managing their keys.

5) Other individuals may prefer the privacy associated with dropping out of participation. These individuals are still welcome to use the network, but must face a wealth tax of 5% per annum to compensate for the security risk created by their behavior.

=== Storage of Blockchain Metadata ===
To facilitate the system, data should be extracted from the block chain in a readily accessible database that is updated with each block. The database only needs to incorporate
public keys which control at least 1 coin. Keys with balances less than 1 coin are considered dead by default. These low-value public keys
are not allowed to create limited stake public keys. If a public key balance drops below 1 coin, the limited stake public key associated with the root key is invalidated.

The database would look like this:

{| class="wikitable"
|-
! Public Key (ordered list) !! Linked Stake Public key (if any) !! Balance !! Cumulative Balance !! Active? !! Coin-age (in years)
|-
| A || As || 1 || 1 || 1 || 0.03
|-
| B || Bs || 2.5 || 3.5 || 0 || 0.1
|-
| C || Cs || 3 || 6.5 || 1 || 0.2
|-
| ... || ... || ... || ... || ... || ...
|}
The block chain must maintain records of links between public keys and delegated limited stake public keys. These should be put in a simple database for easy access.

Cumulative balance can be used to determine the winners of the lottery. (i.e. the lottery is a uniform draw on the support [0,total issued coins]) This indicates a unique lottery winner,
whose chance of winning is proportional to his ownership share.

Coin-age is updated as follows.
If no send, Coin-age_t = Coin-age_t-1 + 1.
If send, Coin_age_t = 1.
If send and receipt of coins, Coin_age_t = 1.
If receipt of coins but no send, Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)

Coin-age is necessary to determine mandatory demurrage fees and to calculate spending limits for limited stake public keys.

Active is 1 by default and becomes 0 if a key fails to provide a requested voluntary signature. 0 is an absorbing state.

=== Beneficiaries and Lossers from Txn Fees ===
The total amount of demurrage fees collected annually varies between 0% and 5% of the total money supply.

The most burdensome fee in the system is the fee paid to PoW miners. This fee imposes a demurrage tax of between 0% and 0.1% per annum on all users of the system. In addition to the demurrage tax, PoW miners receive a 2% share of any optional fees paid to access scarce block space. All coin owners are net losers as a result of PoW mining fees. To minimize costs to coin owners, PoW fee payments are kept as low as possible. Since large hash rates play only a tiny role in security, larger fees for PoW miners are unnecessary.

Other demurrage fees are transfers of revenue from one private key to another. Some keys are net beneficiaries of these transfers, while other keys are net losers. Collectively, these fees do not make coin owners better or worse off. Their effects are neutral. However, individually, the fees do create winners and losers. ''Active'' users that spend infrequently gain from the system. An ''active'' user with average spend frequency is likely to gain from the system as well, but only by a small amount. An ''active'' user that spends very frequently will probably lose from the system. ''Dead'' users will certainly lose from the system. This loss serves as a punishment for failure to maintain an ''active'' node.

== Meni's implementation ==
This proposal is for a proof-of-work (PoW) skeleton on which occasional checkpoints set by stakeholders are placed. In one variant, double-spending is prevented by waiting for a transaction to be included in a checkpoint; the variant described here uses cementing to prevent double-spending, and checkpoints to resolve cementing conflicts.

=== Proof of work ===
Miners use their hashrate to find blocks and build the blockchain exactly as with the pure PoW system. They receive any new generated coins from the block; there will be two kinds of transaction fees, one of which is a mining fee given to the miner who finds the block, just like the PoW transaction fees.

=== Signatures ===
One block every 100 blocks (a different number can be used instead) is a signature block. When a signature block is found and confirmed with several subsequent blocks, stakeholders (people who have bitcoins) are expected to sign it by using a private key associated with their address which contains coins to sign the block hash. If there are several blocks of the same height, an address should not sign more than one of them. The signatures are broadcast on the network and included in a future block. For every candidate block, the total weight of all signatures is tallied (the weight of an address is determined mostly by the number of coins in it, as of the last signature block). Stakeholders will be able to collect signature fees when providing a signature, proportionally to their weight.

At the basic level, there are no rules to choosing which of several conflicting blocks to sign, stakeholders should just choose one.

=== Cementing ===
Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.

In a pure PoW system this is problematic to do because a node could be stuck on "the wrong version" - if an attacker isolates the node and feeds him bogus data, it will not embrace the true, longer chain when he learns of it. However, using PoS to have the final say in such situations makes this possible.

=== Branch selection ===
When a node needs to select which of several branches is valid, it chooses one based on the following criteria in increasing importance (each one is overridden by the next):

#Branch length (total difficulty of all blocks), as in a PoW system.
#Cementing - an already cemented block will not be replaced by a longer branch.
#Signatures - even a cemented block will be overridden by a signature block with signature weight more than half the total possible weight by some margin.

If the conflict is so long that it contains more than one spot for a signature block, the conflicting signature blocks will be traversed earliest to latest, each time choosing the branch with the majority vote. After the newest uncontested signature block it proceeds to use cementing and branch length.

A signature block with no clear majority will be considered tied, and will not override the other criteria. Signature fees will not be given out but instead carried over to the next signature spot, to encourage stakeholders to participate then.

=== [[Double-spending]] prevention ===
A good level of security can be achieved by waiting for a block to be cemented. By that time it is safe to assume that the network recognizes this block and will not easily switch to a different block, even if a longer branch is presented.

A more authoritative confirmation is enabled by waiting for a signature block. Once a block achieves a majority (and some more time is allowed for this majority to spread in the network), it is extremely unlikely that the network will ever switch away from this block.

=== Weights ===
The weight of every address starts at 0. When an address provides a signature, its weight increases so that after several signatures, the weight approaches the number of coins in the address as of the last signature block. For example,
New weight = 0.9 * Old weight + 0.1 * Balance
If a signature is not provided by the address in a signature block, its weight decreases:
New weight = 0.9 * Old weight
This way, addresses whose owners do not wish to participate in signing do not hamper the ability to reach a majority.

If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.

If coins move to a new address, weight is proportionally taken away from the addressed, but is not transferred to the new address. The new stakeholder will have to build up his weight.

=== Malicious stakeholders ===
The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored. This will cause the current majority block to become tied, but the network is already cemented on it and will vote for this branch in the next signature block. The weight of the attacker will by then reduce to 0 so he will be unable to create more disruption.

Another attack is refusing to sign blocks to keep them tied. Since this causes a decay of the weight, they can only stand in the way of a majority for a short time.

=== Denial of service ===
The method as described does not solve a denial of service scenario. A majority miner could create only blocks with no transactions (or with many transactions missing) and reject all other blocks.

This may be solvable by adding some measure of the transaction in a block to the selection criteria, such as Bitcoin days destroyed.

Also, proposals to replace the block chain with a directed acyclic graph have been made, and could be used to make it easier to include transactions.

== Key difference between the two proposals ==
In Cunicula's system, voting power is determined by combining (multiplicatively) your hashrate and stake. This would be problematic if small players could not compete effectively with large players. Though we are waiting on a formal mathematical proof, evidence to date suggests that small and large players would have an equal competitive footing. Simulations described in this thread [https://bitcointalk.org/index.php?topic=68213.msg801253#msg801253] indicate that small players are competitive with large players because the multiplicative combination of hashrate and stake exhibits constant returns. Evidence in the thread suggests that these simulation results are accepted by both Cunicula and Meni.)

In Meni's, there's a skeleton based purely on hashrate, and superimposed on it are occasional checkpoints set by stakeholders. You can contribute PoW without having stake, and you can contribute PoS without having work, and in both cases your voting power and reward is linearly proportional to the resources you have.

= Delegated Proof of Stake =

The [[Delegated proof of stake]] closely resembles pooling of stakes in a manner, similar to PoW [[mining]]. According to the proof of share principle, instead of computing powers, the partaking users are pooling their stakes, certain amounts of money, blocked on their wallets and delegated to the pool’s staking balance.

The network periodically selects a pre-defined number of top staking pools (usually between 20 and 100), based on their staking balances, and allows them to validate transactions in order to get a reward. The rewards are then shared with the delegators, according to their stakes with the pool.

This principle allows increasing the decentralization, and minimizing the possibility of attaining of 51% of staking power by any of the pools, as such pool will be considered insecure by the users, and they would withdraw their stakes.

== See also ==
*[[Proof_of_work|Proof of work]]
*[[Proof_of_burn|Proof of burn]]
*[http://www.reddit.com/r/reddCoin/comments/249dnl/major_announcement_reddcoin_to_implement_new/ Proof of Stake Velocity by Reddcoin]

[[category:mining]]
[[category:Proof-of-x]]

Delegated proof of stake

2019-09-20T13:30:06Z

ChallengeAccepted:

Delegated proof of stake is a [[consensus]] protocol, which provides dependable verification and approval of [[Transaction|transactions]] in a [[blockchain]]. Being an extension of the [[Proof of Stake|proof of stake]] protocol, DPoS allows blockchains to change network parameters, such as fee schedules, block intervals, transaction sizes, on the fly, without creating a [[Hardfork|hard fork]], if the elected delegates vote for such a change.<ref>[https://bitshares.org/technology/delegated-proof-of-stake-consensus/ https://bitshares.org/technology/delegated-proof-of-stake-consensus/]</ref>

Deterministic selection of block producers allow DPoS blockchains to confirm transactions in as fast as 1 second.

== Block Production ==

Under DPoS, network users elect witnesses, or delegates, to generate blocks. A [[block]] is a group of transactions containing a set of updates to the state of the distributed ledger. Each network user (i.e. a wallet) is allowed to certify their trust in one of the witnesses, who will be validating transactions and generating blocks with them. A certain amount of witnesses is selected by the network to obtain enough decentralization. Usually this amount is determined by voting and is between 20 and 100 for the most DPoS blockchains.<ref>[https://medium.com/loom-network/understanding-blockchain-fundamentals-part-3-delegated-proof-of-stake-b385a6b92ef https://medium.com/loom-network/understanding-blockchain-fundamentals-part-3-delegated-proof-of-stake-b385a6b92ef]</ref>

The selected witnesses are allowed to produce blocks by verifying all transactions collected for the last block time (usually around few seconds), in the order of their selection. If they verify and sign all the transactions in a block, they receive a reward, which is usually shared with those who have voted for the witness. If a witness fails to verify all transactions in the given time, the block is missed, all the transactions are left unverified, and the witness is left without a reward. Usually, such transactions are collected in an extra block by the subsequent witness, and such a block is called stolen.<ref>[https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper]</ref>

This consensus mechanism also detects severe discrepancies in the network, for example, separation of its parts due to problems with Internet connection, and protects the network from possible [[double-spending]]. Due to the order of witness work and small timespans allocated to their work, major network outage can be detected in less than a minute. This security mechanism allows building blockchains which support independent side chains, synchronized only when needed, a network of which will support even more transactions and faster block production times.<ref>[https://www.forbes.com/sites/shermanlee/2018/02/07/explaining-side-chains-the-next-breakthrough-in-blockchain/#5185d7f052eb https://www.forbes.com/sites/shermanlee/2018/02/07/explaining-side-chains-the-next-breakthrough-in-blockchain/#5185d7f052eb]</ref>

== Protocol Changes ==

DPoS supports two tiers of changes into protocol. Changes to settings of the current work scheme can be implemented after a voting led by witnesses, and can be deployed on the fly. Changes to the protocol itself have a much complex mechanism to protect the network from jeopardizing. Once a proposal for a change is designed in code, one of the witnesses can propose it for implementation, and sign the changes with a special genesis wallet key. After a two-week audit period, during which any network user can study the proposition, a voting is held. If a quorum is achieved, the network applies the changes automatically, which may create a hard fork.<ref>[https://cryptomaniaks.com/latest-cryptocurrency-news/blockchain/is-dpos-an-improvement-over-pos https://cryptomaniaks.com/latest-cryptocurrency-news/blockchain/is-dpos-an-improvement-over-pos]</ref>

== Advantages ==

# Transaction bandwidth of DPoS blockchain is independent from computing power required to run the network, hence such blockchains are more scalable than PoW, which is used in [[Bitcoin]].
# DPoS requires less financial input from users wishing to partake in block production than standard PoS blockchains, which makes DPoS more democratic and financially inclusive.
# Thanks to the low entry threshold, DPoS provides more decentralization as more people take part in the consensus.
# DPoS doesn’t require lots of power to run the network, which makes it more sustainable.
# DPoS blockchains have good protection from double-spending.

== Disadvantages ==

# Effective operation of the network requires large numbers of interested and well-informed delegators to select suitable witnesses and provide decentralization.
# Limited number of witnesses can lead to centralization of the network.
# DPoS blockchain is susceptible to problems of weighted voting. Users with smaller stake can refuse from taking part in votings after considering that their vote is insignificant.

== History and Use of DPoS ==

DPoS was developed by Daniel Larimer, founder of BitShares, Steemit and EOS. The first implementation of DPoS, BitShared, went live on October 13th, 2015. Currently, DPoS is also used by TRON, [[Tezos]], Cardano, Lisk, Elastos, [[ARK|Ark]], Rise, Credits, Aunite.

== Staking Pools ==

Pooling of stakes is required in the DPoS. There are several companies that provide staking services for multiple blockchains, such as [[Everstake]], [[P2P.org]] and [[Mythos]], and more providers offer stake pooling for one or a few blockchains only.

== References ==
<references />

Staking

2019-09-20T13:25:35Z

ChallengeAccepted: /* Staking Principle */

Staking is the consensus algorithm in [[delegated proof of stake]] coins, which is essentially a process of pooling (delegating) the validation stakes with one wallet, called a staking pool. Like with [[mining]], each delegator gets a share of the rewards, corresponding to their share in the delegate’s staking balance.

== PoS Validation ==

With [[Proof of Stake|proof of stake]] coins, the principle of validation is applied instead of mining. Whereas the possibility of finding a new block in PoW coins depends on the miner’s computing power, in PoS it depends on how many coins the validator is holding. The first coin to introduce PoS validation was [https://en.wikipedia.org/wiki/Peercoin Peercoin].<ref>[https://www.forbes.com/sites/ginaclarke/2018/10/16/proof-of-stake-guru-sunny-king-blockchain-is-easy-we-just-need-to-use-it-like-a-database/#39e83a7e1c04 https://www.forbes.com/sites/ginaclarke/2018/10/16/proof-of-stake-guru-sunny-king-blockchain-is-easy-we-just-need-to-use-it-like-a-database/#39e83a7e1c04]</ref>

Unlike PoW, proof of stake validation doesn’t require large processing power to be allocated for hashing, and requires only large amounts of coins (stakes) to be held on the validator’s wallet. Although PoS doesn’t improve decentralization, it makes the 51% problem insignificant, as collecting 51% of all issued coins is merely impossible on a free market.<ref>[https://www.forbes.com/sites/forbestechcouncil/2019/01/28/proof-of-work-and-proof-of-stake-how-blockchain-reaches-consensus/#4676a25368c8 https://www.forbes.com/sites/forbestechcouncil/2019/01/28/proof-of-work-and-proof-of-stake-how-blockchain-reaches-consensus/#4676a25368c8]</ref>

‘Clean’ PoS allows pooling of resources for validation, however it requires transacting the funds to someone’s wallet and losing control over them, which requires more confidence and trust than in other consensus algorithms. Thus, pooling in PoS is very rare and unusual.<ref>[https://medium.com/the-mission/staking-pools-how-they-work-6fa6f3cbb329 https://medium.com/the-mission/staking-pools-how-they-work-6fa6f3cbb329]</ref>

== Staking Principle ==

Unlike PoS, the delegated proof of stake (DPoS) '''requires''' pooling of resources, but without physically transferring them to another wallet. Usually, pooling is provided by staking service providers, companies that operate [[node|nodes]] built specifically for staking. Each blockchain has its own staking service providers, but several companies exist that provide staking services in multiple blockchains, for example, [[P2P.org]], [[Everstake]] and [[Mythos]].

DPoS was developed in 2014 and first implemented in 2015, by Bitshares,<ref>[https://bitshares.org/technology/delegated-proof-of-stake-consensus/ https://bitshares.org/technology/delegated-proof-of-stake-consensus/]</ref> and is now used by multiple blockchains, with slight differences in the process and terminology.<ref>[https://kryptomoney.com/dpos-coins/ https://kryptomoney.com/dpos-coins/]</ref>

Delegated proof of stake (DPoS) is an extension of PoS distributed consensus. With DPoS, the holders of assets don't validate new blocks. Instead, they delegate their ''stake'' to a block validator of their choice, who and shares the rewards with the delegators (stakers), according to the size of their deposits. The delegates are chosen by combining random selection and staked wealth, like in the PoS blockchains.

The number of validators is voted by network users and varies between 20 and 100. For each period, the network forms a pseudo-random queue of validators, who are given a short time interval (usually one second) to process new transactions and form a new block. If a validator fails to do so, the next one is allowed to take the work and reward for it. For the next period, the validators are sorted randomly again.

== Staking Glossary ==

=== Stake ===

The amount of coins, delegated by a user to the staking balance of a pool. These coins physically remain on the delegator’s wallet, but can’t be sent until they get unstaked.

=== Staking balance ===

Combined balance of all stakes delegated to a staking pool. This balance is used by the consensus algorithm to select top nodes that will be allowed to stake in the next period.

=== Missed block ===

A set of transactions, that a staking pool has failed to verify and confirm in the given time (less than a few seconds). Missed blocks don’t provide rewards to the pool and its delegators.

=== Stolen block ===

A set of transactions, that should have been verified and confirmed by the previous pool, but is verified by the current pool instead. Such a block will generate the usual amount of rewards, but high amount of block steals in a pool signal for fast and up-to-date hardware and good Internet connection.

== References ==
<references />

Comparison of cryptocurrencies

2019-09-19T11:08:25Z

ChallengeAccepted:

The cryptocurrency market is explosive which currently serves hundreds of currencies. Almost all of them are obvious scams—including many which purport to have a large market cap. This article aims to list only the most relevant cryptocurrencies in terms of novel technological advancements or strong engineering teams, or due to widespread awareness thereof. Direct, low-level scams should not be listed here.

{| class="wikitable sortable"
! style="width: 100px;" | Cryptocurrency
! Exchange symbol
! Launched
! Anonymity
! Max supply
! Algorithm
! Proof Type
! Notes
! Website
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] [[Bitcoin]]
| BTC
| 2009-01-03
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| First blockchain.
| [https://bitcoin.org/ bitcoin.org]
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] [[Tonal Bitcoin]]
| TBC
| 2011-01-02
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| First on-chain alternative.
| [[Tonal Bitcoin]]
|-
! {{rh}} | [[File:Bitcoin_Cash.png|16px|link=]] BCH
| BCH
| 2017-08-01
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| An altcoin based on an old snapshot of Bitcoin's blockchain (2017 Aug 1) with replay protection and an increased block size limit of 8MB. An unusual emergency difficulty adjustment algorithm causes significant periods of hyperinflation. Significant miner centralization; often a very low hashrate. Major proponents deliberately attempt to confuse new users into thinking BCH is Bitcoin.
|
|-
! {{rh}} | [[File:Namecoin.png|16px|link=]] Namecoin
| NMC
| 2011-04-18
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256 Merged
| PoW
| First cryptocurrency that implemented Satoshi's BitDNS idea. Essentially the first real altcoin. Still under active development. First merged-mined altcoin.
| [https://namecoin.info/ namecoin.info]
|-
! {{rh}} | [[File:Dash.png|16px|link=]] Dash
| DASH
| 2014-01-18
| {{no|Low}}
| style="text-align: right" | 22,000,000
| X11
| PoW/PoS
| Introduced the X11 algorithm, which is just a composite function of multiple hashing algorithms. Had a significant failure mode in the beginning which equated to a majority premine by a small number of Amazon EC2 customers. This means their Master Node algorithm has been in a failure mode from the beginning.
|
|-
! {{rh}} | [[File:Ethereum_Classic-32x32.png|16px|link=]] Ethereum Classic
| ETC
| 2015-08-07
| {{no|Low}}
| style="text-align: right" | Infinite
| Ethash
| PoW
| Majority premine sale. Used to be known as just "Ethereum" and "ETH" until the Ethereum Foundation split off an altcoin using their trademark.
| [http://www.ethereumclassic.org/ ethereumclassic.org]
|-
! {{rh}} | [[File:Ethereum.png|16px|link=]] Ethereum
| ETH
| 2016-07-20
| {{no|Low}}
| style="text-align: right" | Infinite
| Ethash
| PoW
| An altcoin of Ethereum Classic which split from ETC's blockchain in order to refund the Ethereum Foundation's members' money when the DAO was exploited. Regular hardforks to bail out larger losses by e.g. ETH foundation. Source of the ICO bubbles. Multiple client implementations which fail against each other in terms of consensus errors regularly. Requires multiple months of time to sync to eth blockchain. Contract-building tools interpret input incompatibly.
| [https://ethereum.org ethereum.org ]
|-
! {{rh}} | [[File:Litecoin.png|16px|link=]] Litecoin
| LTC
| 2011-10-07
| {{no|Low}}
| style="text-align: right" | ~84,000,000
| Scrypt
| PoW
| Originally meant to be a CPU-friendly "silver" to Bitcoin's "gold", the early SCRYPT parameters, it was discovered later, led directly to GPU, and then ASIC-mining almost from the start.
| [https://litecoin.org/ litecoin.org]
|-
! {{rh}} | [[File:Monero.png|16px|link=]] Monero
| XMR
| 2014-04-18
| style="background: lightyellow;" | Medium
| ?
| [[CryptoNight]]
| PoW
| The most successful implementation derived from the Cryptonote codedrop. Uses [https://www.ledgerjournal.org/ojs/index.php/ledger/article/view/34 Ring Confidential Transactions].
| [https://getmonero.org/ getmonero.org]
|-
! {{rh}} | [[File:Zcash-16x16.png|16px|link=]] Zcash
| ZEC
| 2016-10-28
| style="background: lightyellow;" | Medium
| style="text-align: right" | ~21,000,000
| Equihash
| PoW
| First cryptocurrency that implemented the zerocash protocol. Large "Founder's Reward" which is paid out over the first few years of mining to people including Roger Ver.
| [https://z.cash/ z.cash]
|-
! {{rh}} | [[File:Zcoin-800x800.png|16px|link=]] Zcoin
| XZC
| 2016-09-28
| style="background: lightyellow;" | Medium
| style="text-align: right" | ~21,000,000
| Lyra2RE
| PoW
| First cryptocurrency that implemented the zerocoin protocol which also makes it the first useful Zero-knowledge proof based anonymous cryptocurrency. First that implements Merkle Tree Proof of Work (MTP).
| [https://zcoin.io/ zcoin.io]
|-
! {{rh}} | [[IOST]]
| IOST
| 2019-02-25
| style="background: lightgreen;" | High
| style="text-align: right" | 21 billion
| N/A
| DPoS
| Voters receive 50% of the rewards earned by nodes with more than 2.1m votes
| [https://iost.io iost.io]
|-
! {{rh}} | [[Cosmos]]
| ATOM
| 2019-03-14
| style="background: lightgreen;" | High
| style="text-align: right" | ~245,000,000
| N/A
| DPoS
| Multi-blockchain network
| [https://cosmos.network cosmos.network]
|-
! {{rh}} | [[Waves]]
| WAVES
| 2016-04-15
| style="background: lightgreen;" | High
| style="text-align: right" | 100,000,000
| N/A
| DPoS
| Oriented on hosting smart contracts
| [https://wavesplatform.com wavesplatform.com]
|-
! {{rh}} | [[Decred]]
| DCR
| 2016-02-08
| style="background: lightgreen;" | High
| style="text-align: right" | 21,000,000
| BLAKE-256
| PoW/DPoS
| Splits rewards between PoW miners and DPoS voters
| [https://decred.org/ decred.org]
|-
! {{rh}} | [[Tezos]]
| XTZ
| 2018-08-30
| style="background: lightgreen;" | High
| style="text-align: right" | ~810,000,000
| N/A
| DPoS
| First platform to implement fork-less decentralized governance
| [https://tezos.com tezos.com]
|-
! {{rh}} | [[IOTEX]]
| IOTX
| 2019-04-15
| style="background: lightgreen;" | High
| style="text-align: right" | 10 billion
| N/A
| DPoS
| Oriented at IoT devices connectivity and data processing
| [https://www.iotex.io www.iotex.io]
|-
! {{rh}} | [[IRISnet]]
| IRIS
| 2019-06-21
| style="background: lightgreen;" | High
| style="text-align: right" | ~2 billion
| N/A
| DPoS
| Integrated into [[Cosmos]] network
| [https://www.irisnet.org irisnet.org]
|-
! {{rh}} | [[QTUM]]
| QTUM
| 2017-10-04
| style="background: lightgreen;" | High
| style="text-align: right" | ~101,000,000
| N/A
| DPoS
| Supports a full x86 virtual machine on blockchain
| [https://qtum.org qtum.org]
|-
! {{rh}} | [[Algorand]]
| ALGO
| TBA
| style="background: lightgreen;" | High
| style="text-align: right" | 10 billion
| N/A
| PoS
| Implements Pure PoS [[consensus]] algorithm
| [https://www.algorand.com algorand.com]
|-
! {{rh}} | [[Harmony]]
| ONE
| 2019-06-28
| style="background: lightgreen;" | High
| style="text-align: right" | 12,6 billion
| N/A
| DPoS
| Multi-[[blockchain]] network able to support digital lives of 10B people
| [https://harmony.one harmony.one]
|-
! {{rh}} | [[EtherZero]]
| ETZ
| 2019-01-19
| style="background: lightgreen;" | High
| style="text-align: right" | 194,000,000
| N/A
| MPoS
| Masternode PoS with self-staking
| [http://etherzero.org/ etherzero.org]
|-
! {{rh}} | [[ICON]]
| ICX
| 2018-01-24
| style="background: lightgreen;" | High
| style="text-align: right" | ~500,000,000
| N/A
| DPoS
|
| [https://icon.foundation icon.foundation]
|-}

[[Category:Alternative cryptocurrencies]]

Mining

2019-09-19T10:11:49Z

ChallengeAccepted:

[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A home-made "[[Mining rig|mining rig]]"]]
== Introduction ==
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "[[Mining rig|mining rig]]" is a colloquial metaphor for a single computer system that performs the necessary computations for "mining".
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].
The blockchain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the blockchain to distinguish legitimate Bitcoin transactions from attempts to re-spend coins that have already been spent elsewhere.

Mining is intentionally designed to be resource-intensive and difficult so that the number of blocks found each day by miners remains steady. Individual [[blocks]] must contain a [[proof of work|proof of work]] to be considered valid. This proof of work is verified by other Bitcoin nodes each time they receive a block. Bitcoin uses the [[hashcash]] proof-of-work function.

The primary purpose of mining is to set the history of [[transactions]] in a way that is [[Irreversible Transactions|computationally impractical to modify by any one entity]]. By downloading and verifying the blockchain, bitcoin [[full node|nodes]] are able to reach consensus about the ordering of events in bitcoin.

Mining is also the mechanism used to [[Controlled supply|introduce Bitcoins]] into the system:
Miners are paid any [[transaction fees]] as well as a "subsidy" of newly created coins.
This both serves the purpose of disseminating new coins in a decentralized manner as well as motivating people to provide security for the system.

Bitcoin mining is so called because it resembles the mining of other commodities:
it requires exertion and it slowly makes new units available to anybody who wishes to take part. An important difference is that the [[Controlled supply|supply]] does not depend on the amount of mining. In general changing total miner hashpower does not change how many bitcoins are created over the long term.

== Difficulty ==
=== The Computationally-Difficult Problem ===
Mining a block is difficult because the SHA-256 hash of a block's header must be lower than or equal to the [[Target|target]] in order for the block to be accepted by the network. This problem can be simplified for explanation purposes: The hash of a block must start with a certain number of zeros. The probability of calculating a hash that starts with many zeros is very low, therefore many attempts must be made. In order to generate a new hash each round, a [[Nonce|nonce]] is incremented. See [[Proof of work]] for more information.

=== The Difficulty Metric ===
The [[Difficulty|difficulty]] is the measure of how difficult it is to find a new block compared to the easiest it can ever be. The rate is recalculated every 2,016 blocks to a value such that the previous 2,016 blocks would have been generated in exactly one fortnight (two weeks) had everyone been mining at this difficulty. This is expected yield, on average, one block every ten minutes.

As more miners join, the rate of block creation increases. As the rate of block generation increases, the difficulty rises to compensate, which has a balancing of effect due to reducing the rate of block-creation. Any blocks released by malicious miners that do not meet the required [[Target|difficulty target]] will simply be rejected by the other participants in the network.

=== Reward ===
When a block is discovered, the discoverer may award themselves a certain number of bitcoins, which is agreed-upon by everyone in the network. Currently this bounty is 12.5 bitcoins; this value will halve every 210,000 blocks. See [[Controlled Currency Supply]].

Additionally, the miner is awarded the fees paid by users sending transactions. The fee is an incentive for the miner to include the transaction in their block. In the future, as the number of new bitcoins miners are allowed to create in each block dwindles, the fees will make up a much more important percentage of mining income.

== The mining ecosystem ==

=== Hardware ===
[[File:Usb-fpga module 1.15x-hs-800.jpg|thumb|right|FPGA Module]]
Users have used various types of hardware over time to mine blocks. Hardware specifications and performance statistics are detailed on the [[Mining Hardware Comparison]] page.
==== CPU Mining ====
Early Bitcoin client versions allowed users to use their CPUs to mine. The advent of GPU mining made CPU mining financially unwise as the hashrate of the network grew to such a degree that the amount of bitcoins produced by CPU mining became lower than the cost of power to operate a CPU. The option was therefore removed from the core Bitcoin client's user interface.

==== GPU Mining ====
GPU Mining is drastically faster and more efficient than CPU mining. See the main article: [[Why a GPU mines faster than a CPU]]. A variety of popular [[Mining rig|mining rigs]] have been documented.
==== FPGA Mining ====
FPGA mining is a very efficient and fast way to mine, comparable to GPU mining and drastically outperforming CPU mining. FPGAs typically consume very small amounts of power with relatively high hash ratings, making them more viable and efficient than GPU mining. See [[Mining Hardware Comparison]] for FPGA hardware specifications and statistics.
==== ASIC Mining ====
An application-specific integrated circuit, or ''ASIC'', is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly faster than all previous technologies and already have made GPU mining financially.

==== Mining services (Cloud mining) ====
[[:Category:Mining_contractors|Mining contractors]] provide mining services with performance specified by contract, often referred to as a "Mining Contract." They may, for example, rent out a specific level of mining capacity for a set price at a specific duration.

=== Pools ===
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. This made mining something of a gamble. To address the variance in their income miners started organizing themselves into [[Pooled mining|pools]] so that they could share rewards more evenly. See [[Pooled mining]] and [[Comparison of mining pools]].

=== History ===
Bitcoin's public ledger (the "block chain") was started on January 3rd, 2009 at 18:15 UTC presumably by [[Satoshi Nakamoto]]. The first block is known as the [[genesis block]]. The first transaction recorded in the first block was a single transaction paying the reward of 50 new bitcoins to its creator.

== Staking ==

Staking is a concept in the [[Delegated proof of stake]] coins, closely resembling pooled mining of proof of work coins. According to the [[Proof of Stake|proof of share]] principle, instead of computing powers, the partaking users are pooling their ''stakes'', certain amounts of money, blocked on their wallets and delegated to the pool’s staking balance.

The network periodically selects a pre-defined number of top staking pools (usually between 20 and 100), based on their staking balances, and allows them to validate transactions in order to get a reward. The rewards are then shared with the delegators, according to their stakes with the pool.

Although staking doesn’t require lots of computing power as mining, it still needs very stable and fast Internet connection in order to collect, verify and sign all transactions in the queue within a small timespan, which can be as short as one second. If a pool fails to do so, it doesn’t get the reward, and it may be shared with the next pool in order.

==See Also==

* [https://99bitcoins.com/beginners-guide-to-mining/ Beginner's Guide to Bitcoin Mining]
* [https://www.zpool.ca Bitcoin Multipool]
* [https://www.bitcoinmining.com Bitcoin Mining]
* [http://codinginmysleep.com/bitcoin-mining-in-plain-english Bitcoin Mining in Plain English] by David Perry
* [https://www.weusecoins.com/en/mining-guide/ Getting Started With Bitcoin Mining]
* [[Automatically mine when computer is locked|Tutorial to automatically start mining when you lock your computer]]. (Windows 7)
* [http://bitcoinminer.com Bitcoin Miner]
* [http://www.bitcongress.org/bitcoin/best-bitcoin-mining-hardware/ Bitcoin Mining Hardware Comparison]
* [http://www.reddit.com/r/Bitcoin/comments/18q2jx/eli5_bitcoin_mining_xpost_in_eli5/ Simplified Explanation of Bitcoin Mining] by reddit user [http://www.reddit.com/user/azotic azotic]
* [https://bitcoinchain.com/pools Bitcoin Mining Pools Comparison]
* [http://www.bitcoinmining.com/best-bitcoin-cloud-mining-contract-reviews/ Research, Review and Compare Cloud Mining Contracts]
* [https://www.youtube.com/watch?v=GmOzih6I1zs Video: What is Bitcoin Mining?]
* [http://yogh.io/#mine:last Mining Simulator] ([https://github.com/JornC/bitcoin-transaction-explorer GitHub source])
* [http://bitcoindaily.org/bitcoin-guides/what-is-bitcoin-mining/ Bitcoin Mining Explained]
[[ru:Mining]]
[[Category:Mining]][[Category:Vocabulary]]

Delegated proof of stake

2019-09-19T08:51:05Z

ChallengeAccepted: /* History and Use of DPoS */

Delegated proof of stake

2019-09-19T08:50:38Z

ChallengeAccepted: Created page with "Delegated proof of stake is a consensus protocol, which provides dependable verification and approval of transactions in a blockchain. Being an extensi..."

Delegated proof of stake is a [[consensus]] protocol, which provides dependable verification and approval of [[Transaction|transactions]] in a [[blockchain]]. Being an extension of the [[Proof of Stake|proof of stake]] protocol, DPoS allows blockchains to change network parameters, such as fee schedules, block intervals, transaction sizes, on the fly, without creating a [[Hardfork|hard fork]], if the elected delegates vote for such a change.<ref>[https://bitshares.org/technology/delegated-proof-of-stake-consensus/ https://bitshares.org/technology/delegated-proof-of-stake-consensus/]</ref>

Deterministic selection of block producers allow DPoS blockchains to confirm transactions in as fast as 1 second.

== Block Production ==

Under DPoS, network users elect witnesses, or delegates, to generate blocks. A [[block]] is a group of transactions containing a set of updates to the state of the distributed ledger. Each network user (i.e. a wallet) is allowed to certify their trust in one of the witnesses, who will be validating transactions and generating blocks with them. A certain amount of witnesses is selected by the network to obtain enough decentralization. Usually this amount is determined by voting and is between 20 and 100 for the most DPoS blockchains.<ref>[https://medium.com/loom-network/understanding-blockchain-fundamentals-part-3-delegated-proof-of-stake-b385a6b92ef https://medium.com/loom-network/understanding-blockchain-fundamentals-part-3-delegated-proof-of-stake-b385a6b92ef]</ref>

The selected witnesses are allowed to produce blocks by verifying all transactions collected for the last block time (usually around few seconds), in the order of their selection. If they verify and sign all the transactions in a block, they receive a reward, which is usually shared with those who have voted for the witness. If a witness fails to verify all transactions in the given time, the block is missed, all the transactions are left unverified, and the witness is left without a reward. Usually, such transactions are collected in an extra block by the subsequent witness, and such a block is called stolen.<ref>[https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper]</ref>

This consensus mechanism also detects severe discrepancies in the network, for example, separation of its parts due to problems with Internet connection, and protects the network from possible [[double-spending]]. Due to the order of witness work and small timespans allocated to their work, major network outage can be detected in less than a minute. This security mechanism allows building blockchains which support independent side chains, synchronized only when needed, a network of which will support even more transactions and faster block production times.<ref>[https://www.forbes.com/sites/shermanlee/2018/02/07/explaining-side-chains-the-next-breakthrough-in-blockchain/#5185d7f052eb https://www.forbes.com/sites/shermanlee/2018/02/07/explaining-side-chains-the-next-breakthrough-in-blockchain/#5185d7f052eb]</ref>

== Protocol Changes ==

DPoS supports two tiers of changes into protocol. Changes to settings of the current work scheme can be implemented after a voting led by witnesses, and can be deployed on the fly. Changes to the protocol itself have a much complex mechanism to protect the network from jeopardizing. Once a proposal for a change is designed in code, one of the witnesses can propose it for implementation, and sign the changes with a special genesis wallet key. After a two-week audit period, during which any network user can study the proposition, a voting is held. If a quorum is achieved, the network applies the changes automatically, which may create a hard fork.<ref>[https://cryptomaniaks.com/latest-cryptocurrency-news/blockchain/is-dpos-an-improvement-over-pos https://cryptomaniaks.com/latest-cryptocurrency-news/blockchain/is-dpos-an-improvement-over-pos]</ref>

== Advantages ==

# Transaction bandwidth of DPoS blockchain is independent from computing power required to run the network, hence such blockchains are more scalable than PoW, which is used in [[Bitcoin]].
# DPoS requires less financial input from users wishing to partake in block production than standard PoS blockchains, which makes DPoS more democratic and financially inclusive.
# Thanks to the low entry threshold, DPoS provides more decentralization as more people take part in the consensus.
# DPoS doesn’t require lots of power to run the network, which makes it more sustainable.
# DPoS blockchains have good protection from double-spending.

== Disadvantages ==

# Effective operation of the network requires large numbers of interested and well-informed delegators to select suitable witnesses and provide decentralization.
# Limited number of witnesses can lead to centralization of the network.
# DPoS blockchain is susceptible to problems of weighted voting. Users with smaller stake can refuse from taking part in votings after considering that their vote is insignificant.

== History and Use of DPoS ==

DPoS was developed by Daniel Larimer, founder of BitShares, Steemit and EOS. The first implementation of DPoS, BitShared, went live on October 13th, 2015. Currently, DPoS is also used by TRON, Tezos, Cardano, Lisk, Elastos, Ark, Rise, Credits, Aunite.

== References ==
<references />

Staking

2019-09-13T12:07:58Z

ChallengeAccepted: Created page with "Staking is the consensus algorithm in delegated proof of stake coins, which is essentially a process of pooling (delegating) the validation stakes with one wallet, called..."

Staking is the consensus algorithm in [[delegated proof of stake]] coins, which is essentially a process of pooling (delegating) the validation stakes with one wallet, called a staking pool. Like with [[mining]], each delegator gets a share of the rewards, corresponding to their share in the delegate’s staking balance.

== PoS Validation ==

With [[Proof of Stake|proof of stake]] coins, the principle of validation is applied instead of mining. Whereas the possibility of finding a new block in PoW coins depends on the miner’s computing power, in PoS it depends on how many coins the validator is holding. The first coin to introduce PoS validation was [https://en.wikipedia.org/wiki/Peercoin Peercoin].<ref>[https://www.forbes.com/sites/ginaclarke/2018/10/16/proof-of-stake-guru-sunny-king-blockchain-is-easy-we-just-need-to-use-it-like-a-database/#39e83a7e1c04 https://www.forbes.com/sites/ginaclarke/2018/10/16/proof-of-stake-guru-sunny-king-blockchain-is-easy-we-just-need-to-use-it-like-a-database/#39e83a7e1c04]</ref>

Unlike PoW, proof of stake validation doesn’t require large processing power to be allocated for hashing, and requires only large amounts of coins (stakes) to be held on the validator’s wallet. Although PoS doesn’t improve decentralization, it makes the 51% problem insignificant, as collecting 51% of all issued coins is merely impossible on a free market.<ref>[https://www.forbes.com/sites/forbestechcouncil/2019/01/28/proof-of-work-and-proof-of-stake-how-blockchain-reaches-consensus/#4676a25368c8 https://www.forbes.com/sites/forbestechcouncil/2019/01/28/proof-of-work-and-proof-of-stake-how-blockchain-reaches-consensus/#4676a25368c8]</ref>

‘Clean’ PoS allows pooling of resources for validation, however it requires transacting the funds to someone’s wallet and losing control over them, which requires more confidence and trust than in other consensus algorithms. Thus, pooling in PoS is very rare and unusual.<ref>[https://medium.com/the-mission/staking-pools-how-they-work-6fa6f3cbb329 https://medium.com/the-mission/staking-pools-how-they-work-6fa6f3cbb329]</ref>

== Staking Principle ==

Unlike PoS, the delegated proof of stake (DPoS) '''requires''' pooling of resources, but without physically transferring them to another wallet.

DPoS was developed in 2014 and first implemented in 2015, by Bitshares,<ref>[https://bitshares.org/technology/delegated-proof-of-stake-consensus/ https://bitshares.org/technology/delegated-proof-of-stake-consensus/]</ref> and is now used by multiple blockchains, with slight differences in the process and terminology.<ref>[https://kryptomoney.com/dpos-coins/ https://kryptomoney.com/dpos-coins/]</ref>

Delegated proof of stake (DPoS) is an extension of PoS distributed consensus. With DPoS, the holders of assets don't validate new blocks. Instead, they delegate their ''stake'' to a block validator of their choice, who and shares the rewards with the delegators (stakers), according to the size of their deposits. The delegates are chosen by combining random selection and staked wealth, like in the PoS blockchains.

The number of validators is voted by network users and varies between 20 and 100. For each period, the network forms a pseudo-random queue of validators, who are given a short time interval (usually one second) to process new transactions and form a new block. If a validator fails to do so, the next one is allowed to take the work and reward for it. For the next period, the validators are sorted randomly again.

== Staking Glossary ==

=== Stake ===

The amount of coins, delegated by a user to the staking balance of a pool. These coins physically remain on the delegator’s wallet, but can’t be sent until they get unstaked.

=== Staking balance ===

Combined balance of all stakes delegated to a staking pool. This balance is used by the consensus algorithm to select top nodes that will be allowed to stake in the next period.

=== Missed block ===

A set of transactions, that a staking pool has failed to verify and confirm in the given time (less than a few seconds). Missed blocks don’t provide rewards to the pool and its delegators.

=== Stolen block ===

A set of transactions, that should have been verified and confirmed by the previous pool, but is verified by the current pool instead. Such a block will generate the usual amount of rewards, but high amount of block steals in a pool signal for fast and up-to-date hardware and good Internet connection.

== References ==
<references />