Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

I think I had at most ~100K genesis block BTS.  I believed in the product so I shorted the hell out of USD -- but that turned out to be almost exactly when the exchange rate was at its peak.  I got margin called when I was in the process of moving to Virginia -- something you wanted me to do -- and didn't have time to check the markets every day.

I had to ask you for AGS funds just to get enough BTS to register my 100% delegate.

I'll have to consume a substantial portion of my 1M BTS bonus to eat over the next couple months.

If I had a guarantee that I'd be able to run a one hundred percent delegate indefinitely, then I would be able to include the NPV of a 100% delegate's future earnings in my compensation.  However, you've publicly stated that you want developers to burn any delegate income in excess of a market salary, and I assume shareholders will side with you -- I'd have no way to keep them from reneging on any promise they make now not to fire my delegate if I continue to operate at 100% after BTS value goes to the moon.

This argument does not apply to me.

I've been meaning to make the BitShares directory read-protected by default on UNIX-like OS's since October -- https://github.com/BitShares/bitshares/issues/856

And now it's in the develop branch

(as you rightly pointed) the config.json file needs to be read-protected with its own user account, which makes it less immediate to setup

Speak for yourself.  I've been running the BitShares client in its own user account since the beginning.

Which reminds me, I've been meaning to make the BitShares directory read-protected by default on UNIX-like OS's since October -- https://github.com/BitShares/bitshares/issues/856

We should also make the issuer-specified authority a slate [1] instead of an account / address.  Then the median of the feed values will be used, and a positive majority [2] of the feed authority can update the effective slate [3].

The UIA owner should also have the right to set the feed authority slate to any value, but will be able to permanently relinquish that right by publishing a transaction [4].

The idea is to allow a UIA to function at small scale with a feed managed by a small group of enthusiasts or even a single individual person.  But when the market starts to gain traction and network effects, the manager should be able to hand off control to a decentralized collective.  Then the membership of that collective should be allowed to evolve over time by consensus of its members.  The power to select the feed authority should not be given to the long holders of the UIA, because they would have an incentive to elect a feed authority that artificially inflates feed prices (in the worst case simply setting the feed to a bogus enormous valuation to cause a black swan and allow the long holders to loot all of the short holders' collateral).

[1] Internally, a slate is just a set of up to 101 accounts.  This currently is simply a size optimization to de-duplicate multiple votes for the same set of delegates.  I'm simply re-purposing the existing "published set of up to 101 accounts" functionality.

[2] "Positive majority" means "more than 50%", in other words exactly 50% is not enough.

[3] Letting a majority of the current authority slate vote for a new authority slate is not really giving them any powers they don't already have de facto, since a positive majority would be able to collude to set the median to any value anyway.

[4] Code which implements revocable UIA owner rights already exists in the develop branch and is planned for inclusion in the 1.0 hardfork.

If you like this proposal, please vote for my delegate dev0.theoretical which is currently hanging on at #101.

The BTS delegates have what I call feed authority which means the blockchain enforces margin call and short wall rules based on the median feed value produced by the BTS delegates.

I think anyone should be able to create a market-based UIA and optionally specify a feed authority other than the 101 BTS delegates.

This will democratize BitAsset creation -- instead of requiring all ideas for BitAssets to go through the BTS delegates in order to launch, anyone with an idea and access to a data source will be able to create a market-based BitAsset.

To pay the costs of publishing a feed, we should let the asset owner [1] specify a percentage of asset-denominated fees [2] to go to feed publishers.  Since publishing a feed will produce revenue, feed publishers will be able to sustainably pay their IT costs and transaction fees for publishing without diluting new BTS or touching BTS-denominated transaction fees.

There will probably a "long tail" of experiments and small-scale markets, and a few big winners that end up gaining traction and network effects.  All of them will provide value to BTS shareholders since these assets will tie up collateral BTS equal to the market cap times the required leverage ratio (and of course generate transaction fees from feeds and actual transactions as well).

[1] N.b. the asset owner is not the issuer; new asset quantities are issued in the market by shorting.

[2] Bid-ask overlap and short interest.  Even though this is a BTS-backed market-issued asset, we have to be careful about allowing users to pay tx fees with it.  In particular we must go by the actual collateral backing rather than feed price, because an attacker Eve would be able to create a private EVIL asset with herself as the feed issuer, publish an EVIL feed of 1 EVIL = 0.0001 BTS, short e.g. 100 EVIL into existence with a total of 0.03 BTS collateral, and then set the EVIL feed to e.g. 1 EVIL = 1,000,000 BTS.  If the blockchain uses the feed as the effective exchange rate for fees, Eve would be able to use 100 EVIL to pay 100,000,000 BTS worth of tx fees, even though the total BTS she invested to get to this point was only one UIA registration fee and a few tx fees.  Whereas using the collateral backing for the exchange rate, we know the exchange rate is based on real BTS that actually exist, not a fictional valuation based on a user-initiated black swan.

So AGS funds aren't gone?

I'm sorry.  I stated,

I believe AGS funds are the ultimate source.

but this is pure speculation from my personal understanding.

Here is what I actually know:

- I submit an invoice to I3 for the rate bytemaster and I negotiated, add a discount to the invoice based on my delegate earnings, and receive an old-fashioned paper check for the difference from I3.

- I deposit the check in my old-fashioned fiat bank account and receive US dollars when the check clears.

- Those dollars come from I3 because "Invictus Innovations, Inc." is on the check.

Here are the limitations of that knowledge:

- I am a software developer, not an accountant.

- Past public statements made by Stan and bytemaster on this forum led me to believe that "I3 = AGS funds."

- This confusion has persisted in my mind since December 2013.

- Whenever I've said "AGS funds" in this thread, I likely actually meant "I3 funds".  I have tried to edit my post to make this clear.

- I have not read the latest disclosures about I3's current, past or future funding sources.

- I have not kept up with I3's public or private accounting of AGS funds.

Transparency here is like looking through a brick wall.

No, the problem is I'm being too transparent.  I'm trying to actually answer your questions about how I'm funded, which has led to me saying things based on my own personal understanding (apparently out-of-date) about how I3 is funded.

The article says delegates receive transaction fees over two weeks.

As clarification, this is not what happens in the current code.  Currently all transaction fees are burned.

However, we did distribute transaction fees to delegates in past versions, and we currently plan to re-enable this functionality at the 1.0 hardfork.

Since the block rewards issued to delegates will decrease over time, giving them transaction fees is necessary to future proof the network.