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

[TKeenan]

Sheesh. With the recent bitcoin price run-up, this contest is now worth ~$80k! Compare that to the meager $25k we gave away for the last one . . .

80K!!!  Hell, you can buy one very freaking nice Harley for that kind of coin.  WOW!

[dacoinminster]

I should probably at least mention in this thread my list of proposed changes for the next rev of the spec:

I have cloned the github repo of the spec (https://github.com/mastercoin-MSC/spec), and I have prepared the following comprehensive list of changes planned for version 1.2 of the spec:

• Fix incorrect sequence number description (https://bitcointalk.org/index.php?topic=265488.msg3122349#msg3122349)
• Clean up various things which were still undecided as of 1.1 or are now out-dated (as I find them)
• Include description of how to determine change addresses (https://bitcointalk.org/index.php?topic=265488.msg3190175;topicseen#msg3190175)

  • All protocol transactions should have the same output amount. If one output is different, that is the change address.
  • If all outputs are the same, then look at sequence numbers:
    • If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
    • If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
    • If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!

• Integrate Zathras' Class A/B/C documentation describing multi-sig (https://masterchest.info/files/mscappendix_draft.pdf)
• Clarify distributed exchange rules when BTC is not involved (especially that buy/sell orders can be matched automatically
• Add support for "pay dividend" command (https://bitcointalk.org/index.php?topic=265488.msg3233723;topicseen#msg3233723)
• Add support for "spending limits" on a savings address (https://bitcointalk.org/index.php?topic=265488.msg3412565;topicseen#msg3412565)
• Add support for "kickstarter" type fundraisers (where money is returned if the goal isn't met) (https://bitcointalk.org/index.php?topic=265488.msg3451098;topicseen#msg3451098)
• Add support for "Contract For Difference" betting (https://bitcointalk.org/index.php?topic=324830.0)
• Add support for "Distributed e-commerce" transactions (http://www.reddit.com/r/mastercoin/comments/1nqcq3/mastercoin_could_be_extended_into_a_fully/)

I hope I got everything. If you think something else should be in that list, please let me know!

[Bitoy]

Example scenario

Seller post 10 coins for sale
BuyerA post a purchase  request for 3 coins (but has not paid)
Available is 7

BuyerB  post a purchase for 10 coins but since available is only 7 he gets only 7.
BuyerB makes a payment.
Available is 0 (7 paid by buyerB and 3 still pending payment from buyerA)

After 1 day BuyerA didn't pay and time expired.
Available is 3.

Is this correct?

According to my interoperation Buyer B's Purchase Offer would be invalid since he wanted 10 coins but at that moment only 7 were available.

Thank you Tachikoma.  I'll update my codes.

[Bitoy]

bitoy - great job on mymastercoins.com!

I've added links to the OP of the main project thread, and to our subreddit. I'll see about getting it listed on Mastercoin.org too. Looks like masterchain.info needs a link from there too.

Thanks!

If anybody notices that their project isn't linked from one of our channels, please let me know. I don't want to slight anyone!

Thanks dacoinminster  

[Bitoy]

Thanks mate, have to say I am quite proud of how the new exchange panels look, might post a teaser screenie later after work

Looking forward to see your work.  We need to post more test data 

[grazcoin]

I really don't understand the problem.

Zathras is making an Windows based client. I'm sure it will have a nice installer with it and for him this is as easy as pressing the compile button.

My client will be very easy to use on any unix-based system, much like Grazcoin's implementation. As long as there is a wallet for any flavour I don't really see a problem.

I feel strongly about this because I have no way to accomplish a windows installer because of a decision I made months earlier. If I knew this was a requirement before hand I would have decided to build the application in Python since it's much easier to build on Windows. I am working my ass of and you are basically telling me; sorry it's useless.

Whew! I'm relieved to hear you say this. I think I must have chosen my words poorly at first.

I didn't mean to say that all desktop clients need a Windows installer, but rather that we need a Windows installer for at least one of the desktop clients before we can call this contest finished. It sounds like you agree?

I am glad to hear that windows installer is not a must now, since I speak no MSFT.
The wallet mastercoin-tools will announce is javascript based, and runs inside a browser. It solves then also windows usage case as well (and more importantly in recent times - smartphones usage).
Support for offline usage will be available too.

[Tachikoma]

Please don't store any sensitive data server-side, make it a full javascript implementation. There have been too many hacks already.

[grazcoin]

Please don't store any sensitive data server-side, make it a full javascript implementation. There have been too many hacks already.

Server side has only public available data. Nothing to steal there.
Private keys - they better stay totally offline, but if you like to risk, they could be on your online private device, making the usage easier.

[grazcoin]

Example scenario

Seller post 10 coins for sale
BuyerA post a purchase  request for 3 coins (but has not paid)
Available is 7

BuyerB  post a purchase for 10 coins but since available is only 7 he gets only 7.
BuyerB makes a payment.
Available is 0 (7 paid by buyerB and 3 still pending payment from buyerA)

After 1 day BuyerA didn't pay and time expired.
Available is 3.

Is this correct?

According to my interoperation Buyer B's Purchase Offer would be invalid since he wanted 10 coins but at that moment only 7 were available.

I am more for Bitoy interpretation.
Right after BuyerB sent the purchase/accept offer of 10, he could see that he actually reserved only 7 coins (as 3 are reserved for BuyerA).
Then he should pay for those 7 coins.
At that point, if BuyerA pays, he gets the 3 coins he reserved, and if he doesn't, those 3 coins become available for other buyers - BuyerB could then ask for another 3 coins.

Generally, purchase offers for more than the available amount should be considered valid for the whichever amount available.

[Tachikoma]

This makes the implementation much harder to validate and makes it harder for people to understand what is going on with their offers.

J.R. can you make a decision on this one?

[zathras]

The spec does provide for truncating an order to available units:

3. Amount you are purchasing = 130,000,000 (1.30000000 MasterCoins) (64-bit unsigned integer, 8
bytes, should not exceed number available for sale, but if it does, assume buyer is purchasing all
of them)

The question I don't see discussed yet; was Buyer A's purchase request confirmed in a block before Buyer B placed their purchase request?

[Tachikoma]

The spec does provide for truncating an order to available units:

3. Amount you are purchasing = 130,000,000 (1.30000000 MasterCoins) (64-bit unsigned integer, 8
bytes, should not exceed number available for sale, but if it does, assume buyer is purchasing all
of them)

The question I don't see discussed yet; was Buyer A's purchase request confirmed in a block before Buyer B placed their purchase request?

I still think this is a different situation. At one point there _were_ 10 coins available, it just wasn't the case when the payment got confirmed. Only 3 were left. I think it would be weird to see my Purchase Offer being accepted but all of the sudden the amount got reduced from 10 to 3 coins. I might not notice and send Bitcoins worth 10 MSC instead of the 3 I got now. It's all around confusing. I don't understand why not just invalidate the whole Purchase Offer and make it easier for everybody.

[dacoinminster]

I still think this is a different situation. At one point there _were_ 10 coins available, it just wasn't the case when the payment got confirmed. Only 3 were left. I think it would be weird to see my Purchase Offer being accepted but all of the sudden the amount got reduced from 10 to 3 coins. I might not notice and send Bitcoins worth 10 MSC instead of the 3 I got now. It's all around confusing. I don't understand why not just invalidate the whole Purchase Offer and make it easier for everybody.

I think this is more of a UI design question than a spec question. There will be lots of buy and sell offers going on, and the higher the trading volume, the more annoying it will be to not get partial fills.

We already need to design the UI carefully so that the user knows not to send bitcoin payment until they receive confirmation. We also need to make sure that the confirmation is very explicit about how many coins they have reserved for purchase (which might not be the amount they were trying to buy) and how much money they need to send, and where to send it. A simple binary switch (you got it, or you didn't) doesn't handle collisions very elegantly.

[dacoinminster]

The question I don't see discussed yet; was Buyer A's purchase request confirmed in a block before Buyer B placed their purchase request?

Yeah, the order in the block chain is what matters. We shouldn't show confirmation that it is ok to send bitcoins until at LEAST one block, preferably more.

[zbx]

Hello, all.

I'm having trouble with a Mastercoin transaction that I just crafted (using my own software): 'ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc'. It's called 'Valid' on Mastercoin explorer, but the destination address isn't being properly recognised. It isn't even showing up on Masterchest. It seems that the problem may be with the sequence numbers, which are, in that transaction, ascending. Previous transactions that I sent from that address (using Test MSC), used descending sequence numbers and were parsed properly. But the latest spec (on GitHub) says that they should be ascending, no? In any case, it's not a big deal to me if the transaction in question is invalidated, because I control the destination address, too.

[zathras]

Hello, all.

I'm having trouble with a Mastercoin transaction that I just crafted (using my own software): 'ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc'. It's called 'Valid' on Mastercoin explorer, but the destination address isn't being properly recognised. It isn't even showing up on Masterchest. It seems that the problem may be with the sequence numbers, which are, in that transaction, ascending. Previous transactions that I sent from that address (using Test MSC), used descending sequence numbers and were parsed properly. But the latest spec (on GitHub) says that they should be ascending, no? In any case, it's not a big deal to me if the transaction in question is invalidated, because I control the destination address, too.

So for this one, it looks like a mastercoin transaction (specifically Class A simple send):

Code:

Console.WriteLine(mlib.ismastercointx(bitcoin_con, "ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc"))
simple

However as you note the sequence numbers are not correct:

Code:

50 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby 
51 15efTnSCG13druGmetEp1AULCEqudtCSwq 

Sequence number 51 is your data address, so your reference address should be 52, not 50 - this is why Masterchest throws it out.

From my suggested appendix:

The reference address sequence number must be the data address sequence number + 1

I hope JR won't mind me saying this, but I think my suggested appendix is the most up to date reflection of how we're parsing transactions at this point in time.  With that said I understand JR is slap bang in the middle of a spec update, and these changes will (I believe) make it into rev 1.2 of the spec.

Tachikoma, I don't consider this valid but mastercoin-explorer seems to (though it does seem to throw a bad destination address), is that a bug or do we have differing interpretations of Class A?  

Thanks!

[Tachikoma]

Tachikoma, I don't consider this valid but mastercoin-explorer seems to (though it does seem to throw a bad destination address), is that a bug or do we have differing interpretations of Class A?  

Thanks!

That's a bug! Will fix that

[zbx]

Great. Thanks for the help.

@zathras, just to be clear, shouldn't it be the other way around, i.e., shouldn't the sequence number of the reference address determine the sequence number of the data address? I can't change the sequence number of the reference address to 52; I must change the sequence number of the data address to 49 (in this example). (This is really just a question of how the spec. should be worded... in parsing, the two might well be equivalent.)

[zathras]

Great. Thanks for the help.

@zathras, just to be clear, shouldn't it be the other way around, i.e., shouldn't the sequence number of the reference address determine the sequence number of the data address? I can't change the sequence number of the reference address to 52; I must change the sequence number of the data address to 49 (in this example). (This is really just a question of how the spec. should be worded... in parsing, the two might well be equivalent.)

Of course sorry, my reply was worded poorly - I simply meant that during decoding we would expect the sequence number to be 52 but as it's 50 we throw the transaction out - you're correct, in this instance when encoding you would change the data address seqnum to 49

I would however encourage you to target Class B transactions in your software for simple sends rather than Class A due to the blockchain bloat issue.

Thanks!

[Tachikoma]

I've submitted a PR for the spec to include our "reserved funds" discussion. Please comment on the PR to keep the discussion centralised there: https://github.com/mastercoin-MSC/spec/pull/1