300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[dacoinminster]

This thread has MOVED to MastercoinTalk: http://mastercointalk.org/index.php?topic=297.0

Thread is now locked. Please join us on the Mastercoin Forum!!

If you've been living under a rock, you may not know that we recently raised nearly 5000 BTC to build a new protocol layer on top of bitcoin. The new layer is NOT an alt-chain currency - it's built right on top of bitcoin, and is called "MasterCoin" (not to be confused with the alt-chain currency of the same name). You can read all about it here: https://bitcointalk.org/index.php?topic=265488.0

A few days ago, I pre-announced that we would be doing our second major coding contest, with total prizes adding up to 300 BTC (https://bitcointalk.org/index.php?topic=265488.msg3358444#msg3358444). The goal of this contest is to implement a distributed bitcoin/mastercoin exchange. NOBODY has ever made a distributed exchange between two digital currencies, and we aim to do it first. We are also still looking for our first full-time hire, hopefully recruited from among the contestants.

This thread is devoted to the current MasterCoin contest (this thread was originally for contest #1). Following are the official rules of the current contest, subject to change if deemed necessary:

Official Rules

• ALL serious entries will win a prize (although some prizes may be very small)
• Prize money will be divvied up by myself, with input from the community and the board of the MasterCoin Foundation, based primarily on how useful and valuable your code is to accomplishing the goals of the contest
• In addition to the overall impact and value of your code, other important things will be taken under consideration:
  
  • How often you post updates in this thread. Ideally, you should post what you plan to do, and then post extremely frequent updates as you make progress.
  • Ease of use and testability. If you just dump some source code on me at the end of the contest with a bunch of grandiose claims, you may not get much. Ideally, you should be posting demos, screenshots, and/or set up a website demonstrating your code.
  • Collaboration. If you are helping other people working on MasterCoin projects, that will weigh favorably on how much you win. If you release your source code early and other people build on it, that will weigh even more favorably.
    • Note that contest contestants will give me feedback on each other, and that feedback will be heavily considered when making payouts (so be nice to each other!)
    • If somebody forks your code, and builds on it, you will get some consideration at payout time, even if you did nothing in the current contest.
  • Breaking new ground, or being redundant. Doing something new is awesome, but you will NOT be penalized for implementing the same thing as someone else. We need redundancy for cross-checking.
• Only open-source projects will be considered for a prize. You must release your source code before the end of the contest to be eligible.
• Getting the biggest prize in this contest does NOT guarantee you a job, but having some kind of entry in this contest will help your chances a lot.
• Contest ends once all acceptance criteria have been met (see below), with prizes paid out once the dust settles.
• Prizes will total 300 BTC, regardless of the current price of bitcoins
  • 200 BTC will be split up among contributing developers
  • 100 BTC will be split up among anybody who helped by doing code reviews, testing, and bug reporting (this may be the same people as the developers, or different people)
• Contestants may elect to take some or all of their prize money in MasterCoins if desired. (We'll purchase them on the open market for you, using the bitcoins we would have paid you)

Acceptance criteria:

• Minimum one PC wallet (for both Linux and Windows) which can generate simple sends and the buy/sell messages required for the distributed exchange, using agree-upon multisig format
• Minimum two websites parsing such messages, and the resulting balance transfers
• Minimum one website showing BTC/MSC price charts derived from these messages
• Minimum 10 days of real-world usage with no major problems
• High bar for usability. (Current heavy traders like maxmint, lishbtc, and buymastercoin should be happy with the final product, if at all possible)

This thread is for development-related discussion ONLY. If you want to discuss MasterCoin in ways not related to our development effort, please do so here: https://bitcointalk.org/index.php?topic=265488.0

Posts immediately below are from the first contest. Discussion regarding work on the current contest starts here: https://bitcointalk.org/index.php?topic=292628.msg3381794#msg3381794

Thanks, and good luck!

Important update: We'll be paying out half of this bounty early (on 1/22/2014). Details here: https://bitcointalk.org/index.php?topic=292628.msg4398023#msg4398023

Another important update: the remainder of this bounty will be paid out in monthly chunks until we are done. Details here: https://bitcointalk.org/index.php?topic=292628.msg4921986#msg4921986

[TomHirsch]

we recently raised over half a million dollars to build a new protocol layer on top of bitcoin.

You should be aware that multiple projects eligible for entry into this contest are already started, and have made amazing progress.

Wow!!! This is excellent.  What a way to launch a project.  People are just jumping in before the contest is even official.  Hope we find some great coders.

Very cool.

[doof]

There is a mistake in your specification.  From https://e33ec872-a-62cb3a1a-s-sites.googlegroups.com/site/2ndbtcwpaper/MasterCoin%20Specification%201.1.pdf

The maximum reversibility period is 365 days (1,892,160,000 seconds) to avoid accidents.

365 days = 365 * 24 * 60 * 60

= 31536000 seconds

NB a year could be 365.2425 too.

[dacoinminster]

There is a mistake in your specification.  From https://e33ec872-a-62cb3a1a-s-sites.googlegroups.com/site/2ndbtcwpaper/MasterCoin%20Specification%201.1.pdf

The maximum reversibility period is 365 days (1,892,160,000 seconds) to avoid accidents.

365 days = 365 * 24 * 60 * 60

= 31536000 seconds

NB a year could be 365.2425 too.

Heh. I was originally thinking 6 years when I calculated that number, then decided that nobody needed a reversibility period quite that long. I changed the number of days but didn't recalculate the number of seconds.

Thanks for catching that!

[dacoinminster]

I just got this interesting PM from an interested party (I've removed their name since they chose to share this concern privately):

Hey J.R.

Something is bothering me about the contest and I wanted to discuss this with you.

Although the contest is a great thing I'm afraid that without a proper way of encoding Mastercoin data a lot of the time and energy of developers is going to waste.

People will probably build all sorts of cool stuff based on the current encoding standard (Bitcoin address for data) but once a new way, hopefully multisig, of encoding is in place all these projects become obsolete unless the author is going to keep supporting it. The question is if they will continue to support their code after they already received the bounty.

Going to encode data in multisig transactions is harder because you need to dive a level deeper into the Bitcoin protocol leaving the address codebase behind and diving into scripting. The amount of people who can solve this problem is significantly smaller then the amount who can use a library that does the multisig encoding and build awesome stuff on top of it.

I would have advised you to hold off on the contest until a developer came forward with a new encoding spec so that all the tools build in the contest would be here to last.

I can imagine that you don't want to pause the contest anymore at this point, although I hope you might consider it. An other option might be to set a specific bounty for multisig encoding to try and make sure this is the first thing that gets released so other tools can build on top of this. I know maraoz is working on multisig encoding and you might poke him to see if he is making progress on this. If so this whole pm might be moot

Anyway; just my two cents!

Regards,

-----

This is definitely a concern. However, there are a number of things I am counting on to hopefully mitigate this risk:

• We will always support simple-send using the current method, because people need a way to move money out of standard bitcoin wallets into full-featured MasterCoin wallets
• We will NOT be accepting projects which implement new features using the existing methods
• Since all projects must have their source-code released, even if the developer abandons the project, someone else can pick it up
• If somebody releases a library with a method for better encoding of our data early on in the contest, and lots of people use it, that person will definitely be rewarded for their efforts (hint hint)
• Since the rewards will be distributed according to our impression of the overall value of each project, projects which store our data in a new way and projects which build on that method get a pretty big bonus over those which don't. People who put a lot of effort into elaborate systems using the old method may be disappointed with what they get
• This is probably, hopefully, not our last coding contest

I hope that helps. I'm definitely open to modifying the contest rules to make sure the right work gets done!

[doof]

There is a mistake in your specification.  From https://e33ec872-a-62cb3a1a-s-sites.googlegroups.com/site/2ndbtcwpaper/MasterCoin%20Specification%201.1.pdf

The maximum reversibility period is 365 days (1,892,160,000 seconds) to avoid accidents.

365 days = 365 * 24 * 60 * 60

= 31536000 seconds

NB a year could be 365.2425 too.

Heh. I was originally thinking 6 years when I calculated that number, then decided that nobody needed a reversibility period quite that long. I changed the number of days but didn't recalculate the number of seconds.

Thanks for catching that!

Happy to peer review.  I dont fully understand the inbuilt betting.

The layer, lays a bet such as Gold Price @ 2:1.  These odds then remain fixed?  So the backer could then wait n days, if gold prices raise the backer is getting better odds?

[Super T]

Happy to peer review.  I dont fully understand the inbuilt betting.

The layer, lays a bet such as Gold Price @ 2:1.  These odds then remain fixed?  So the backer could then wait n days, if gold prices raise the backer is getting better odds?

Any odds/offers published would need to be maintained and updated or removed if no longer valid, in the same way as anyone offering betting services online has to keep on top of the odds they offer.  This is a necessary and vital facility.

Where it gets interesting is if a major event occurs which significantly changes the odds of an event occurring whilst an offer is live, we might see the bet provider racing to close/adjust an offer whilst a flood of bet matches are submitted - with the outcome (bet filled or bet adjusted) potentially being determined by nothing more than the order of transactions within the next block.

[dacoinminster]

GO  AWAY
It's Bitcointalk not Altcoin or freelancer or some coding central forum.

Doesn't this belong in the alt-coin forum with the rest of the alt-coin stuff?

Thanks for your interest in my project.

MasterCoin is a bitcoin project built on top of bitcoin, making bitcoin more valuable and useful. The mods have (so far) allowed MasterCoin to stay here, where I believe it belongs.

I hope you'll forgive me for deleting your posts - I don't want to distract from the purpose of this thread.

[dacoinminster]

Happy to peer review.  I dont fully understand the inbuilt betting.

The layer, lays a bet such as Gold Price @ 2:1.  These odds then remain fixed?  So the backer could then wait n days, if gold prices raise the backer is getting better odds?

Any odds/offers published would need to be maintained and updated or removed if no longer valid, in the same way as anyone offering betting services online has to keep on top of the odds they offer.  This is a necessary and vital facility.

Where it gets interesting is if a major event occurs which significantly changes the odds of an event occurring whilst an offer is live, we might see the bet provider racing to close/adjust an offer whilst a flood of bet matches are submitted - with the outcome (bet filled or bet adjusted) potentially being determined by nothing more than the order of transactions within the next block.

That is absolutely correct

It will be interesting to see all the repercussions.

[doof]

Happy to peer review.  I dont fully understand the inbuilt betting.

The layer, lays a bet such as Gold Price @ 2:1.  These odds then remain fixed?  So the backer could then wait n days, if gold prices raise the backer is getting better odds?

Any odds/offers published would need to be maintained and updated or removed if no longer valid, in the same way as anyone offering betting services online has to keep on top of the odds they offer.  This is a necessary and vital facility.

Where it gets interesting is if a major event occurs which significantly changes the odds of an event occurring whilst an offer is live, we might see the bet provider racing to close/adjust an offer whilst a flood of bet matches are submitted - with the outcome (bet filled or bet adjusted) potentially being determined by nothing more than the order of transactions within the next block.

That is absolutely correct

It will be interesting to see all the repercussions.

Ok.  So who determines the outcome of the wager?  If it is the layer, what stops them not paying out?

[Ola]

• How often you post updates in this thread or the main project thread. Ideally, you should post what you plan to do, and then post extremely frequent updates as you make progress.

OK, I guess I'll start posting more frequently then! I'm building a desktop mastercoin client. It currently requires a bitcoin-qt client running on the same machine to operate, because it uses the bitcoin-RPC server to broadcast transactions.

The code is here: https://github.com/maraoz/pymastercoin
and I'll post any updates here. Technical discussion will remain on the Mastercoin original thread.


Right now I'm working on data storage methods, because it seems like we should first define that and then build over it. I'm looking to create a simple GUI for a PC wallet. The goal is to be able to see the current Mastercoin balance for your bitcoin addresses and create simplesend transactions. I'm also looking to update the client to support advanced features when they become specified and reviewed.

I think the project will be useful because it'll allow desktop users (who normally don't want to trust web wallets) to fully use Mastercoin on their own machines.
Cheers!

great job to you and Tachikoma...if later down the line you need a slick simple interface developed that is intuitive, easy use e.t.c post a front-end brief somewhere so that others and I can contribute some free time to the development. I got a full plate already, least I can do right now is encourage from the sidelines and I am bringing some press to mastercoin today.

[dacoinminster]

Ok.  So who determines the outcome of the wager?  If it is the layer, what stops them not paying out?

Everyone parsing Mastercoin recognizes the winner as the new owner of the coins. There is no action required to pay out - everyone knows who won, and only the winner can validly spend those coins.

[dacoinminster]

• How often you post updates in this thread or the main project thread. Ideally, you should post what you plan to do, and then post extremely frequent updates as you make progress.

OK, I guess I'll start posting more frequently then! I'm building a desktop mastercoin client. It currently requires a bitcoin-qt client running on the same machine to operate, because it uses the bitcoin-RPC server to broadcast transactions.

The code is here: https://github.com/maraoz/pymastercoin
and I'll post any updates here. Technical discussion will remain on the Mastercoin original thread.


Right now I'm working on data storage methods, because it seems like we should first define that and then build over it. I'm looking to create a simple GUI for a PC wallet. The goal is to be able to see the current Mastercoin balance for your bitcoin addresses and create simplesend transactions. I'm also looking to update the client to support advanced features when they become specified and reviewed.

I think the project will be useful because it'll allow desktop users (who normally don't want to trust web wallets) to fully use Mastercoin on their own machines.
Cheers!

Awesome! I assume you are following Tachikoma's work on alternate storage methods?

It would be awesome if the three main contributors so far (Tachicoma, grazcoin, and yourself) could agree on a single method and run with it for the duration of the coding contest.

I've said it before: I don't think any of you are going to get enough money for the awesome work you are putting in. Hopefully it will be a nice bonus though

[dacoinminster]

Update 9/18/2013:

I'm currently aware of four people working on MasterCoin-related projects: tachikoma, grazcoin, maraoz, and zathras (if you think you should be on that list, please let me know, and please start posting about your project!). Most of the project updates have been on the main MasterCoin thread, which is fine: https://bitcointalk.org/index.php?topic=265488.0

I've been thinking in more detail about how the judging will go. I think that the contestants are doing a great job of collaborating and reviewing each others' work, and it makes sense to me to ask them to comment on each other's work when it comes time to disperse funds. Consequently, I'm thinking I will ask each contestant to answer this question: if you weren't participating in this contest, how would you distribute funds among the other contestants (using the judging criteria from the rules). The answers to those questions I will then combine with my own opinion which I take to the board for approval.

I don't want things to get overly political or create a popularity contest, but I really value the opinions of the developers working on this project. Opinions on this?

I've also been thinking more about our first full-time hire. Tachikoma has said he doesn't want the job (he hasn't said why, but I suspect he may be in a similar situation to myself, and knows that the MasterCoin Foundation simply can't afford him). Without him as a possibility, there isn't really a clear front-runner yet, although we still have most of the contest ahead of us. I'd be interested to hear which of the other contestants would like to be considered for a job, assuming we can create a compensation package which meets your needs. If at the end of this contest it isn't clear who we should hire, I suppose we could just keep running coding contests and bounties . . .

Thanks!

[joele]

Update 9/18/2013:

I'm currently aware of four people working on MasterCoin-related projects: tachikoma, grazcoin, maraoz, and zathras (if you think you should be on that list, please let me know, and please start posting about your project!).

I'm also interested to work on this project, just busy this month, I'll try to catch up next month before the deadline hopefully. 

[dacoinminster]

I'm also interested to work on this project, just busy this month, I'll try to catch up next month before the deadline hopefully. 

Cool!

Note the rules: Posting early about what you'd like to do, and posting progress as you do it are both important in the final judging.

[axilla]

Just found this, been looking for a new and very interesting coding project.. Will read over the main thread and maybe jump in

[dacoinminster]

Just found this, been looking for a new and very interesting coding project.. Will read over the main thread and maybe jump in

Prepare for a LONG read!

The most important stuff is all linked in the OP of the project thread: https://bitcointalk.org/index.php?topic=265488.0

[Tachikoma]

The library behind http://mastercoin-explorer.com is now available on Github.

At this moment it can do the following:

• Decoding and encoding Mastercoin-data from addresses
• Decoding and encoding Mastercoin-data from public keys
• Decoding multi-sig Mastercoin-data from a tx hash, requires bitcoin-ruby node
• Decoding normal Mastercoin-data from a tx hash, requires bitcoin-ruby node
• Advise address-based Mastercoin transaction
• Calculate Exodus coins bought based on address or transaction-id
• Create and send multisig-encoded Masteroin transaction

[ndsdb]

Hi All,

I would like to contribute something with mastercoin development. Can anyone guide me to take a way.