the very point of dpos is to centralize for the purpose of specialization, which allows for faster block times and confirmations and also allows for scalability on the level of visa's 10,000 tps payment processor. the system is still decentralized in that there is no one point of failure and there is no one point of control. delegates have a simple job and can be fired on command if they do not perform their duties. consensus on a whole is reach by each individual stake holder, whereas in pow only hashing shares contribute to network consensus.
What makes you so technically qualified?
Topic: Delegated Proof of Stake (DPOS) White Paper by Daniel Larimer - page 4. (Read 11482 times)
It is time to squash Proof-of-Stake once and for all. It can NEVER remain decentralized. Satoshi's Proof-of-Work is the only known solution to the Byzantine General's Problem (was a known unsolved problem since at least the 1970s).
Apologies I've been busy and hadn't had time to squash bytemaster's latest N.A.O.D. (nonsense algorithm of the day).
First of all, he never was able to address the issues I raised about Transactions as Proof-of-Stake quoted as follows.
The bottom line is that no proof-of-stake system can ever remain decentralized.
They all will require some sort of delegation of reputation to achieve consensus. I would have to go through a laundry list of examples to cover all the cases. For example, in Transactions as Proof-of-Stake it is required to delegate trust of propagation to the other nodes as I explained above. Thus there needs to be some reputation system to enforce this, e.g. blacklisting, whitelisting, etc.. All the other proof-of-stake systems have a requirement for some form of delegated reputation.
I have many times explained to bytemaster and others the fundamental problem is that any system that attempts to replace proof-of-work will rely on some form of reputation, and reputation is centralization. And centralization is precisely what decentralized crypto-currency is not supposed to be because centralization will always end up control and manipulated (i.e. it is a fiat system).
(In any non-Proof-of-Work design, ) It is mathematically impossible for there to be external consensus trust of the honest chain if the dishonest chain is controlled by more than 51% of the peers. We've covered some of the scenarios upthread, and it always boils down to that the external viewers can not know who to trust except by trusting the majority of peers.
The only mathematical way around this is to centralize the network, by placing more trust in some peers than others over time.
Indeed long-term reputation is a mathematically viable alternative to Proof-of-Work. This is centralization. There are tradeoffs.
So this is not "7 billion individually watching the network", but rather a fewer # of peers with reputation being trusted. This is just the political power vacuum all over again with its contingent problems of vested interests Olsen power scramble:
https://bitcointalksearch.org/topic/no-money-exists-without-the-majority-226033 (No Money Exists Without the Majority)
Notwithstanding the above, any non-Proof-of-Work system can be attacked with much less than 51% of the peers, due to the fact that the input entropy is preimageable, as I explained upthread. Again the only way to work around this is to trust some established peers to guard against this.
The only way you can prove a pool isn't cheating is by estimating the hash rate of the pool and comparing it to the number of blocks found. Unfortunately, you could probably still skim a couple of a percent this way.
Modern protocols (GBT & Stratum) both have the full coinbase transaction visible to the miners, meaning you can verify that the block being built will be paid to a certain address or has a certain message encoded in the block that identifies the pool. This allows you to audit if the pool is trying to skim blocks if certain users start seeing work without a coinbase message that identifies the pool. In the case of BTC Guild, it's both, they always pay to the same address and always include "Mined by BTC Guild" in the coinbase message.
It's not no-trust, but all it would take is a few % of users monitoring this to determine if a pool was trying to skim blocks by sending a certain % of work that doesn't include identifying marks.
How could anything less than 100% of the pool miners know if some of the coinbase transactions were to addresses not owned by pool miners who contributed shares?
Since you can never know if you are the 100% (because mining pool shares* are not recorded in the block chain), thus seems to me there is no way to verify if there is skimming or not, as bytemaster and I wrote.
*For those who don't know the terminology, a pool share is a proof-of-work hash below some threshold that is easier than the current network difficulty. It might also be a block solution.
I was waiting for bytemaster to answer because I wanted to know his thoughts. Seems to me that you have no way to stop the Share Withholding Attack since it is decentralized. And every peer has to run more of a full client if I am not mistake. And there is a lot more overhead I believe. And perhaps also much less resistance against denial-of-service flooding. Frankly I didn't analyze for long enough to be very sure of my initial intuition which is to stay away from it.
I know it is generally impossible to enforce reputation on a 100% decentralized system. So I am intuitively skeptical of P2Pool.
P.S. I won't have time to go back here and debate. I am technically qualified and I am 100% sure I am correct.
Apologies I've been busy and hadn't had time to squash bytemaster's latest N.A.O.D. (nonsense algorithm of the day).
First of all, he never was able to address the issues I raised about Transactions as Proof-of-Stake quoted as follows.
This proposal appears to be flawed, unless I am missing something. I have only read the first 4 pages thus far.
1. You propose to decrease the coin rewards as coin-days-destroyed volume increases, so this makes it less costly for an attacker to obtain > 50% of the hash rate assuming the attacker includes all the transactions. You apparently are attempting to imply there is no useful attack to do if the attacker is including the most coin-days-destroyed? Please confirm or deny then I will dig into more analysis of this vector.
2. Also how do you choose between someone who generates a proof-of-work hash with lower coin-days-destroyed several times sooner than the network propagation delay versus another who generates it that much delayed with a higher coin-days-destroyed? If you choose the latter, then you've killed the proof-of-work incentive because it means it will always pay to be later and wait for more transactions to arrive.
3. You claim to defeat my Transactions Withholding Attack, by blacklisting those who send blocks with transactions that were not recently seen by all miners. I retorted against this recently. This centralizes the network (all for one and one for all outcome) by requiring every miner to be responsible for the incoming network connectivity of other miners. And it centralizes the network in other ways, such it can't tolerate a temporary partitioning of the network due to connectivity outages.
P.S. By coin-days-destroyed, I assume you mean coin value x days, otherwise you would motivate proliferation of dust.
1. You propose to decrease the coin rewards as coin-days-destroyed volume increases, so this makes it less costly for an attacker to obtain > 50% of the hash rate assuming the attacker includes all the transactions. You apparently are attempting to imply there is no useful attack to do if the attacker is including the most coin-days-destroyed? Please confirm or deny then I will dig into more analysis of this vector.
2. Also how do you choose between someone who generates a proof-of-work hash with lower coin-days-destroyed several times sooner than the network propagation delay versus another who generates it that much delayed with a higher coin-days-destroyed? If you choose the latter, then you've killed the proof-of-work incentive because it means it will always pay to be later and wait for more transactions to arrive.
3. You claim to defeat my Transactions Withholding Attack, by blacklisting those who send blocks with transactions that were not recently seen by all miners. I retorted against this recently. This centralizes the network (all for one and one for all outcome) by requiring every miner to be responsible for the incoming network connectivity of other miners. And it centralizes the network in other ways, such it can't tolerate a temporary partitioning of the network due to connectivity outages.
P.S. By coin-days-destroyed, I assume you mean coin value x days, otherwise you would motivate proliferation of dust.
The most significant flaw of any proof-of-stake system and any system that diminishes coin rewards, is it can't distribute currency from the hoarders to the users of the currency, thus it will end up with the hoarders (the banksters) accumulating all the coin and the currency usage dying.
This is because the wealthy spend a much lower % of their net worth than the masses do.
[snip]
Whereas those who actually mine are proactively using their time, ingenuity, initiative and capital to secure the network, thus it seems more capitalistic they should receive the redistribution from the hoarders. Besides itmay beis the only viableplausible way to secure the public ledger.
This is because the wealthy spend a much lower % of their net worth than the masses do.
[snip]
Whereas those who actually mine are proactively using their time, ingenuity, initiative and capital to secure the network, thus it seems more capitalistic they should receive the redistribution from the hoarders. Besides it
The other attacks you describe all derive from the fundamental reason I declared all non-proof-of-work systems to be insecure back in April.
My logic was mathematically fundamental. The input entropy set is quite deterministic and well known and thus can be preimaged. For example, accumulating a lot of coin-days-destroyed and then targeting them in clever ways to subvert the security.
The randomness (entropy) of each proof-of-work is fundamental and mathematical and it can not be preimaged. It can only be surely defeated with > 50% of the network hash rate. Note I recently offered what I believe to a solution to the selfish-mining attack (the one at hackingdistributed.com that claims 25 - 35% attack).
I am skeptical that you can characterize all possible attack vectors of proof-of-stake in one coherent mathematical proof. Thus you will not know formally what the security is; instead a list of adhoc attacks and counter-measures.
[snip]
Edit: Perhaps coin-days-destroyed in some attack vectors motivates not transacting for long periods of time.
My logic was mathematically fundamental. The input entropy set is quite deterministic and well known and thus can be preimaged. For example, accumulating a lot of coin-days-destroyed and then targeting them in clever ways to subvert the security.
The randomness (entropy) of each proof-of-work is fundamental and mathematical and it can not be preimaged. It can only be surely defeated with > 50% of the network hash rate. Note I recently offered what I believe to a solution to the selfish-mining attack (the one at hackingdistributed.com that claims 25 - 35% attack).
I am skeptical that you can characterize all possible attack vectors of proof-of-stake in one coherent mathematical proof. Thus you will not know formally what the security is; instead a list of adhoc attacks and counter-measures.
[snip]
Edit: Perhaps coin-days-destroyed in some attack vectors motivates not transacting for long periods of time.
The bottom line is that no proof-of-stake system can ever remain decentralized.
They all will require some sort of delegation of reputation to achieve consensus. I would have to go through a laundry list of examples to cover all the cases. For example, in Transactions as Proof-of-Stake it is required to delegate trust of propagation to the other nodes as I explained above. Thus there needs to be some reputation system to enforce this, e.g. blacklisting, whitelisting, etc.. All the other proof-of-stake systems have a requirement for some form of delegated reputation.
I have many times explained to bytemaster and others the fundamental problem is that any system that attempts to replace proof-of-work will rely on some form of reputation, and reputation is centralization. And centralization is precisely what decentralized crypto-currency is not supposed to be because centralization will always end up control and manipulated (i.e. it is a fiat system).
Trust is orthogonal to reputation and centralization. I can trust Proof-of-Work, which is decentralized trust without reputation. Reputation isn't needed in Proof-of-Work, because the input entropy is fresh (can't be preimaged) on every new TB.
You can 75% attack it if you like, but your nodes wont have any trust, so that block chain will just be ignored.
(In any non-Proof-of-Work design, ) It is mathematically impossible for there to be external consensus trust of the honest chain if the dishonest chain is controlled by more than 51% of the peers. We've covered some of the scenarios upthread, and it always boils down to that the external viewers can not know who to trust except by trusting the majority of peers.
The only mathematical way around this is to centralize the network, by placing more trust in some peers than others over time.
Indeed long-term reputation is a mathematically viable alternative to Proof-of-Work. This is centralization. There are tradeoffs.
So this is not "7 billion individually watching the network", but rather a fewer # of peers with reputation being trusted. This is just the political power vacuum all over again with its contingent problems of vested interests Olsen power scramble:
https://bitcointalksearch.org/topic/no-money-exists-without-the-majority-226033 (No Money Exists Without the Majority)
Notwithstanding the above, any non-Proof-of-Work system can be attacked with much less than 51% of the peers, due to the fact that the input entropy is preimageable, as I explained upthread. Again the only way to work around this is to trust some established peers to guard against this.
Financial transactions must be recorded in a public or private ledger trusted by both the spender and the recipient, otherwise funds could be unspent or double-spent to a plurality of recipients. To provide a ledger that can't be captured, Satoshi described a proof-of-work (PoW) scheme where transaction peers communicating over the network compete to be the first to solve a computational puzzle which is unique for each block of transactions added to a public ledger. The security of this ledger against double-spends has three (3) essential requirements.
1. The computational puzzle can't be preimaged, i.e. nothing can be known about solving the puzzle until the prior block's puzzle is solved.
2. Without at least 50% of the aggregate computational power of all transaction peers, it is not possible to create a modified chain of blocks starting from any present or past block, which would contain more blocks than the block chain controlled by the remaining cooperating peers. Thus the longer chain is trusted.
3. The block chain is cryptographically linked in forward order, such that the historical proof-of-work and transactions can be independently verified at any time in the future. Thus the transaction peers may leave and rejoin the network at will without need for a trusted centralized storage.
Note security point #1 eliminates from consideration PoW schemes in which the puzzle is some real-world computational work because the puzzles are known a priori and are thus pre-imageable. Non-PoW voting and membership schemes disqualify because the ordering of designation of authority (to decide which transactions are in each block) to transaction peers is pre-imageable, or requires peers trusted by reputation which is centralizing on a slippery slope towards Olsen capture.
1. The computational puzzle can't be preimaged, i.e. nothing can be known about solving the puzzle until the prior block's puzzle is solved.
2. Without at least 50% of the aggregate computational power of all transaction peers, it is not possible to create a modified chain of blocks starting from any present or past block, which would contain more blocks than the block chain controlled by the remaining cooperating peers. Thus the longer chain is trusted.
3. The block chain is cryptographically linked in forward order, such that the historical proof-of-work and transactions can be independently verified at any time in the future. Thus the transaction peers may leave and rejoin the network at will without need for a trusted centralized storage.
Note security point #1 eliminates from consideration PoW schemes in which the puzzle is some real-world computational work because the puzzles are known a priori and are thus pre-imageable. Non-PoW voting and membership schemes disqualify because the ordering of designation of authority (to decide which transactions are in each block) to transaction peers is pre-imageable, or requires peers trusted by reputation which is centralizing on a slippery slope towards Olsen capture.
You must also consider the negative impacts of design features when you state the positive impacts.
Reputation has many downsides:
a. It can be stolen, e.g. threaten first to extort private key, then kill, and keep key.
b. Censorship based on metadata which doesn't always correlate rationally.
c. Discriminate against early adopters out of jealously, i.e. retribution for #b.
d. Regulatory authorities can require the BitName same as they now do Social Security # and Id. They can now establish the BitName is real, because it has (duration) reputation.
The high cost to transfer or revoke a name also has many downsides, e.g. see #d.
Reputation has many downsides:
a. It can be stolen, e.g. threaten first to extort private key, then kill, and keep key.
b. Censorship based on metadata which doesn't always correlate rationally.
c. Discriminate against early adopters out of jealously, i.e. retribution for #b.
d. Regulatory authorities can require the BitName same as they now do Social Security # and Id. They can now establish the BitName is real, because it has (duration) reputation.
The high cost to transfer or revoke a name also has many downsides, e.g. see #d.
I thinking the pool operator (server) does so little relative to work of the pool miners that it doesn't need to charge a very high fee. Thus there isn't much ability (incentive for pool miners) to undercut competitors based on fee.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
So there just needs to be a slightest incentive to encourage pool miners to seek out another pool as a pool grows large. This will encourage a poliferation of pools.
How do pool miners know that a pool server isn't cheating them by paying some of the earnings to themselves pretending to be a pool miner?
Go down that line of thought and you will discover what I am thinking.
The only way you can prove a pool isn't cheating is by estimating the hash rate of the pool and comparing it to the number of blocks found. Unfortunately, you could probably still skim a couple of a percent this way.
Modern protocols (GBT & Stratum) both have the full coinbase transaction visible to the miners, meaning you can verify that the block being built will be paid to a certain address or has a certain message encoded in the block that identifies the pool. This allows you to audit if the pool is trying to skim blocks if certain users start seeing work without a coinbase message that identifies the pool. In the case of BTC Guild, it's both, they always pay to the same address and always include "Mined by BTC Guild" in the coinbase message.
It's not no-trust, but all it would take is a few % of users monitoring this to determine if a pool was trying to skim blocks by sending a certain % of work that doesn't include identifying marks.
How could anything less than 100% of the pool miners know if some of the coinbase transactions were to addresses not owned by pool miners who contributed shares?
Since you can never know if you are the 100% (because mining pool shares* are not recorded in the block chain), thus seems to me there is no way to verify if there is skimming or not, as bytemaster and I wrote.
*For those who don't know the terminology, a pool share is a proof-of-work hash below some threshold that is easier than the current network difficulty. It might also be a block solution.
Why don't you just use P2Pool? Is there any reason?
I was waiting for bytemaster to answer because I wanted to know his thoughts. Seems to me that you have no way to stop the Share Withholding Attack since it is decentralized. And every peer has to run more of a full client if I am not mistake. And there is a lot more overhead I believe. And perhaps also much less resistance against denial-of-service flooding. Frankly I didn't analyze for long enough to be very sure of my initial intuition which is to stay away from it.
I know it is generally impossible to enforce reputation on a 100% decentralized system. So I am intuitively skeptical of P2Pool.
P.S. I won't have time to go back here and debate. I am technically qualified and I am 100% sure I am correct.
Interesting stuff. I wish the altcoin forum structure would be such that good posts are highlighted.
How does this approach tie in with the following statement?
How does this approach tie in with the following statement?
Quote
The future of currency is not shares in decentralized companies such as Bitcoin, but instead in assets issued by these companies that have the price stability of the dollar, gold, or silver.
right now we are using shares in a decentralized company as currency because they are a good medium of exchange simply by virtue of their digital nature. the point of bitcoin (the network) is to provide a better a currency, so shouldn't these decentralized companies do just that? currencies that are not beholden to inflation or price instability. essentially they are financial instruments of the clients choosing. this is what bitshares x (the decentralized autonomous bank and exchange) allows. individuals can use this bank to acquire assets that maintain the purchasing power of any asset that you can think of. the bank holds at least 200% reserve for all the debt that it issues, so there is no possibility of default. everything within the system is collateralized and accounted for with the bank's shares. as the banks market cap increases it can issue more debt, but it can only do so in accordance with rule that debt can only be issued with 200% collateralization.
Interesting stuff. I wish the altcoin forum structure would be such that good posts are highlighted.
How does this approach tie in with the following statement?
How does this approach tie in with the following statement?
Quote
The future of currency is not shares in decentralized companies such as Bitcoin, but instead in assets issued by these companies that have the price stability of the dollar, gold, or silver.
Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
I quoted you on the bitsharestalk forum and Daniel "bytemaster" Larimer and delulo replied,
From bitcointalk, https://bitcointalksearch.org/topic/m.6086884
Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Nothing prevents Ripple from doing this..
The difference is: It wouldn't make much of a difference towards the current state of ripple because they control more than 50% of the money supply anyway... The more distributed BTS are the more decentralized it is!!
Inside Ripple the 90% are divided among many players..... so it may still be of some use to them... especially if they ever want to sell.
Good point. But the potential for collusion is still higher than with BTS shareholders...
Join the discussion here https://bitsharestalk.org/index.php?topic=4009.0
A paper justifying a 100% premine. Honestly?
You didnt read it. This is not about coin distribution but about payment verification.
Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
A paper justifying a 100% premine. Honestly?
Delegated Proof-of-Stake (DPOS)
by Daniel Larimer
April 3, 2014
Abstract
This paper introduces a new implementation of proof of stake that can validate transactions in seconds while providing greater security in a shorter period of time than all existing proof of stake systems. In the time it takes Bitcoin to produce a single block a DPOS system can have your transaction verified by 20% of the shareholders and by the time Bitcoin claims the transaction is almost irreversible (6 blocks, 1 hour) your transaction under DPOS has been verified by 100% of the shareholders through their representatives.
http://107.170.30.182/security/delegated-proof-of-stake.php
by Daniel Larimer
April 3, 2014
Abstract
This paper introduces a new implementation of proof of stake that can validate transactions in seconds while providing greater security in a shorter period of time than all existing proof of stake systems. In the time it takes Bitcoin to produce a single block a DPOS system can have your transaction verified by 20% of the shareholders and by the time Bitcoin claims the transaction is almost irreversible (6 blocks, 1 hour) your transaction under DPOS has been verified by 100% of the shareholders through their representatives.
http://107.170.30.182/security/delegated-proof-of-stake.php
Daniel "bytemaster" Larimer is answering technical questions in this thread.
Jump to: