BitShares Forum
Main => General Discussion => Topic started by: Simulacra_and_Simulation on April 17, 2014, 03:37:20 pm
-
The only difference I see is that the miners aren't wasting energy mining(not getting paid either) and you are mandating 100 operators.
When I pool mine I am delegating my hash power to the pool operator in turn that he/she pays me out proportional to what I put in and there will be no funny business. Generally what I mine is profitable or at least zero sum, where my costs are less than equal to what I am producing through mining.
This is the same as voting for a delegate except zero payout and zero energy costs.
Both are keeping the network going. Both are technically subject to what the miners want to do, change the vote or change pools.
Other questions:
How does one get informed of a delegate not doing a proper job?
If the top 100 vote receivers automatically win regardless of total votes, I can also see a problem where 95%of the votes go to a couple delegates, let's say 10, and then 5% are spread amongst 90 delegates. Popularity exists, see Ypool. Doesn't the minority vote going to a majority of delegates pose a weakness/vulnerability? Possibly a problem with these delegates getting voted in an out, missing blocks all the while the 10 with 95% are solving most of the blocks and they now become the threat? The weakness in one end opens opportunity for the others. What if you change the numbers to 1 delegate gets 99% of the vote because he decides to divvy out the transaction fees as vote rewards. The other 99 getting 1% could easily be manipulated right?
-
Very much like a mining pool, I think "signing pool" is a good transitionary term.
How does one get informed of a delegate not doing a proper job?
How do you get informed about a pool getting too large? Delegates are all watching each other, each delegate has a few people watching, and everyone is incentivized to bring bad delegates to light.
For last question:
3.2 Centralizing power in a few Delegates
Because each delegate has an equal vote and the top 100 are given equal weight regardless of votes delegated to them there is no ability to concentrate power by acquiring more than 1% of the vote in a single delegate.
It may be possible for a single individual or organization to control multiple delegates in the chain, but this process would involve deceiving a large percentage of the shareholders into supporting sock-puppets.
Even if 51 sock-puppets could be set up their power to disrupt the network would still be limited, quickly identified, and then remedied. Without the barriers to entry caused by proof of work, the honest majority would identify the attack and issue a fork of the code that ignored blocks produced by the attacker. It would be disruptive, but not fatal.
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
Just a quick heads up, check spelling on "Assumptions" header.
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
will this not alienate voters? If you deny ones vote, you can't force them to vote for someone else. This kinda goes against everything voting stands for. I fear if people aren't allowed to vote for who they want, they will abstain from participating or vote for a lesser delegate which is compromising.
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
will this not alienate voters? If you deny ones vote, you can't force them to vote for someone else. This kinda goes against everything voting stands for. I fear if people aren't allowed to vote for who they want, they will abstain from participating or vote for a lesser delegate which is compromising.
This isn't a political presidential election, people can vote against people as well so if they don't see anyone they can vote for, they just vote against everyone else. If there is only *ONE* person someone is willing to vote for that is a problem.
It is actually a security concern for one delegate to get a large percentage of the vote because it means it is more difficult to fire them. We don't want anyone getting too much power.
If someone really wants more than 2% then they have to run as two delegates.
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
Reading this: http://bitshares.org/documentation/group__dpos.html
The following conversion comes to my mind:
‘Why have mining that can be centralized (but requires investment in hardware and electricity to name a few) when a system can be designed that centralizes/puts the fee in the hands/pockets of selected few. Even better why not make sure that those selected few are us (as we are the biggest stakeholders).
Genius up to here right!
We only need to develop a system that hides the true nature of this scheme and appears fair!’ one day BM said to his buddies…
How about much simple (unfortunately) more fair system:
-Every active client/node is rotated (instead of just 100), when its times comes for its turn, it either produce the block or not.
-If such node/client is more than 10-15 sec late, any of the next 50 in line can come with the block. The first one of said 50 that does wins and gets the commission (the average of the last 100 or whatever plus say 5%-10% bonus i.e. 105%-110% of what otherwise the comm. Would have been). The one that produced the block is removed from the ‘in line list’.
This way the next 50 clients that will come to turn in the next 50 blocks can do the work and if: somebody is late, those next 50 will provide the speed for the network;
- there will be no whales advantage.
Additional suggestion: The new #50 in line (#49 and #50) in the case of jumping because of inactive current node), is included as info in the new blockchain – this should be the address with say -the oldest unspent amount, logarithmically weighted by the amount of the transaction, of let say the last 5000 transactions (all prev. if no more than 5000 transaction in the system).
Ignoring the accusations that we are trying to control this thing (trust me, I do not want to be in control)... let me address your proposal very quickly:
1) Avoiding ambiguity about who should produce the next block is key. Your proposal makes it ambiguous when someone misses a block.
2) Blocks would need to be produced proportional to stake not 'active client/node'.
3) Most people don't want to leave their computers on to secure the network, so there is demand for this job to be delegated. Even Nxt is doing this now.
4) When blocks are produced by your method they do not provide equal weight... a block produced by someone with .001% of stake vs someone with 10% has entirely different meanings with respect to the consensus reached. You want approximately equal weights for each block and to have the indirect consensus of almost everyone in a timely manner. Under your proposed approach, the amount of consensus accumulated per block is FAR less and thus the network is more subject to attack.
5) There is no way to prevent bad actors as the block producers have no reputation
6) Highly reliable nodes serve everyone better, especially when it comes to reducing latency and preventing systematic abuse.
As you can see these issues are not easily solved and DPOS is balancing a whole lot of factors.
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
Reading this: http://bitshares.org/documentation/group__dpos.html
The following conversion comes to my mind:
‘Why have mining that can be centralized (but requires investment in hardware and electricity to name a few) when a system can be designed that centralizes/puts the fee in the hands/pockets of selected few. Even better why not make sure that those selected few are us (as we are the biggest stakeholders).
Genius up to here right!
We only need to develop a system that hides the true nature of this scheme and appears fair!’ one day BM said to his buddies…
How about much simple (unfortunately) more fair system:
-Every active client/node is rotated (instead of just 100), when its times comes for its turn, it either produce the block or not.
-If such node/client is more than 10-15 sec late, any of the next 50 in line can come with the block. The first one of said 50 that does wins and gets the commission (the average of the last 100 or whatever plus say 5%-10% bonus i.e. 105%-110% of what otherwise the comm. Would have been). The one that produced the block is removed from the ‘in line list’.
This way the next 50 clients that will come to turn in the next 50 blocks can do the work and if: somebody is late, those next 50 will provide the speed for the network;
- there will be no whales advantage.
Additional suggestion: The new #50 in line (#49 and #50) in the case of jumping because of inactive current node), is included as info in the new blockchain – this should be the address with say -the oldest unspent amount, logarithmically weighted by the amount of the transaction, of let say the last 5000 transactions (all prev. if no more than 5000 transaction in the system).
Tonyk is using character assassination to advance his point. This is a form of violence. The pretend conversation is outrageous, and should not be tolerated in an open and free forum. If he is too lazy to argue his points without the use of violence (character assassination) then he should be relegated to a subforum for persons who want to use those kinds of tactics.
I am reporting this post to the Moderator.
-
How to prevent someone setting up a voting pool and collect all votes from shareholders, then split the earning among them? More small shareholders would like to join this pool to earn transaction fees instead vote again it. Then the pool will have enough votes to sign several delegates and centralize the power. Am I missing anything?
-
Tonyk is using character assassination to advance his point. This is a form of violence. The pretend conversation is outrageous, and should not be tolerated in an open and free forum. If he is too lazy to argue his points without the use of violence (character assassination) then he should be relegated to a subforum for persons who want to use those kinds of tactics.
I am reporting this post to the Moderator.
That is f-ing hilarious! I hope you are joking!
Very serious. I have reported the post to the moderator. It is up to the Moderator to agree or disagree with me.
-
Meaner things have been said on these forums... I only censor robot spam
Sent from my SCH-I535 using Tapatalk
-
The blockchain will enforce the rule that no delegate be given more than 2% of the vote... transactions that give more are rejected.
More details about how the client automatically identifies misbehaving nodes and votes against them:
http://bitshares.org/documentation/group__dpos.html
Reading this: http://bitshares.org/documentation/group__dpos.html
The following conversion comes to my mind:
‘Why have mining that can be centralized (but requires investment in hardware and electricity to name a few) when a system can be designed that centralizes/puts the fee in the hands/pockets of selected few. Even better why not make sure that those selected few are us (as we are the biggest stakeholders).
Genius up to here right!
We only need to develop a system that hides the true nature of this scheme and appears fair!’ one day BM said to his buddies…
How about much simple (unfortunately) more fair system:
-Every active client/node is rotated (instead of just 100), when its times comes for its turn, it either produce the block or not.
-If such node/client is more than 10-15 sec late, any of the next 50 in line can come with the block. The first one of said 50 that does wins and gets the commission (the average of the last 100 or whatever plus say 5%-10% bonus i.e. 105%-110% of what otherwise the comm. Would have been). The one that produced the block is removed from the ‘in line list’.
This way the next 50 clients that will come to turn in the next 50 blocks can do the work and if: somebody is late, those next 50 will provide the speed for the network;
- there will be no whales advantage.
Additional suggestion: The new #50 in line (#49 and #50) in the case of jumping because of inactive current node), is included as info in the new blockchain – this should be the address with say -the oldest unspent amount, logarithmically weighted by the amount of the transaction, of let say the last 5000 transactions (all prev. if no more than 5000 transaction in the system).
Ignoring the accusations that we are trying to control this thing (trust me, I do not want to be in control)... let me address your proposal very quickly:
1) Avoiding ambiguity about who should produce the next block is key. Your proposal makes it ambiguous when someone misses a block.
2) Blocks would need to be produced proportional to stake not 'active client/node'.
3) Most people don't want to leave their computers on to secure the network, so there is demand for this job to be delegated. Even Nxt is doing this now.
4) When blocks are produced by your method they do not provide equal weight... a block produced by someone with .001% of stake vs someone with 10% has entirely different meanings with respect to the consensus reached. You want approximately equal weights for each block and to have the indirect consensus of almost everyone in a timely manner. Under your proposed approach, the amount of consensus accumulated per block is FAR less and thus the network is more subject to attack.
5) There is no way to prevent bad actors as the block producers have no reputation
6) Highly reliable nodes serve everyone better, especially when it comes to reducing latency and preventing systematic abuse.
As you can see these issues are not easily solved and DPOS is balancing a whole lot of factors.
Invictus Innovations is building decentralized solutions for centralized problems – this seems not to be the main goal of DPOS.
I will start with point #5 of BM’s which is the most important:
‘5) There is no way to prevent bad actors as the block producers have no reputation’
The solution I suggest is based on the following premises: 95% of all wallets are honest actors. Those are people that just download the standard wallet and start using it – making no modification to any aspect of the way such wallet is supposed to behave (among other things is not trying to gain the system).
Additionally the system by design makes the transactions with the oldest balance holders the most likely to be awarded the right to make a block. What this achieves is one of the most important features of this suggestion. – It strongly de–incentivizes cheating players! Who will make changes to the software and then wait to be having very old balance to have a chance at cheating?
1) Avoiding ambiguity about who should produce the next block is key. Your proposal makes it ambiguous when someone misses a block.
I do not know why it is so important but here is a solution if want my proposal can be changed to the following –“The next 49 in line are listening, if the lock is missed any of them (can) submit the block and the valid one is the one from the highest in line #2>#3….>#50
2) Blocks would need to be produced proportional to stake not 'active client/node'.
Now, on this we must fight, I guess! – Why is this necessary – because the proposed system does not have it? I see this condition of yours to serve the only purpose for centralization/keeping the monopoly of the big stakeholders… Elaborate if any benefit for the chain/system is stone and depends on it….
3) Most people don't want to leave their computers on to secure the network, so there is demand for this job to be delegated. Even Nxt is doing this now.
The fact that somebody does it is not an argument, you know better than anybody…
One the other part here is how it works:
Whenever somebody is submitting a transaction s(he) receives a chance to produce a block (and get paid for it). The wallet gives you the chance if want or not to stay connected to the network and be rewarded this chance or no.(here one can add even a second option for the impatient – auto close/disconnect if more than N transactions with better scores are observed).
The idea is that enough nodes will choose to stay active/connected for from several minutes to several hours to get a shot at a commission.
The score of each transaction will be soothing in the form Sc=Age of the transaction balance (in sec) / 3600 /24 * Log ( Transaction Amount)
4) When blocks are produced by your method they do not provide equal weight... a block produced by someone with .001% of stake vs someone with 10% has entirely different meanings with respect to the consensus reached. You want approximately equal weights for each block and to have the indirect consensus of almost everyone in a timely manner. Under your proposed approach, the amount of consensus accumulated per block is FAR less and thus the network is more subject to attack.
As with 3. You have to explain what do you mean here… for now it seems as you are claiming that this system is more unsecure simple because it is not your system (To make it as an analogy people say ‘mining provides security’ without explaining why. You say ‘equal weight and consensus provides security’) In my opinion the design of this system provides security and you are insisting that consensus is needed just to keep the status quo. If really advantage do exists please explain.
6) Highly reliable nodes serve everyone better, especially when it comes to reducing latency and preventing systematic abuse.
Again – unbacked claims. If you ask me this system provides better solution to the attempt of abuse, as well as removing the build in system abuse – i.e. concentrating the fee producing activities in the hands of (in large preselected) few.
-
"3) Most people don't want to leave their computers on to secure the network, so there is demand for this job to be delegated. Even Nxt is doing this now."
Don't get it. If we have totall of 100.000 people and "only" 1000 of them want to keep their computers on... are they not enough to secure the network, even if they aren't the "most" of the total (100.000)?
-
Depends. What percent of the shares do they own.
Dacs don't know about people or nodes. Just shares.
How are these 1000 selected?
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Depends. What percent of the shares do they own.
Dacs don't know about people or nodes. Just shares.
How are these 1000 selected?
I am assuming that this 1000 people own's the most percent (or at least a respectfull %) of shares because they have a big motivation to be the one's they keep their computer on... Nobody select them.They participate on their own because they want to secure their own investment.(So statisticaly the most have all together a very big % because the most had the motive)
I think, at least for me, its easier to keep my computer on 24 hours* a day instead of the "trouble" to choose to which one to give my vote...
*I think many users do it right know after all for so much reasons (mining etc. :P)
-
-Every active client/node is rotated (instead of just 100), when its times comes for its turn, it either produce the block or not.
-If such node/client is more than 10-15 sec late, any of the next 50 in line can come with the block. The first one of said 50 that does wins and gets the commission (the average of the last 100 or whatever plus say 5%-10% bonus i.e. 105%-110% of what otherwise the comm. Would have been). The one that produced the block is removed from the ‘in line list’.
This way the next 50 clients that will come to turn in the next 50 blocks can do the work and if: somebody is late, those next 50 will provide the speed for the network;
- there will be no whales advantage.
??? how is this not totally vulnerable to sybil attacks? You can only have proof of work or of stake. I can spin up 10,000 clients for free and control a majority of blocks.
-
Sure, make 10k clients, let them sit for 3 months, then make big enough transaction, and if they have the best scored transaction of the last 5000, you have the chance to do exactly what (in an otherwise good design definitely not double spent, maybe not include transaction or few…)?
[EDIT] with such amount of resources you will be able to control probably 3-5% of those 100 delegates not on a once in a while bases but most of the time.
-
Oh ok so it's still tapos. This sounds similar to NXT and the response I remember to that was that people would form signing pools anyway. How many distinct pools secure nxt? Probably less than 100
Sent from my SCH-I535 using Tapatalk
-
How to prevent someone setting up a voting pool and collect all votes from shareholders, then split the earning among them? More small shareholders would like to join this pool to earn transaction fees instead vote again it. Then the pool will have enough votes to sign several delegates and centralize the power. Am I missing anything?
Can this be addressed?
-
Isnt that question the same as "a mining pool can return 100% of its income and attract small miners, then they can have enough hashpower to do 51% attack"?
What's the answer to that?
Sent from my SCH-I535 using Tapatalk
-
How to prevent someone setting up a voting pool and collect all votes from shareholders, then split the earning among them? More small shareholders would like to join this pool to earn transaction fees instead vote again it. Then the pool will have enough votes to sign several delegates and centralize the power. Am I missing anything?
Can this be addressed?
If a pool tried this then I suspect that many people would vote against that pools delegates. The average individual is already getting 90% of the trx fees as dividends and thus what remains for the delegate is hardly enough to justify this kind of move.
A pool operator that wants support in this form would just commit to taking less than their allowed 10% and pay the rest as dividends to all shareholders.
-
How to prevent someone setting up a voting pool and collect all votes from shareholders, then split the earning among them? More small shareholders would like to join this pool to earn transaction fees instead vote again it. Then the pool will have enough votes to sign several delegates and centralize the power. Am I missing anything?
Can this be addressed?
If a pool tried this then I suspect that many people would vote against that pools delegates. The average individual is already getting 90% of the trx fees as dividends and thus what remains for the delegate is hardly enough to justify this kind of move.
A pool operator that wants support in this form would just commit to taking less than their allowed 10% and pay the rest as dividends to all shareholders.
What is the weakest point of DPOS that has been discovered up to now?
-
How to prevent someone setting up a voting pool and collect all votes from shareholders, then split the earning among them? More small shareholders would like to join this pool to earn transaction fees instead vote again it. Then the pool will have enough votes to sign several delegates and centralize the power. Am I missing anything?
Can this be addressed?
If a pool tried this then I suspect that many people would vote against that pools delegates. The average individual is already getting 90% of the trx fees as dividends and thus what remains for the delegate is hardly enough to justify this kind of move.
A pool operator that wants support in this form would just commit to taking less than their allowed 10% and pay the rest as dividends to all shareholders.
What is the weakest point of DPOS that has been discovered up to now?
I too am interested in what is perceived to be the weakest point... and compared to what...
I think all POS chains suffer from the inability to validate block headers on their own. IE: bitcoin can do a fast check of POW difficulty before even looking at the transactions. Finding a way to do rapid validation of the chain you are on without having to process the whole thing would be helpful.
I suspect trusting a few delegates to sign statements on threat of being fired for lying is the best we can get.
-
How to prevent someone setting up a voting pool and collect all votes from shareholders, then split the earning among them? More small shareholders would like to join this pool to earn transaction fees instead vote again it. Then the pool will have enough votes to sign several delegates and centralize the power. Am I missing anything?
Can this be addressed?
If a pool tried this then I suspect that many people would vote against that pools delegates. The average individual is already getting 90% of the trx fees as dividends and thus what remains for the delegate is hardly enough to justify this kind of move.
A pool operator that wants support in this form would just commit to taking less than their allowed 10% and pay the rest as dividends to all shareholders.
What is the weakest point of DPOS that has been discovered up to now?
I too am interested in what is perceived to be the weakest point... and compared to what...
I think all POS chains suffer from the inability to validate block headers on their own. IE: bitcoin can do a fast check of POW difficulty before even looking at the transactions. Finding a way to do rapid validation of the chain you are on without having to process the whole thing would be helpful.
I suspect trusting a few delegates to sign statements on threat of being fired for lying is the best we can get.
You talk a lot about firing delegates for lying. I'm curious: will the firing process be automatic? If so, is it possible that someone could be fired spuriously? How does the firing process work?
-
Presenting an invalid transaction that has been signed by the delegate is a type of transaction that can be used to automatically fire a delegate. No one else could be spuriously fired unless their private key is compromised or they sign a transaction that lacks enough confirmation (ie: is less than 10 minutes old).