Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 54. (Read 129207 times)

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.


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.

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)


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.

Million thanks man!

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

How do you install paramiko?

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.

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

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?

Yep, that's right - well done!

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)

To be honest I'm not sure if this new contest has started yet (I did ask JR a few pages back).  I assume it has, but I know for example Tachikoma & I have been working to button down storing data in the blockchain as that's a pre-requisite to building the features targeted in the new contest like distributed exchange.

Thanks!

I'm not asking for any kind of quick start here.  I know packaging things up takes time.  I'm just trying to get a few words on the progress of each of those items.  I'm just trying to find where best I can make a contribution with out duplicating work.

Thanks guys!

Using my library is as simple as creating a new project and importing a DLL - admittedly there is not a whole lot of documentation, but at this early stage I had envisaged potential developers actually looking at the code behind the library to see how it works. 

If it would be beneficial to have a sort of 'test/dummy' project showing some simple usage of the library, then sure, I'll try and put something together

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.  Using identical outputs does not solve the problem - as you note we would have to consider certain transactions invalid or find more complex rules to handle the random circumstance of change amount collision.  Using double the value for the multisig is also not a valid approach (see further back in the development conversation around dust; how large (byte-wise) the multisig is determines how much it's output needs to be.  I for example use 0.00012 only because I know that my two compressed keys won't more than double the transaction size.  Once you throw in a third signatory and/or use an uncompressed key our output is now substantially larger - I'd have to run the numbers to see if 0.00012 was still enough.  Point being as m-of-n supports more n our size grows and our output needs to adapt to meet dust thresholds - 0.00006 * n is a fairly safe bet.

Could you let me know what future uses would require us to do anything with change?  The whole idea of change is giving it back to the sender - that's it, nothing else - so I'm not sure how we restrict Mastercoin in any way giving the change back to the sending address - all we do is keep the protocol clean and have a simple single rule for returning change (and not a myriad of complexities as we see in Class A because we don't send change back to sender and thus have to do lots of 'ifs and buts' to work out which output is change).

I'd love to take credit but Tachikoma made the best case for using 'change goes to sender' - always returning an output that can be used for the next Mastercoin transaction.  If we output change elsewhere, the user has to repeatedly send bitcoins back to the sending address to cover fees for the next Mastercoin transaction.

Since it will only be Mastercoin software creating Class B transactions, it's an easy rule to enforce (change goes back to sender) in my opinion.

EDIT: Just reflecting on the work involed here - to switch away from requiring 'change goes to sender' and to make outputs the same as per Class A in addition to the multisig output != the rest issue, we'd also have to redo Class B again to bring sequence numbers back into the non-multsig outputs, could no longer start the multisig packets at 01, would need to add rules to handle random chance of sequence number collisions and so on - it's quite a lot of work  Anyway I won't go on (any more than I already have!), I've made my case for 'change goes to sender' - if you wouldn't mind spelling out (for clarity) your suggested alternative approach & perhaps JR can weigh in.  Would be good to settle this aspect of the spec & move on


I'm sorry but I still don't understand what you mean by BIP11 change address - there is no change address in the BIP11.  There is only a public key for redeeming that output.

EDIT: Sorry, I think I see what you're getting at - do you mean if a user views the transaction outside of a Mastercoin wallet (eg on blockchain.info) then changing the compression on the sender pubkey in the multisig causes the first address in the multisig output to not look like the users own?  If that's what you mean then yes, that would be the case - though it's subjective as to whether that's an issue.  The outputs are a fraction over dust, so even if a user (who we're assuming knows enough about Mastercoin to know the first signatory should be theirs, but not enough to know it's a compressed key) did dive into the multisig outputs & incorrectly think the first address wasn't theirs, would they care?  I'd posit they'd care about as much as the other dust+0.000000whatever outputs they couldn't redeem (ie not at all).  Appreciate the technical distinction for sure I just don't think it reflects something that would see us add 32 bytes to some Class B transactions - especially when you consider with the current max 1-of-3 over 254 packets that's an extra 4,000+ bytes (or adding almost 50% to the size).

My implementation currently considers both uncompressed and compressed public keys as valid for the first signatory in a m-of-n multisig, but that doesn't mean we shouldn't standardize on compressing the first signatory and make the protocol lighter (the other one or two data signatories already have to be compressed keys).

This is all meant in the friendliest possible light Again apologies to all you guys if you guys feel I'm being pushy trying to have these rules formalized, but I cannot possibly see how we can develop inter-operating and compatible implementations without a core set of rules we all adhere to (Mastercoin is a protocol, and a protocol is defined as "A standard procedure for regulating data transmission between computers" - if we can't all agree on what that procedure and the rules that define it are I see unnecessary hardship ahead).

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

Hello!

I'm a software developer and I'd like to try to make a contribution to this project.  I've been reading about Mastercoin and trying to follow along with the development discussion.   Good to meet all of you.

I'm wondering if someone could give a quick status (who's working on them, what's the progress, etc) about the goals from the current coding contest

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)

Thanks!

*yawn*  *gets out from under the rock*

Well I need to do some more reading about what is mastercoin and why it exists, but while I'm checking that out you might be interested in my related proposal, for a distributed pricing mechanism for distributed exchanges:

https://bitcointalksearch.org/topic/proposal-pricecoin-312812

Hi all,

I am going to need some help with the QA part of the Distributed Exchange.
There is space for 9 more QA tester/developers to help build the Features list to test.

Who would like to help?

I have setup a Project at the following cloud Issue tracking software.
http://msctst.myjetbrains.com/youtrack


1.) Please PM me with your bitcointalk user and email address.
2.) I will setup an account for each person
3.) Need to have a small meeting to hash out the features, etc...

Let me know how I can help.

I already said before that flexibility is welcomed for more advanced uses of mastercoin. We have to remember that mastercoin is only the first layer above bitcoin, and there can be higher/other protocols using mastercoin that appear later. Leaving less restrictive rules on outputs would keep mastercoin in the game also when more advanced protocols come.
My suggestion is to consider all the outputs with value identical to the one of the exodus address output as mastercoin relevant outputs, and ignore all other outputs regarding mastercoin purposes.
This solves the change problem (except for the case of identical output also to change address - we could consider that case invalid, or find an alternative set of rules). It leaves enough flexibility for further parallel protocol development.
I could continue developing this approach and say that the BIP11 for mastercoin should be considered as mastercoin relevant if and only if it has the value of double the exodus one, and irrelevant otherwise.


My suggestion of leaving the same format for the BIP11 change address is identical to Tachikoma's method of looking at the inputs for this transaction (that's exactly how I implemented this myself). This approach is only for comfort purposes (you can see on blockchain.info that one of the bitcoin addresses belongs to the sender), but the protocol should not enforce it. Both tx with compressed as well as uncompressed pubkey should be considered as valid. Your wallet can choose by default to generate tx with only compressed pubkey. Bitcoin fees will anyway make us choose shorter tx.

Hey Guys,

I've spent some time looking at our Class C transactions (OP_RETURN).

A few points:

• Just like Class B, change goes back to the sender.  This makes things so much simpler.
• The sequence number is no longer needed in the OP_RETURN output as we can simply state that the OP_RETURN output is always the first data packet and has a sequence number of zero.
• Since Class C tranasctions can only have a single (80 byte) packet in the OP_RETURN output, additional Class B CHECK_MULTISIG outputs can be attached where extra data storage is required. These already start with a sequence number of one.
• Obfuscation is not required with a Class C transaction (except for any extra attached Class B outputs) as the OP_RETURN output is provably prunable and there is thus no need (?) to obfuscate our use of it for storing data.

This transaction 3e2efaa85bdb1c2d7cc70e4a66fc2119a6b55a6bdf9dad3c362f70a0d2458384 is an example of a straight 'simple send' in a Class C transaction.  This hasn't been accepted by any miners yet.  It's decoded as:

NOTE: This example packet still contains a sequence number, I erroneously left this in when building the transaction.

NOTE: None of this is currently supported by the reference client.  The above testing was done with a test version of bitcoind 0.9 compiled with the most recent changes and broadcasted to Eligius (not sure if they even mine non-standard anymore).  You'll get different results (eg non-standard outputs) with current 0.8.x versions.

Comments most welcome, I'll add Class C to the amendment but I'd like to get a little feedback first

Hey Bitoy,

It looks like you're talking about transaction cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c here.

If you're using the masterchest library, you can parse (including decryption to cleartext and packet decoding) with a one-liner:

Then just simply check with something like If Not IsNothing(txdetails) to make sure you have a mastercointx object and use the object properties as you need.  Properties of a mastercointx object include fromadd, toadd, value, type, blocktime, blocknum, curtype etc.

This is what masterchest engine does, building up a database of all parsed transactions before running a second 'processing' function to work out balances & which transactions are valid (eg whether the sending address had funds etc).

If you're not using the library and doing your own implementation, my advice is to try not to think about data as addresses in a Class B like you would in Class A.  The addresses in our multisigs don't matter, only the compressed public keys.  So in your quote above where you have the addresses from the multisig, they're irrelevant - you'll need to take the compressed public keys from the multisig output and work with them. 

       

So here we can see we have the senders public key of 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575, this can be used to redeem the multisig output.  We also have a data public key of 0270d93998cd9653541a6f1cfc50eddffafd936ab54495a5a8526abd08510fffd0.

We work out the sending address (our largest input - 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826) and we can then do our SHA256 hashing and XORing (as has been discussed at length over the last few pages) to get the cleartext packet (010000000000000001000000002060BA100000000000000000000000000000) from our obfuscated public key.

Hope that helps, but please feel free to ask any more questions