AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW vertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites are not endorsed bythe Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 25, 2013, 08:56:59 PM #202 Quote from: Tachikoma on October 25, 2013, 11:38:55 AM 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



Quote from: Tachikoma on October 25, 2013, 11:38:55 AM Quote 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

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!



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 thoseThat'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! Smart Property & Distributed Exchange: Master Protocol for Bitcoin

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 26, 2013, 10:26:09 AM #205



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!

Hey guys,I've moved my code from dev into the masterchest libraryThis includes: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 validOf the four Class B transactions you guys posted about, masterchest.info sees these as: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?Bitoy, please feel free to use as you likeYou 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:Check (and fix) ECDSA validity:Encode a simple send transaction using Class B (requires sufficient fees at from address):Thanks!P.S. Can any of you guys think of any further changes needed to the amendment? Feel free to criticize and suggest changes! Smart Property & Distributed Exchange: Master Protocol for Bitcoin

Paleus



Offline



Activity: 260

Merit: 100





www.diginomics.com







Full MemberActivity: 260Merit: 100www.diginomics.com Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 26, 2013, 12:24:03 PM #206



The repository is available here:



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. 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: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. Bitcoin Aptitude Test

Bitoy



Offline



Activity: 449

Merit: 250







Sr. MemberActivity: 449Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 26, 2013, 02:39:13 PM #208



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

}

]}





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 ?Sender1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is theReceipients1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcbAre the address below the data?1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ313Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR

Loozik



Offline



Activity: 378

Merit: 250





Born to chew bubble gum and kick ass







Sr. MemberActivity: 378Merit: 250Born to chew bubble gum and kick ass Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 26, 2013, 07:39:56 PM #212 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



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 26, 2013, 09:48:59 PM #213 Quote from: Bitoy on October 26, 2013, 02:39:13 PM



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

}

]}



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 ?Sender1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is theReceipients1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcbAre the address below the data?1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ313Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR

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

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 liketo 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 Smart Property & Distributed Exchange: Master Protocol for Bitcoin

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 27, 2013, 04:08:37 AM #214



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.

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

Hey Guys,I've spent some time looking at our Class C transactions (OP_RETURN).A few points: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 Smart Property & Distributed Exchange: Master Protocol for Bitcoin

grazcoin



Offline



Activity: 284

Merit: 250









Sr. MemberActivity: 284Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 27, 2013, 02:04:02 PM #215 Quote from: zathras on October 25, 2013, 08:56:59 PM Quote from: Tachikoma on October 25, 2013, 11:38:55 AM 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

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.



Quote from: zathras on October 25, 2013, 08:56:59 PM

Quote from: Tachikoma on October 25, 2013, 11:38:55 AM Quote 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

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!



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

GPG key ID: B29A528142A29BF9 , and OTC ID:

* Check My BTC Tip Jars: https://blockchain.info/address/1GRazCon4gDqTh1pMNyh1xHVWnbQEVPfW8 GPG key ID: B29A528142A29BF9 , and OTC ID: http://bitcoin-otc.com/viewgpg.php?nick=grazcoin * Check https://masterchain.info

hashman



Offline



Activity: 1264

Merit: 1007







LegendaryActivity: 1264Merit: 1007 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 27, 2013, 05:14:50 PM #217

*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



*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:

bitsample



Offline



Activity: 7

Merit: 0







NewbieActivity: 7Merit: 0 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 27, 2013, 07:02:24 PM #218 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



Offline



Activity: 874

Merit: 1000









Hero MemberActivity: 874Merit: 1000 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 27, 2013, 07:58:47 PM #219 Quote from: bitsample on October 27, 2013, 07:02:24 PM 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.



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.