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

[td services]

I concur that everyone who sent the coins prior to the deadline should receive Mastercoin since they performed according to the spec, and they have no control when the transactions are processed by the system. It is like deadlines of postmark vs. received. The postmark is an objective measure by a third party and under the control of the sender (fair) while a recipient can claim receipt whenever it suits them, and the sender has no control over what happens once the item is placed in the mail (not fair as a deadline).

[1713890391]

1713890391

[1713890391]

1713890391

[1713890391]

1713890391

[1713890391]

1713890391

[1713890391]

1713890391

[Tachikoma]

Cool, I've been researching the option of using OP_CHECKMULTISIG and just adding public keys with data in it. Haven't really got time to implement anything yet though since I'm mainly working on features on top of the explorer. Let me know when you have some code so I can update mastercoin-explorer to support it

[StarenseN]

I'm already working on a prototype for alternate methods of storing Mastercoin data in the blockchain, using python. Will post update soon!

Just in case you don't know it and to avoid spending bitcoins, are you doing this on the testnet blockchain ?

[grazcoin]

I concur that everyone who sent the coins prior to the deadline should receive Mastercoin since they performed according to the spec, and they have no control when the transactions are processed by the system. It is like deadlines of postmark vs. received. The postmark is an objective measure by a third party and under the control of the sender (fair) while a recipient can claim receipt whenever it suits them, and the sender has no control over what happens once the item is placed in the mail (not fair as a deadline).

• In the bitcoin protocol, "sent tx" has no meaning to the consensus if the tx is not confirmed (e.g. double spend, hanging transactions, etc). Time of a sent tx is only the time of the corresponding block.
• It is not totally true that the sender has no control when the transaction are processed. See  https://blockchain.info/tx/d1a7922993d7ed20a597b931fe30b10fca08382ecbb087f6325e71ea08750758 which paid 0.5 bitcoins fees to make sure that the tx is really confirmed, while 20 seconds later (according to blockchain.info timings) https://blockchain.info/tx/935dfdcb31237ab4435877f2c6d28dd3906974753b0072c6921fa30c8239e4f3 had no fee, and it was not confirmed on time (although there was theoretically enough time). Obviously if there was no block found in those 18 last minutes, also the 0.5 bitcoin fee would not have helped.
• If we decide to extend the deadline, I would prefer that it is extended a little longer - to the last block confirmed before 1.10.2013. Then it would be more fair ...
• There is nothing like "receive Mastercoins" for the bootstrap purchases. The mastercoin protocol says that they are simply there, and we use this information. There is no need for extra transactions.
• At this point I agree that  J.R. Willett is the one to decide on the exact interpretation of the spec, so please ..

[Tachikoma]

I've just put a new version of the http://mastercoin-explorer.com online.

This version actually has some useful information. For one it can approximate balances for a given address and show what kind of transactions where done by them. As always this is an initial version of this functionality so don't expect any miracles

J.R.: I spend way more time on this then I originally planned. So to be honest I hope there will still be a bounty for something like this even if I build it already; not that that was the reason for me doing it to begin with

[dacoinminster]

I've just put a new version of the http://mastercoin-explorer.com online.

This version actually has some useful information. For one it can approximate balances for a given address and show what kind of transactions where done by them. As always this is an initial version of this functionality so don't expect any miracles

J.R.: I spend way more time on this then I originally planned. So to be honest I hope there will still be a bounty for something like this even if I build it already; not that that was the reason for me doing it to begin with

Sweet mother of bacon!! I'll take a look at this shortly!

We're launching a month-long coding contest soon, and this will be a fantastic entry, even if you don't touch it again before the end of the contest. We'll be giving away a bunch of money proportional to the awesomeness of the various entries. The only caveat is that you'll have to release the source code at the end of the contest, which I assume won't be a problem

At this point, I have no doubt you will get a significant chunk of the pie, although you may have to share it if others come along with similarly fantastic code. You've got a HUGE head start though, and if you keep up this pace, you may get most of the money. If no serious competitors appear, you may get nearly all of the money.

As I mentioned before, ALL serious entries will get a prize, but some of them will be very small, so you could be running against 10 competitors and still get 90% of the money.

For those of you looking to enter the contest, the biggest unaddressed need right now is for alternate ways to store our data in the block chain. We need to do that before we can do the advanced features without REALLY annoying the bitcoin core devs.

Reproducing Tachikoma's code is also to be encouraged, so if you want to go that direction, don't hesitate. Having multiple implementations will help a lot in finding bugs and inconsistencies.

I want to get the issue of refunds nailed down before I proceed with the contest, which is why I haven't started the contest thread yet.

[dacoinminster]

Speaking of refunds, I just got this email from one poor fellow who barely missed the deadline:

On Sat, Sep 7, 2013 at 7:31 AM, ------- wrote:

    Hey Willett,
    It's me 1Bqp4VEweM1S8FKGHWYviRRtSxv5tMAVih
    I've just seen the talk on the forum you want to decline my investment! :-(
    I can't replay on the forum, so Ron gave me this Email, to talk to you.

    It's really unfair, I was a fan of the project from the start, and I did send
    the coins before the deadline. (as blockchain.info records state)
    and I think this is what counts!

    Please take into consideration that Blockchain.info was under heavy attack at the last hour.
    The site was almost always unreachable, and I could hardly send the order
    after half hour(!) of repeated attempts at 3AM (in ------ ) before I could go to sleep.
    Maybe, the heavy attacks also caused the delay in including the TX it the block.
    I invested a little at the beginning of August, but I saw the great potential and needed time
    to raise money to invest much more in you work, So I finely bought the coins on 31Aug,
    especially for this investment.
    I hope you'll reconsider including block 255365 as you wrote in previous posts,
    it will be only fair, and it's not really "Breaking the rules" because of blockchain.info's
    time stamp before Sept 1, it should count.

    Also, now when the bitcoin tanked to 125, I'll be loosing alot of money if you refund me,
    as I said, I bought those coins especially for mastercoin, at 145 USD/BTC with great loses
    from before too, So it sucks

    Thanks, -------

I'm very sympathetic to our friend, and I'd be willing to include purchases through block 255365 if there are no objections. Although the spec is very clear that the arbitrator is the block-chain time-stamp (so I don't think there is risk of legal trouble), any transaction which was sent before the deadline was clearly sent in good faith respecting the deadline, and I'd like to extend some grace to those people. I hadn't realized that block 255365 included transactions sent before the deadline, or I would have suggested including them before.

Tachikoma's opinion on this issue matters a lot to me, since he has the best implementation of MasterCoin so far. Tachikoma, are you willing to update your code to recognize transactions through block 255365?

I'm absolutely firm on one thing though - I don't want to include more blocks beyond 255365 unless they can be shown to contain MasterCoin purchases sent before the deadline!

[dacoinminster]

Spec Updated to 1.1

On Sunday all three kids were napping and my wife ran some errands, leaving me with 80 whole minutes of peace and solitude, in which I updated our spec to version 1.1, which includes the following changes:

• Smart property! Instructions on how to create a deed/title, issue a user-backed currency, and IPO a company are included.
• Escrow fund changes to defend against the bytemaster/d'aniel attack
• All MasterCoin transactions now reference the Exodus Address for easier parsing (previously data tickers and MasterCoin purchases on the distributed exchange made with bitcoin did not reference the Exodus Address)
• Specified that only sendmany transactions are valid for now (no breaking MasterCoin transactions into multiple pieces, at least not yet)
• Specified that advanced features (beyond simple send) need to wait for a better way to store our data in the block chain

All updates in the spec are clearly marked with "Update 9/8/2013:"

The latest version of the spec is always available here: https://sites.google.com/site/2ndbtcwpaper/ (first link on the page)

[dacoinminster]

Willet, can you add a link to the FAQ to the op?

Done. Thanks!

[hephaist0s]

I don't want to add too much noise to this thread, but holy cow -- http://mastercoin-explorer.com/ is amazing! That is some exciting stuff.

[superfluouso]

I've just put a new version of the http://mastercoin-explorer.com online.

This version actually has some useful information. For one it can approximate balances for a given address and show what kind of transactions where done by them. As always this is an initial version of this functionality so don't expect any miracles

J.R.: I spend way more time on this then I originally planned. So to be honest I hope there will still be a bounty for something like this even if I build it already; not that that was the reason for me doing it to begin with

Excellent!  This looks great and its the first version that has correctly calculated my total purchase amount. There definitely needs to be some bounty for you.

[dacoinminster]

I don't want to add too much noise to this thread, but holy cow -- http://mastercoin-explorer.com/ is amazing! That is some exciting stuff.

I don't think we could say that enough - it's definitely not noise. I am seriously in awe at how fast this is coming together. I thought I'd have to spend a ton of money over multiple coding contests and probably a couple hired employees to even get this far.

What do you guys think about offering Tachicoma $10,000 to release the source code to mastercoin-explorer.com right now, and using THAT as the starting point for our coding contest? Obviously, he'd still be welcome to participate in the contest by improving on his code further . . .

I have NOT run this by the board at all, so I'm just speculating here. No promises. Also, Tachicoma might prefer to hold on to the source code through the end of the contest, although I doubt he would get quite as much money that way

Thoughts?

[vokain]

Let's run the contest as expected and let the best men win, which at the moment is tachikoma? At least the others will have a chance to compete against the already high bar that's set, and we'll get more quality efforts as a result.

[maxmint]

I don't want to add too much noise to this thread, but holy cow -- http://mastercoin-explorer.com/ is amazing! That is some exciting stuff.

I can't believe how fast this is evolving. Superbe functionality and a great UI – excellent work!!!

[hephaist0s]

I support the idea of offering some reward/encouragement to Tachikoma for his work so far, since he's jumped on this on his own without being motivated by the contest, and it's both a great tool for MasterCoin and wonderful for our visibility/acceptance as well -- it makes MasterCoin feel a lot more real, which will subsequently help spurr the coding contest.

[dacoinminster]

holy cow -- http://mastercoin-explorer.com/ is amazing!

What do you guys think about offering Tachicoma $10,000 to release the source code to mastercoin-explorer.com right now, \

10 bucks is a lot of money.  There is no doubt he's earned 5.  Let him have 5 now plus he can enter the contest.  Impromptu bonuses like this have the great effect that other programmers will also jump in.  Being loose with rewards is far better than being tight with them.  I'd say send him the juice today to lube him up and keep him working hard.  It is a nice tool.  I look forward to many more.  

I chose 10 because it's a little less than he would probably earn by holding onto the code and working on it through the coding contest against other motivated participants. If we buy the code now, he can get 10k now, PLUS enter the coding contest fresh and earn more money by making improvements along with everyone else.

As you say, I'd rather be generous.

Again, no promises. The board hasn't approved this expenditure.

[ldrgn]

Haven't read the thread, but may eventually.  If this stuff was brought up before that's great, otherwise idk how everyone ignored it for so long:

General notes:

• if you can get a PKI in the blockchain using this system that single feature would make MasterCoin actually viable.  Seriously, everything in here is schlock compared to that.
• URLs in the prospectus messages is a pretty useful idea, it's probably worth having your MasterCoin foundation buy a domain and use it as an official shortener.  Alternatively if you still want everything in the blockchain I'd have a special URL message type with the ability for other messages to refer to it and the ability for the URL messages to succeed each other.
• Pretty much everything here would benefit from a 'prospectus' parent message with a numeric ID (or pubkey) and 'update' messages that reference the parent rather than re-specify all the bajillion little details
• Even if you're not coding you can start outlining a test suite now

Data streams:

• You use strings but don't mention encodings?  What have you been working on for the past 10 years of software experience?  The 80s are over brah.
• I think you're greatly underestimating the value of identity for a data stream, especially for one where you have to pay to get the data into the blockchain[0].  If you're going to the step of paying to put it into the blockchain and distribute it publicly like that it's likely that people are interested in your exact stream and not a generic category like Commodities::Metals::Gold.  So why keep the categorization in the blockchain and waste your precious transaction space?  Why use the serial number (unique identifier in the spec) at all?  Why not just stick to the source address as the identifier for a stream and leave it at that?  Nobody's interested in "Gold", they're interested in "The gold spot price at xyz exchange as published by the xyz exchange".  The whole category system is pointlessly wasteful.
• It would be cool to keep data feeds optionally encrypted for paid services but this might necessitate a PKI (also another useful thing to build)
• It would be cool to have the feed choose what the multiplier goes against (another sub-currency or another feed).  That's a much more useful use of transaction space than the category c strings.
• You need to have 'update' and 'prospectus' message types to save on size/cost

Bets:

It seems like you would be better served by implementing a scripting language allowing you to express conditionals for contracts of all types rather than the somewhat specific bet transaction type.

Smart Property:

• This is woefully under-specified.  Issuing new shares is a critical part of financing any business.
• Why do you waste space on another string identifier (redundant, addresses fill that role much better) but don't leave space for a URL (something actually useful?)
• Once again a place that would benefit from a scripting language for contracts/trades

Currency stabilization:
In general this is antithetical to the idea of a decentralized currency - someone in authority needs to pick a data stream and use it for your hedging.  So why keep all this stuff in the blockchain if it's not decentralized?  You're making an inefficient and wasteful service by keeping it there.

• You need to specify the formulas/algorithms that are going to be used for hedging!!!!!!!!
• You need to publish a paper modelling these algorithms and showing possible outcomes, measuring risk and generally throwing the wall at it under simulation.  Anything else is not due diligence.
• Another string as an identifier, wtf mate

You might have experience as a programmer but I take it you're not a systems guy.  Find someone who is and have them draft the spec.  You might not be familiar with hedging algorithms but you've got one implemented for the currency stabilization process.  Either find one and have them write a paper for you or dig up what the finance guys have in their literature and refer to it.  You don't have a bibliography and that's a bad thing, there is a whole lot here that is not novel and needs to be referenced so everyone knows you're not butting heads with what's generally held to be true.  tl;dr shoddy work designed by the clueless and implemented by the fools that follow them, stay away

[dacoinminster]

Haven't read the thread, but may eventually.  If this stuff was brought up before that's great, otherwise idk how everyone ignored it for so long:

General notes:

• if you can get a PKI in the blockchain using this system that single feature would make MasterCoin actually viable.  Seriously, everything in here is schlock compared to that.
• URLs in the prospectus messages is a pretty useful idea, it's probably worth having your MasterCoin foundation buy a domain and use it as an official shortener.  Alternatively if you still want everything in the blockchain I'd have a special URL message type with the ability for other messages to refer to it and the ability for the URL messages to succeed each other.
• Pretty much everything here would benefit from a 'prospectus' parent message with a numeric ID (or pubkey) and 'update' messages that reference the parent rather than re-specify all the bajillion little details
• Even if you're not coding you can start outlining a test suite now

Data streams:

• You use strings but don't mention encodings?  What have you been working on for the past 10 years of software experience?  The 80s are over brah.
• I think you're greatly underestimating the value of identity for a data stream, especially for one where you have to pay to get the data into the blockchain[0].  If you're going to the step of paying to put it into the blockchain and distribute it publicly like that it's likely that people are interested in your exact stream and not a generic category like Commodities::Metals::Gold.  So why keep the categorization in the blockchain and waste your precious transaction space?  Why use the serial number (unique identifier in the spec) at all?  Why not just stick to the source address as the identifier for a stream and leave it at that?  Nobody's interested in "Gold", they're interested in "The gold spot price at xyz exchange as published by the xyz exchange".  The whole category system is pointlessly wasteful.
• It would be cool to keep data feeds optionally encrypted for paid services but this might necessitate a PKI (also another useful thing to build)
• It would be cool to have the feed choose what the multiplier goes against (another sub-currency or another feed).  That's a much more useful use of transaction space than the category c strings.
• You need to have 'update' and 'prospectus' message types to save on size/cost

Bets:

It seems like you would be better served by implementing a scripting language allowing you to express conditionals for contracts of all types rather than the somewhat specific bet transaction type.

Smart Property:

• This is woefully under-specified.  Issuing new shares is a critical part of financing any business.
• Why do you waste space on another string identifier (redundant, addresses fill that role much better) but don't leave space for a URL (something actually useful?)
• Once again a place that would benefit from a scripting language for contracts/trades

Currency stabilization:
In general this is antithetical to the idea of a decentralized currency - someone in authority needs to pick a data stream and use it for your hedging.  So why keep all this stuff in the blockchain if it's not decentralized?  You're making an inefficient and wasteful service by keeping it there.

• You need to specify the formulas/algorithms that are going to be used for hedging!!!!!!!!
• You need to publish a paper modelling these algorithms and showing possible outcomes, measuring risk and generally throwing the wall at it under simulation.  Anything else is not due diligence.
• Another string as an identifier, wtf mate

You might have experience as a programmer but I take it you're not a systems guy.  Find someone who is and have them draft the spec.  You might not be familiar with hedging algorithms but you've got one implemented for the currency stabilization process.  Either find one and have them write a paper for you or dig up what the finance guys have in their literature and refer to it.  You don't have a bibliography and that's a bad thing, there is a whole lot here that is not novel and needs to be referenced so everyone knows you're not butting heads with what's generally held to be true.  tl;dr shoddy work designed by the clueless and implemented by the fools that follow them, stay away

I certainly can't stop people for escaping unicode characters in the ASCII strings if that is what they want to do, but I'm trying to keep the spec simple, with a tiny footprint in the block chain, so I'm not including unicode support in the spec out of the gate. I believe internationalization effort should be mostly client-side, and via URLs which have been shortened, as you alluded to.

As for the rest, I look forward to seeing your much-improved spec, or anybody else's for that matter. I waited a long time for somebody else to take a crack at this, and finally got tired of waiting, but maybe now that I have demonstrated the fund-raising method others will take a shot. We'll do our best to shamelessly steal any good ideas we see

[ripper234]

Woah, nice addition.

Can the spec be moved to github, for better history tracking and pull requests?

[Tachikoma]

Sorry, wall of text incoming

Tachikoma's opinion on this issue matters a lot to me, since he has the best implementation of MasterCoin so far. Tachikoma, are you willing to update your code to recognize transactions through block 255365?

I'm absolutely firm on one thing though - I don't want to include more blocks beyond 255365 unless they can be shown to contain MasterCoin purchases sent before the deadline!

I'm updating the code right now to include everything up to and including 255365. Nothing we can do about it now but I think the spec should be more pro-active to prevent problems like this in the future.

The only caveat is that you'll have to release the source code at the end of the contest, which I assume won't be a problem

I always planned to release the underlying libraries but originally did not plan to release the source code to the website since it's just one implementation of the library itself.

• Specified that advanced features (beyond simple send) need to wait for a better way to store our data in the block chain

This a thousand times. It's very easy to extend the functionality once there is a proper way to store data in the chain. I will focus on this next if nobody comes forward with a way to do this in the next few days.

Spec Updated to 1.1

I did not re-read it yet so forgive me if you already did this. Did you describe which timestamps to use for transactions and how to deal multiple transactions from the same user in the same block (especially if not all transactions can be satisfied)? (See discussion on the previous page)

Tachikoma has done some great work on it so far, on his own volition. Its looks awesome and it's appreciated by everyone who invested. However, the project is barely out of the conceptual stage. Do you really want to start playing loose and fast with the investment funds? Wouldn't it be better to have a structured Bounty/Reward system laid out and discuss this kind of thing with the board before throwing out random offers?

I tend to agree. This project is barely started up and there is so much work to be done still. Although I really appreciate the gesture I think a formal bounty system would benefit Mastercoin better. I will see what I can do to just claim some bounties

Although I have no problems releasing my code but I really want to motivate others to build the same stuff I did. In order for Mastercoin to work a dialog needs to happen between developers. A lot of things in Mastercoin are open for interpretation and having multiple coders working on it in their own code might bring the problems to the surface. The other problem with releasing it now is that a lot of stuff that's written at the moment won't work when we implement a new method to encode the data and it won't work with anything other then simple send. I rather release it once these problems have been solved so it's at least future complete.

Lastly; thanks everybody for the compliments; I am happy that my work these past days is appreciated