If you make things "free" then you must limit the supply. This means rate limiting accounts.

You can also set things up so that users "earn" the means to pay.  For example, a competitor to Open Ledger may use free "tweets" as a means of getting users to sign up through their centralized service and then make money on the referral income.  In this case, the OL competitor would give the user the pennies required to pay the fee to the network.   From the user's perspective the tweet is free, but from the network's perspective it was fully paid for.

It is like a website appears free, but the person producing it is still paying for bandwidth.

To help prioritize and/or value various proposals we have created some new assets that act as a pre-sale auction for ownership of various revenue streams.   The first revenue stream is 80% of all confidential transfer fees.  We have registered the STEALTH asset with a maximum supply of 1M shares.  If you are interested in owning a cut of this revenue stream you can place a bid in this market.  Stealth fees will be set to 3x the normal transfer fee set by the committee.

@onceuponatime has an implicit bid of  12 BTS per STEALTH for 1M shares giving STEALTH a market cap of $45,000.   

The purpose of this market is to help prioritize various features and give the more passive members of the community an easy way of evaluating / comparing the various proposals.  Those that have the highest market caps (with sufficient liquidity to fund the development) represent the highest value features. 

For this proposal we have already produced a basic GUI workflow that will be implemented before any STEALTH is actually sold to the market.  At no time will proceeds from this sale be spent prior to delivering of the feature.   If you are interested in stealth and believe it will be a profitable feature for BitShares, then place some bids to show your support.

Once the feature is implemented, ONCEUPONATIME will be given 1M STEALTH which he may choose to sell as he sees fit. 

https://bitshares.openledger.info/#/market/STEALTH_BTS

There are far too many opportunities out there and prioritizing new features for BitShares becomes very challenging.  Polls/Voting, etc are not good means of prioritizing. Profit is perhaps the most important means of prioritizing.

So I would like to take some time to outline a plan I am devising for getting features lined up and prioritized based upon the concept of Fee Backed Assets (FBA).  For each of the following features I will create a UIA that represents stake in the future fees generated from that feature.  Community members / "investors" can place bids in an open auction to buy stake in these features.   These bids will represent current demand for the feature and help establish a price.   Once the price and depth get to a level that we feel justifies building the feature, we will sell the UIA into the buy wall.    We will keep the proceeds of this purchase locked up until the feature is delivered.  When the feature is delivered, the UIA will be converted into a FBA and the proceeds of the sale will become our private property.   

In addition to creating the UIA we will also create a corresponding worker proposal that is symbolic of shareholder support for enabling the feature.  The worker proposal must be funded before we will sell into the buy wall of the UIA.   

BitShares stakeholders will now have price information that indicates how the market values each potential feature.  This price information can in turn be used to inform them on which features they should vote for.   A highly valued feature means that the market believes that feature will generate significant ROI and therefore be profitable for BitShares holders. 

As a company, Cryptonomex is interested in working on the most profitable features.  Those features that we can sell for the highest price will get the highest priority. 

Examples of features for which we will be creating a UIA and/or worker:

1. Bond Market (Poloniex Style Lending)
2. Prediction Market (Auger Style)
3. Ethereum (or something similar) VM integration
4. Liquidity Incentivisation
5. Gambling Systems

The assumption for all features is that a working reference GUI will be provided to make the features accessible.  Each feature will be fully documented with a detailed design complete with UI wireframes prior to Cryptonomex taking any money.  We want to ensure that the community knows what they are bidding on and to maximize the price we can get for each feature.   Bidding can start early (prior to detailed documentation), and users can cancel their bids if they change their minds prior to us locking them in.   

So to get this started, please place your bids for the MAKER asset which will earn 20% of all liquidity incentivization rewards if the Liquidity Incentivization proposal is approved and executed.  Lets see how the community actually values this potential feature and then move on from there.

There have been several opinions expressed that I would like to address:

Opinion 1. If we don't increase the taker fee, then we won't shift the market and we can still incentivise market making by reducing the maker fee up the opposite of the taker fee.

If I offered everyone on this forum $0.01 to visit me in my office every day you could claim that I am incentivising an increase in visitors.  If my goal is to get 1000 visitors per day will such an incentive program make any meaningful difference?   Of course not, the cost of traveling to see me is greater than $0.01.  On the other hand, if I was handing out Cryptonomex stock to everyone who came to see me then I will probably get a lot of people buying airplane tickets to come visit me.   There is a non-linear curve on the incentive scale.  Below a certain point it makes almost no difference, above a certain point there would be a mob outside my office. 

If we are going to implement something it has to be "big enough" to have a meaningful impact on liquidity, not just theoretically incentivise it.   To have a meaningful impact it has to significantly offset the volatility risk faced by liquidity providers.  In other words, the reward should be equal to the average volatility during the average period a market maker takes to turn over their inventory.   This volatility risk is what we must overcome.  Throwing a few pennies at market makers and saying, "hey take a big risk and we will increase your revenue by 0.2%" and they will say, thanks but no thanks.   



Opinion 2.  We should simply encourage liquidity by diluting BTS

99% of assets on BitShares are user issued assets.    Companies like Open Ledger want to incentivise liquidity in their UIA and will need tools to do so.  Surely we wouldn't want to dilute BTS to provide liquidity in every UIA?  If we are going to code a solution to improve things for some BTS assets, we should do so for all UIA assets. 

As you can see in this thread, diluting BTS is not an option because it has no market feedback via price indicators.

So rather than viewing this as a tool for BTS, view this as a tool for businesses built on BitShares.  These are the businesses that need to self-fund their own liquidity from their own future profits. 

Referral income should be corrected as soon as you connect the GUI to an upgraded witness node.  Open Ledger will have to upgrade before it shows up in normal wallets.

Quote

Paying a negative fee immediately from the buyer who pays a positive fee is nothing more than shifting the price.  It is a meaningless change.

Taker pays the fee to both maker and the network. It's more than shifting price because it encourages makers thus improving the liquidity.

Sometimes it helps me to imagine an extreme case to get a better feel for what is happening on the smaller scales.  So what follows is my own thought experiment.

Lets try the experiment with a 20% taker fee just to be outrageous.  Lets have the maker fee be -20%.    Under such a market, those who demand liquidity take a 20% loss and those who provide it get a 20% gain. The trader would view such a market similar to a market with a 20% spread. They would be hesitant to buy such an asset because they know they will take an instant 36% loss if they are the taker on both sides. (.8 in and .8 out).  This means that someone looking to get in-or-out of such a market with the least loss would have to be a maker for one of the two trades in which case they take a 4% loss (.8*1.2=.96).  Those who are willing to "wait" on both sides of the trade can profit by 44% (1.2*1.2).   Hence the negative maker fee encourages users to wait (which is the opposite of liquidity).  You create "lines" on both side of the order book of people who want to exit their position. I suspect you would see very narrow spreads with steep walls.  This market would have the appearance of good liquidity, but the underlying reality is that 'day traders' view it as a market with a 20% spread.

So in this extreme case the takers (aka traders) end up paying for their liquidity TODAY the same way they would pay for their liquidity without the 20/-20 maker/taker rule: via a large spread.  Market makers end up making the same profits they would if they had a 20% spread between their buy and sell walls. The only thing the negative maker fee is doing under this model is enforcing a minimal spread that makers can provide, in other words price-fixing the market maker fee.    Instead of market makers competing to reduce spread, they are competing to be the first in line of a "virtual" 0 spread.   Because no value is moving through time all this price fixing is doing is creating shortages (of takers) and gas lines (those waiting to exit on both sides of the book). 

So it is clear that if we set the maker/taker fees to be greater than the natural spreads that things break down.  Our real goal is to reduce spreads, not enforce a minimum spread with steep cliffs of liquidity on either side of that minimum spread.

So this means that we want to maximize maker rewards without increasing the cost to the taker.  So lets look at another extreme market:

1. Suppose that takers paid a 0.1% fee
2. Suppose that makers earned 20% bonus from someone else (ie: the network).

In this market there would be huge walls of liquidity as people compete to get a 44% return every time they turn over.  This 44% return completely eliminates almost all market volatility risk.  Traders/takers see an effective spread of just 0.1% which means they feel very comfortable buying the asset because they know they can turn around and sell it instantly with only a 0.2% loss.  Assuming there was no limit on the 20% bonus, then people would start trading against themselves.   Obviously you would have to mitigate this self trading by making the reward based upon how long the order was on the books before getting filled.  This is the situation we really want to create.

So the question becomes how do you compensate makers today without making todays traders (takers) pay for it.  My proposal has tomorrows takers pay today's makers by paying for market making today, but not tomorrow.

The proposal here says you give them 0.1% today + a cut of the net present value of all future fees.

The cost of providing liquidity on early on is much more expensive than the cost of providing the same liquidity in a mature market.
Under this model you gain more liquidity from makers early on (when it costs the most) without actually decreasing liquidity available in the future (when it costs less).  If you set the decay curve properly you can end up with "constant liquidity" equal to the average liquidity over the entire life of the market.  Over a long enough time horizon this means that you should get almost as much liquidity in year 1 as you do in year 30 if market makers believe in the future of a given market.

So when people suggest "simple" rules they are not really getting the result they want. 

This looks like some data on disk got corrupted, resyncing should fix it.   

Using the "drop box" approach does not solve the "routing" problem unless you use the same drop box over and over.  In which case the problem can be described as:

How do I put information "X" into public mailbox "Y" without anyone knowing I was the one putting the message there. 
A second question is how do I check mailbox "Y" without anyone knowing I am the one checking it.

The solution is for me to put my message in an envelope, then put the envelope inside another envelope, and lastly put that inside yet another envelope.  I then mail the message, the first recipient opens it and "re-mails it", the second recipient does the same. This is how remailing works in the physical world (where it is grey market / illegal).   

The only difference here is that the remailer batches messages and then adds bogus messages into the mix.  This means that second remailer cannot correlate inputs to the source with outputs. 

The final destination for all mail would be the blockchain which is replicated in such a manner that users can check their mail without revealing which mailbox they are looking at.

The challenges posed by this protocol include:
1. How do the remailers get paid?
2. How is payment made in such a way that doesn't compromise the intended goal?
3. How do you verify the remailer doesn't just drop your message after taking payment?
4. What size should every message be, they must all be the same size or patterns can be detected / correlated.

Lastly, and most significantly, how much does this degrade the user experience? If it degrades it much at all then your target audience is greatly reduced. 

In fact, I would argue that BitMessage is already sufficient for this market (with a better UI perhaps).