Proof of stake bitcoin miner
These voluntary signatures can be inserted into any block within the next 6 blocks as special txns. These txns do not require fees. Block pairs that lose this race are orphaned. 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: The numbers are so favorable that consideration of exact statistics is not particularly interesting. 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. 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.
An attacker who mines publicly could simply produce empty PoW blocks. However, this would fail to deny service. The attacker cannot force the PoS miners to produce empty blocks. Therefore he cannot deny service regardless of how much hash rate he controls. 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.
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. 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.
This is costly for them. This means that the incentives to remain increase dramatically as participation falls. This is equal to an annual of return of 2. The alternative, inactivity, yields an annual return of I consider this a reasonable incentive level and participation rate.
This is a very strong incentive and is almost certain to be sufficient, even if nodes are quite costly to maintain. 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. 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 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. Coin-age is updated as follows. 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. The most burdensome fee in the system is the fee paid to PoW miners. 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. 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.
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. One block every 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 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. 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:.
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.
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.
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. 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. 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. 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.
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 [1] 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. Retrieved from " https: Navigation menu Personal tools Create account Log in.
Views Read View source View history. Sister projects Essays Source. This page was last edited on 10 November , at Incentives also differ between the two systems of block generation. Under proof of work, miners may potentially own none of the currency they are mining and thus seek only to maximize their own profits. It is unclear whether this disparity lowers or raises security risks. Some authors [12] [13] argue that proof of stake is not an ideal option for a distributed consensus protocol.
One issue that can arise is the "nothing-at-stake" problem, wherein block generators have nothing to lose by voting for multiple blockchain histories, thereby preventing consensus from being achieved. Because unlike in proof-of-work systems, there is little cost to working on several chains. Statistical simulations have shown that simultaneous forging on several chains is possible, even profitable. But proof of stake advocates believe that most described attack scenarios are impossible or so unpredictable as to be only theoretical.
From Wikipedia, the free encyclopedia. This article may rely excessively on sources too closely associated with the subject , potentially preventing the article from being verifiable and neutral. Please help improve it by replacing them with more appropriate citations to reliable, independent, third-party sources.
August Learn how and when to remove this template message. Archived from the original on 3 February Retrieved 2 January Retrieved 22 December Retrieved 29 December Retrieved 21 December Retrieved 3 January A Punitive Proof-of-Stake Algorithm". Retrieved 23 January Ethash is the planned PoW algorithm for Ethereum 1.
Retrieved Jan 19, Cryptocurrencies without Proof of Work.