Quote from: toast on February 06, 2015, 01:00:26 AM

Quote from: arhag on February 05, 2015, 11:48:08 PM

Quote from: vikram on February 05, 2015, 11:39:53 PM

Quote from: fluxer555 on February 05, 2015, 10:58:00 PM
1. What happens to votes for a delegate when the delegate is retracted?
2. Can you still vote for a delegate that has rectracted, even though it will not result in this delegate being elected?

If 1 is "Votes are still counted, but they don't matter toward the election" and 2 is "Votes for these delegates are still valid transactions, even though they do not count toward the election", then we have a functioning proposal system. All you would need to do is create a 0% delegate, immediately retract it, and now you have something in the system you can use to vote with without any consequences on the security of the network.

This is correct.

Ohhhhh.... finally this makes sense to me. So they aren't "arbitrary ints" like I thought. They need to refer to the ID of a retracted delegate?  (By the way that is way less flexible than I thought it would be since it doesn't allow you to vote using a number, rather than simply approve, for a specific ballot. But, baby steps ...)

No, they actually are arbitrary ints, vikram must have not seen that change

You can vote for an arbitrary set of ints, and if any of them is a delegate ID at the time of voting, then the votes are applied to the delegate ranking. If any of those delegate accounts are retracted, then they are still automatically ranked by the current client but will never become active, as in the OP.

Btw I think this thread made me realize a bug that I am fixing right now: https://github.com/BitShares/bitshares/issues/1358

Quote from: lil_jay890 on February 06, 2015, 01:06:13 AM
This needs an "explain it to me like I'm 5" version

You're right, I'm locking this until I can think of a better way to go about this, this thread was a bit impulsive and probably wasting time.

Probably off-chain stake-polling with support directly in the GUI is the way to start working towards this.

This needs an "explain it to me like I'm 5" version

Quote from: arhag on February 05, 2015, 11:48:08 PM

Quote from: vikram on February 05, 2015, 11:39:53 PM

Quote from: fluxer555 on February 05, 2015, 10:58:00 PM
1. What happens to votes for a delegate when the delegate is retracted?
2. Can you still vote for a delegate that has rectracted, even though it will not result in this delegate being elected?

If 1 is "Votes are still counted, but they don't matter toward the election" and 2 is "Votes for these delegates are still valid transactions, even though they do not count toward the election", then we have a functioning proposal system. All you would need to do is create a 0% delegate, immediately retract it, and now you have something in the system you can use to vote with without any consequences on the security of the network.

This is correct.

Ohhhhh.... finally this makes sense to me. So they aren't "arbitrary ints" like I thought. They need to refer to the ID of a retracted delegate?  (By the way that is way less flexible than I thought it would be since it doesn't allow you to vote using a number, rather than simply approve, for a specific ballot. But, baby steps ...)

No, they actually are arbitrary ints, vikram must have not seen that change

Quote from: arhag on February 06, 2015, 12:15:30 AM

Quote from: Bitcoinfan on February 06, 2015, 12:08:06 AM

Quote from: toast on February 05, 2015, 10:56:24 PM

Quote from: Bitcoinfan on February 05, 2015, 10:54:25 PM
Are you saying that delegate voting should instead change to each independent proposal voting?   Or the Bitshares user interface should be expanded so that delegate's proposals are shown and with great detail?

No, I'm saying we should have proposals with voting done separately from voting for delegates because they are distinct concepts we shouldn't be hacking together

Your separating proposals plans from the delegates.  If this happens, you've diminished the role of a delegate, and they wouldn't need to ever get paid a 100% inflation.  Am I understanding this right?

That assumes that proposals would be binding (which I hope they eventually would be), meaning that the blockchain reacts to a proposal getting enough support from stakeholders by doing something in response (like inflating a certain amount of BTS within the allowed inflation budget and paying it to some specific account). At the start, I believe the discussion is simply for non-binding proposal so we can simply understand what is the collective desire of the BTS shareholders. Then, for example, we could have 100% delegates move their money to support that cause if they want to stay elected.

excellent sequential approach arhag. I like it.  +5%

Quote from: Bitcoinfan on February 06, 2015, 12:08:06 AM

Quote from: toast on February 05, 2015, 10:56:24 PM

Quote from: Bitcoinfan on February 05, 2015, 10:54:25 PM
Are you saying that delegate voting should instead change to each independent proposal voting?   Or the Bitshares user interface should be expanded so that delegate's proposals are shown and with great detail?

No, I'm saying we should have proposals with voting done separately from voting for delegates because they are distinct concepts we shouldn't be hacking together

Your separating proposals plans from the delegates.  If this happens, you've diminished the role of a delegate, and they wouldn't need to ever get paid a 100% inflation.  Am I understanding this right?

That assumes that proposals would be binding (which I hope they eventually would be), meaning that the blockchain reacts to a proposal getting enough support from stakeholders by doing something in response (like inflating a certain amount of BTS within the allowed inflation budget and paying it to some specific account). At the start, I believe the discussion is simply for non-binding proposal so we can simply understand what is the collective desire of the BTS shareholders. Then, for example, we could have 100% delegates move their money to support that cause if they want to stay elected.

Quote from: toast on February 05, 2015, 10:56:24 PM

Quote from: Bitcoinfan on February 05, 2015, 10:54:25 PM
Are you saying that delegate voting should instead change to each independent proposal voting?   Or the Bitshares user interface should be expanded so that delegate's proposals are shown and with great detail?

No, I'm saying we should have proposals with voting done separately from voting for delegates because they are distinct concepts we shouldn't be hacking together

Your separating proposals plans from the delegates.  If this happens, you've diminished the role of a delegate, and they wouldn't need to ever get paid a 100% inflation.  Am I understanding this right?

I like the idea a lot. Quick question. Would there be any way, or plan, to tie proposals from specific delegates to the voting popularity of that delegate? Say that a proposal is rejected, could that delegate also be rejected? It would make for an interesting network.

Quote from: vikram on February 05, 2015, 11:39:53 PM

Quote from: fluxer555 on February 05, 2015, 10:58:00 PM
1. What happens to votes for a delegate when the delegate is retracted?
2. Can you still vote for a delegate that has rectracted, even though it will not result in this delegate being elected?

If 1 is "Votes are still counted, but they don't matter toward the election" and 2 is "Votes for these delegates are still valid transactions, even though they do not count toward the election", then we have a functioning proposal system. All you would need to do is create a 0% delegate, immediately retract it, and now you have something in the system you can use to vote with without any consequences on the security of the network.

This is correct.

Ohhhhh.... finally this makes sense to me. So they aren't "arbitrary ints" like I thought. They need to refer to the ID of a retracted delegate?  (By the way that is way less flexible than I thought it would be since it doesn't allow you to vote using a number, rather than simply approve, for a specific ballot. But, baby steps ...)

Quote from: arhag on February 05, 2015, 11:41:56 PM

Quote from: toast on February 05, 2015, 08:32:35 PM
BM and I have gone back and forth, with me claiming we need to get proposal-based governance online ASAP and him arguing that delegates provide a good-enough proxy since shareholders can always use a "poll" delegate. BM claims it would add voter complexity, but I think that's wrong. It is much much easier to analyze self-contained proposals with their own UX than it is to find and analyze various delegate bids. It is also qualitatively different to think about a proposal when it is presented as "shareholders need your input on this yes/no question right now".

Yes, yes, yes! Thanks for fighting for this, toast.

Quote from: Chronos on February 05, 2015, 09:33:47 PM
NuBits has the same problem. As more and more diverse holders become absent voters, it becomes more and more difficult to approve anything (which requires 51%). With delegates, at least, you don't need 51% of stake voting "yes" to be approved -- you just need more votes than the other candidates receive.

The idea in this thread is called "motions" in NuBits, and already exists on that blockchain, but with the above-mentioned issue. I would recommend "yes, no, abstain" as three distinct voting states, though then it's not clear how to determine final approval. 3% yes, 1% no, 96% abstain does not sound like the final will of the voters.

Yes, as you mentioned, requiring 51% for all proposals is problematic and leads to grid lock because of voter apathy. I agree with the three option system (approve, disapprove, neutral by default). I proposed such a system for deciding whether proposals become ratified.

Thanks to both of you. 100% agree.

Quote from: toast on February 05, 2015, 08:32:35 PM
BM and I have gone back and forth, with me claiming we need to get proposal-based governance online ASAP and him arguing that delegates provide a good-enough proxy since shareholders can always use a "poll" delegate. BM claims it would add voter complexity, but I think that's wrong. It is much much easier to analyze self-contained proposals with their own UX than it is to find and analyze various delegate bids. It is also qualitatively different to think about a proposal when it is presented as "shareholders need your input on this yes/no question right now".

Yes, yes, yes! Thanks for fighting for this, toast.

Quote from: Chronos on February 05, 2015, 09:33:47 PM
NuBits has the same problem. As more and more diverse holders become absent voters, it becomes more and more difficult to approve anything (which requires 51%). With delegates, at least, you don't need 51% of stake voting "yes" to be approved -- you just need more votes than the other candidates receive.

The idea in this thread is called "motions" in NuBits, and already exists on that blockchain, but with the above-mentioned issue. I would recommend "yes, no, abstain" as three distinct voting states, though then it's not clear how to determine final approval. 3% yes, 1% no, 96% abstain does not sound like the final will of the voters.

Yes, as you mentioned, requiring 51% for all proposals is problematic and leads to grid lock because of voter apathy. I agree with the three option system (approve, disapprove, neutral by default). I proposed such a system for deciding whether proposals become ratified.

Quote from: fluxer555 on February 05, 2015, 10:58:00 PM
1. What happens to votes for a delegate when the delegate is retracted?
2. Can you still vote for a delegate that has rectracted, even though it will not result in this delegate being elected?

If 1 is "Votes are still counted, but they don't matter toward the election" and 2 is "Votes for these delegates are still valid transactions, even though they do not count toward the election", then we have a functioning proposal system. All you would need to do is create a 0% delegate, immediately retract it, and now you have something in the system you can use to vote with without any consequences on the security of the network.

This is correct.

Delegates already have an unclear double role, adding proposal voting might be quite hard to swallow for many people.

Won't vote, +5% for toast proposal

Quote from: vikram on February 05, 2015, 10:40:18 PM

Quote from: skyscraperfarms on February 05, 2015, 08:43:45 PM
You would miss blocks until you are voted out if you take it offline. Doesn't this cause problems? Security, forking, transaction times... Etc.? If we had this happening frequently and with multiple delegates, this couldn't be a good thing, right?

After 0.6.x, active delegates can retract their accounts in order to instantly (at the start of the next round) be removed from the active 101.

Depending on how this is implemented, this could effectively give the functionality that toast wants for a proposal system. The important details:

1. What happens to votes for a delegate when the delegate is retracted?
2. Can you still vote for a delegate that has rectracted, even though it will not result in this delegate being elected?

If 1 is "Votes are still counted, but they don't matter toward the election" and 2 is "Votes for these delegates are still valid transactions, even though they do not count toward the election", then we have a functioning proposal system. All you would need to do is create a 0% delegate, immediately retract it, and now you have something in the system you can use to vote with without any consequences on the security of the network.

Quote from: Bitcoinfan on February 05, 2015, 10:54:25 PM
Are you saying that delegate voting should instead change to each independent proposal voting?   Or the Bitshares user interface should be expanded so that delegate's proposals are shown and with great detail?

No, I'm saying we should have proposals with voting done separately from voting for delegates because they are distinct concepts we shouldn't be hacking together