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

[Bitoy]

Hi Zathras,

Thank you for pointing me to "scriptPubKey".  Finally I was able to parse from the multi sig from the txhash =).   

txhash:  cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c

CLEAR TEXT: 010000000000000001000000002060ba100000000000000000000000000000
01: 1 (01)
Trans Type: 0 (00000000)
Currency ID: 1 (00000001)
Amount to Send: 543210000 (000000002060ba10)

[1715058744]

1715058744

[1715058744]

1715058744

[zathras]

Hi Zathras,

Thank you for pointing me to "scriptPubKey".  Finally I was able to parse from the multi sig from the txhash =).   

txhash:  cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c

CLEAR TEXT: 010000000000000001000000002060ba100000000000000000000000000000
01: 1 (01)
Trans Type: 0 (00000000)
Currency ID: 1 (00000001)
Amount to Send: 543210000 (000000002060ba10)

Yep, that's right - well done!

[superfluouso]

Does anyone have guidance for setting up mastercoin advisor in Mac OS X and/or Ubuntu?

To answer my own question in case anyone else is interested and is pretty much a novice to this stuff as I am, yes, MasterCoin Advisor works perfectly fine in Mac OS X.  As JR explained, running his tool requires python 2.7 and pycrypto.  Python is native to Mac OS X.  The easiest process I found to get things working in Mac OS X (Mavericks) is:

1. Download/install latest XCode
2. Download/install latest XCode command line tools (in my case, the latest version released in October 2013 for Mavericks)
3. Download/install paramiko https://pypi.python.org/pypi/paramiko/1.12.0 Install for this is easy - from directory you can type: sudo easy-install ./
4. Download JR's MasterCoin advisor https://github.com/dacoinminster/MasterCoin-Adviser/blob/master/MasterCoinAdvisor.py

And that's pretty much it.  

Been wanting to test sending coins around and was getting stuck setting things up so was pretty excited once I got things going.  So maybe this will help others. Sorry this is way too trivial for this thread and probably not the best place to post.  I was going to put this in the buy/sell thread but that's been getting cluttered with other non-trade related discussion as is...maybe its time for a How to send MSC/Troubleshooting thread?

[Tachikoma]

Other than the senders pubkey in the multisig being uncompressed/compressed and what we do with change in a Class B, are there any other areas of the amendment that are open to debate or do we agree on everything else?  

Thanks!

I think I'm caught up with everything that has been said over the weekend but I'm not sure.

As far as the compressed/uncompressed discussion goes. I think this really should not matter. As far as I know it does not (or should not) influence the inner workings of Mastercoin itself all transactions should be parsed the same regardless of what kind of key is being used. I think we should allow both since I think Bitcoin do won't recognise a transaction as your own if you use a compressed key. In the future the reference client might build in support for multisig redemption via the GUI and if we all force compressed keys that might not work for people using Mastercoin. I would still vote to keep the keys in the source format. So whatever the user of a wallet supplied.

As for the change amount.

As soon as there are some stable wallet implementation which has a 'consolidate multisig output' I think we should send the change amount to the multisig output. It saves a bit of space and looks cleaner. For now however, since it's hard to redeem multisig outputs, let's keep the change amount separate.

how far are we from finishing the distributed exchg

Progress is being made although the last few weeks we have been working on improving the message encoding itself.

I've broadcasted the first ever Mastercoin BTC/MSC exchange message on the 25th of October. You can see it here on Mastercoin-explorer. For convenience I also made an order book page which shows all broadcasted orders. There is no way to accept these orders for now or for any non-technical to create offers but I expect there might be in the next week or so.

Just a quote from other thread where somebody was asking for an update on the BTC/MSC progress.

[klee]

Does anyone have guidance for setting up mastercoin advisor in Mac OS X and/or Ubuntu?

To answer my own question in case anyone else is interested and is pretty much a novice to this stuff as I am, yes, MasterCoin Advisor works perfectly fine in Mac OS X.  As JR explained, running his tool requires python 2.7 and pycrypto.  Python is native to Mac OS X.  The easiest process I found to get things working in Mac OS X (Mavericks) is:

1. Download/install latest XCode
2. Download/install latest XCode command line tools (in my case, the latest version released in October 2013 for Mavericks)
3. Download/install paramiko https://pypi.python.org/pypi/paramiko/1.12.0 Install for this is easy - from directory you can type: sudo easy-install ./
4. Download JR's MasterCoin advisor https://github.com/dacoinminster/MasterCoin-Adviser/blob/master/MasterCoinAdvisor.py

And that's pretty much it.  

Been wanting to test sending coins around and was getting stuck setting things up so was pretty excited once I got things going.  So maybe this will help others. Sorry this is way too trivial for this thread and probably not the best place to post.  I was going to put this in the buy/sell thread but that's been getting cluttered with other non-trade related discussion as is...maybe its time for a How to send MSC/Troubleshooting thread?

How do you install paramiko?

[Tachikoma]

Download the tar.gz file, extract it via the finder. Open a terminal and navigate to the extracted folder. Issue the command sudo easy-install ./

[klee]

Download the tar.gz file, extract it via the finder. Open a terminal and navigate to the extracted folder. Issue the command sudo easy-install ./

Million thanks man!

[zathras]

Other than the senders pubkey in the multisig being uncompressed/compressed and what we do with change in a Class B, are there any other areas of the amendment that are open to debate or do we agree on everything else?  

Thanks!

I think I'm caught up with everything that has been said over the weekend but I'm not sure.

As far as the compressed/uncompressed discussion goes. I think this really should not matter. As far as I know it does not (or should not) influence the inner workings of Mastercoin itself all transactions should be parsed the same regardless of what kind of key is being used. I think we should allow both since I think Bitcoin do won't recognise a transaction as your own if you use a compressed key. In the future the reference client might build in support for multisig redemption via the GUI and if we all force compressed keys that might not work for people using Mastercoin. I would still vote to keep the keys in the source format. So whatever the user of a wallet supplied.

That's actually a fair point if you intend the multisigs to be redeemed by the user at some point in the future when bitcoin supports it in the GUI, but since they're almost dust I had seen cleaning up (redeeming/consolidating) multisig outputs as a regular maintenance task for a Mastercoin wallet - all part of cleaning up after ourselves (blockchain wise).  

And yep they don't affect the transaction other than adding weight. Though I do feel the weight is substantial if we're trying to be lightweight (66 bytes vs 98 bytes for the pubkeys in a simple send).

What are your thoughts on redeeming the multisig outputs in Mastercoin software itself as a regular task? (eg consolidate into a standard pubkeyhash output every 10/20/50 transactions etc)

As for the change amount.

As soon as there are some stable wallet implementation which has a 'consolidate multisig output' I think we should send the change amount to the multisig output. It saves a bit of space and looks cleaner. For now however, since it's hard to redeem multisig outputs, let's keep the change amount separate.

I can't say I agree with this - a multisig will never be added to the users balance until it's redeemed (as far as bitcoin is concerned there are two/three parties that could potentially redeem the output).  Thus every time a user sent a Mastercoin transaction their bitcoin balance would reduce by what they'll probably see as a random amount (and we know as change).  Whilst they could get the balance back with the 'consolidate multisig' button you suggest, this is an extra (IMO unnecessary) step that could cause confusion and fear.

That's a question for the future though   As long as we're agreed that change goes back to the sender (the important part in removing ambiguity) the output in which that is done (separate or multisig) can be based on the evolving behaviour of bitcoin.

[Tachikoma]

That's actually a fair point if you intend the multisigs to be redeemed by the user at some point in the future when bitcoin supports it in the GUI, but since they're almost dust I had seen cleaning up (redeeming/consolidating) multisig outputs as a regular maintenance task for a Mastercoin wallet - all part of cleaning up after ourselves (blockchain wise).  

And yep they don't affect the transaction other than adding weight. Though I do feel the weight is substantial if we're trying to be lightweight (66 bytes vs 98 bytes for the pubkeys in a simple send).

What are your thoughts on redeeming the multisig outputs in Mastercoin software itself as a regular task? (eg consolidate into a standard pubkeyhash output every 10/20/50 transactions etc)

That was what I was proposing. The software could keep track of how many multisigs are done and if it thinks it's efficient to redeem them all back to a normal address it will do just that.

As for the change amount.

As soon as there are some stable wallet implementation which has a 'consolidate multisig output' I think we should send the change amount to the multisig output. It saves a bit of space and looks cleaner. For now however, since it's hard to redeem multisig outputs, let's keep the change amount separate.

I can't say I agree with this - a multisig will never be added to the users balance until it's redeemed (as far as bitcoin is concerned there are two parties that could potentially redeem the output).  Thus every time a user sent a Mastercoin transaction their bitcoin balance would reduce by what they'll probably see as a random amount (and we know as change).  Whilst they could get the balance back with the 'consolidate multisig' button you suggest, this is an extra (IMO unnecessary) step that could cause confusion and fear.
[/quote]

I guess this is true. From a UX standpoint it does not make much sense to do that. Let's keep it seperate.

[zathras]

That's actually a fair point if you intend the multisigs to be redeemed by the user at some point in the future when bitcoin supports it in the GUI, but since they're almost dust I had seen cleaning up (redeeming/consolidating) multisig outputs as a regular maintenance task for a Mastercoin wallet - all part of cleaning up after ourselves (blockchain wise).  

And yep they don't affect the transaction other than adding weight. Though I do feel the weight is substantial if we're trying to be lightweight (66 bytes vs 98 bytes for the pubkeys in a simple send).

What are your thoughts on redeeming the multisig outputs in Mastercoin software itself as a regular task? (eg consolidate into a standard pubkeyhash output every 10/20/50 transactions etc)

That was what I was proposing. The software could keep track of how many multisigs are done and if it thinks it's efficient to redeem them all back to a normal address it will do just that.

So if we're redeeming the multisig outputs via Mastercoin software, could I enquire what are your reasons for wanting the Bitcoin client to pick them as your own?  And do those reasons provide value that exceeds the extra 32 bytes per multisig output cost (which scales horribly as we use more packets)?

I do support uncompressed keys already so it's not a question of compatibility, I'm just looking for all the places we can trim the fat as it were

I can't say I agree with this - a multisig will never be added to the users balance until it's redeemed (as far as bitcoin is concerned there are two parties that could potentially redeem the output).  Thus every time a user sent a Mastercoin transaction their bitcoin balance would reduce by what they'll probably see as a random amount (and we know as change).  Whilst they could get the balance back with the 'consolidate multisig' button you suggest, this is an extra (IMO unnecessary) step that could cause confusion and fear.

I guess this is true. From a UX standpoint it does not make much sense to do that. Let's keep it seperate.

OK I'll keep change as-is in the amendment then

[Luckybit]

I'm a software developer and I'd like to try to make a contribution to this project.
Thanks!

I really hope someone will help this guy.  And every guy who wants a technical introduction.  If Mastercoin had a representative who work closely for one day bringing people up to speed - it would encourage more developers to work.  We don't want willing devos to get frustrated by the steep learning curve. 

For example, if Zathras puts together a really cool single zip file which has everything prepared so it can be opened as a working Visual Studio project testbed - it would be worth a very huge amount to all holders of Mastercoin. 

Please, please, please.  Can we get a developer into kit made in .net with all necessary and useful libraries for the beginners to get warmed up and come up to speed?  This will double our programmer participation.  OK - these guys won't take any lead role, but they will surely build very nice little pieces which integrate with the whole package. 

Zathras last instructions were very vague and brief.  I know it is not his job to get everyone up and running.  But a tiny effort from him (say 2 hours) and newish programmers will save tons of time not searching of the pieces to get started with Manstercoin.  Zathras - can you spare two hours time?  Please?

Maybe the foundation will vote for a few coins for a programmer's starter kit like this. 

What we need is a complete technical specification on the wiki. I can't develop for it either because as soon as I think I understand it, some change is made and it's slightly different. So it's a fast moving target.

A wiki is required which puts everything in one place. We also need a reference/command list so people know what to do because even the best programmer isn't going to just know how to do stuff. Basically a detailed road map is needed, code has to be commented so that other people can read it, and the specifications along with the to-do list have to be clear. Finally there needs to be an API or at least something similar to what Open Transactions has where you have a high level API which everyone can connect to. Python is relatively easy to read which is a good thing but for stuff like building a user interface or bug testing that is something people can help out with after the basic code is finished.

Documentation documentation Documentation.

[Tachikoma]

J.R. hinted that the the Mastercoin spec is being rewritten to markdown. If this is the case documentation will get a lot easier to do. Currently J.R. has sole control over this and I believe this is a real problem since we are currently amending it by forum posts and other documents spreading the documentation out and making everything harder.

[Tachikoma]

Zathras / Grazcoin need your thoughts on the following.

User A has 300 Mastercoins and creates/broadcasts selling offer to sell these 300 coins. What happens with user A's balance?

Two options as I see it:

1. The 300 get deducted from his balance making it 0 and simple send transactions sent while his offer is still valid open will get invalidated until he cancels the offer.
2. The 300 stay and are not reserved, only accepted offers get deducted from the balance. If User A sends 100 coins while the offer was still open and User B wants to purchase 300 coins his Purchase Offer will be invalid and he should not send the funds.

I prefer option 1 since it makes things easier to work with and it's expected behaviour on exchanges. This would also mean that you can't make an valid offer that is larger then the amount of MSC that you hold.

[djohnston]

"J.R. hinted that the the Mastercoin spec is being rewritten to markdown."

Yes this is the case. I've talked to J.R. about this and its just a matter of him taking the time to get this done. The plan is to put it in Markdown and upload it to Github to get this part of things fully distributed.

If someone wants to volunteer to do the markdown conversion I'm sure J.R. would gladly hand off the document. You might just want to email him first to make sure he hasn't already done it.

[dacoinminster]

Sorry I wasn't clear about the contest start date. I consider the new contest to be adjacent to the old one. Any work which supports the goals of this contest counts toward the contest. For instance, we need multi-sig issues ironed out for creating the distributed exchange, so that work definitely counts towards the contest.

Thanks guys.

[zathras]

Zathras / Grazcoin need your thoughts on the following.

User A has 300 Mastercoins and creates/broadcasts selling offer to sell these 300 coins. What happens with user A's balance?

Two options as I see it:

1. The 300 get deducted from his balance making it 0 and simple send transactions sent while his offer is still valid open will get invalidated until he cancels the offer.
2. The 300 stay and are not reserved, only accepted offers get deducted from the balance. If User A sends 100 coins while the offer was still open and User B wants to purchase 300 coins his Purchase Offer will be invalid and he should not send the funds.

I prefer option 1 since it makes things easier to work with and it's expected behaviour on exchanges. This would also mean that you can't make an valid offer that is larger then the amount of MSC that you hold.

My view is definitely on option 1 as I think it will cause branding issues and disappointment if users can't accept trade offers knowing reliably they will be fulfilled.  Also helps to reduce spam & fake offers as you note.

Also rather than simple send transactions sent while his offer is open being invalidated, ideally they shouldn't be sent in the first place - the wallet should just say insufficient funds.  

[grazcoin]

Zathras / Grazcoin need your thoughts on the following.

User A has 300 Mastercoins and creates/broadcasts selling offer to sell these 300 coins. What happens with user A's balance?

Two options as I see it:

1. The 300 get deducted from his balance making it 0 and simple send transactions sent while his offer is still valid open will get invalidated until he cancels the offer.
2. The 300 stay and are not reserved, only accepted offers get deducted from the balance. If User A sends 100 coins while the offer was still open and User B wants to purchase 300 coins his Purchase Offer will be invalid and he should not send the funds.

I prefer option 1 since it makes things easier to work with and it's expected behaviour on exchanges. This would also mean that you can't make an valid offer that is larger then the amount of MSC that you hold.

My view is definitely on option 1 as I think it will cause branding issues and disappointment if users can't accept trade offers knowing reliably they will be fulfilled.  Also helps to reduce spam & fake offers as you note.

Also rather than simple send transactions sent while his offer is open being invalidated, ideally they shouldn't be sent in the first place - the wallet should just say insufficient funds.  

+1 for 1.

[Tachikoma]

Awesome, let's do that for now

[grazcoin]

If you guys think there are better ways though let's look at those

I already said before that flexibility is welcomed for more advanced uses of mastercoin.

I'm not sure I agree with this - the whole idea of using the sender for change (which I believe both Tachikoma and I do) is to 'solve the change problem' in the simplest manner.

This is a strategic question that we are dealing here with, and more people have to decide on this (J.R., board, ...):
Do we want masterchain to be future compatible or not?

I obviously think that the answer is YES, and I try to come up with solutions that keep the common tx simple, but leave an option for more advanced uses (in a similar way to bitcoin's protocol approach). Any solution that enables reasonable future compatibility is fine with me.
Taking zathras comments into consideration I modified my porposal to the following:

TX with 3 outputs: exodus, recipient, BIP11 - is valid (trivial case). The redeeming public key inside BIP11 MUST be the one of the sender.
TX with 4 outputs: exodus, recipient, change, BIP11 - is valid (change case). Like above + the change MUST go to the sender (to identify easily the recipient).
TX with more than 4 outputs (future compatible) - valid ONLY under the following set of rules:

• Exodus and recipient outputs MUST have the same value (we have it already today).
• Change MUST go to sender (tachikoma+zathras suggestion).
• Pubkey in BIP11 MUST belong to sender (tachikoma+zathras suggestion).
• Other outputs CANNOT have the same value like the Exodus one.

"Other outputs" (which are easily detectable) are ignored for mastercoin purposes.
If tx has more than 4 outputs (the advanced sender uses future-compatible feature intentionally), the sender knows that by not following the above 4 rules, his tx will be invalid.

[bitsample]

Did someone mention that they successfully sent an exchange message on the forums?  I thought I read it yesterday, now I cannot find it.  Sorry about the trouble just trying to stay upto speed.

BTW, is there there an interest in forking the Bitcoin QT client to support mastercoin? 
 
Thanks,
Dan