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

[Tachikoma]

Yeah looks good!

[1714781391]

1714781391

[1714781391]

1714781391

[1714781391]

1714781391

[1714781391]

1714781391

[1714781391]

1714781391

[zathras]

Hey guys,

I've moved my code from dev into the masterchest library

This includes:

• Code adjustments to apply the transaction processing rules as defined in the amendment
• Support for decoding the new Class B obfuscated keys
• Support for encoding the new Class B obfuscated keys
• Support for ECDSA point validity checking
• Various bugfixes

Masterchest.info has had the new library deployed & the two Class A transactions from the other thread with ambiguous sequence numbers are now interpreted correctly and considered valid   Of the four Class B transactions you guys posted about, masterchest.info sees these as:

Code:

95869c648953ee937d1956a62cbde051cedc26c8d33855d951930340e7c45fd0 invalid
7a02df33eddfb9dbcc7988f980630297089454f13a8bd059ada4b7842e2d1615 valid
a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95 valid
2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc valid

I've broadcast a few of my own transactions (I just plugged the new library into my wallet and sent a couple of transactions from it) - yours seems to be spot on Tachikoma & Grazcoin I tried to test against yours but it's not showing any transactions and times out when I try to check a transaction - could you please let me know how your implementation sees these?

Code:

5885b1aa8938f234da483a5190084c3c425ab03363810e68b0214d358a8144c6 - should be invalid (no funds at source)
5fe5e0a2c7a4c9ae92708631b0559c32ebad33aa65d12d9d13b23869a1a68cbf - should be invalid (no funds at source)
cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c - should be valid

Bitoy, please feel free to use as you like   You can just import the library (at my github) and use what you need.  Some of the extra functions this time round:

Obfuscate a mastercoin packet:

Code:

Dim encodedpacket As String = mlib.encryptmastercoinpacket(fromaddress, seqence_number, 31_byte_clear_text_mastercoin_packet)

Check (and fix) ECDSA validity:

Code:

Dim valid As Boolean = False
Do While valid = False
   Dim rbyte As String = getrandombyte()
   encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
   valid = validateecdsa(encodedpubkey)
Loop

Encode a simple send transaction using Class B (requires sufficient fees at from address):

Code:

Dim rawhex As String = mlib.encodetx(bitcoin_connection, from_address, to_address, currency, amount)

     

Thanks!

P.S. Can any of you guys think of any further changes needed to the amendment?  Feel free to criticize and suggest changes! 

[Paleus]

I've been underway with the BTC/MSC price ticker. So far I've completed some of the HTML framework and the stylesheet.

The repository is available here: https://github.com/travispatron/mastercoin-ticker

I have contacted BitcoinWisdom to gain some insight into how they have developed their Javascript framework, so I am hoping they can collaborate on the project with me. Note, some of the work is pulled from their source code, he is aware of this.

I invite others to join me in developing this price ticker, perhaps someone strong in Javascript. I am not an expert yet in this area, but I will continue to work on it and tweak the HTML/CSS.

Areas we are looking to finish up for price tracking:

• Linking bids & asks to market data charts
• Creating javascript framework so the program can properly communicate with changes in demand
• Making the chart look professional and informative

Are we going to continue to use the thread/google docs to hold the bid/ask offers? If so, how would we pull these requests to display them on the ticker?

Let me know how this fits in with the rest of the developments, what we should focus on to create a program which will best serve mastercoin's users.

[Bitoy]

Thanks Zathras,

I will check your library =)

Check (and fix) ECDSA validity:

Code:

Dim valid As Boolean = False
Do While valid = False
   Dim rbyte As String = getrandombyte()
   encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
   valid = validateecdsa(encodedpubkey)
Loop

Encode a simple send transaction using Class B (requires sufficient fees at from address):

Code:

Dim rawhex As String = mlib.encodetx(bitcoin_connection, from_address, to_address, currency, amount)

     

Thanks!

P.S. Can any of you guys think of any further changes needed to the amendment?  Feel free to criticize and suggest changes! 

[Bitoy]

Trying to parsing from the Exodus address (and build a database). 

The code below looks like a multi sig transaction.  How can I get the public key ?

Sender
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is the

Receipients
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb

Are the address below the data?
1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3
13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR

Code:

{[
  {
    "n": 0,
    "value": 9950000,
    "addr": "1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826",
    "tx_index": 94812526,
    "type": 0
  },
  {
    "n": 1,
    "value": 6000,
    "addr": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P",
    "tx_index": 94812526,
    "type": 0
  },
  {
    "n": 2,
    "value": 6000,
    "addr": "1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb",
    "tx_index": 94812526,
    "type": 0
  },
  {
    "addr2": "1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3",
    "n": 3,
    "value": 12000,
    "addr": "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
    "tx_index": 94812526,
    "type": 1
  }
]}

[Loozik]

Areas we are looking to finish up for price tracking:

• Linking bids & asks to market data charts
• Creating javascript framework so the program can properly communicate with changes in demand
• Making the chart look professional and informative

I suggest you contact these guys: https://www.tradingview.com/

This is how BTCUSD charts look like (html5, not java; you should play around with the charting features for a while): https://www.tradingview.com/e/?symbol=MTGOX:BTCUSD

These guys are also behind this: http://www.multicharts.com/ this trading and charting software should be the reference.

[ASIC-8Tile]

I've been underway with the BTC/MSC price ticker. So far I've completed some of the HTML framework and the stylesheet.

The repository is available here: https://github.com/travispatron/mastercoin-ticker

I have contacted BitcoinWisdom to gain some insight into how they have developed their Javascript framework, so I am hoping they can collaborate on the project with me. Note, some of the work is pulled from their source code, he is aware of this.

I invite others to join me in developing this price ticker, perhaps someone strong in Javascript. I am not an expert yet in this area, but I will continue to work on it and tweak the HTML/CSS.

Areas we are looking to finish up for price tracking:

• Linking bids & asks to market data charts
• Creating javascript framework so the program can properly communicate with changes in demand
• Making the chart look professional and informative

Are we going to continue to use the thread/google docs to hold the bid/ask offers? If so, how would we pull these requests to display them on the ticker?

Let me know how this fits in with the rest of the developments, what we should focus on to create a program which will best serve mastercoin's users.

http://www.wakanda.org/ would be a good tool to build with. It has A JavaScript framework.

[Paleus]

Excellent, thank you both.

I will post an update tomorrow or early next week.

[Loozik]

Has it already been decided what the timestamping of events (order submission, order cancellation, order execution) of the distributed exchange will be? Seconds / milliseconds / microseconds / nanoseconds?

What will be the format of the data feed? This is important to know, based on the format, what third party frontends (if any) one will be able to hook up.

[zathras]

Trying to parsing from the Exodus address (and build a database). 

The code below looks like a multi sig transaction.  How can I get the public key ?

Sender
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is the

Receipients
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb

Are the address below the data?
1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3
13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR

Code:

{[
  {
    "n": 0,
    "value": 9950000,
    "addr": "1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826",
    "tx_index": 94812526,
    "type": 0
  },
  {
    "n": 1,
    "value": 6000,
    "addr": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P",
    "tx_index": 94812526,
    "type": 0
  },
  {
    "n": 2,
    "value": 6000,
    "addr": "1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb",
    "tx_index": 94812526,
    "type": 0
  },
  {
    "addr2": "1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3",
    "n": 3,
    "value": 12000,
    "addr": "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
    "tx_index": 94812526,
    "type": 1
  }
]}

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:

Code:

Dim txdetails As mastercointx = mlib.getmastercointransaction(bitcoin_connection, cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c, "send")

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. 

Code:

        {
            "value" : 0.00012000,
            "n" : 3,
            "scriptPubKey" : {
                "asm" : "1 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575 0270d93998cd9653541a6f1cfc50eddffafd936ab54495a5a8526abd08510fffd0 2 OP_CHECKMULTISIG",
                "hex" : "5121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575210270d93998cd9653541a6f1cfc50eddffafd936ab54495a5a8526abd08510fffd052ae",
                "reqSigs" : 1,
                "type" : "multisig",
                "addresses" : [
                    "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
                    "1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3"
                ]
            }
        }

       

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
     

[zathras]

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:

Code:

{
    "hex" : "0100000001d68f051c4fbfa2d3493749b94804b86331dc50ad8fc751aab46af2657233a8e1010000006a47304402200f14911114ad75ad605f8234de5896e36e5eba1455f3a73597c2c0dc103f6dd20220230b95e6861ad8a7869d84b022029405b7167ea5177ef94d7e989b94e740d111012103a84eb2552033903a1b891ba5081c5a8993380c8676e48a23128ff6a8d31c0a03ffffffff04b0453c00000000001976a914558119e5d23a58f5241fa8368d95c53fd40fec9b88ac70170000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac70170000000000001976a914dd84a40b878d042a5d0a957ab7d3c7052ff6aef688ac7017000000000000216a1f01000000000000000200000000000003e8000000000000000000000000000000000000",
    "txid" : "3e2efaa85bdb1c2d7cc70e4a66fc2119a6b55a6bdf9dad3c362f70a0d2458384",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "e1a8337265f26ab4aa51c78fad50dc3163b80448b9493749d3a2bf4f1c058fd6",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "304402200f14911114ad75ad605f8234de5896e36e5eba1455f3a73597c2c0dc103f6dd20220230b95e6861ad8a7869d84b022029405b7167ea5177ef94d7e989b94e740d11101 03a84eb2552033903a1b891ba5081c5a8993380c8676e48a23128ff6a8d31c0a03",
                "hex" : "47304402200f14911114ad75ad605f8234de5896e36e5eba1455f3a73597c2c0dc103f6dd20220230b95e6861ad8a7869d84b022029405b7167ea5177ef94d7e989b94e740d111012103a84eb2552033903a1b891ba5081c5a8993380c8676e48a23128ff6a8d31c0a03"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.03950000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 558119e5d23a58f5241fa8368d95c53fd40fec9b OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "18o76QsnwXZnzn6ep2M5psZZdwXSf9KN72"
                ]
            }
        },
        {
            "value" : 0.00006000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
                ]
            }
        },
        {
            "value" : 0.00006000,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 dd84a40b878d042a5d0a957ab7d3c7052ff6aef6 OP_EQUALVERIFY OP_CHECKSIG",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826"
                ]
            }
        },
        {
            "value" : 0.00006000,
            "n" : 3,
            "scriptPubKey" : {
                "asm" : "OP_RETURN 01000000000000000200000000000003e80000000000000000000000000000",
                "reqSigs" : 32585,
                "type" : "nulldata",
                "addresses" : [
                ]
            }
        }
    ]
}

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

[grazcoin]

Did we discuss how to determine the receiving address when there is a change address present? Basically did we formalise that the outputs for Exodus and Receiving address should be the same for Class B transactions?

We'd discussed that Class B required the change output to go to the sender address.  

This way if we have an output to the same address as the sender, we take that output out of the equation.  So we're only ever dealing with three outputs - the multisig and two other outputs; one to exodus and one to the reference address - easy to identify.

We still have to consider the 'what if' though.  So what if someone sends a Class B transaction and sends the change to a new address for example?  Do we call it invalid or try to parse another way etc?  I don't think that's a major concern as it'll only be our respective Mastercoin softwares that are building the raw transactions and thus we can always enforce the rule, but still worth considering.

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

I would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.

I'm taking a different approach which I think should give the correct result regardless of the what type of key is being used for the spending public key. I'm looking at the inputs for this transaction and then getting the previous output and I generate that address. That way the key format does not matter anymore. That's my theory at least

That's exactly how I work out the sending address also, I think going on the inputs is the only way we should trust to enumerate the 'from' address.

Grazcoin,

Did I have any luck trying to convince you of the merits of standardizing on a compressed public key as a signatory in the multisig?

Thanks!

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.

[ASIC-8Tile]

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.

[hashman]

*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://bitcointalk.org/index.php?topic=312812.0

[bitsample]

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!

[TKeenan]

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. 

[zathras]

Did we discuss how to determine the receiving address when there is a change address present? Basically did we formalise that the outputs for Exodus and Receiving address should be the same for Class B transactions?

We'd discussed that Class B required the change output to go to the sender address.  

This way if we have an output to the same address as the sender, we take that output out of the equation.  So we're only ever dealing with three outputs - the multisig and two other outputs; one to exodus and one to the reference address - easy to identify.

We still have to consider the 'what if' though.  So what if someone sends a Class B transaction and sends the change to a new address for example?  Do we call it invalid or try to parse another way etc?  I don't think that's a major concern as it'll only be our respective Mastercoin softwares that are building the raw transactions and thus we can always enforce the rule, but still worth considering.

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

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 would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.

I'm taking a different approach which I think should give the correct result regardless of the what type of key is being used for the spending public key. I'm looking at the inputs for this transaction and then getting the previous output and I generate that address. That way the key format does not matter anymore. That's my theory at least

That's exactly how I work out the sending address also, I think going on the inputs is the only way we should trust to enumerate the 'from' address.

Grazcoin,

Did I have any luck trying to convince you of the merits of standardizing on a compressed public key as a signatory in the multisig?

Thanks!

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.

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!

[zathras]

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. 

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

[bitsample]

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!

[zathras]

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!

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!