BitShares Forum
Main => General Discussion => Topic started by: bitmeat on July 22, 2014, 03:21:32 pm
-
These are assumptions, correct me if wrong. We have 101 slots reserved for elect delegates, rearranged every 101 blocks.
PROPOSAL:
Each batch of 101 blocks randomly assign 101 delegates based on certain total % (adjustable) of their total votes.
EXAMPLES:
A1-A10 have 20% of the votes (2% each)
B1-B20 have 20% of the votes (1% each)
C1-C40 have 20% of the votes (0.5% each)
D1-D100 have 20% of the votes (0.2% each)
E1-E1000 have 20% of the votes (0.02% each)
In our configuration each of the groups will technically have equal chance to get a delegate to "represent" them.
A typical example might be that each batch you could have a good distribution of delegates, should closely represent the following:
21 A (technically I only listed 10 delegates above)
20 B
20 C
20 D
20 E
This means that the delegates in the E section will have a very tiny chance of getting selected, but will have a very big chance of having a delegate picked out.
To Bytemaster, please consider this option. Otherwise whoever has the highest stake, dominates the delegate selection and nothing is stopping them from having 100% delegates even if they only have 20% of the BTSX.
---
IN SHORT:
We currently have 101 out of 101 elect delegates. Make elections every batch and pick 101 out of 1001, such that chance to get selected is proportional to vote count. Make the two numbers adjustable via proposals + shareholder voting.
-
I like the idea.
However there should be another variable missed/produced blocks ratio. It should penalise low-performing delegates.
And perhaps not all the seats should be random. Top 10 voted delegates should stay regardless.
-
Updated in red so proposal is more clear.
-
In short you have not read the economics of the situation. Your proposal costs 10x as much for the network to operate.
-
In short you have not read the economics of the situation. Your proposal costs 10x as much for the network to operate.
Because 1001 delegates need to be running in case they get selected, instead of 101? How is that different at the moment, all the pending candidates are running a node anyways.
-
In short you have not read the economics of the situation. Your proposal costs 10x as much for the network to operate.
Because 1001 delegates need to be running in case they get selected, instead of 101? How is that different at the moment, all the pending candidates are running a node anyways.
Because once you are in you still need to break even. In your bid to become a delegate you may have to front some costs, but if you don't get any traction you shut it down. Under your system 1001 people need to be up at all times.
-
So implement online presence for delegates and only pick from the ones that are running.
-
Also my proposal is for the numbers 101 and 1001 to be dynamically adjusted. You can start with 101/101 which is what you have right now
-
Also my proposal is for the numbers 101 and 1001 to be dynamically adjusted. You can start with 101/101 which is what you have right now
That just means fees go up in the long-run...
-
So implement online presence for delegates and only pick from the ones that are running.
Not viable in a blockchain.
-
Sure it is
-
Delegate pays a fee which gets destroyed to toggle online presence or in fact set any attribute on their user.
-
Delegate pays a fee which gets destroyed to toggle online presence or in fact set any attribute on their user.
Ok, I suppose there is that option, it would cost them something to maintain that status and they would have to earn it back when the produce a block which means everyone has to pay for it.
-
It's a flag that says "include me in the considered delegates" only needs to be switched when a delegate WANTS to be considered. Say my servers are down instead of missing blocks and screwing up my stats - like it happened to me I could turn myself off for awhile
-
It's a flag that says "include me in the considered delegates" only needs to be switched when a delegate WANTS to be considered. Say my servers are down instead of missing blocks and screwing up my stats - like it happened to me I could turn myself off for awhile
He has to come back online and validate all the blocks he missed and so his costs are the same. In the end the cost comes from validating transactions and not making 1 signature. A full validating node is a full validating node no matter how you amortize it
-
the system could decrease pay rate to zero for delegates that choose to "pause" block production and switch back to the original pay rate after they signed the number of blocks needed to "pay" the standby delegate that was chosen to sign the "lost" blocks...
PS so when a delegate "pause" block production because of technical problems for example (or for the opportunity for a server maintenance), the network would not miss that blocks, plus we would give the chance to more "players" to prove their abilities...
-
Sorry but this is a terrible idea. Unless I'm mistaken what you are proposing would fluctuate all the delegates constantly. You are never guaranteed to stay a delegate and therefore have no incentive to try hard to be a good one.
Ultimately if what you want is just to give more people a chance to try to be a delegate then what if we stop trying to say that voting is broken and start giving people a chance to prove themselves? There could be a "delegate proving grounds" test net that is a clone of the current release so that other people could have a chance to show that they are good at producing blocks. Voting wouldn't be as critical because the shares wouldn't have actual value. Oh wait... That sounds a lot like the test net that we already have!
OR
We can just live with the fact that voting is voting and just give people a good place to promote themselves. I REALLY THINK THIS WOULD SOLVE ALL THE PROBLEMS. People who deserve to be delegates should be able to explain exactly why they deserve to be a delegate. Not just "plz plz plz vote for me! ;P " The problem is that we need to have 1 place where everyone knows and can easily find, where potential delegates can promote themselves. It really should be a part of the main website for BitShares.org . And what would be REALLY awesome would be if there could be something as simple as a Facebook thumbs up that masses could click on if they like what they see. And it would automatically sync up to the thumbs up link in the delegate page of the GUI wallet. Heck it could even set up a transaction of all your BTSX to yourself and ask you to verify that. Even better would be some kind of HTML code link that could be added to websites or forums that works a lot like the Facebook thumbs up.
All people want is a chance. And everyone wants to see the best delegates get the job. So we just need to let people (active delegates or not) get a legitimate chance to prove themselves and I think all these "voting sux!" problems will go away.
Thoughts on that? I'll probably repost this in it's own thread.
Sent from my iPhone using Tapatalk
-
He doesn't have to validate blocks he missed because he won't be included in the batch selection if he has marked himself as I'm no longer running.
In fact you kinda already have that. If I edit my account could I remove the delegate portion? If yes then you have what I'm talking about. I'm not sure if one can make themselves not a delegate and then later reregister. And if they lose the votes in the process.
-
He doesn't have to validate blocks he missed because he won't be included in the batch selection if he has marked himself as I'm no longer running.
In fact you kinda already have that. If I edit my account could I remove the delegate portion? If yes then you have what I'm talking about. I'm not sure if one can make themselves not a delegate and then later reregister. And if they lose the votes in the process.
To check that block N is valid you have to check that block N-1 is valid. So if you miss X blocks you have to validate all X before you validate "your" block. Right now you can un-register yourself as a delegate and also right now every single client is a full validator. This is a discussion about scale in the long term when you can only have a small number of full validators, like how bitcoin's full nodes number in the hundreds at less than 10 trx/s.
This is unless you do something like embed "trusted checkpoints" signed by enough delegates as database diffs into the blockchain directly.
-
I'm trying to make sure that if a delegate has 5% of the votes, they get to produce 5% of the blocks. Some services run a good cause and pay for a node regardless this can help them offset that cost even if it doesn't fully pay it.
I understand the concern of running 1000 nodes instead of 100. But come one $50k/mo is nothing when the network grows.
Also as far as voting goes these numbers should be votes by the community and not hard coded let the market decide how many delegates we need.
-
I'm trying to make sure that if a delegate has 5% of the votes, they get to produce 5% of the blocks. Some services run a good cause and pay for a node regardless this can help them offset that cost even if it doesn't fully pay it.
I understand the concern of running 1000 nodes instead of 100. But come one $50k/mo is nothing when the network grows.
Also as far as voting goes these numbers should be votes by the community and not hard coded let the market decide how many delegates we need.
No no no, that just can't be. All of the potentially good delegates with 5% will be right alongside the crappy/evil delegates that were good long enough to get more votes and havent gone back down to 0% yet. It may be okay to adjust the number of delegates but that needs to not allow for all potential delegates to get a chance. Bad idea! And it also can't screw over the really awesome delegates with 90% of the vote but can randomly not get to produce blocks and not be able to predict the income that they need in order to be such an awesome delegate.
-
Ok. How about this:
Self correcting system. Based on a delegate % of missed blocks, you let in a random potential candidate for a block.
So a delegate drops down to 80% of reliability. In the future with a 20% chance you give their block to a delegate waiting in line.
That will motivate delegates to be 100% and also self correct if they are down for some reason.
-
I'm trying to make sure that if a delegate has 5% of the votes, they get to produce 5% of the blocks. Some services run a good cause and pay for a node regardless this can help them offset that cost even if it doesn't fully pay it.
I understand the concern of running 1000 nodes instead of 100. But come one $50k/mo is nothing when the network grows.
Also as far as voting goes these numbers should be votes by the community and not hard coded let the market decide how many delegates we need.
No no no, that just can't be. All of the potentially good delegates with 5% will be right alongside the crappy/evil delegates that were good long enough to get more votes and havent gone back down to 0% yet. It may be okay to adjust the number of delegates but that needs to not allow for all potential delegates to get a chance. Bad idea! And it also can't screw over the really awesome delegates with 90% of the vote but can randomly not get to produce blocks and not be able to predict the income that they need in order to be such an awesome delegate.
To be honest if I'm a delegate and my rate starts going down I would rather not have bad reliability % and be paused and my slot given to someone else temporarily until I say it's ok to go again.
-
Ok. How about this:
Self correcting system. Based on a delegate % of missed blocks, you let in a random potential candidate for a block.
So a delegate drops down to 80% of reliability. In the future with a 20% chance you give their block to a delegate waiting in line.
That will motivate delegates to be 100% and also self correct if they are down for some reason.
That is a little better. But:
Problem 1: 80% reliability doesn't account for last 100 blocks missed of 100000 which would work out to 99.9% reliable but still bad.
Problem 2: You can't guarantee that the new delegates will be able to produce blocks so it could be bad to let in new delegates all the time.
It sounds to me like you just want the ability to punish delegates for missing blocks. Negative voting?! ;D Plus automatic voting actually.
-
You are misinterpreting my words. Reliability is currently all time. We could find a good measure. 24hr/last hour etc. there are still 101 slots not 10000.
It couldn't be worse than before if he's been missing 20%, might as well give that chance to somebody else.
-
I want to avoid the scenario where one big fish of 10% in BTSX could have 100% of the delegates and declare monopoly! Which has kinda been happening.
-
I want to avoid the scenario where one big fish of 10% in BTSX could have 100% of the delegates and declare monopoly! Which has kinda been happening.
krabbypatty please see this links and comment on my thoughts ;)
https://bitsharestalk.org/index.php?topic=5569.msg74886#msg74886
https://bitsharestalk.org/index.php?topic=4009.msg59537#msg59537
https://bitsharestalk.org/index.php?topic=5317.0
-
I want to avoid the scenario where one big fish of 10% in BTSX could have 100% of the delegates and declare monopoly! Which has kinda been happening.
do we agree that this would only happen if at least 80% didnt vote (assumptions: big fish voted with his full stake for his delegates; and the rest that voted did not vote for big fish's delegates) at all?
-
Even if all the rest of 90% vote, unless they all vote for the same small guys, they will not kick out the big fish.
-
Even if all the rest of 90% vote, unless they all vote for the same small guys, they will not kick out the big fish.
that assumes that they would all also vote for the big fish's delegate. Is that realistic?
The conclusion is again that shareholder education / information (decentralized is vital) and and norms are important for an open consensus network to stay decentralized!
-
I'm sure Dan and team will come up with a good solution, it's good that we put the ideas out in the open. I'm focusing on making a delegate statistics tool, so we can speak in numbers.
And to answer your question:
SHARES:
30% BTSX Monopoly Big Fish
70% BTSX Smaller guys
VOTES:
30% Big Fish - votes for 101 positions
next in line - even thought they have high % votes, they are fragmented, so none make it to the top. You get 30% to control 100%
28%
23%
15%
15%
(And I think this was Dan's consideration for having negative votes, he gives a similar example there)
Let's give it more time to evole, I was being reactive. After I build the tool voters will have more visibility and will make voting an easier decision for them.
-
Under the situation I supposed
...assumptions: big fish voted with his full stake for his delegates; and the rest that voted did not vote for big fish's delegates...
+ the assumption that all shareholders voted and given your 30/70 stake distribution...
votes would be:
big fish's 1-101 delegates: 30 % each
some other 101 delegates: 70% each
So big fish's delegates would not be in the top 101.
The assumption that all shareholders vote is a bit extreme. Therefore I proposed that it would be enough if more than the 10% you suggested for the big fish in the first place of the distributed shareholders vote and would vote all not for the big fish's delegate. The latter I think is not unrealistic if they know the percentages + know that decentralization is crucial.
I'm sure Dan and team will come up with a good solution, it's good that we put the ideas out in the open. I'm focusing on making a delegate statistics tool, so we can speak in numbers.
+5%
-
You are assuming that the rest 70% will actually manage to select and vote for the SAME 101 delegates, enough to push big fish out.
Right now if I have 6% of BTSX I could kick everybody else out. That's about 2,000 BTC or $1.2M. Even a medium size fish could pull that off :)
Luckily there is no withdrawals yet at BTER and BTC38.
-
You are assuming that the rest 70% will actually manage to select and vote for the SAME 101 delegates, enough to push big fish out.
Right now if I have 6% of BTSX I could kick everybody else out. That's about 2,000 BTC or $1.2M. Even a medium size fish could pull that off :)
Luckily there is no withdrawals yet at BTER and BTC38.
You are assuming that the rest 70% will actually manage to select and vote for the SAME 101 delegates, enough to push big fish out.
Right, but the 30% fish is also a bit much :)
It is based on the assumptions I made initially....
Right now if I have 6% of BTSX I could kick everybody else out.
...because not many are voting yet.
Do we actually know what the distribution of BTS X is?
And could there be an incentive for shareholders to vote? Less tx fees for shareholders that vote?
-
Do we actually know what the distribution of BTS X is?
And could there be an incentive for shareholders to vote? Less tx fees for shareholders that vote?
This is the best thing I heard so far. I would even go as far as say dormant accounts, should experience burn of 5%/year. And one way to not be dormant is to vote.
-
Do we actually know what the distribution of BTS X is?
And could there be an incentive for shareholders to vote? Less tx fees for shareholders that vote?
This is the best thing I heard so far. I would even go as far as say dormant accounts, should experience burn of 5%/year. And one way to not be dormant is to vote.
Not sure I saw more or less that suggested somewhere else :)
-
Bytemaster himself actually suggested as much. This is probably the best solution I've heard yet. We just have to get people voting and the big fish problem will be largely gone.
Sent from my iPhone using Tapatalk
-
Right now if I have 6% of BTSX I could kick everybody else out.
...because not many are voting yet.
does it make sense that every new account/user will automaticaly vote by default 101 delegates with specific characteristics (like highest delegate reliability for last x blocks produced), until of course he decides to start manual voting and change the default votes ?
-
Automatically setting up initial votes is good but really only if the votes automatically change. Because a bad delegate could get in early and then a bunch of new people keep voting them in without realizing it. But with both of those it would be really good.
Sent from my iPhone using Tapatalk