Author Topic: refund worker only has 32M voter , oh oh ,  (Read 5218 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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

Offline svk

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.
Worker: dev.bitsharesblocks

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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')?
« Last Edit: March 24, 2016, 06:29:03 pm by tonyk »
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.
BitShares committee member: abit
BitShares witness: in.abit

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline BunkerChainLabs-DataSecurityNode

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%
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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!

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.
BitShares committee member: abit
BitShares witness: in.abit

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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???????????
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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
« Last Edit: March 19, 2016, 11:19:18 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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:
Code: [Select]
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:
Code: [Select]
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...
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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:
Code: [Select]
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:
Code: [Select]
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
« Last Edit: March 19, 2016, 11:18:22 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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)
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.
« Last Edit: March 19, 2016, 05:17:35 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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?
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
Refund worker only has 32M voter , oh oh ,

Don't panic.
After next hard fork there will be much more.
BitShares committee member: abit
BitShares witness: in.abit

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
Refund worker only has 32M voter , oh oh ,
« Last Edit: March 19, 2016, 01:03:47 pm by BTSdac »
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091