5:30 - BitUSD is great, DACs not so. If only he was still onboard and we had listened to him. Then our core value proposition could have been much further ahead and usable by now.

Quote from: delulo on January 02, 2015, 09:28:31 pm

Quote from: Gentso1 on January 02, 2015, 08:03:46 pm

I think  everything Op has said is great and we should support their team with a delegate or 2 IF/WHEN
They have sealed the deal and are working with a bank......Once they get the green light from the bank THEN all that development needs to happen not the other way around.

I am just trying to understand. I do welcome it A lot.

Where did the OP say that bank relationships are worked on?

Good news guys!

We have an agreement with the bank and now we can move forward with the development.

Our goals:
 - Enable bitUSD deposits
 - Have On/Off ramp with Bitcoin and supported cryptocurrencies
 - Have On/Off ramp with EUR
 
Then 50% funds will be used to give a signup bonus (10 bitUSD) for all new customers who make their first bitUSD or bitcoin purchase.

As soon as our delegate get approved we will dedicate to it a full time developer.

Great, more concerns are being mixed into delegates. They are becoming a catch-all for every role. We need to separate concerns.

The best person to be a block producer is not the best person to act on the PR board or make decisions about the future of the blockchain (a board of directors) who is also not the best person to execute those decisions (developers, marketers).

To separate concerns we will need stake-based proposal voting on the blockchain. It is an acceptable hack to add these roles to the delegates for the time being until such a proposal voting system is built. But I think it is essential to eventually build proposal voting support into the client and I think it is a mistake to keep overloading the tasks of the delegates for too long.

I would like to see the delegates eventually only act as block producers and the authority to submit binding proposals / dynamic parameter changes (some of which may require a quorum of stakeholders to approve before they become ratified).

Generalized BitAssets would allow the creator of the BitAsset to specify a name, margin call limit, collateral asset type, expiration period, initial description, initial feed price definition, and initial authority. If a certain quorum of the current authority agrees, they could change the description, authority, or feed price definition.  The feed price definition could be a mathematical expression dealing only with multiplication and division operations and terms that are either constants or price feed sources. The authority can optionally be set to the dynamic set of top 101 delegates. Anyone could create a price feed source which defines an initial authority, the initial feed providers, and some additional parameters governing price feed aggregation. If a certain quorum of the current authority of a price feed source agrees, they could change the authority or the feed providers of the source. The feed providers regularly publish prices into the price feed source and a median of those provided prices is used to determine the latest price of the price feed source (there are other details left out such as how a price feed source determines if a price is stale and should be ignored). Either the authority or feed providers of the source or both could optionally be set to the dynamic set of top 101 delegates. Until generalized BitAssets are built, the price feed of BitAssets can be hard-coded to come from the median of the delegate price feed submissions as they do today.

Binding proposals submitted by a majority of the delegates would allow for changing certain dynamic parameters in the blockchain (e.g. minimum transaction fee, asset registration fee, etc.) as well as hiring and firing workers (who would not necessarily be delegates) or changing their salary. If the new total pay of all workers is within the current budget limit, these "worker change" binding proposals become ratified by only a super majority approval of the delegates (who will typically merely act as a proxy for the decisions of the board of directors, to be discussed below, who in turn are guided by the wishes of the shareholders via non-binding proposals). If the budget limit needs to be increased, a "budget limit change" binding proposal can be submitted by a majority of the delegates and ratified by approval from the necessary quorum of shareholders. Until such functionality is enabled, workers will just use helper delegates and get paid from a fraction of their delegate pay (as is done today), and other parameters of the blockchain can only be changes through hard forks (as is done today).

Finally, non-binding proposals would allow the stakeholders to add and remove members (they don't have to be delegates) from the board of directors group (by add and remove, I mean conceptually, since these are non-binding proposals and so the set of board members is not actually known to the blockchain itself). This board of directors would be privy to the internal discussion of key workers (such as the core developers) and future plans for the BitShares ecosystem. They would approve of the release of PR-vetted information out to the public. They can delegate the task of PR vetting to another PR review board better suited to handling that task (which can include a subset of the board of directors as well as other trusted members outside the board) but at the end of the day each board member is the one who has to put their seal of approval (or not) on releasing information to the public (so the shareholders can know who to vote out if necessary). Also, some of the internal deliberations surrounding the decision that was made public should also be publicly released (potentially redacted if necessary) so the shareholders can better know who to vote out of the board and who to keep. Finally, some decisions that are more controversial, but that the board nevertheless agrees is important to reach a consensus on, can be released as an official proposal (not an official final decision) to the public, and they should rely on non-binding proposal voting by the shareholders to determine whether the proposal is ratified (thus becoming an official decision) or not.

In this system, as long as the delegates do a good job at producing blocks (and potentially also providing price feeds) and also follow the chain of command when submitting and potentially approving binding proposals (such as worker-related changes or changes to dynamic parameters on the blockchain like transaction fees), they can be fairly confident that they won't be voted out. By following chain of command, I mean that they keep track of who the members of the board of directors are and how much quantitative influence each has in decision votes (to be determined by following the results of related non-binding proposals that have the necessary approval by shareholders) and that they follow the public final decisions made by the current board of directors that have some predefined quorum of their approval. Shareholders provide a check and balance on the board of directors through the use of non-binding proposals to replace board of director members if necessary. Also certain significant binding changes to the blockchain, such as "budget limit change" proposals and eventually "hard fork" proposals, would require enough of the shareholders' direct approval votes in order to be ratified and actually make the change happen on the blockchain. If some delegates are not respecting the changes to the board of directors made through the non-binding proposals, the shareholders can always vote out those delegates and replace them with delegates who will follow the official chain of command.