I propose to this community this draft creating the Bylaws for the Board of Reputed Signers (BRS) complementing and upgrading the motion previously proposed by our fellow shareholder Sabreiib.
My proposal aims to reach a reasonable consensus after the motion creating RSOT and the following “counter-motion” supressing it.
Main goals of this proposal: “…to promote, protect, direct, control, improve and speed up BCX’s development, supervise all its development effort, decrease third party risks of holding and managing development fund raised by previous token sale (BKS crowdsale or crowdfunding), increase accountability and transparency, improve communication between developers and shareholders.”
I gently ask the help of this community so we can evaluate this Draft.
Please take your time to read, evaluate, contribute, share your ideas, opinions, proposals and lemme know of mistakes found in the text, typos, incoherences, contradictions, etc.
I specially invite @Sabreiib and @Phoenix to manifest their opinions about this proposal so we can get a good final motion that satisfies the needs of all of us…
I tried to keep the text as short as possible, believe me!
I’m just wondering about…
…even after what’s written in Section 14.6 maybe we should replicate your text @ RSOT motion:
After this motion passed, Angela and Jordan should hand over the
remaining development fund(NBT, BTC etc)to this group with
multisignature.
And make it clear that this is not gonna be allowed anymore:
When this group makes a decision(4 out of 6), there will be 10 days
publicity period for shareholders to veto, if no opposite motion is
passed, the decision becomes valid.
If shareholders veto every decision of the Board within 10 days with 50% voting power (5k blocks) this will turn into an inoperative and useless Vetocracy.
I haven’t had time to read or evaluate most of the document, but it appears to be quality work that would be helpful.
Given the tremendous costs that Nu (and B&C) has borne as a result of multisig group failures, I can’t see any set of circumstances that could emerge in the short term that would make it worthwhile to gamble the entire B&C Exchange project on an experimental and unprecedented method of handling funds when more conventional and proven methods are quite adequate. What may be possible is to have the multisig group doing all disbursements of funds, with me transferring modest sums to the multisig group as needed to pay expenses (so that the multisig balance never exceeds $10,000). To put more funds in such a high risk experiment would be irresponsible.
I wish to point out that well defined bylaws are necessary but certainly insufficient to ensure the funds are under shareholder control. With Nu multisig failures, procedures and rules were also very well defined, yet there came a moment in time where the majority of signers unilaterally declared all of those null and void, saying things had changed and the clearly defined procedures and rules were obsolete. So, we have to find a way to ensure that won’t happen again. It destroyed about 90% of the market caps of B&C and Nu, so these are project killing risks we are talking about here. There are well known ways to prevent this kind of rebellion against shareholders. I don’t have time to enumerate them now, but suffice it to say that it involves doing things closer to the way they are commonly done outside of the crypto world. Publicly traded companies don’t generally have issues with employees staging a rebellion against shareholders. There are good reasons for that and we would do well to understand them and replicate them.
The draft motion states that any changes to the provisions of the motion requires 75% consensus, even though only 50% consensus is required to pass the draft motion. Motions cannot prejudice future passage of motions in this way. It may be allowable to pass a motion that requires 75% consensus on all motions, but it seems like such a motion should pass with 75% support itself. In any case, I am firmly opposed to changing the motion passage threshold. There is a “no” bias in our voting system already, making 50% consensus difficult to achieve. This is because the default vote in all blocks is “no”, so if a shareholder is unaware of a motion or abstains from from voting on it, it counts as a “no” vote.
Currently, B&C is an experimental blockchain still under initial development. It is unstable. The latest version doesn’t even work on Windows or OS X. The market cap is hardly over $100,000 and there is little interest in B&C after the Augeas default. These facts render voting on the blockchain unstable. This means under some circumstances it is easier to achieve 50% support than if the blockchain were solid and stable. This is an additional reason not to allow a provision that requires 75% support of any future changes of a motion that passes with a mere 50% support.
One thing we learned from the spectacular failure of Nu multisig groups recently is that there is a strong bias among multisig signers to do nothing. We didn’t have problems with signers colluding to transfer funds in illegal ways or ways that violated our own regulations. Rather, when passed motions clearly required multisig signers to transfer funds to support the peg, most signers did absolutely nothing. They essentially locked down all funds intended for use in liquidity operations, causing the peg to fail until shareholders could take direct action (but that takes time: about a month in this case). Our 3 of 5 groups could only gather 2 signatures and our 5 of 8 multisig group only got 3 signatures, as I recall. With failure occurring in this way, it will be important to reduce the number of required signers in the future. Once we have all other problems worked out, I would like to see 3 of 7, 4 of 9 or 5 of 11 experimented with. The draft motion requires too many m signers (where we speak of m of n signers).
There was no multisig default, Nu simply ran out of funds and the rules for what to do in case of peg failure were poorly spelled out because JordanLee blocked consensus on them. You’re trying so hard to change history, posting about the “AES default” that never happened. Almost dillusional, if i thought youd actually covinced yourself of that fantasy.
Starting to realize that the voting system is flawed are we? Please tell me where it says that a motion cant make rules about future motions? Please tell me where any rules about motions exist, except in some fuzzy kind of unspoken consensus. We make the rules up as we go, thats what motions are. If the motion says 75%, then that’s the rule. It is nowhere near as covoluted of a rule as your motions canceling motions. You opened the floodgates of meta motions and now you’re upset ones other than your own are being voted in.
You’re hiding behind a notion that the blockchain is “unstable”, yet the blockchain just passed a motion empowering motions to provide structure to the DAC. In the same way, you make it out like the multisig is an unstable entity. Electing you and handing you hundreds of thousands of dollars when you had no history with either project was extremely risky and unstable. Trusting a multisig shouldnt phase shareholders in the least.
Spectacular failure of the half baked JordanLee economic structures that were incomplete and slapped together with bubblegum. None of this was a failure of multisig and you do the cryptosphere a great disservice with your doublespeak.
Very much to the point!
The dictator Phoenix, formerly known as JordanLee, is depressed and scared, because some are still giving thought to Nu and even dare opposing him.
I don’t know whether Nu was designed as ponzi scheme, but it presently is run as such.
Opposition risks this ponzi scheme, hence it must be fought - e.g. by trying to rewrite history and trying to put the blame on others while the major reasons for Nu’s (economic) failure were in the design and decisions JordanLee proposed and pushed (e.g. no revenue except dust from tx fees, NSR buyback, high liquidity at close spread).
I seriously wonder how Phoenix can sling mud at others regarding Nu’s failure, while the world knows that he’s just a JordanLee alias. Both aliases decline to answer inconvenient questions, e.g.
Both refuse to learn the appropriate lessons from the past.
Major lesson: you need revenue if you want to survive. If you don’t have revenue (yet), you need to budget to get as far as achieving revenue. I’m dreaming of accounting again, but that would make it hard for Phoenix to play his games.
The most important thing is to get B&C finished, multi-signatured team can be postponed as long as Sigmike gets paid and still works on software development.
What may be possible is to have the multisig group doing all disbursements of funds, with me transferring modest sums to the multisig group as needed to pay expenses (so that the multisig balance never exceeds $10,000). To put more funds in such a high risk experiment would be irresponsible.
I understand your worries, but If we keep 90% of dev fund with one single person (one single point of failure) the third party risk is still hundred times far greater than keeping it with multisig group.
With Nu multisig failures, procedures and rules were also very well defined, yet there came a moment in time where the majority of signers unilaterally declared all of those null and void, saying things had changed and the clearly defined procedures and rules were obsolete. So, we have to find a way to ensure that won’t happen again. It destroyed about 90% of the market caps of B&C and Nu, so these are project killing risks we are talking about here.
I agree that there were some issues with FLOT in the past but FLOT’s duties is much different than the Board of Reputed Signers’. BRS is prohibited of doing liquidity operations of tradings. BRS is only allowed (by these bylaws) to use dev funds in development related tasks. With these bylaws in force it’ll be much easier to supervise and charge BRS’s decisions/operations.
Another difference: by FLOT being a liquidity operations team, it needs to deliberate and take action as fast as possible. BRS does not deal with it that way, there will be time to contest its decisions before dev funds are spent (if necessary) with zero harm.
There are well known ways to prevent this kind of rebellion against shareholders. I don’t have time to enumerate them now
I’d be kindly interested in hearing about those ways…
If there’s consensus about that matter among everyone here, I’d be willing to decrease the necessary 75% consensus to 2/3 (~67%) for these bylaws to pass and for it to be altered/amended in the future.
If we fall to 50% we get stuck in what I mentioned as Vetocracy[quote=“Phoenix, post:6, topic:4783”]
Once we have all other problems worked out, I would like to see 3 of 7, 4 of 9 or 5 of 11 experimented with. The draft motion requires too many m signers (where we speak of m of n signers).
[/quote]
I see your point, in your point of view we’d better trade majority/consensus for speed of deliberation/transaction.
If we get dedicated signers (and I think the already elected members are), I see no problem with these alterations for Section 5.8:
I don’t intend to rush the voting for this motion because this document has several points we need to discuss and reach consensus beforehand.
Although I think even while the Board is not operating by itself, we should adopt what’s enlisted in Article XIII. So we could try to reach more stable development pace and set better chronologic goals for BCX project:
[quote]ARTICLE XIII – ANNUAL STRATEGIC DEVELOPMENT PLAN
13.1 CHARACTERISTICS AND CONTENT
The Annual Strategic Development Plan shall be presented to the shareholders’ evaluation and approval every accounting year. The plan consists of:
(a) Work plan – which detailed steps are planned to be taken in order to reach the goals of development for the year;
(b) Budget – the available funds (development fund), estimate of expenses and revenues (if any) for the year;
That’s why I keep on holding my opinion that we need the dev funds back in BTC so we can keep BCX segregated from the (lack of) revenue troubles of Nu.
Let’s face it: 99% of developers in cryptoworld wanna get paid in BTC. If we speed up BCX development and launch its platform with full trading available soon, Nu’s problems might be minimized. That’s a good decision for both projects.
That’s why I drafted Section 7.5(e):
[quote]7.5 PROHIBITIONS
It’s expressly forbidden for the Board of Reputed Signers and its members:
[…]
(e) to keep development fund in any other cryptocurrency, crypto-asset, crypto-token, other than Bitcoin (XBT) or alternative cryptocurrency (altcoin) that might overcome XBT in liquidity, market capitalization and adoption in the future;
[/quote]
Maybe not…
…developers will accept Bitcoin and will agree to code for it whenever possible no matter what the price is…
…and NSR is broken in its basic essence (it lacks intrinsic value).
I’d also suggest to move BCX’s repository to GitHub (the largest coders community around) in order to aim at more free contributors/coders (people forking BCX’s so we could merge/commit their code).