Here is my proposal fully explained. The PDF version is much easier to follow and read. It is available here: http://docdro.id/2OcoImM

This proposal has some really solid concepts and reflects some of the things I have been thinking about. The challenge is preventing the feed from being abused among a few other things.

I have identified the problem, fix to be pushed shortly.

At the right price you will be able to exit.

Quote from: bytemaster on January 25, 2016, 04:46:02 pm

Lack of dilution does not support a price and in fact can collapse it all the way to liquidation price.

Suppose a startup company spent $3 million dollars and three years of development and had so little revenue that it couldn't even fund one developer, but still had some of the best technology and lots of potential value.

Suppose this startup company had bylaws that prevented it from diluting without 100% approval.

Suppose there was a single shareholder that refused to allow dilution.

All work would stop, offices closed, servers shut down until that single shareholder sold to someone who would approve dilution to raise funds.

The longer that shareholder held out the lower the liquidation price would go until finally the price is 0 because the assets of the company were not maintained and all the talent left.

So the question of dilution is really about a game of musical chairs where current speculators want to minimize "sell pressure" so they can exit at a higher price and leave everyone else holding the bag.

My conclusion is that dilution hurts speculators who didn't factor it into their purchase decision. Dilution does push the price down if it is sold, this is identical to selling shares for dollars to hire labor. The more you dilute the larger the "funding round".

But just because dilution, by definition, lowers the price it does not prove that not-diluting will raise the price or prevent it from falling.  Instead, the price will fall because the market knows that dilution is needed to keep the company alive and adapting long enough to find the product / market fit.

In other words, whether you want dilution or not, the price will ultimately reflect the need for investment (aka the need for dilution). In some sense, the longer you delay the more you must dilute to make up for lost time and lower valuations.     

So if the premise is that diluting by $6 million per year when BTS is at $100M is ok, but diluting by $300 thousand per year when BTS is at $5M is not ok then you are essentially saying that once BTS falls below a certain threshold all work should stop and everyone who is left should be powerless to revive their investment by attracting new capital?

So what happens next is that a clone of BTS is created with a new allocation that then attempts to fix all of the problems and realize the value potential of the basic technology. At this point the BTS holders will be lucky if the new investors allocate them a cut at all when they have little financial incentive to do so.

Ultimately, dilution is the means of bringing in new investors to BTS and discouraging them from starting a clone that grants them sufficient ownership to make it worth their time and money.

I think all you're saying is that :
1. You need dilution .
2. You think after all these magical amazing development result that you're so proud of , BitShares will go to zero after stop continue working on it , even BitShares is already significantly lower than Dogecoin(a coin with zero function) or Dash's market cap already . So the translation is , the value of BitShares is contingent on the continue work , and if one day there is no more work , BitShares dies  .

So your future worker proposal's value proposition becomes , "this work will cost BitShares xxx dilution , but keep in mind , its effect won't be sustained if you reject our future proposal" .

I'm not really following .  When you built good DAC software , it doesn't suppose to work that way .
And I don't think a system that runs this way can really be used for major user cases . After all , what if one day the developers go on a trip and don't have time to manually keep it running ? 1 week ? 2 week ? What time do you expect this trip could kill BitShares ?

Can one of your future proposal do something "that even if we left , the valuable work that we've done will provide good strength for BTS , and BTS wouldn't die because of my amazing work ? " ?

I think that's the kind of proposal that people would be gladly vote it in ,  not these "you have to keep paying , or the previous work will be for nothing " .

In fact , let's make it two kinds of worker proposals . The ones that truely strenghthens BitShares and will keep BitShares grow  , and the other ones will contribute nothing just empty promise of adding value to it but even the writer of the proposal doesn't believe it .  People should file their proposal properly in order for a true vote .

I am not saying that dilution is necessary to pay developers to support and maintain the network.  Witnesses are already paid plenty and the network will be fine.  Bug fixes for critical issues will always be funded if they are discovered because otherwise everyone loses everything.

Does the blockchain need us, no it doesn't.   I could be hit by a bus and BTS would continue on.   What the blockchain needs is people working and building on it.  New features alone will not magically solve things.

So please do not conclude that I am saying BTS needs to dilute, instead understand that calling for a blanket end to dilution is not sound thinking. 

If the claim is that the protocol is "done" and all future work on BTS should be for private business models like is done in BTC then I would agree that we shouldn't fund more work. 

I have been actively looking for ways to minimize worker proposals and dilution and be efficient with spending.

Lack of dilution does not support a price and in fact can collapse it all the way to liquidation price.

Suppose a startup company spent $3 million dollars and three years of development and had so little revenue that it couldn't even fund one developer, but still had some of the best technology and lots of potential value.

Suppose this startup company had bylaws that prevented it from diluting without 100% approval.

Suppose there was a single shareholder that refused to allow dilution.

All work would stop, offices closed, servers shut down until that single shareholder sold to someone who would approve dilution to raise funds.

The longer that shareholder held out the lower the liquidation price would go until finally the price is 0 because the assets of the company were not maintained and all the talent left.

So the question of dilution is really about a game of musical chairs where current speculators want to minimize "sell pressure" so they can exit at a higher price and leave everyone else holding the bag.

My conclusion is that dilution hurts speculators who didn't factor it into their purchase decision. Dilution does push the price down if it is sold, this is identical to selling shares for dollars to hire labor. The more you dilute the larger the "funding round".

But just because dilution, by definition, lowers the price it does not prove that not-diluting will raise the price or prevent it from falling.  Instead, the price will fall because the market knows that dilution is needed to keep the company alive and adapting long enough to find the product / market fit.

In other words, whether you want dilution or not, the price will ultimately reflect the need for investment (aka the need for dilution). In some sense, the longer you delay the more you must dilute to make up for lost time and lower valuations.     

So if the premise is that diluting by $6 million per year when BTS is at $100M is ok, but diluting by $300 thousand per year when BTS is at $5M is not ok then you are essentially saying that once BTS falls below a certain threshold all work should stop and everyone who is left should be powerless to revive their investment by attracting new capital?

So what happens next is that a clone of BTS is created with a new allocation that then attempts to fix all of the problems and realize the value potential of the basic technology. At this point the BTS holders will be lucky if the new investors allocate them a cut at all when they have little financial incentive to do so.

Ultimately, dilution is the means of bringing in new investors to BTS and discouraging them from starting a clone that grants them sufficient ownership to make it worth their time and money.

If I had a guess I would say I am one of the largest (if not the largest) whale.

Primary rules for BitShares operations include:

1. All values relevant to the display of the transaction history should be included in the operation.  Namely, the fee must be calculated in advance and explicitly included in the transaction.
2. Existing operations should not be changed if this requires adding additional fields.
3. As long as the FEE * CORE_EXCHANGE_RATE > MIN_NETWORK_FEE_IN_BTS then things should be fine.

The MIN fee is important to prevent spamming of UIAs that have no value.   

What I was thinking is this:

-I create a website where people can create there own bets.
-User A creates a bet with an expiration time (Packers vs Redskins for 2 bitUSD by 10pm 1/10/2016)
-This bet is displayed on the website for anyone to take (only 1 user can take the bet for 2 bitUSD)
-Once the bet expiration time expires, an email notification is sent to each player to settle there bet within 24hrs
-If both players agree on the winner, the money is released from escrow, and sent to the winning player.  Each player can rate each other as well.
-If players disagree, the bet is randomly sent to a UIA holder to make the determination,  The UIA holder receives 10% of the bet for work done. Basically 2 of 3 escrow.
-The UIA holder can also rate each player.
-The UIA would hold value because of it's ability to settle bets and make money.  UIA holders would also be incentivised to make correct decisions in order to attract more players and settle more bets correctly.

I know there are some holes in this, and I believe it needs to be at least somewhat centralized.  Please point out any improvements or show stoppers you see in this.

I really like this simple approach.