MasterCoin: New Protocol Layer Starting From “The Exodus Address”

[dacoinminster]

Would it not be a good idea for dacoinminster to create a Testnet Exodus address?  Surely it should be under his control, or that of the oversight board.

I'm totally fine with someone else doing it - it's the sort of thing that if we run into a snag we can always start a new one. If you guys really want me to I can, but the consequences of making a mistake on testnet are pretty small, and possibly the benefits of such a mistake would be worth the trouble - we might learn something valuable that will help keep the funds at the real Exodus Address safer.

[dacoinminster]

Question, when am I going to receive my 3 BTC tip?

In your PM, you asked me to send it to 1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb:

You can send my tip here: 1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb

Which I did in this transaction: http://blockchain.info/tx/99160b37b3294eebc83bd8ff44849c813d2e9da986a25fb127b0c5915e799c0a

If you no longer have that address, I'm very sorry! I did post my intention to use that address for you publicly more than once. For instance: https://bitcointalk.org/index.php?topic=265488.msg3132645#msg3132645

[dacoinminster]

I thought you guys might like to see what some of the candidates for the open board seats at the bitcoin foundation are saying about MasterCoin:

Ben Davenport:

Hi JR,

In general, I'm supportive of protocols built on top of the blockchain. As I previously stated, I'm a big fan of the BitcoinX colored coin initiative. Anything that follows the rules of the network ought to be fair game. I'm all for projects succeeding or failing on their own merits. That said, I'd really encourage you to listen to Gavin and GMaxwell about not creating unspendable outputs (especially when they've given you an alternate approach). Bloating the UTXO set will impose negative externalities on the entire network. We should ideally figure out how to disincentivize such behavior.

Elizabeth Ploshay:

JR,

Thank you for reaching out.

To date, Bitcoin serves as the best base for further development of a number of innovative and valuable tools that will benefit the community and movement towards further decentralization. The Bitcoin Foundation should continue to ensure that Bitcoin remains a stable base so that individuals can continue to develop these tools.

While I have reservations about the feasibility of the implementation of MasterCoin in its current form, I appreciate the concept behind MasterCoin. It is important that protocol layers built on top of bitcoin not undermine the basic function of the network.

I encourage the exploration of tools that enhance the Bitcoin ecosystem as there is still value in the marketplace of ideas and the exchange of information and lessons learned from the strengthens and weaknesses of the variety of digital cryptocurrencies growing today will just continue to strengthen Bitcoin.  

Trace Mayer:

Hi JR,

Yes, I remember you and I have followed your work with great interest. Indeed, a little over a month ago your name popped up when I was reviewing potential talent with some others and I suggested we pass since the work you were doing on MasterCoin was more important and of higher and better use than what we had in mind.

To quite brow-nosing and address your question directly I am a fan of both alt coins and new protocol layers like MasterCoin. I think they both have, along with other tools like OT and Ripple, significant potential to create some incredible innovations in this space and others yet undeveloped in even the most rudimentary way.

For example, I really like the potential of OT and BitMessage for federated exchanges and think MasterCoin could even further enhance the possibilities. Creating scarcity by code has really opened up so many possibilities!

Consequently, my general attitude is pretty aligned with Gavin's that the Bitcoin protocol should remain very stable and only change slowly, incrementally, with backwards compatibility and by supermajority. Thus, Bitcoin can increasingly become a registry/settlement mechanism and be secured, perhaps overly so, with massive amounts of processing power.

Where I differ with him, but only slightly, would be I really like the idea of experimenting with alt-coins and other projects even if that means allocating some resources away from Bitcoin (people should feel free to allocate their time, attention and money where they feel they want to anyway) whether it is decentralized DNS with Namecoin or a decentralized Twitter with Florincoin. And MasterCoin is really just an even more complicated abstraction and application which I think could end up being really cool with multiple great use case scenarios.

Bottom line: I think we have a ton of opportunity to build out all types of useful things for Cipherspace using both alt-coins and additional protocol layers on either Bitcoin or even other alt-coins that may be more specifically suited to accomplish particular tasks.

Meyer "Micky" Malka:

J.R. -

Thank you for the question.  I am a fan of Mastercoin and have been following its progress.  I applaud your efforts and others involved in the project for pushing the idea forward.

As a general matter, I am of the view that Bitcoin is and can be different things to different people.  To me, it is both an improved form of money AND a disruptive technology.  So I appreciate and support comparing Bitcoin to gold or fiat currency - i.e. pointing out all the ways that Bitcoin is simply better money (i.e. scarcity, durability, fungibility, divisibility, verifiability, portability) - as well as the view of Bitcoin as a protocol for storing and transferring value.  As an investor and someone who has seen the worst of our existing systems of money, the first is very important to me.  As a venture capitalist and an entrepreneur, the second is where I see the enormous potential for what Bitcoin can become.

To get back to your specific question: in my view, cryptocurrencies are here to stay and Bitcoin is the gold standard.  Solidifying Bitcoin's role as the gold standard requires both continuing to strengthen Bitcoin as well as encouraging innovation on top of it.  New layers can make Bitcoin more functional, increase general accessibility and open up additional use cases (e.g. enabling distributed currency exchange, programmable property, et al.)  I see Mastercoin as one of the first and most ambitious efforts to do exactly this, so I am excited at the prospect.  

I believe (as I know many other members of the foundation do) that Bitcoin today is like the Internet in the early 1990s: the fundamental technology is there, but we are still in early days.  Obviously I do not know whether Mastercoin will take hold, but I believe that by supporting people like you and your colleagues, the Bitcoin community can ensure that the protocol spawns an amazing amount of innovation (just like TCP/IP did) .  And I think that the Foundation, by bolstering Bitcoin and addressing market and regulatory challenges facing the protocol, can help pave the way for this innovation.

Thanks again for the question.  Please reach out to me anytime.

Micky

Luke Dashjr also sent me a PM about his candidacy and MasterCoin, but I don't have an official quote from him yet.

Disclaimer: I'm not endorsing anybody. I don't even know who I'm voting for!

[dacoinminster]

There was a lot of critics about the Mastercoin network, in particular due to the many generated un-prunable transactions that are necessary to transmit the data between Mastercoin users.

I have an idea how to solve this problem, but this would require some changes to the protocol. Basically, instead of sending Bitoins to a data address without known private key (which is the current Mastercoin implementation), data can also be transmitted by sending Bitcoins to addresses that other Bicoin users own. To do so, a 'directory' of addresses has to be generated first. Each address can store a few bytes of data - and by sending tiny amounts of Bitcoins to these addresses, the pieces of data can be connected (similar to the current Mastercoin implementation). In this presented implementation, each address can store about 3 bytes. Therefore, to have enough data for a Mastercoin transaction, about 6 - 12 Bitcoin transactions have to be sent.

However, there is an important advantage in this implementation: Users that 'own' these addresses can later send all their earned Bitcoins to a single address. As a result, the millions of addresses are fully spent, and the whole system becomes prunable.

In contrast, in the current Mastercoin system, all the data addresses will remain with 0.00006 BTC stored and have to be saved in the blockchain forever.


Here's the implementation:

First, a global list of length 58^4 = 11316496 and width = 30 is created, and each cell can contain a Bitcoin-address. Let us index these cells with (n,#). The size of the list is a few GB, which is well managable to keep in lots of copies among all Mastercoin users.

Now to the actual idea: The cells (1,#) must contain addresses with the last four characters being -1111. The cells (2,#) must contain addresses -1112, and so on. Finally, the cells (11316496,#) must contain addresses with the last 4 characters -zzzz.

Now, every Bitcoin user that finds a key pair can publish the corresponding address in this list. To this end, he has to prove that he owns the private key of this address, to prevent people 'scamming' the list. Assumed, he found an address ending with -1113, he publishes it and it will be written into cell (3,1). Now let's assume > 29 other users also find addresses ending with -1113 and publish them. Then, all these addresses are alphabetically ordered and written into cells (3,1), (3,2), ... (3,30). Addresses with index > 30 are discarded. Obviously, with time, it becomes harder and harder to 'win' a cell in the list, because an address with low alphabetical index has to be found to kick out another one.

Since it is attractive for users to 'own' cells in the list, the time will come the list is complete, meaning that every cell has an address written in it. Of course, after completing the list, new addresses with lower index can still be published, and the list will be continuously updated.

Last, how can a string of data be transmitted?
First, the data is converted into base58 and chopped into pieces with length 4. Example: 3HZ28xpWUhq4... -> 3HZ2, 8xpW, Uhq4... The addresses (taken from the global directory) to send bitcoins to must have the following properties:

1.) They have to end with -3HZ2, -8xpW, -Uhq4...
2.) The addresses have to be in alphabetic order: (...-3HZ2) < (...-8xpW) < (...-Uhq4) < ...

Point 2 is important to connect the data pieces in the right order. It should be possible to find such an alphabetic order, since there are 30 different available addresses for each piece of data.


So, what you think... Assumed that Bitcoin miners feel threatened by the current Mastercoin implementation and stop to confirm transactions that have an Exodus recipient, this implementation could be a solution, since it harms the Bitcoin network less.


edit: follow-up here: https://bitcointalk.org/index.php?topic=284178.msg3166749#msg3166749

I believe that something like this would work, and as you say, it wouldn't create unspendable transactions. However, it would take a LOT more bytes to store the same data in the block chain using this method.

As I've said before, I need to get smarter about the internal workings of bitcoin, but I have a lot of confidence that our developers will come up with something which works. Currently they are (if I understand correctly) attempting to use Gavin's suggestion (https://bitcointalk.org/index.php?topic=284178.msg3040840#msg3040840). If that doesn't work, they may try the OP_RETURN method suggested by maaku on the same thread. If that doesn't work, there may be more options which haven't been suggested yet.

Once this is nailed down, I'll be looking forward with great anticipation to see the first try at the distributed exchange using testnet and/or test MasterCoins. Given how dang fast these guys are, we may all be pleasantly surprised with how quickly that comes together

[dacoinminster]

Aw crap. I meant to update the spec to change how the sequence numbers worked. Thanks for catching that.
When I was writing the code for MasterCoin Adviser, it occurred to me that it might be easier to parse MasterCoin transactions if the first data packet had the first sequence number, then additional data packets following, and then the reference packet last, with the last sequence number. But I never went back and updated the spec to reflect that change. I made that change because I thought it might help if we ever had transactions with data but no reference address.

Won't that be a problem when the data chunk is bigger than what fits in one address (20 bytes)? I mean, we'll need more than 1 sequence number, besides the reference sequence number. The only solution I see is to number the data addresses decreasingly from n-1 (n is reference sequence, n-1 for the first data address, n-2 for the second data address, etc), which seems untidy.

Anyway, I hope the alternate methods for data storage will make sequence numbers obsolete

I had intended Test MasterCoins to be used so I didn't have to create a TestNet version at all, but I have no opposition to TestNet implementations if that is helpful, especially if that helps reduce block-chain bloat

So... let's agree on a testnet address and epoch so that developers can test on the same grounds. Are you all OK with using miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 as the testnet exodus address (proposed by Tachikoma) and 15-Sept-2014 as the testnet epoch?

Yeah, I was going to do something similar to that untidy method (although I was going to have the lowest sequence number be the first data address), but as you say, it's not clear how the new method of storing our data affects sequence numbers. If we continue to use them, I'll be sure to update the spec so it is correct.

[Tachikoma]

There are two types of multisig outputs available at the moment that are useful for us.

• 1-out-of-3
• 1-out-of-2

While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones.  

What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.

Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction.

I would like to suggest that we keep the original spec and use one output for the receiving address.

We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output.

We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.

A simple encoded simple send would look like (and forgive my horrible photoshop skills):



A complete tx could look something like this:

Code:

{"hash":"c4551b2e0b8470cc3e03212f823cb9a66580c512aa66ac71a4bfc0a6500dd1eb","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":305,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100cb314569b0b194c2e510a101c5a6d9ec5a95a9a8cfc4009bd8f11affbec1b835022100b6e8b08be3b42e037a18f497a595996c40c49e83b114dc360601fdb3526e4d8001 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 exodusaddressshouldbeinsertedhere OP_EQUALVERIFY OP_CHECKSIG"},
{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 020000000001000000020000000000000001000000000000000000000000000000 2 OP_CHECKMULTISIG"}]}

I appreciate some feedback on this spec before I start writing code

First of all, I have to admit that I don't understand the inner working of bitcoin well enough yet to tell you if there is a problem with this method. (I'm working on it!) What you propose sounds reasonable to me, although I did receive this PM from a concerned party which seems to indicate there may be some hidden gotchas:

https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831

I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.

I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"

If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past (pybond) and may be able to take on that role.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.

I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.

I'm sorry but this pisses me off beyond believe.

I've been spending a lot of my own free time, which I don't have much off, trying to help out this project. I am mostly trying to do this alone since nobody seems willing/able to give proper technical feedback to my theories. Now finally somebody steps forward who sees that something is wrong with my proposal but he wants to be paid in order to tell us what is wrong with it? Why not just specify what's wrong so we can work around it?

I won't be giving this any more energy if this is the way the community is going to respond to a group effort.

[dacoinminster]

I'm sorry but this pisses me off beyond believe.

I've been spending a lot of my own free time, which I don't have much off, trying to help out this project. I am mostly trying to do this alone since nobody seems willing/able to give proper technical feedback to my theories. Now finally somebody steps forward who sees that something is wrong with my proposal but he wants to be paid in order to tell us what is wrong with it? Why not just specify what's wrong so we can work around it?

I won't be giving this any more energy if this is the way the community is going to respond to a group effort.

Believe me, I know how you feel. This project has forced me to thicken up my skin - people can be very cruel, especially when they are not face-to-face with somebody they are criticizing. I tried not to show it publicly, but I was very discouraged by some of the feedback I got early on.

Let's just ignore it for now. I don't personally see anything wrong with your method, but I figured I'd post the PM in case anybody else knew what he was talking about.

And no, I don't plan on paying to find out whatever this problem is. Hopefully if there is a problem, somebody will recognize it and post it.

You are right that most of us are not able to offer technical feedback, myself included for the time being, and some of those who are able seem to be less than charitable towards us, and/or are opportunistically aiming to extract a bunch of cash from our project funds.

However, there are a bunch of smart people in the bitcoin community, and they aren't all like that. I'll PM some other smart people and see if I can get us some proper feedback.

edit: PMs asking for comments have been sent to Gavin Andresen, Jeff Garzik, Mike Hearn, Gregory Maxwell, Peter Wiulle, Luke Dashjr, Alan Reiner, and maaku.

Can you guys think of anybody else?

Luke-Jr said:

Ok, I'll take a look when I get a chance. Not sure it'll be this week, but I'll try to squeeze it in if I can

[TomHirsch]

I'm sorry but this pisses me off beyond believe.

Believe me, I know how you feel. This project has forced me to thicken up my skin

Chill!  This is VERY explainable.  Some of these guys really know a ton about bitcoin and how it works.  They are all very seriously pissed that Mastercoin - albeit not perfectly elegant - is a damn cool idea that they didn't think about.  Further, and this is the very hard part - now Mastercoin is very well funded.  These guys think they are far above Mastercoin technically and they are furious that they didn't find a way to raise $500,000 to advance their concepts.  Rather than help Mastercoin, they are going to beat it down from every angle - and try to take money away while Mastercoin grows.  Open source projects get F'd everytime by ego. 
Press on.  You don't need them.  You'll find your way clear of these minor obstacles and very soon will be far passed all their pussy fussing.  You don't need their inputs.  Their inputs are corrupt. 


Jealousy often means you've got something good going on.

[dacoinminster]

Chill!  This is VERY explainable.  Some of these guys really know a ton about bitcoin and how it works.  They are all very seriously pissed that Mastercoin - albeit not perfectly elegant - is a damn cool idea that they didn't think about.  Further, and this is the very hard part - now Mastercoin is very well funded.  These guys think they are far above Mastercoin technically and they are furious that they didn't find a way to raise $500,000 to advance their concepts.  Rather than help Mastercoin, they are going to beat it down from every angle - and try to take money away while Mastercoin grows.  Open source projects get F'd everytime by ego. 
Press on.  You don't need them.  You'll find your way clear of these minor obstacles and very soon will be far passed all their pussy fussing.  You don't need their inputs.  Their inputs are corrupt. 


Jealousy often means you've got something good going on.

So far we only have one or two people acting this way. I'm hopeful that we'll get some good feedback from friendlier smart people soon

[dacoinminster]

Jeff Garzik's reply, from the other thread:

OP_RETURN is the current proposal that people have been using, for adding prune-able data to the blockchain.  Here is an example implementation for relaying such transactions https://github.com/bitcoin/bitcoin/pull/2738 and https://github.com/bitcoin/bitcoin/pull/2791 is the pruning piece.

alt-coins and similar schemes should at a minimum produce pruneable outputs or use inputs + P2SH.  The data remains available via blockchain, just not bloating the precise UTXO space.

CHECKMULTISIG schemes still bloat the UTXO space (unless they are P2SH).

This is another vote for using OP_RETURN. Tachikoma, I'm very interested in what you think about this approach!

edit:

It appears that this change to bitcoin hasn't actually been merged yet. I sent Jeff a follow-up question:

Thank you so much for the reply!

It appears that these changes haven't been merged yet? I'm a little worried about relying on features which haven't been officially approved. What will current bitcoin implementations do with transactions using OP_RETURN - hopefully not reject them?

His reply:

It appears that these changes haven't been merged yet?

The prune-unspendable is very likely to go in, and the general consensus is that OP_RETURN is the lesser of the various other more-bloat-producing solutions for timestamping data into the chain.  We did not want to put in OP_RETURN without having the prune-unspendable change in first.

I'm a little worried about relying on features which haven't been officially approved. What will current bitcoin implementations do with transactions using OP_RETURN - hopefully not reject them?

Most implementations today will not relay OP_RETURN transactions, meaning they will probably not be confirmed without a little extra legwork and patience.

All implementations will accept OP_RETURN in mined blocks, as it is a normal and supported opcode.

In practice, today, that means sending the transaction with appropriate fee attached to https://en.bitcoin.it/wiki/Free_transaction_relay_policy

After OP_RETURN is upstream, implementations will relay OP_RETURN transactions just like any other "standard" transaction.

[dacoinminster]

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

edit:

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  . . .

[dacoinminster]

I don't really like the idea of using transactions that standard clients won't rebroadcast, and being at the mercy of a small group of non-standard miners to include our data. I'm also not willing to pause the project to wait for this change.

One way to handle this is to just broadcast both kinds of messages - the way currently defined in the spec AND the same data using the OP_RETURN message (which won't be relayed yet). Once the friendlier message starts getting relayed, we can stop broadcasting the unprunable ones. In order to avoid processing the same transaction twice, MasterCoin clients would only look at the unprunable transactions until some specified block number that we would all agree on when we would switch to only looking at the OP_RETURN transactions.

That might light a fire to get the change merged into bitcoin, and it makes it really easy to go back if OP_RETURN ever stops being supported.

It's maybe a bit passive-aggressive, but it seems low risk. Opinions?

[killerstorm]

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

That is, you can write code to parse both CHECKMULTISIG and OP_RETURN, and test in on the testnet.

Code which creates transactions will use only CHECKMULTISIG now.

If at some point OP_RETURN will be viable, a new version of client can start using it: and old versions will be able to recognize such transactions too.

Now as CHECKMULTISIG adds more bloat to UTXO space, developers have an incentive to approve OP_RETURN.

I think everybody can agree that CHECKMULTISIG is definitely better than what you're doing now, so there are no reasons not to upgrade. (I mean, aside from desire to piggyback on existing clients.) Use of OP_RETURN is a separate issue.

Passive-aggressive strategy like you mentioned can work too, but it will create some junk in process, and, sadly, that junk will stay in UTXO set forever, which is kinda sad.

[dacoinminster]

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

That is, you can write code to parse both CHECKMULTISIG and OP_RETURN, and test in on the testnet.

Code which creates transactions will use only CHECKMULTISIG now.

If at some point OP_RETURN will be viable, a new version of client can start using it: and old versions will be able to recognize such transactions too.

Now as CHECKMULTISIG adds more bloat to UTXO space, developers have an incentive to approve OP_RETURN.

I think everybody can agree that CHECKMULTISIG is definitely better than what you're doing now, so there are no reasons not to upgrade. (I mean, aside from desire to piggyback on existing clients.) Use of OP_RETURN is a separate issue.

Passive-aggressive strategy like you mentioned can work too, but it will create some junk in process, and, sadly, that junk will stay in UTXO set forever, which is kinda sad.

I like that approach, since it also doesn't waste Tachikoma's work on CHECKMULTISIG

Also, here's what Alan Reiner said:

Hi J.R. -- I'm not sure exactly what it is you're doing?  Embedding data in extra keys of a multi-sig script?  You're right, I'm pretty busy.  I'll take a cursory look but no guarantee I'll see the problem...

Yeah, it's between that and using OP_RETURN (opcode which may soon be supported), though most of the bitcoin core devs seem to favor OP_RETURN.

I completely understand busy - let me know if you have an opinion I can add to the mix

Thanks!

[zathras]

I thought I should make a post and detail what I'm working on

I'm currently attempting a build of a web wallet and block explorer - 'Masterchest'.  Some notes:

* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)
* Hosted at masterchest.info
* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc
* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC.  This lowers risk and complexity.  You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users).  This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.
* Tools to lookup addresses and transactions (block explorer)
* Initial support will be simple send only
* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during development

I have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this!  If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.

At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.  

Edit: Pictures help so quick teaser screenshot

[dacoinminster]

Wow, it's becoming harder and harder to stay up to date with Mastercoin.
First off, Tachikoma thank you for all your work. You've contributed far more than anyone else to Mastercoin. I'm sad to hear you are demotivated by the way some community members react.


Back to the new data method proposal: I can't see any error in the details of what you said. That transaction does contain the data, and the bitcoins are redeemable via the actual public key. Nevertheless, the mysterious PM dacoinminister cited got me thinking more broadly about the method. I think there might be a more general  problem in the concept of storing data in the blockchain using multisig txs. For mastercoin to work we need mastercoin transactions to be stored in a decentralized, permanent way (like bitcoin transactions are). Using multisig transactions and then taking the bitcoin away with the other key may cause the transaction to be pruned from the blockchain by future bitcoin clients (why would you need to store transactions which have all its outputs spent?). In fact, the same should happen with ANY method which doesn't bloat the UTXO. If a transaction can be pruned for whatever reason (multisig, op_return), it means bitcoin clients could potentially delete that transaction, thus deleting mastercoin data?

Clearly my technical knowledge of the bitcoin protocol is below most of the people reading/writing here, so I'm sorry if what I'm saying is stupid.

If my understanding is correct, bitcoin-only clients could ignore the transaction itself, but it would still be in the block chain for MasterCoin clients to use. Anybody storing the entire block-chain would have our transactions.

MasterCoin clients will want to do their own style of pruning - they don't need to look at or store any transaction which does not reference the Exodus Address. Currently that lets us ignore almost everything

For the record, I don't think this question is stupid at all.

[dacoinminster]

I thought I should make a post and detail what I'm working on

I'm currently attempting a build of a web wallet and block explorer - 'Masterchest'.  Some notes:

* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)
* Hosted at masterchest.info
* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc
* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC.  This lowers risk and complexity.  You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users).  This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.
* Tools to lookup addresses and transactions (block explorer)
* Initial support will be simple send only
* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during development

I have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this!  If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.

At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.  

Edit: Pictures help so quick teaser screenshot

Awesome! We have a new entrant!

Well, maybe not so awesome for everybody else competing, but it's awesome for the MasterCoin project anyway

I am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute!

[ldrgn]

I am mostly trying to do this alone since nobody seems willing/able to give proper technical feedback to my theories.

The people in the know did give technical feedback, but they did it one abstraction level above the one you're working on now.  Didn't you see this thread?  The bitcoin maintainers came out of the woodwork to say "no, stop, this is a terrible idea."  retep even compared mastercoin/dacoinmeister to BTCST/pirateat40.  The message is unified and clear: do not implement Mastercoin, these ideas are all deeply flawed.

[Tachikoma]

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong.

Question 1:
Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs).

[dacoinminster]

Somebody asked me why I keep downplaying the money:

I am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute!

Why do you keep repeating that? I don't understand!
And it's really demotivating :s

Sorry - I'm just trying to manage expectations. If silicon-valley programmers join the effort thinking of it as a job motivated by money alone, they will be disappointed, and I'm trying to avoid that.

For people in other countries, the message is perhaps misplaced