Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 124. (Read 448462 times)

Fantastic job, Tachikoma! Thanks for your efforts!

Question: if you click on "New Transaction" the MasterCoin Advisor appears. How does this work?

Let's not forget that there's a bitcoin address posted in the footer of mastercoin-explorer.com (1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B).
I just sent a small tip because I think this site just totally rocks!

Hah no I think that's the only one; just think it needs to be added to the spec ^^

All the transactions up to 255365 should be added. But it's late so I did not check them all.

Awesome.

We need some closure on the refunds issue, so let's draw the line at block 255365. Do NOT ask me to massage the spec to include your attempted purchase which was not included after block 255365! Everything after that block (not including MasterCoin transaction outputs) will be refunded. If somebody sends MORE money to the Exodus Address after I process the refund, they risk never seeing that money again.

Tachikoma, I'm sorry - I just have a very strong impulse to send you money after all the work you've done. I'll try to restrain myself. My board is already doing their job - when I mentioned this to them, they also advised me to not be too fast and loose with the money

It's up to you whether you release the source code for the library only or for the whole web page. The rules for the contest will only allow consideration of projects which have source code released at the end of the contest, so only your library would be considered in the contest if you didn't release the code to the web page. Either way is fine by me.

Regarding the timestamp question, I did not clarify it further (although I did address several other things which have come up). Let's take MasterCoin transactions in the order they are included in the block by the miner. I'll try to address that in the next rev of the spec.

Do we have another timestamp we could use besides the timestamp on the block itself? I was assuming the block timestamp was our only option . . . 

Sorry, wall of text incoming



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.


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.


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.

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)


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

Woah, nice addition.

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

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

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

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.

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

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.

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?

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.

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.

Done. Thanks!

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)

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




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!

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.

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