I propose 101 "technical delegates" as currently, plus up to 101 "business delegates"

This proposal was unexpectedly contentious.  The key words are up to -- I expect the number of business delegates at any one time to be very far below the limit.  I don't think there are anywhere near 101 organizations currently operating within the BitShares space whose models justify inflation.  I'm not sure that there will ever be anywhere near 101 organizations that we want to be funding directly from inflation.

The 101 number was intended to be more along the lines of a technical protocol-level limit.  Initially recipients of the inflation would likely be I3 and perhaps one to three other key partners.

But if we get a couple more solid partners, we don't want to be in a situation of "A quorum of shareholders agrees this fifth partner would really help us, but the code really can't support more than four, so to add them we have to kick somebody out, oh noes what do we do?"

I am on board with bytemaster's suggestion for future DAC's.

I would even go so far as to say we could even increase max delegate pay in BTSX without breaking the social contract, so long as the total delegate pay never exceeds total fees / burn.

But I am worried about arhag's objection [1] that delegates with support from a substantial minority of the network may be able to game the system and introduce a level of inflation that is neither justified by their activities nor approved by a majority.

How about having each balance vote for a desired overall inflation cap as well as a slate of delegates?  Then we can determine a "consensus inflation cap" as the point where 50% [2] of outstanding shares have approved that cap or some higher cap.  We can implement this by giving only e.g. 256 choices for the desired inflation cap, and keeping track of the number of votes for each choice.  Then you sum the table from highest inflation cap down, stopping when you've accumulated more than 50% of the total share supply -- the inflation cap at which that happens is the maximum desired inflation the shareholders are willing to tolerate.

If all delegates' requested funding can be provided within the inflation cap, then everything is OK.  Otherwise, we adjust the delegates' pay rates downward proportionally [3] until the effective inflation level is equal to the consensus level.  And prominently display some "WE ARE IN A BUDGET CRISIS" banner on everyone's client until the situation is resolved, which happens when:

- Some or all delegates reduce their requested funding levels so the inflation cap is no longer exceeded ("management cuts costs to avoid shareholders' wrath")
- Shareholders agree to more dilution by adjusting their inflation cap upwards ("shareholders approve management's request for greater funding")
- Shareholders vote out delegates with high funding requirements in favor of delegates with lower expenses ("shareholders fire management for blowing the budget")

The banner would fight voter apathy by serving as a call to action to all delegates and shareholders that now is a time to get involved in the debate and examine your votes, regardless of which of the above policy choices you support.

[1] https://bitsharestalk.org/index.php?topic=9452.msg122842#msg122842

[2] Instead of 50%, you could make this a parameter MAX_INFLATION_QUORUM and require e.g. 55%, 60% or 66.7% quorum to set the inflation cap.

[3] Other downward adjustment schemes are possible, where e.g. the pay of the delegates with the most recent raises is cut first, or there is some explicit prioritization of delegates.  These likely would be additional implementation complexity for unclear benefits.

The system's current implementation relies more heavily on feeds than the original design.  Frequent publishing of feeds will increase the stability and integrity of the system.

However, AFAIK currently delegates must pay a transaction fee to publish a feed.  I think a delegate who has published fewer than, say, 200 feed updates in the past 72 hours should be able to publish a feed update for free (no tx fee).

The quota should be high enough to allow delegates to allow rapid response in volatile market conditions, but low enough that all delegates regularly filling their quotas would still use only a negligible amount of blockchain storage.

Scripts should still defer publishing updates due to tiny price movements, to conserve quota which can be "bursted" if a volatile condition occurs later.

Thoughts?

I was thinking some more about my above post.  I realized that, instead of pulling a table of numbers out of thin air, we can derive the curve from geometric-random-walk theoretical model of how prices change over time.  Basically you assume the current price incorporates all available information, and moves based on the cumulative effect (sum) of a bunch of small random events.  Which means the price at time t will be drawn from a Gaussian distribution with mean equal to the current price and standard deviation proportional to sqrt(t).  But this happens in log-space since investments compound, so it's actually log(price) that's Gaussian with standard deviation proportional to sqrt(t).  (This is a widely used mathematical model of prices.)

The reason we require 1x collateral is we're trying to confine the probability of a black swan [1] at the expiration time T to some bound p_swan.  I'm pretty sure if you believe the geometric-random-walk model, the log of the margin requirement should actually be proportional to sqrt(T).  Setting the 360-day requirement to be equal to the original table gives us these numbers:

duration   | min_rat
-----------|----------
14 days    | 0.31x
30 days    | 0.49x
60 days    | 0.76x
90 days    | 1.00x
120 days   | 1.23x
180 days   | 1.67x
270 days   | 2.32x
360 days   | 3.00x

[2**math.sqrt(t / 90.0)-1 for t in [14,30,60,90,120,180,270,360]]     # python code to generate above numbers

A 3.0x collateral requirement for a 1-year short implies a 90-day time horizon for 1.0x collateral.  But mathematical models are not reality, and allowing shorts with less than 1x collateral may be controversial in terms of adding black swan risk to the system.  So I suggest using this formula / table, but forcing the minimum collateral to be at least 1x.  The new table is:

duration   | min_collateral    | order_priority
-----------|-------------------|-----------------------
14 days    | 1.00x             | collateral_rat / 0.31
30 days    | 1.00x             | collateral_rat / 0.49
60 days    | 1.00x             | collateral_rat / 0.76
90 days    | 1.00x             | collateral_rat / 1.00
120 days   | 1.23x             | collateral_rat / 1.23
180 days   | 1.67x             | collateral_rat / 1.67
270 days   | 2.32x             | collateral_rat / 2.32
360 days   | 3.00x             | collateral_rat / 3.00

where of course collateral_rat is shorter_collateral / (price * quantity) and min_collateral is the minimum value of collateral_rat required for the short to execute.

[1] An adverse price movement that wipes out the collateral and puts the short "underwater," i.e. the BitUSD that must be destroyed to cover the short is more valuable than the collateral that would be unlocked.

Here's what I'm seeing:

>>> blockchain_market_order_book GLD BTSX
                  BIDS (* Short)                                        |                                   ASKS                                 
TOTAL                     QUANTITY                                     PRICE | PRICE                                        QUANTITY                     TOTAL   COLLATERAL
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0.332047 GLD              12,820.34749 BTSX               0.000025900000 GLD*| 0.000025899355 GLD                     965.27500 BTSX              0.024999 GLD
                                                                             | 0.000025966903 GLD                   3,851.05605 BTSX              0.099999 GLD
                                                                             | 0.000025969500 GLD                   1,155.20130 BTSX              0.029999 GLD
                                                                             | 0.000026072220 GLD                     464.09549 BTSX              0.012099 GLD
                                                                             | 0.000026097390 GLD                   3,831.80077 BTSX              0.099999 GLD
                                                                             | 0.000026100000 GLD                     114.94252 BTSX              0.002999 GLD
                                                                             | 0.000033178535 GLD                     968.99999 BTSX              0.032149 GLD
                                                                             | 0.000033333333 GLD                  30,000.00000 BTSX              0.999999 GLD
                                                                             | 0.000040000000 GLD                  50,000.00000 BTSX              2.000000 GLD
                                                                             | 0.000050000000 GLD                  80,000.00000 BTSX              4.000000 GLD
                                                                             | 0.000780640000 GLD                   1,281.00000 BTSX              0.999999 GLD
                                                                             | 0.000815294933 GLD                   3,679.64999 BTSX              2.999999 GLD
                                                                             | 0.990099009901 GLD                   2,828.00000 BTSX          2,799.999999 GLD
                                                                             | 1.000000000000 GLD                     100.00000 BTSX            100.000000 GLD
                                                                             | 1000.000000000000 GLD                    1.00000 BTSX          1,000.000000 GLD
                                                                             |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                             SHORT WALL                                      |                                   MARGIN                                 
TOTAL                     QUANTITY                          COLLATERAL RATIO | CALL PRICE                                   QUANTITY                     TOTAL   COLLATERAL
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0.032149 GLD              1,241.27413 BTSX                         100001.00 | 0.000017857143 GLD                       6.30000 BTSX              0.000100 GLD   8.40000 BTSX
0.100000 GLD              3,861.00386 BTSX                          80000.00 |
0.099999 GLD              3,860.96525 BTSX                          70000.00 |
0.099899 GLD              3,857.10424 BTSX                          44000.00 |
Center Price: 0.0000259 GLD / BTSX     Maximum Short Price: 0.0000259 GLD / BTSX     Bid Depth: 22,610.63215 BTSX     Ask Depth: 179,249.42111 BTSX     
>>> blockchain_market_status GLD BTSX
{
  "quote_id": 7,
  "base_id": 0,
  "bid_depth": 2261063215,
  "ask_depth": 17924942111,
  "center_price": 2.5899999999999999e-05,
  "last_error": null
}

Top bid isn't executing.  Looks buggy to me!  (Current block is #607787.)

I think this is already possible.  wallet_account_update_registration has a data field which can contain arbitrary JSON data.  You can access it via the "Edit" tab in your account in the GUI.

They are also thinking of being closed source because they are worried we might copy them (due to my comments on this thread).

Will people really trust their crypto-money to a closed-source product?  What would keep the creators from including code that quietly lines their own pockets and dilutes everyone else?