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

[bluemeanie1]

Time to buy some MSC:

ok where exactly is it explained as to how you will construct this Distributed Exchange?

it seems the winners of this Distributed Exchange contest are making anything but a Distributed Exchange. (appears to be wallets and other tools analogous to past Color Coin efforts).

if you have a Distributed Exchange, I would be very interested to see what you have done.

Please provide some information.  Thanks.

[Tachikoma]

It seems you might have misunderstood what a distributed exchange means. In this case it's not a place you go to exchange. It's a feature of Mastercoin build into the protocol. In order to sell/buy coins you need to send a crafted Mastercoin message with information on what you want to buy/sell. These wallets you talk about offer to do this for you and thus implement the distributed exchange functionality. 

[Tachikoma]

Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.

The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.

I hate chance, and I would like to eliminate it as a factor for Mastercoin.

My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.

Current situation
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.

If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.

Artificial 1 Block lag
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.

However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.

I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better.  

Opinions!?

[Bitoy]

Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.

The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.

I hate chance, and I would like to eliminate it as a factor for Mastercoin.

My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.

Current situation
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.

If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.

Artificial 1 Block lag
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.

However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.

I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better. 

We can give priority to purchase offer over selling offer is they have the same block time.
That way user b will get the price at .1

[Tachikoma]

I wouldn't want to make an exception for just one message, it needs to be protocol wide if we want to even consider this.

FYI: I made a small change to the Verification Spec; I changed the url from mastercoin-verify to mastercoin_verify. I also tried checking out your urls but http://mymastercoins.com/jtransaction.aspx?Address=1QF9Hag3nyjAcXRd6mFrL5KyM3r71hVu2T doesn't seem to work.

My verification API is online.

http://mastercoin-explorer.com/mastercoin_verify/addresses
http://mastercoin-explorer.com/mastercoin_verify/transactions/17UDyggWFP6T3tUPTUEHMU8gxRtLZHG322

As soon as I have some tools available I will create a small comparison service.

[Bitoy]

I wouldn't want to make an exception for just one message, it needs to be protocol wide if we want to even consider this.

FYI: I made a small change to the Verification Spec; I changed the url from mastercoin-verify to mastercoin_verify. I also tried checking out your urls but http://mymastercoins.com/jtransaction.aspx?Address=1QF9Hag3nyjAcXRd6mFrL5KyM3r71hVu2T doesn't seem to work.

My verification API is online.

http://mastercoin-explorer.com/mastercoin_verify/addresses
http://mastercoin-explorer.com/mastercoin_verify/transactions/17UDyggWFP6T3tUPTUEHMU8gxRtLZHG322

As soon as I have some tools available I will create a small comparison service.

I now got your idea. Your delay 1 block will work to fix this issue.


Try (missing  s)
http://mymastercoins.com/jtransactions.aspx?Address=1QF9Hag3nyjAcXRd6mFrL5KyM3r71hVu2T

[Tachikoma]

Thanks, that worked! Your feed is not valid JSON yet however. Strings and keys need to be surrounded in quotes, I think it should be valid after that.

You can always check your feed using: http://jsonlint.com/

[rbdrbd]

Hi guys, quick question on the distributed exchange: as Mastercoin is becoming much more valuable now, is there a way to create buy and sell offers from a totally "offline" machine?

I was planning on moving to an offline armory-based setup (with cheapo laptop with no internet connection) for BTC, and wanted to use this same kind of setup with MSC as well...i.e. comprise the trade on the offline machine (that has wallet.dat), then sneakernet/email some trade code/key/trade token to the connected machine to actually input into the MSC network (that does not have wallet.dat). It seems that currently one can not do simple sends with an offline setup like this (from my own experimentation), but I wanted to check on the distributed exchange features.

If this is not possible, then any ideas when someone may get around to it? If MSC raises another 10-30x, you'll have several MSC millionaires in the bunch. If I was one of those guys, I'd be very concerned with doing any trades out of a wallet connected to the internet.

I am no expert on Armory but I believe it can sign raw transactions. If this is indeed the case you can use mastercoin-explorer.com to create the offers then sign the raw transactions with your own client and relay them through Eligius or Blockhain.info. I also have plans to implement seedless addresses into my wallet software but that's a long term plan. This can be used right now.

Thank you, I am getting an offline system in a few days and will try that out. I'll document whatever works and send it to Ron to make part of the FAQ.

[Bitoy]

Thanks, that worked! Your feed is not valid JSON yet however. Strings and keys need to be surrounded in quotes, I think it should be valid after that.

You can always check your feed using: http://jsonlint.com/

Ok json is validated.

[dacoinminster]

I know I've been promising (and promising and promising) to update the spec. Well, I finally did:

OK - Ron has gotten about a billion balls rolling all at once, and I can't keep up.

What I can do, and did, was get most of the changes I promised ready for version 1.2 of the spec. It's a giant pull request, but I agree that future pull requests should be smaller: https://github.com/mastercoin-MSC/spec/pull/3

This version of the spec, which I labeled 1.2, has dividend payments, CFD betting, spending rate-limits for savings wallets, and distributed e-commerce. Many people will probably use the latter feature as a distributed silk road, but I used selling contraband Bibles as my example

I haven't done proof-of-stake voting yet, although that should be easy. I decided against a kickstarter feature, since someone who can be trusted to run a kickstarter can also be trusted to give the money back if the target isn't raised.

FYI here is the full 1.2 spec on J.R's repository:

https://github.com/dacoinminster/spec

This doesn't affect anything you guys are currently working on - just fleshing out a bunch of stuff I had promised to add.

This is one giant pull request, but expect to see smaller ones in the future, and originating from other people besides myself

[dacoinminster]

Oh, and Zathras, your documentation is now Appendix A. Would you mind taking a look? I broke some of the formatting, but I hope I at least got all the text correct. Feel free to make pull requests yourself

[Tachikoma]

There are actually threediscussions going on that might affect the spec. Block-lag, reserved funds and the validation api. I already did a quick glance through the new docs and so far it looks good

[grazcoin]

Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.

The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.

I hate chance, and I would like to eliminate it as a factor for Mastercoin.

My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.

Current situation
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.

If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.

Artificial 1 Block lag
User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25
User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.

However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.

I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better. 

We can give priority to purchase offer over selling offer is they have the same block time.
That way user b will get the price at .1

Giving priority to purchase offer over selling offer in the same block is a better name for "Artificial 1 Block lag".
This solution means that any increase in price (or even a try to cancel the offer), could be easily attacked by listening to unconfirmed tx, and sending accept immediately.
I still like the original "random" way that Bitcoin imposes, but I will not insist on it

[Tachikoma]

I'm not even sure I'm 100% behind it, but it would make parsing much more straight forward.

The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.

Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here https://github.com/mastercoin-MSC/spec/pull/1

[dacoinminster]

I'm not even sure I'm 100% behind it, but it would make parsing much more straight forward.

The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.

Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here https://github.com/mastercoin-MSC/spec/pull/1

I replied on that pull request thread (After some thought, I support the pull request for reasons detailed in the discussion thread there, although I don't feel strongly about it).

[zathras]

I'm not even sure I'm 100% behind it, but it would make parsing much more straight forward.

The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.

Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here https://github.com/mastercoin-MSC/spec/pull/1

I need to reflect on this a little further but I'm not sure I'm supportive of the 'artificial lag' at first look.

If the change to the sell offer gets into the blockchain before the purchase offer/accept then so be it - that's the nature of transaction ordering.  Our UI's need to be smart enough to adapt to scenarios where the purchase offer doesn't match the original purchase intent (different price, different amount of coins etc) as there are various scenarios in which this can and will happen.

My methodology is to scan the entire blockchain and dump all Mastercoin transactions, in order, into a table of known transactions.  Those transactions are then processed to arrive at final values for balances & whether the various types of transaction are valid.  As such (at first glance at a high level) I'm quite 'anti' anything that artificially re-orders transactions away from how they are stored in the blockchain.

Oh, replied to PR#1 also.

Thanks!

[grazcoin]

I'm not even sure I'm 100% behind it, but it would make parsing much more straight forward.

The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.

Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here https://github.com/mastercoin-MSC/spec/pull/1

I replied on that pull request thread (After some thought, I support the pull request for reasons detailed in the discussion thread there, although I don't feel strongly about it).

On https://github.com/mastercoin-MSC/spec/pull/1 I went on option 2 (like ripper234). I started implementing it, and we'll see if there are any complications.

Thinking about it again - I changed my mind, and I am for option 2.
Adding the "reserved funds" seems like a wrong architecture decision.
I don't think avoiding it increases the complexity of implementation too much, but it sure simplifies the user actions side and opens new dynamics.
The protocol takes care of all the required calculations and the UI gives the users the correct state at any moment.

[dacoinminster]

Bitoy, can I have a MSC address for you please? I think you should be included when I send the devs some MSC from the Exodus Address.

I was going to send 1500 between you all, and it seems that I had better get a move on before that becomes worth more than our current contest!

(This is a fun little incentive I mentioned before to make sure all our web clients recognize dev Mastercoins)

[prophetx]

I haven't pushed to git for a while. I will finish my rspec testsuite and push the code, they are almost human-readable and should be easy enough to understand

i'm almost human so I should be able to read it 

looking forward to seeing it.

[prophetx]

I have tried to upload all of your repo's to ohloh.net, which is a repo analytics tool

you can claim them, and also use them for stats to compare and view individual projects. probably not very useful now, but perhaps will be helpful later as you look to see how many dev's are supporting a particular project, what's being worked on and so forth.

this one for example compares the 3 wallet sites
https://www.ohloh.net/p/compare?project_0=mastercoin-wallet&project_1=BMX-2&project_2=masterchest-wallet