BitShares Forum
Main => General Discussion => Topic started by: BTSdac on March 19, 2016, 01:00:13 pm
-
Refund worker only has 32M voter , oh oh ,
-
Refund worker only has 32M voter , oh oh ,
Don't panic.
After next hard fork there will be much more.
-
Refund worker only has 32M voter , oh oh ,
Don't panic.
After next hard fork there will be much more.
Yes I was wondering the same [without sitting and actually calculating it] BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in, but all those negative votes for the refund workers will be gone too. so what is the actual net result?
-
Refund worker only has 32M voter , oh oh ,
Don't panic.
After next hard fork there will be much more.
Yes I was wondering the same [without sitting and actually calculating it] BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in, but all those negative votes for the refund workers will be gone too. so what is the actual net result?
Result: harder to vote in a worker. How did you got the feeling that "BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in"?
//Update: removing negative voting is not for easier dilution, but for better security.
-
Refund worker only has 32M voter , oh oh ,
Don't panic.
After next hard fork there will be much more.
Yes I was wondering the same [without sitting and actually calculating it] BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in, but all those negative votes for the refund workers will be gone too. so what is the actual net result?
Result: harder to vote in a worker. How did you got the feeling that "BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in"?
//Update: removing negative voting is not for easier dilution, but for better security.
I get the better security argument and I somewhat agree with it. The question was have you actually calculated is it gonna be easier or harder to vote in workers after negative voting is removed? ( assuming we are having the same votes as today and the negative votes removed)
-
Refund worker only has 32M voter , oh oh ,
Don't panic.
After next hard fork there will be much more.
Yes I was wondering the same [without sitting and actually calculating it] BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in, but all those negative votes for the refund workers will be gone too. so what is the actual net result?
Result: harder to vote in a worker. How did you got the feeling that "BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in"?
//Update: removing negative voting is not for easier dilution, but for better security.
I get the better security argument and I somewhat agree with it. The question was have you actually calculated is it gonna be easier or harder to vote in workers after negative voting is removed? ( assuming we are having the same votes as today and the negative votes removed)
While you have not been "sitting and actually calculating it", I did some rough calculations and got the result it's harder. Perhaps I need to do more accurate calculation? OK, give me some minutes, will post here.
//Update: @tonyk
Before hardfork:
177485837.48796 1.14.16 GUI Development and Maintenance by svk
136401810.11109 1.14.30 Blockchain maintenance developer
135828368.94863 1.14.29 [BSIP10] Percentage-based transfer fee solution based on CER
53745006.89039 1.14.32 Documentation and Technical Support
51602832.53078 1.14.33 Blockchain Explorer and API Development
46689331.26361 1.14.31 Python Library and Applications
35516161.86478 1.14.23 refund-100k-1
35142781.79344 1.14.24 refund-100k-2
-20117829.80640 1.14.0 refund400k
After hard fork:
308342857.81402 1.14.16 GUI Development and Maintenance by svk
270837740.80509 1.14.30 Blockchain maintenance developer
267573685.39132 1.14.29 [BSIP10] Percentage-based transfer fee solution based on CER
205793019.18600 1.14.0 refund400k
194793714.92736 1.14.23 refund-100k-1
194582278.30307 1.14.24 refund-100k-2
186046012.80095 1.14.32 Documentation and Technical Support
182459612.10747 1.14.33 Blockchain Explorer and API Development
177546110.84030 1.14.31 Python Library and Applications
176725782.12500 1.14.28 Graphic Design / UI/UX Design / Web Development
154853485.71291 1.14.34 svk - Bitshares GUI Development and Maintenance #2
-
Refund worker only has 32M voter , oh oh ,
Don't panic.
After next hard fork there will be much more.
Yes I was wondering the same [without sitting and actually calculating it] BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in, but all those negative votes for the refund workers will be gone too. so what is the actual net result?
Result: harder to vote in a worker. How did you got the feeling that "BM is so sure after negative voting is thrown out it will be much easier for workers to be voted in"?
//Update: removing negative voting is not for easier dilution, but for better security.
I get the better security argument and I somewhat agree with it. The question was have you actually calculated is it gonna be easier or harder to vote in workers after negative voting is removed? ( assuming we are having the same votes as today and the negative votes removed)
While you have not been "sitting and actually calculating it", I did some rough calculations and got the result it's harder. Perhaps I need to do more accurate calculation? OK, give me some minutes, will post here.
//Update: @tonyk
Before hardfork:
177485837.48796 1.14.16 GUI Development and Maintenance by svk
136401810.11109 1.14.30 Blockchain maintenance developer
135828368.94863 1.14.29 [BSIP10] Percentage-based transfer fee solution based on CER
53745006.89039 1.14.32 Documentation and Technical Support
51602832.53078 1.14.33 Blockchain Explorer and API Development
46689331.26361 1.14.31 Python Library and Applications
35516161.86478 1.14.23 refund-100k-1
35142781.79344 1.14.24 refund-100k-2
After hard fork:
308342857.81402 1.14.16 GUI Development and Maintenance by svk
270837740.80509 1.14.30 Blockchain maintenance developer
267573685.39132 1.14.29 [BSIP10] Percentage-based transfer fee solution based on CER
194793714.92736 1.14.23 refund-100k-1
194582278.30307 1.14.24 refund-100k-2
186046012.80095 1.14.32 Documentation and Technical Support
182459612.10747 1.14.33 Blockchain Explorer and API Development
177546110.84030 1.14.31 Python Library and Applications
176725782.12500 1.14.28 Graphic Design / UI/UX Design / Web Development
154853485.71291 1.14.34 svk - Bitshares GUI Development and Maintenance #2
Thanks! for the numbers.
The margin between actual and refund workers are small. So it seems, it will all depend on the vote of guys like mindplux and how they change their voting style. Right now he/they have not seen an actual worker they do not like, while also voting for refund/burn workers...
-
Thanks! for the numbers.
The margin between actual and refund workers are small. So it seems, it will all depend on the vote of guys like mindplux and how they change their voting style. Right now he/they have not seen an actual worker they do not like, while also voting for refund/burn workers...
Depends more on BM..
//Update: added the very original "refund400k" worker
-
Thanks! for the numbers.
The margin between actual and refund workers are small. So it seems, it will all depend on the vote of guys like mindplux and how they change their voting style. Right now he/they have not seen an actual worker they do not like, while also voting for refund/burn workers...
Depends more on BM..
//Update: added the very original "refund400k" worker
Yup...my original statement
BM: "It will be easier to vote workers in" and your observation in the last post seem to be the case.
And you are right...it was done for security reasons... what is more secure than BM voting in anyone he likes, anyway???????????
-
Thanks! for the numbers.
The margin between actual and refund workers are small. So it seems, it will all depend on the vote of guys like mindplux and how they change their voting style. Right now he/they have not seen an actual worker they do not like, while also voting for refund/burn workers...
Depends more on BM..
//Update: added the very original "refund400k" worker
Yup...my original statement
BM: "It will be easier to vote workers in" and your observation in the last post seem to be the case.
And you are right...it was done for security reasons... what is more secure than BM voting in anyone he likes, anyway???????????
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.
Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
-
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.
Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!
-
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.
Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!
^^ that! +5%
-
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.
Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!
^^ that! +5%
I was aware of this BUT removing the negative vote makes it much easier for an exchanges to vote workers in, if they so wish.
Before we collectively could vote against it and remove such workers...not anymore.
So 'more secure' in this regard is true, but it is not more secure in general.
-
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.
Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!
^^ that! +5%
I was aware of this BUT removing the negative vote makes it much easier for an exchanges to vote workers in, if they so wish.
Before we collectively could vote against it and remove such workers...not anymore.
So 'more secure' in this regard is true, but it is not more secure in general.
No.. it's not easier or harder for an exchange to do so, before the hard fork, although we can vote against an exchange's worker, the exchange can vote against all other workers, and/or create a new worker.
At this moment, exchanges has too much power, we can just hope them don't act bad. One stake votes for one committee member could be an option to limit exchanges' power. With this, the committee can at least disable worker pay.
-
It's not the case. With or without the feature, it's almost same difficulty for BM to vote in workers (when most of other voters/stake holders are rational). But with the new feature, it's harder for attackers to vote in their worker(s), so more secure.
Some people may ask what's an attack? Create one or more worker(s) which will take effect (get funds) immediately and vote in it without any explanation why it should be voted in.
^^ this!
^^ that! +5%
I was aware of this BUT removing the negative vote makes it much easier for an exchanges to vote workers in, if they so wish.
Before we collectively could vote against it and remove such workers...not anymore.
So 'more secure' in this regard is true, but it is not more secure in general.
No.. it's not easier or harder for an exchange to do so, before the hard fork, although we can vote against an exchange's worker, the exchange can vote against all other workers, and/or create a new worker.
At this moment, exchanges has too much power, we can just hope them don't act bad. One stake votes for one committee member could be an option to limit exchanges' power. With this, the committee can at least disable worker pay.
It is easier. Before you can tell everyone "hey there is this real real bad player come and vote against it ". What can you say now "hey there is this real real bad player come and vote for someone else you do not quite like just so you can get rid of this bad guy" ?
//edit
and as I was writing that... this happens https://bitsharestalk.org/index.php/topic,22051.msg287078.html#msg287078
What I am expected to do now? Start voting for workers I do not like? Just wait for BM to vote for a refund worker (just to cut this non sense of an 'offer')?
-
Guess you vote for the ones (if any) you do like and the refund or burn workers to raise the floor for the amount of votes needed to be voted in. End result is as abit says: it's harder for any one entity to game the system since a higher stake is needed.
-
Guess you vote for the ones (if any) you do like and the refund or burn workers to raise the floor for the amount of votes needed to be voted in. End result is as abit says: it's harder for any one entity to game the system since a higher stake is needed.
exactly
https://github.com/bitshares/bsips/blob/master/bsip-0015.md