Author Topic: dele-puppy as temporary committee member  (Read 9095 times)

0 Members and 1 Guest are viewing this topic.

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
I don't think high fees are hurting our adoption.  I also don't think high fees have helped our adoption.

If it was up to me I would probably set all fees to their default except for account_creation fee, which I would set to 90, and all per KB which I would raise substantially. 

This would mean 20bts transfer 10k bts LTM.  I think that doubling the fees when our price tanked was not a good idea.

I am of course willing to consider other options and ideas.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
what's your stance on the ongoing fee debate? are you for or against lowering?

Offline roadscape

[
It would be great to have proposals stay in the core for now! Are there any other objects that are purged that we should keep around? (workers, etc)

Your site is giving out useful insights into the blockchain.  Is it possible to add the ability to store expired proposals while the devs are implementing a proposal history in the core?

Yes! I will add this before 1.10.10 expires, I think it's high priority
http://cryptofresh.com  |  witness: roadscape

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube

It's always been our intent to transition responsibility for proposals from the init witnesses to the community.  Two conditions are necessary for this to happen:

  • We need to be running a production network long enough to be confident that we won't wish we had the capability to do swift parameter changes to mitigate potentially catastrophic issues.
  • We need a good proposal UI which allows users and committee members to create and inspect committee proposals and vote accordingly.

Right now I think a good GUI for committee proposals needs to be implemented before BitShares is truly ready for self-governance.  But it's still great to see the community experimenting with this feature even though the UI provided by cli_wallet and object inspection leaves much to be desired.

Thanks for giving us a good view of what and how a proposal works.   I am truly excited by this evolution of governance decentralisation.

We can mitigate the two mentioned factors:

1) Having a shorter time to effect a parameter change is fine for the initial phase.  We can always work around this with better communication with the community members.

2) I believe a good proposal UI may not be available any time soon. This can be mitigated.  As BM mentioned in mumble, he encourages Witnesses to step up and become Committee members in the absent of the UI.  Witnesses have the know-how and ability to quickly prepare and submit a proposal to the BTS2 blockchain.  We have active and capable Proxies to communicate the value of the proposal to the community before it is submitted.  Users who support the proposal but unable to do so due to lack of a UI can channel their votes via an active Proxy who votes with the cli wallet on their behalf.

The community has the tool to vote for the changes they need, right now.  It is a dream comes true.   :)


[
It would be great to have proposals stay in the core for now! Are there any other objects that are purged that we should keep around? (workers, etc)

Your site is giving out useful insights into the blockchain.  Is it possible to add the ability to store expired proposals while the devs are implementing a proposal history in the core?
« Last Edit: October 29, 2015, 05:34:28 am by cube »
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline roadscape

Thanks Cube,

Thats what I figured.  I appreciate your confirmation.  I created a new proposal and voted for it.  This one will expire on 11-1-15 at 12:00 UDT http://cryptofresh.com/p/1.10.10 (great site by the way.  It would be good to backup these proposals so we could look at then after they are expired.  Perhaps in a different section so people don't get confused about what is currently available to vote for)
I think I understand how we get approval from 1.2.0 as well.  get_object 1.2.0 returns
Code: [Select]
    "active": {
      "weight_threshold": 28461,
      "account_auths": [[
          "1.2.1191",
          1224
        ],[ 
          "1.2.22517",
          1750
        ],[ 
          "1.2.90742",
          5994
        ],[
          "1.2.90744",
          5994
        ],[
          "1.2.90746",
          5994
        ],[
          "1.2.90747",
          5994
        ],[
          "1.2.90748",
          5994
        ],[
          "1.2.90749",
          5994
        ],[
          "1.2.90750",
          5994
        ],[
          "1.2.90751",
          5994
        ],[
          "1.2.90752",
          5994
        ]
      ],
weight seems to be based upon total votes, and we need 51% of that vote, or  "weight_threshold": 28461 for approval.  So at this point we will need 5 inits to pass anything, and dele-puppy and mindphlux are after thoughts.  (5 inits are 29970)

You are welcome. :)

Object 1.2.0 is the committee account which consists of all the inits, mindplux and you currently.  The total votes is 56920 and a weight threshold of 28461 means that we need more than 50% participation of the total number of committee members to pass the proposal. 

BTS2 is modelling after how a modern democracy works.   +5%

Good info.. +5%

How do members who don't want this proposal to go through vote against it?

There is no way to vote against a proposal.  You can however revoke a previously granted approval for a proposal with "active_approvals_to_remove".

The 'review_period_time - 2015-10-28T11:00:00' is too soon. (Now is "2015-10-28T03:39:48")  I think we need more time for committee members to review and approve it.  Perhaps give it about 5 days at least?

A proposal has an expiration time and a review period.  No new approvals may be added during the review period, and a committee proposal must have "committee_proposal_review_period" seconds (with get_global_properties, you can see it is currently 3600 seconds, or one hour).  A proposed parameter change will take effect at the next maintenance interval after the review period.

We learned through experience in testnets that it would be wise to launch with a short committee_proposal_review_period and centralized control of a quorum of committee members (i.e., putting all the init accounts in the committee) in order to allow us to react quickly when critical problems arise.  (And we were later glad we did.)

And what's with old proposals being inaccessible? get_object(1.10.1 thru 1.10.8) all return "null".. I think there needs to be an easy way to reference previous changes..

Originally we designed to have Graphene consist of a core, which only tracks what's needed for validation, and plugins, which track any historical data users might be interested in (e.g. account transaction history, market price / volume / order history, chain budget history, old proposals, etc.)  According to the original design, witnesses would only run core, users running local wallets would track account history (but only for their own accounts), wallet providers would track account history for their userbase, etc.  You'd be able to change what you track just by reconfiguring your plugins and re-indexing.

That's the theory, but in practice, as the release date approached and we started to worry more about shipping and less about code purity:

  • We've put some things in core that really ought to be in plugins
  • Plugin configuration is a difficult, undocumented, compile-time process
  • Writing plugins is a difficult, undocumented process, even for core developers

I have a ton of improvements in mind to move code to the place in the architecture it should properly go, and greatly simplify and document the process of creating plugins.  Which should lead to a highly modular, configurable experience for any kind of chain state tracking you want to do.  But I can tell you that it's not likely something I'll get to this week, or next week.  Maybe not even next month.

For now, I can add proposal tracking to core.


It would be great to have proposals stay in the core for now! Are there any other objects that are purged that we should keep around? (workers, etc)

And thanks for the other clarifications.. all VERY useful now that we're trying to figure out how to pilot this thing...
I'll keep updating the interface as I digest this new info.. I agree that GUI for proposals is critical.
http://cryptofresh.com  |  witness: roadscape

Offline theoretical


It's always been our intent to transition responsibility for proposals from the init witnesses to the community.  Two conditions are necessary for this to happen:

  • We need to be running a production network long enough to be confident that we won't wish we had the capability to do swift parameter changes to mitigate potentially catastrophic issues.
  • We need a good proposal UI which allows users and committee members to create and inspect committee proposals and vote accordingly.

Right now I think a good GUI for committee proposals needs to be implemented before BitShares is truly ready for self-governance.  But it's still great to see the community experimenting with this feature even though the UI provided by cli_wallet and object inspection leaves much to be desired.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical


There are actually two different layers to what's going on here:  The proposal system, and the chain parameter changes.

The proposal system:  The proposal system is essentially a way to broadcast unsigned or partially signed transactions on the blockchain itself.  You don't need to be a committee member to use proposed transactions; Alice can create a proposed transaction saying "Bob transfers 100 BTS to Alice" and then broadcast it as a proposed transaction; the transaction then doesn't take effect until Bob signs it.

Proposals are intended to make multisig user-friendly, for example, if you have an account X which requires signatures from A, B, and C, you can have anyone propose "I propose X transfers 1,000,000 BTS to Y."  Since the proposal appears on-chain, with suitable wallet support anyone who hasn't signed can get some kind of alert in their wallet advising them a transaction is awaiting their approval.

Once we had proposals implemented (it is general and any operation can be proposed, not just transfers), we created a special operation (committee_member_update_global_parameters_operation) which can only be executed by a special account (the committee account), whose authority is always the set of currently active committee members.  Further committee_member_update_global_parameters_operation can only be executed in a proposal, and any proposals by the committee account have to have a minimum review period as specified in the global_parameters.

The review period is designed as checks and balances to prevent "ninja proposals," i.e. proposals pushed through quickly by the committee without any chance for community input.  If a majority of the committee members collude and vote for a proposal that will harm the network, the BTS holders can vote them out during the review period.  The decision of whether to implement the proposal or not actually happens at its expiration time.  So a committee member's vote won't count if they voted for the proposal and then lost their committee seat before the expiration time.  And a new committee member can't vote for any proposal which is in its review period when he gains his seat; votes can only be added to proposals before the review period.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

How do members who don't want this proposal to go through vote against it?

There is no way to vote against a proposal.  You can however revoke a previously granted approval for a proposal with "active_approvals_to_remove".

The 'review_period_time - 2015-10-28T11:00:00' is too soon. (Now is "2015-10-28T03:39:48")  I think we need more time for committee members to review and approve it.  Perhaps give it about 5 days at least?

A proposal has an expiration time and a review period.  No new approvals may be added during the review period, and a committee proposal must have "committee_proposal_review_period" seconds (with get_global_properties, you can see it is currently 3600 seconds, or one hour).  A proposed parameter change will take effect at the next maintenance interval after the review period.

We learned through experience in testnets that it would be wise to launch with a short committee_proposal_review_period and centralized control of a quorum of committee members (i.e., putting all the init accounts in the committee) in order to allow us to react quickly when critical problems arise.  (And we were later glad we did.)

And what's with old proposals being inaccessible? get_object(1.10.1 thru 1.10.8) all return "null".. I think there needs to be an easy way to reference previous changes..

Originally we designed to have Graphene consist of a core, which only tracks what's needed for validation, and plugins, which track any historical data users might be interested in (e.g. account transaction history, market price / volume / order history, chain budget history, old proposals, etc.)  According to the original design, witnesses would only run core, users running local wallets would track account history (but only for their own accounts), wallet providers would track account history for their userbase, etc.  You'd be able to change what you track just by reconfiguring your plugins and re-indexing.

That's the theory, but in practice, as the release date approached and we started to worry more about shipping and less about code purity:

  • We've put some things in core that really ought to be in plugins
  • Plugin configuration is a difficult, undocumented, compile-time process
  • Writing plugins is a difficult, undocumented process, even for core developers

I have a ton of improvements in mind to move code to the place in the architecture it should properly go, and greatly simplify and document the process of creating plugins.  Which should lead to a highly modular, configurable experience for any kind of chain state tracking you want to do.  But I can tell you that it's not likely something I'll get to this week, or next week.  Maybe not even next month.

For now, I can add proposal tracking to core.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
Thanks Cube,

Thats what I figured.  I appreciate your confirmation.  I created a new proposal and voted for it.  This one will expire on 11-1-15 at 12:00 UDT http://cryptofresh.com/p/1.10.10 (great site by the way.  It would be good to backup these proposals so we could look at then after they are expired.  Perhaps in a different section so people don't get confused about what is currently available to vote for)
I think I understand how we get approval from 1.2.0 as well.  get_object 1.2.0 returns
Code: [Select]
    "active": {
      "weight_threshold": 28461,
      "account_auths": [[
          "1.2.1191",
          1224
        ],[ 
          "1.2.22517",
          1750
        ],[ 
          "1.2.90742",
          5994
        ],[
          "1.2.90744",
          5994
        ],[
          "1.2.90746",
          5994
        ],[
          "1.2.90747",
          5994
        ],[
          "1.2.90748",
          5994
        ],[
          "1.2.90749",
          5994
        ],[
          "1.2.90750",
          5994
        ],[
          "1.2.90751",
          5994
        ],[
          "1.2.90752",
          5994
        ]
      ],
weight seems to be based upon total votes, and we need 51% of that vote, or  "weight_threshold": 28461 for approval.  So at this point we will need 5 inits to pass anything, and dele-puppy and mindphlux are after thoughts.  (5 inits are 29970)

You are welcome. :)

Object 1.2.0 is the committee account which consists of all the inits, mindplux and you currently.  The total votes is 56920 and a weight threshold of 28461 means that we need more than 50% participation of the total number of committee members to pass the proposal. 

BTS2 is modelling after how a modern democracy works.   +5%
« Last Edit: October 28, 2015, 05:33:59 pm by cube »
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
Thanks Cube,

Thats what I figured.  I appreciate your confirmation.  I created a new proposal and voted for it.  This one will expire on 11-1-15 at 12:00 UDT http://cryptofresh.com/p/1.10.10 (great site by the way.  It would be good to backup these proposals so we could look at then after they are expired.  Perhaps in a different section so people don't get confused about what is currently available to vote for)
I think I understand how we get approval from 1.2.0 as well.  get_object 1.2.0 returns
Code: [Select]
    "active": {
      "weight_threshold": 28461,
      "account_auths": [[
          "1.2.1191",
          1224
        ],[ 
          "1.2.22517",
          1750
        ],[ 
          "1.2.90742",
          5994
        ],[
          "1.2.90744",
          5994
        ],[
          "1.2.90746",
          5994
        ],[
          "1.2.90747",
          5994
        ],[
          "1.2.90748",
          5994
        ],[
          "1.2.90749",
          5994
        ],[
          "1.2.90750",
          5994
        ],[
          "1.2.90751",
          5994
        ],[
          "1.2.90752",
          5994
        ]
      ],
weight seems to be based upon total votes, and we need 51% of that vote, or  "weight_threshold": 28461 for approval.  So at this point we will need 5 inits to pass anything, and dele-puppy and mindphlux are after thoughts.  (5 inits are 29970) 
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
I think you created the previous proposal correctly.  The only thing is it expired without sufficient committee members voting for it.

Code: [Select]
approve_proposal <committee_member> "1.10.1" {"active_approvals_to_add" : ["init1", "init2", "init3", "init4", "init5", "init6", "init7", "init8", "init9", "init10"]} falsethrows an error unless I run it as
Code: [Select]
approve_proposal dele-puppy "1.10.1" {"active_approvals_to_add" : ["dele-puppy"]} false

You do not 'own' the inits and that is why 'approve_proposal with the inits' will throw an exception - "You do not have the authority..." or something like that.

from the intructions on http://docs.bitshares.eu/user/Committee.html I would expect it to be
Code: [Select]
approve_proposal <committee_member> "1.10.1" {"active_approvals_to_add" : ["init0","init2", "mindlphlux", "init4", "init5", "init6", "init7", "init8", "init9", "init10"]} false but that didn't work. 

I also had to change all the booleans to true from http://docs.bitshares.eu/user/Committee.html to get anything to work.

The boolean was set to 'false' tells the bts2 system not to broadcast the transaction.  Setting it to true will broadcast the tx.

Let's try again.  I hope more committee members can be voted in and support the proposal.
« Last Edit: October 28, 2015, 04:56:42 pm by cube »
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
That is a good thing.  As much as I would like the fee to be lower, being able to set any of those parameters with just mindphlux and myself would be a scary scary thing.  I'm currently running a testnet which has a completely different fee structure. last night I did a get_global_properties from the wrong terminal and got this testnets fee structure instead.  As I saw basic account creation at 0 and a scale of 1000, I started to panic a little bit.  I thought I had entered something wrong, or something like that.  Anyways I am glad I do not have the authority to change any parameters all by my lonesome.  I will try another proposal with more more time until it takes effect. 
@mindphlux, how do I set up which approvals are needed?
Code: [Select]
approve_proposal <committee_member> "1.10.1" {"active_approvals_to_add" : ["init1", "init2", "init3", "init4", "init5", "init6", "init7", "init8", "init9", "init10"]} falsethrows an error unless I run it as
Code: [Select]
approve_proposal dele-puppy "1.10.1" {"active_approvals_to_add" : ["dele-puppy"]} falsefrom the intructions on http://docs.bitshares.eu/user/Committee.html I would expect it to be
Code: [Select]
approve_proposal <committee_member> "1.10.1" {"active_approvals_to_add" : ["init0","init2", "mindlphlux", "init4", "init5", "init6", "init7", "init8", "init9", "init10"]} false but that didn't work. 

I also had to change all the booleans to true from http://docs.bitshares.eu/user/Committee.html to get anything to work.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
Proposal 1.10.9 is now nowhere to be found.. so what happened? Did it take effect?

The time now is '"2015-10-28T14:56:18".  I think it expired on

Code: [Select]
"expiration_time": "2015-10-28T12:00:00"

It did not take effect.  The fee remains.

Code: [Select]
            "basic_fee": 9500000,
            "premium_fee": 200000000,
            "price_per_kbyte": 100000


The last time I saw it when it was still alive:
Code: [Select]
    "available_active_approvals": [
      "1.2.1191",
      "1.2.22517"

Two committee members (mindphlux and dele-puppy) voted for it.  Apparently, it is not enough.

It needed more committe members to vote for it.
« Last Edit: October 28, 2015, 03:03:48 pm by cube »
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline roadscape

Proposal 1.10.9 is now nowhere to be found.. so what happened? Did it take effect?
http://cryptofresh.com  |  witness: roadscape

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies

    • BUT any proposal can also be rejected by shareholders within the review period? If so, how?
    [/list]

    Vote the Committee member who made the proposal out within the review period. The review period should be 14 days.
    The Committee member can specify what other Committee members are required for approval - if those Committee members do not approve, the proposal is not valid, if I'm not mistaken.

    puppy has not designed any Committee members that are required to approve, so it could go through if he's not voted out before the review period ends.

    Interesting.

    Just when you think you have it figured out.
    https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads