Ok so it now seems that you have received $10K+ in funds for this project and are apparently providing a large amount of personal funds for this. I hope you have a plan for refunding everyone's money because I would wager money that your system cannot and will not work as you think it will. I was going to leave this thread be, but for the sake of those who are sending money in I wanted to make one more attempt to engage in real debate regarding the economics behind this.
1) I have read your more recent paper and most of my critiques still stand, but I will attempt to refocus them here.
2) My critique isn't that you couldn't manipulate prices using supply, but that manipulating supply is a very 'sloppy' control and has some lag. Markets can develop momentum and thus change faster than your supply manipulation can correct. It would be like attempting to fly an airplane with a 30 second lag between when you issue the command and the flaps adjust. It would be very easy to 'over correct' yourself into the ground.
That said, it would be possible to 'price fix' if the escrow fund had a bottomless ability to buy when the price started to fall and then sell when it got to high. Unfortunately, this means the fund either has the ability to create money from nothing, hyper-inflate, or go bankrupt. It is also clear from your paper that you have introduced the potential for multi-day lag before they can enter/exit the market.
In your paper you show the escrow fund as an 'entity' that is attempting to buy low and sell high. You already assume that these escrow funds could 'make mistakes' by being too aggressive and that when they are weak they will take longer to get the price back to parity. These escrow funds ability to influence the market is directly proportional to the real economic value backing the fund. Every mistake these funds make directly undermines the value available to back these coins.
3) I was suggesting other means of accomplishing what you are doing that have SIGNIFICANT advantages and which your system will be competing with in the market because I have far more financial backing than you do at the moment. This means you are taking peoples money to develop a system that will be competing against what I am doing and yet have failed to produce a comprehensive critique of what I am doing and how your system will out-compete mine in the market. From what I gather you admit my approach will work and has no need for any trusted parties, public oracles (data feeds), or price fixing authorities. Seems like your marketing is based entirely upon using Bitcoin's blockchain as some sort of credibility while destroying bitcoins as people convert to your system in a one-way trip.
Suppose I were to issue bytemaster coins to anyone willing to destroy a Bitcoin to create one.... the act of destroying the bitcoin does NOTHING to give value to the BytemasterCoin.
There is one last thing I would like to point out that you must address:
Bitcoin has some little-known advanced features (such as scripting) which many people imagine will enable it to perform fancy new tricks someday. MasterCoin uses exactly NONE of those advanced
features, because support for them is not guaranteed in the future, and MasterCoin doesn't need them
anyway.
You then go on to state:
MasterCoin transactions are defined as a series of bitcoin payments from a bitcoin address where the payments match this pattern: ... One or more “data” payments (of any amount) to fake bitcoin addresses. (A fake bitcoin address can contain 20 bytes of arbitrary data, not including overhead such as the version number and
check-sum of the address.) This is data used by the protocol, such as the number of MasterCoins being paid.
Because these are 'fake addresses' and money is being sent to them (or Bitcoin would block them as dust) all of this money must be destroyed or lost as you do not have private keys for these data addresses. This represents a VERY HIGH COST-PER-BYTE for your protocol. Not to mention the fact that you incur the full overhead of a bitcoin transaction just to communicate a relatively small amount of information imbedded in the address.
I have spent SIGNIFICANT time thinking about scalability issues with BitShares which I am actively working on 80hrs /week and I recognize that every byte of bandwidth counts. Furthermore, if you want a reasonable buy-sell spread you need a large number of market participants or you will have a thin market. This implies a need for a significant number of transactions and for your system this represents a large amount of overhead.
Lastly, you have said that you didn't want to go in my direction, but have not stated why which would have enabled some useful discussion. I have spent significant time explaining the problems faced with your approach and you owe it to those sending you money to do the same.
Investor beware... don't send him money on faith alone until he has throughly vetted his idea and addressed heavy critique that should be a prereq. for any fund raising. I vetted my idea and paid money for people to find problems with it. I suggest he start a bounty and pay people to prove him wrong as this would be far cheaper than building it out and learning it the hard way.
I love the pilot/airplane analogy. I spent 10 years developing software for an avionics firm, which is where I was exposed to the idea of a PID loop, which I used the Integral term of for this revision of the paper.
You are correct that the escrow fund acts slowly, with a very long time lag. This is quite intentional, because the escrow fund isn't actually trying to "fly the airplane". The purpose of the escrow fund is to make sure that the price will
eventually converge. The cool thing about markets is that when everyone in the market knows that the price of two assets will eventually come back in line, they tend to do so very quickly, because buying the low one and selling the high one is essentially free money. I'm sure you are familiar with arbitrage, but some of the readers of this thread probably aren't.
Whatever "mistakes" the escrow fund makes, it will still be buying low and selling high, and making itself more healthy, not less. The possibility of collapse comes from possibility that the value of MasterCoins could crash to near zero - not from any actions the escrow fund might take.
I'm really honestly happy that you have raised more money than me. That is fantastic. We really need innovation in this space! I suggest everybody on this thread go take a look at your whitepaper - it may be they should be investing with you instead of me!
I'm just really enthralled by the idea of a message-based currency stored in the block-chain. That's all there is to it. I think its really simple to understand and really flexible. It's not that I know of some fundamental flaw in your approach. Eventually, the market will decide the best way. I hope that you will be successful with your project, and I will continue to follow your progress.
Yes, this protocol does rely on sending unspendable transactions, and therefore destroying bitcoins. The typical MasterCoin transaction will destroy 0.00006 BTC (one data transaction just above the dust threshold), thus adding about half a cent of cost to each transaction at today's prices. However, I feel that the benefits outweigh that cost. Also, any bitcoins destroyed make everyone else's bitcoins more valuable, essentially paying a tax to the bitcoin protocol layer that supports us.
Note that a second dust transaction goes to the exodus address, and a third goes to the reference address. Those bitcoins aren't destroyed, but the minimum cost to the sender then is about 1.5 to 2 cents a today's prices.