Author Topic: Request for shareholder opinion  (Read 6241 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
Your steps 1+2 are basically the same as the worker proposal mechanism, but reduced to committee members only.

I don't see how reducing the scope would make that any better. It only creates more work for the committee. Keep in mind that committee members receive no compensation for their work, so we should not place any unneccessary load on them.
Also, my original question refers to *small* bugfixes. It does not make sense to create an approval process that takes an order of magnitude more work than the actual issue to be solved. That's why I see the proposal/vote mechanism as inappropriate.

Step 3 is something entirely new which we've never had before. In my understanding, once a change has been approved the actual execution is put into the hands of developers and witnesses.

Step 4, i. e. witness approval, seems to have the biggest support in this thread. Witnesses are responsible for keeping the blockchain alive, so ultimately they decide which code to run.
This!

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Your steps 1+2 are basically the same as the worker proposal mechanism, but reduced to committee members only.

I don't see how reducing the scope would make that any better. It only creates more work for the committee. Keep in mind that committee members receive no compensation for their work, so we should not place any unneccessary load on them.
Also, my original question refers to *small* bugfixes. It does not make sense to create an approval process that takes an order of magnitude more work than the actual issue to be solved. That's why I see the proposal/vote mechanism as inappropriate.

Step 3 is something entirely new which we've never had before. In my understanding, once a change has been approved the actual execution is put into the hands of developers and witnesses.

Step 4, i. e. witness approval, seems to have the biggest support in this thread. Witnesses are responsible for keeping the blockchain alive, so ultimately they decide which code to run.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
We have a mechanism in place, in the form of worker proposals.

But the overhead of creating worker proposals is rather high and not really appropriate for stuff like small bugfixes.

I read this as "Thanks for the suggestion, but we already have a mechanism, and that mechanism isn't suited for this."

Do you have any direct criticism of the method I outlined?

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
We have a mechanism in place, in the form of worker proposals.

But the overhead of creating worker proposals is rather high and not really appropriate for stuff like small bugfixes.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
that must be the blockchain itself

While I ultimately agree, pragmatically it makes sense to not halt everything else to implement an on-chain solution. Besides, how would we implement this on-chain without a hard fork?

Offline lakerta06

I think there should be a decided, known placewhere these bug fixes / hard forks are announced, with a "please speak now or forever hold your peace" kind of setup. If there is a big controversy about something, then we can take it to stakeholder vote. If not, then the update can be done without it.

Ideally, this should be done on-chain. This is how I imagine it:

1. A committee member creates a "hard fork proposal", which includes a brief description of the problem to be fixed or feature to be implemented.

2. At this stage, other committee members are assumed to a "yes" vote and must veto to "no" proactively. Otherwise, the feature is green-lighted to be developed after a certain amount of time, perhaps 15 days. If shareholders don't like the proposal and there are not enough vetos, then they can vote in committee members that agree with them.

3. After the feature/bugfix is developed and a release candidate is created, a committee member creates a "hard fork commitment proposal" which references the previous "hard fork proposal", and also includes the release hash and block number for the fork.

4. Witnesses commit to this, and when a supermajority of witnesses do, then the hard fork will activate at the block number.
that must be the blockchain itself

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I think there should be a decided, known place where these bug fixes / hard forks are announced, with a "please speak now or forever hold your peace" kind of setup. If there is a big controversy about something, then we can take it to stakeholder vote. If not, then the update can be done without it.

Ideally, this should be done on-chain. This is how I imagine it:

1. A committee member creates a "hard fork proposal", which includes a brief description of the problem to be fixed or feature to be implemented.

2. At this stage, other committee members are assumed to a "yes" vote and must veto to "no" proactively. Otherwise, the feature is green-lighted to be developed after a certain amount of time, perhaps 15 days. If shareholders don't like the proposal and there are not enough vetos, then they can vote in committee members that agree with them.

3. After the feature/bugfix is developed and a release candidate is created, a committee member creates a "hard fork commitment proposal" which references the previous "hard fork proposal", and also includes the release hash and block number for the fork.

4. Witnesses commit to this, and when a supermajority of witnesses do, then the hard fork will activate at the block number.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Thanks guys. Looks like there is consensus.

@bitcrab @xeroc - you're the biggest proxies, what's your position?
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline fuzzy

Community can Always Propose changes as needed and witnesses can choose accept or not. They are voted in by community anyway.

WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline Brekyrself

  • Hero Member
  • *****
  • Posts: 512
    • View Profile
features that require a hard fork or general rule changes - yes.

bugfixes - no

Some bugfixes may require a hardfork however this is a good guideline.  The more visibility into any hardfork upgrades is good for the whole community and those who are building businesses around the chain.

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
features that require a hard fork or general rule changes - yes.

bugfixes - no

Offline lakerta06

IMHO No
Shareholders should vote for trusted witnesses who, in the end, are expected to make that kind of call on behalf and in the best interest of the same shareholders
Agreed

Offline Thom

IMHO No
Shareholders should vote for trusted witnesses who, in the end, are expected to make that kind of call on behalf and in the best interest of the same shareholders

I agree. In general s/h don't have the expertise to evaluate bug fixes. IMO it would be counterproductive and slow progress.

This is the type of issue (approve / disapprove fix) we should have a direct voting mechanism for. What I'm thinking of is the DASH masternode governance model. If BitShares had a website that witness node operators could authenticate on and vote yea or nea on things, such decisions could be made before going thru the trouble of creating and testing a bug fix that won't be approved by witnesses.

Also, such a website would help to keep witnesses informed about upcoming changes, and provide shareholders with more info on which witnesses are active and how they vote (or don't).   
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Bhuz

  • Committee member
  • Sr. Member
  • *
  • Posts: 467
    • View Profile
  • BitShares: bhuz
IMHO No
Shareholders should vote for trusted witnesses who, in the end, are expected to make that kind of call on behalf and in the best interest of the same shareholders

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Do we need shareholder approval for these bugfixes?

Can we decide on that question? Not just specifically for the PRs in the OP, but generally.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de