Mike Hearn also votes for OP_RETURN. His message and my reply:
You should just fix the issues with making provably unspendable OP_RETURN outputs. There's already an open pull request for it. I'm not a fan of any "solution" that involves putting things which are not keys into OP_CHECKMULTISIG scripts. They're intended for keys, not other data.
But I'm really unclear why you need to build things into Bitcoin anyway. If you or the people you're working with aren't able to make a merge mined coin with your current abilities, then maybe it's time to learn how? I explained years ago how alternative chains can interact with the Bitcoin chain (e.g. have the contents of your new database depend on the contents of the bitcoin database).
Thanks for your reply!
Making another alt-coin isn't really interesting to me, merged-mined or not. Frankly, I wouldn't have raised much money at all if I were trying to make another alt coin. I'm very committed to making a new protocol layer on top of bitcoin, but I want to do it in the most friendly way possible
Mike followed up with an appeal to stop what I'm doing entirely and reboot the project as an alt-chain! I of course refused, as charitably as I could:
Yes, I'm familiar with your reasons for not wanting to make an alt coin.
The fact that you raised money isn't relevant to anything. A block chain is merely a technical method to synchronise a database. It has no importance beyond that. To say a new block chain "competes" with Bitcoin is meaningless because there's no requirement that the block chain be used to create another currency. It could do anything that requires a key/value store. It could, for instance, track annotations to regular Bitcoin transactions but which are nonetheless not stored in the Bitcoin chain.
In short, your ideas for MasterCoin will succeed or fail independently of whether you use the Bitcoin block chain or create a new one. I suspect the real reason you want to use normal Bitcoin transactions is you don't have the technical skill required to implement your ideas in a separate system. This will not gain much sympathy from other people.
You're also going to cause big problems for other people who are building apps using the protocol as it was meant to be designed (like me) - now features we're using to make things will be seen as a vector for abuse (your abuse) and people will argue to remove those features rather than risk the viability of the core system. I've had to spend a lot of time arguing against people disabling useful features because of abuse by technically inadequate programmers, and I'm tired of it.
In short - stop now, step back, and evaluate alternative technical approaches. If necessary temporarily return money that was given to you and promise to come back with a MasterCoin v2 that resolves the valid technical concerns people have. If you don't then people with far more experience than you will start looking for ways to shut MasterCoin out of the network, and that would be a huge timesink and potentially quite damaging to both Bitcoin and MasterCoin itself. Nobody wants to go there.
Thanks Mike. I definitely understand your concerns, and I partially agree with your reasoning (partially, because I don't expect I would have any trouble making an alt chain, if my interests were in that direction). I can understand your frustration with wanting to have more features in bitcoin, balanced against the fear that people will abuse them.
I appreciate that it would be better for you (and perhaps lots of other people) if I stopped what I am doing and approached the matter from a different angle. However, I think it's much more constructive to recognize that people are going to try to do things like this, and try to minimize the impact on the block chain. Even if I did exactly as you suggest, someone else would try it, possibly even someone more foolish than myself, if you can imagine that
I understand that my approach may result in changes to bitcoin which might not be favorable to my project, but I spent quite a bit of time contemplating how to make sure my transactions didn't get banned from bitcoin, and I don't plan on relying on any mechanism that would allow that. Frankly, I simply can't conceive of anything that would shut MasterCoin out of the block chain permanently. Perhaps I just lack imagination.
You can predict my future actions with perfect accuracy if you simply assume that "J.R. will do what he thinks is best for the owners of MasterCoins", which of course includes myself. If I thought that a complete reboot of my project was in the best interests of my investors, I would do it in a heartbeat. Any argument attempting to get me to change direction must appeal to that motivation, not my compassion for whatever projects of yours that my project may be hindering, or my concern for the bitcoin economy in general, or . . . anything else at all. If it's not in the best interest of my investors, I won't do it. Period.
I really do appreciate your feedback though, and I highly respect your views on this matter. One thing that is in the interest of my investors is to make our project as bitcoin-friendly as possible, since if we don't, someone else will gain a competitive advantage over us by being better block-chain citizens.
Perhaps the end result will be that someone will create an alt-coin using merged mining which is more in line with what you would like to see, and that coin will win out by its inherent superiority. Perhaps you yourself might create it? If so, I sincerely wish you luck - I might even buy some!
-J.R.
Another reply. Looks like he'll be mostly satisfied if we just use OP_RETURN.
Well, you're assigning new semantics to existing transactions. So nothing stops you from hard-forking your own system onto a separate chain. You just say "at block height X on the bitcoin chain, the mastercoin genesis block will be initialized to the contents of the system at that height and all new mastercoin transactions take place on the new chain". It's not impossible or anything to split it off, as you already define the rules and indeed the system doesn't have much code yet.
At the moment it seems that MasterCoin transactions all pay money to the exodus address (i.e. you), so that seems like a fairly major giveaway. For your system to work, there has to be a way to identify the special transactions, and if your software can do it so can any other program. Perhaps I missed something but that seems fairly fundamental.
People are much more relaxed about provably unspendable outputs. Using the OP_RETURN form is a quick fix that doesn't require much effort on your part, but it does mean finishing off the work Jeff did on the bitcoind patch and getting it merged in, then starting to use it once people upgrade. Your software can recognise both forms so the transition is smooth.
Your current approach strikes me as similar to a company executive whose factory is dumping waste into a river. People in the community ask you to stop, and even suggest ideas for how to avoid doing it, but you simply answer that you only care about your shareholders and anyway, anyone can dump toxic waste in the river so it shouldn't matter that you're doing it. That may be so, but that attitude will alienate the people around you. Eventually it will cause problems.
The tiny outputs which reference the exodus address are not intended as a way to raise money, but merely as a convenience for finding our data in the block chain. We could switch to a different reference address at any time if for some reason bitcoin clients started looking for that address.
I think that's exactly the direction we are heading (using OP_RETURN once it becomes possible to do so). I DO want to minimize the toxic waste being dumped in the river, and thankfully I believe it is in the best interests of my investors to do so
I personally think that the river-polluting example is a pretty strong argument against an-cap world-views, but that is a different conversation . . .
