Burning supply to pay a dividend works well with an asset like BTSX, where you create a fixed amount, and then burn them over time.


But the way that bitUSD is created and destroyed is different.  Opening a new short creates bitUSD.
Closing the short removes the bitUSD.  Every short must be closed within 30 days, so whenever a bitUSD is created, that bitUSD will be destroyed within 30 days.


If you wanted to pay dividends by burning bitUSD then here is what would happen:


* People short, creating 1 million bitUSD.
* 1000 bitUSD are burned for the yield, resulting in 999,000 bitUSD remaining.
* People now need to cover the shorts by buying up 1 million bitUSD, but only 999,000 remain! 

The result is that it is not possible to cover all the shorts.  The price would go to infinity as the short was forced to buy bitUSD that did not exist.


This would be a reverse ponzi.   100% of the initial collateral that the shorts used to create bitUSD would be given to the buyers of the bitUSD.  The late adopters would get everything and the ones who originated the bitUSD would lose everything.   Lol!

Try this thought experiment: in the current system, what happens if someone throws away the private key to some bitUSD? Does that cause the price to go to infinity since shorts now have to buy supply that no longer exists?

The economics of money supply/demand can be pretty tricky, but the simplest way to see it is that burning/losing supply is exactly the same as distributing proportionally to all other supply holders.  You are right that the uniqueness with bit assets are the way they are created, and that's why you have to use the yield accumulator to adjust the feed price as supply is burned, ensuring a stable equilibrium.

Will be pretty awesome if ccedk implement it. I for one will be ready to provide some bitUSD liquidity against fiat currency.

Rather than distributing yield in some hack way that doesn't pay every bitAsset holder equally, I believe a more graceful method is to simply use the same kind of system that delegates use to pay "dividends" to BTSX holders: by burning supply.

The obvious issue this creates, is the decoupling of the bitAsset peg, as it appreciates due to the limited supply. My proposal is to use underlying  deflationary supply tokens to handle the actual transactions on the network level, and then use a locally calculated variable, the yield accumulator, to transform the supply tokens into front-end bitassets, and continously update the yield of the bitAsset in the client. The second important function of the yield accumulator is to transform the price feed from real world asset price into supply token price.

This has a number of advantages over other solutions that distribute yield through transactions to every bitAsset holder:

1) It takes the lowest amount of network resources, increasing max TPS of the market.

2) It distributes yield instantly in real time to every bitAsset holder. This will have some marketing benefits since it means your bitAsset holdings will begin to tick upwards literally within 10 seconds of buying them in the client (assuming a busy market).

3) It is non-gameable by bots or clever people with spreadsheets, because of the instant yield allocation. I.e. you cannot get an unfair share of the already accumulated yield by getting in or out of the market at good times.

4) Due to number 3, every bitasset holder will gain the same yield over time, making it an ideal savings vehicle even for normal non-tech, non-trader people.

5) Exchanges that don't implement the supply token to bitAsset transformation will be nice visual demonstrations of the yield over time, possibly providing positive marketing. bitAsset sales pipelines for average people will of course have the transformation implemented, so average people will not be confused by the increasing price.

To simplify things, I will use bitUSD as the example for explaining the system. To make it work we need to convert all current bitUSD into stUSD, the bitUSD supply tokens. bitUSD instead becomes the way the average user interacts with the supply tokens. Initially, bitUSD supply tokens will have identical value to bitUSD, and can be shorted into existence at the feed value of USD, since no yield has been distributed yet.

When fees are paid or shorts are covered, the yield is burned in a special transaction, since burning supply has the same economic effect as distributing the supply proportionally to all other supply holders (assuming the market follows standard microeconomic rules). To keep track of the price increase that this creates, we use a variable called the yield accumulator, A_y. The advantage is that this variable can be calculated locally by each client, lessening network load. It can also be benchmarked in blocks at regular intervals, such as every 30 minutes, for lightweight clients.

A_y is updated each new block by calculating the amount of supply tokens burned proportional to total supply, and thus the average price increase, into a variable called the yield increase I_y.

I_y = n_stUSD/(n_stUSD-n_{stUSD, burned})-1

Where n_stUSD is the current stUSD supply and n_{stUSD, burned} is the amount of stUSD burned this block.

This variable is then added onto A_y each new block, accumulating the total proportional price increase of stUSD (lifetime yield) into the yield accumulator.

A_{(y, blockn + 1)} = A_{(y, blockn)} + I_{(y, blockn+1)}

Whenever at user interacts with bitUSD in the client, A_y is used to transform his orders into stUSD orders with some simple linear relationships:

n_bitUSD = n_stUSD * A_y
price_bitUSD = price_stUSD / A_y

After the commands have been sent to the network, they are dominated solely in stUSD. The price relationship is also used to determine the feed price of stUSD:

feed_stUSD = feed_USD * A_y

After the delegate making a block has determined the A_y, he will apply it to the average USD price feed and then determine if any shorts are executed. I guess he will have to ignore the increase in stUSD amounts, so the effect of shorts in block n will be added to the I_y and thus A_y of block n+1.

Any feedback? I guess some people will criticize the idea of using an underlying asset that differs from bitUSD as being more confusing than the current system, but I think that as long as the user experience does not show it to the user in any way (unless they want to see it), and the average user interacts only with bitUSD, this system will be superior for non-techy users, since they will not be at a disadvantage to bots when it comes to yield distribution. I think fairness and openness in the yield distribution should be bitAssets number 1 priority, the second being user experience. Like I mentioned earlier, I think this proposal also helps the user experience due to the real time, instant yield.

How can you trade something like bitAAPL or other virtual stocks on bitshares, won't the peg break whenever dividends are issued?

I don't see any problem with the name

BitSharesX - kinda as in Exchange, just like ForeX.

BitShares is just the family name

BitShares Music
BitShares DNS
BitShares WhatsNext

Indeed there was a debate on this a while back but have not searched back for it, but this was my understanding from it all.
Oh BitShares Music tokens are called Notes I believe.

Right, you don't see a problem with the name, but that doesn't change the fact that new users do. Also, a name that has to be explained like you just did is inherently bad.

I think inflation should only be implemented on one-time basis. I.e. getting the supply inflated would require a big campaign that mobilized a majority of voting stakeholders, and would be voted on in several rounds. This would make the basic inflation "block" a project - something that would be very easy to do transparent accounting on. The newly inflated funds from a project would not be released instantly, they would be given over a predetermined time period.

In the beginning, there would be smaller projects where people experiment with what is actually a net benefit on share price. As project leaders build up community trust, they can begin to do more longterm, or widereaching projects. If a project leader ever messes up or turns out to be corrupt, it will be easy to inform the community and his current "project pool" can be wiped, so that he has only been able to waste what was released beforehand.

This gives the advantage of trickling inflation, without having the risk of slow, perpetual debasement of the share price.

The naming/branding was extensively debated many months ago (well before the release).

I'd say it is not the time to re-open the debate.

On the contrary, I think it is crucial to find out if the DAC and community has the capability to rebrand itself and carry out largescale votes of consensus on a singular, important topic, before we start largescale marketing. We might later find ourselves in a situation where the entire community might need to mobilize itself in order to achieve some shared goal, I'd say a namechange would be the ideal way to practice this, since it doesn't involve changing any actual system or code.

To be honest, if in-spite of all the innovations behinds BitSharesX, the name was the only thing that stopped you from committing, perhaps BitSharesX isn't for you...

This is not a counterargument.

If an arbitrary name is more important to you than maximizing adoption, shareholder worth and chance of success, perhaps BitSharesX isn't for you...