Consensus is almost complete.
Consensus Address MyMastercoins Masterchain Mastercoin-Explorer Masterchest
181k55nxGuqDRpJx3iU43T4wJznf7ZazFN 0.043 0.043 0.043
182osbPxCo88oaSX4ReJwUr9uAcchmJVaL 376.1846 376.1846 376.1846 376.2706
18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji 0.043 0.043 0.043
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P 11034.92330741 11035.15874017 10812.36900066 11034.92330741
1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm 60.12630845 60.12630845 60.12630845 10.00
Masterchain, mastercoin-explorer and mymastercoins are already synchronized except for the exodus address.
For the exodus address Mymastercoins recalculates based on the time of the latest block.
(Mymastercoins and masterchest has the same balance)
Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 25. (Read 129207 times)
January 11, 2014, 11:20:37 AM
January 11, 2014, 10:34:51 AM
Consensus is nearing!
Let's close it today
masterchain.info and mastercoin-explorer.com have only one difference - the exodus address.
see https://masterchain.info/general/difference.json
at the moment the exodus address has different values on all 4 implementations:
11016.58589661 on MyMastercoins
11031.52547426 on Masterchain
10812.36900066 on Mastercoin-Explorer
11032.15274926 on Masterchest
Description of my calculation:
The constants are:
exodus_bootstrap_deadline = 1377993600
seconds_in_one_year=31556926
This calculation is also done for the validation of each simple send that exodus address sent (to verify that the amount does not exceed the balance at that moment).
masterchest gets a very close number to masterchain.
I suspect that the minor difference is due to the number of seconds in a year.
This commit is available here:
https://github.com/grazcoin/mastercoin-tools/commit/6e45b1dd7592e6094979044b82b1fc7b7132dd3b
Let's close it today
masterchain.info and mastercoin-explorer.com have only one difference - the exodus address.
see https://masterchain.info/general/difference.json
at the moment the exodus address has different values on all 4 implementations:
11016.58589661 on MyMastercoins
11031.52547426 on Masterchain
10812.36900066 on Mastercoin-Explorer
11032.15274926 on Masterchest
Description of my calculation:
- all_reward is 10% of the mastercoins sold during the bootstrap (total of 56316.23576245 MSC)
- seconds_passed = last_block_timestamp - exodus_bootstrap_deadline
- years = seconds_passed / seconds_in_one_year
- part_available = 1 - 0.5 ** years
- available_reward = all_reward * part_available
The constants are:
exodus_bootstrap_deadline = 1377993600
seconds_in_one_year=31556926
This calculation is also done for the validation of each simple send that exodus address sent (to verify that the amount does not exceed the balance at that moment).
masterchest gets a very close number to masterchain.
I suspect that the minor difference is due to the number of seconds in a year.
This commit is available here:
https://github.com/grazcoin/mastercoin-tools/commit/6e45b1dd7592e6094979044b82b1fc7b7132dd3b
January 10, 2014, 04:22:20 AM
OK - hopefully have my head on straight with this (but bear with me, it's been a long day!).
Tachikoma, the way you've laid it out is great - I had a slightly different approach (same endgame) in mind when I brought it up - for clarity I've just gone ahead and drawn up the sort of spec simplification I had in mind (kind of more focused on rules than methodology) - can you have a look and I'd appreciate your thoughts?
Regarding the specific levels/order of testing is it necessary to lock in the rule evaluation method/order? I think the approach can be left up to the implementation providing the rules are clear enough - if we need to specify a methodology for interpreting the rules then the rules are not clear enough.
Original
Revised
I also took out the byte range stuff too as it seemed a little unnecessary - if the transaction doesn't have a data address that can be decoded it doesn't satisfy 'Has an output for the encoded fake address (the 'data' address)' and thus is already explicitly invalidated by said rule. What constitutes a valid data address is already defined elsewhere (under the simple send section).
Can you think of any cases my alternative revision doesn't cover? Essentially it's anything P&Dable = valid.
I realize this is a different approach to the simplification - as you can see I've been quite aggressive in removing the ambiguity that currently surrounds Class A (so that a transaction either satisfies the rules or it doesn't, no interpretation). Please let me know your thoughts on this and whether you still prefer to document with decoding methodology (eg levels/order etc) - as always happy to discuss
I'll be excited to have Class A done & dusted!
Thanks
Zathras
EDIT just for clarity - in practice I would still just use P&D for all Class A decoding as that is the (imo) simplest implementation methodology for testing against "Has exactly two outputs with a value equal to the Exodus output and/or has exactly one output with a sequence number +1 of the data address for reference output identification".
Hope the post makes sense!
Tachikoma, the way you've laid it out is great - I had a slightly different approach (same endgame) in mind when I brought it up - for clarity I've just gone ahead and drawn up the sort of spec simplification I had in mind (kind of more focused on rules than methodology) - can you have a look and I'd appreciate your thoughts?
Regarding the specific levels/order of testing is it necessary to lock in the rule evaluation method/order? I think the approach can be left up to the implementation providing the rules are clear enough - if we need to specify a methodology for interpreting the rules then the rules are not clear enough.
Original
Quote
The transaction data is encoded into said fake Bitcoin address which is then used as an output in a single Bitcoin transaction satisfying the following requirements:
* Has a single or the largest input signed by the sending address
* Has an output for the recipient address (the 'reference' address)
* Has an output for the exodus address
* Has an output for the encoded fake address (the 'data' address)
* Has all output values above the 'dust' threshold (currently 0.00005430 BTC) and preferable be equal.
* Additional outputs are permitted for the remainder of the input (the 'change' address)
The following conditions must also be satisfied for the transaction to be considered decode-able:
* The reference address sequence number must be the data address sequence number + 1
* Ideally, all outputs should be the same (except the change). In fringe cases where the change output value is equal to the other output values the change address can be identified by sequence number, which must not equal or be +/-1 of the sequence number for either the reference address or the data address
* A last resort 'peek and decode' method may be used to identify the data packet in the event of ambiguity following the above rules. This involves decoding each packet and looking for the correct bytes for a simple send (the majority of bytes in a Class A simple send do not change). These byte checks are defined as:
+ Bytes two to eight must equal 00
+ Byte nine must equal 01 or 02
* Should there still be packet ambiguity or 'peek and decode' reveals more than one packet (simple sends are always one packet) the transaction is considered invalid.
NOTE: The sequence number for a given address is defined as a 1 -byte integer stored as the first byte of each 'packet'. Sequence numbers are continuous with 0 following 255 (256=0, 255+1=0).
* Has a single or the largest input signed by the sending address
* Has an output for the recipient address (the 'reference' address)
* Has an output for the exodus address
* Has an output for the encoded fake address (the 'data' address)
* Has all output values above the 'dust' threshold (currently 0.00005430 BTC) and preferable be equal.
* Additional outputs are permitted for the remainder of the input (the 'change' address)
The following conditions must also be satisfied for the transaction to be considered decode-able:
* The reference address sequence number must be the data address sequence number + 1
* Ideally, all outputs should be the same (except the change). In fringe cases where the change output value is equal to the other output values the change address can be identified by sequence number, which must not equal or be +/-1 of the sequence number for either the reference address or the data address
* A last resort 'peek and decode' method may be used to identify the data packet in the event of ambiguity following the above rules. This involves decoding each packet and looking for the correct bytes for a simple send (the majority of bytes in a Class A simple send do not change). These byte checks are defined as:
+ Bytes two to eight must equal 00
+ Byte nine must equal 01 or 02
* Should there still be packet ambiguity or 'peek and decode' reveals more than one packet (simple sends are always one packet) the transaction is considered invalid.
NOTE: The sequence number for a given address is defined as a 1 -byte integer stored as the first byte of each 'packet'. Sequence numbers are continuous with 0 following 255 (256=0, 255+1=0).
Revised
Quote
The transaction data is encoded into said fake Bitcoin address which is then used as an output in a single Bitcoin transaction satisfying the following requirements:
* Has a single or the largest input signed by the sending address
* Has an output for the recipient address (the 'reference' address)
* Has an output for the exodus address
* Has an output for the encoded fake address (the 'data' address)
* Has all output values above the 'dust' threshold (currently 0.00005430 BTC)
* Has exactly two outputs with a value equal to the Exodus output and/or has exactly one output with a sequence number +1 of the data address for reference output identification
* Additional outputs are permitted for the remainder of the input (the 'change' address)
NOTE: The sequence number for a given address is defined as a 1 -byte integer stored as the first byte of each 'packet'. Sequence numbers are continuous with 0 following 255 (256=0, 255+1=0).
* Has a single or the largest input signed by the sending address
* Has an output for the recipient address (the 'reference' address)
* Has an output for the exodus address
* Has an output for the encoded fake address (the 'data' address)
* Has all output values above the 'dust' threshold (currently 0.00005430 BTC)
* Has exactly two outputs with a value equal to the Exodus output and/or has exactly one output with a sequence number +1 of the data address for reference output identification
* Additional outputs are permitted for the remainder of the input (the 'change' address)
NOTE: The sequence number for a given address is defined as a 1 -byte integer stored as the first byte of each 'packet'. Sequence numbers are continuous with 0 following 255 (256=0, 255+1=0).
I also took out the byte range stuff too as it seemed a little unnecessary - if the transaction doesn't have a data address that can be decoded it doesn't satisfy 'Has an output for the encoded fake address (the 'data' address)' and thus is already explicitly invalidated by said rule. What constitutes a valid data address is already defined elsewhere (under the simple send section).
Can you think of any cases my alternative revision doesn't cover? Essentially it's anything P&Dable = valid.
I realize this is a different approach to the simplification - as you can see I've been quite aggressive in removing the ambiguity that currently surrounds Class A (so that a transaction either satisfies the rules or it doesn't, no interpretation). Please let me know your thoughts on this and whether you still prefer to document with decoding methodology (eg levels/order etc) - as always happy to discuss
I'll be excited to have Class A done & dusted!
Thanks
Zathras
EDIT just for clarity - in practice I would still just use P&D for all Class A decoding as that is the (imo) simplest implementation methodology for testing against "Has exactly two outputs with a value equal to the Exodus output and/or has exactly one output with a sequence number +1 of the data address for reference output identification".
Hope the post makes sense!
January 10, 2014, 03:28:59 AM
I already got the chance to say it in person but I will say it again: Awesome news 
Indeed!
While I did promise not to comment again on the main Mastercoin thread, and I do not intend to post on / follow the bounty thread a lot ... I want to say - this is so very great! We are building a real dream team here.
Welcome aboard zathras!
While I did promise not to comment again on the main Mastercoin thread, and I do not intend to post on / follow the bounty thread a lot ... I want to say - this is so very great! We are building a real dream team here.
Welcome aboard zathras!
Congrats Zathras!
Looks like mastercoin will be moving at a faster pace this year with the additional full timers
Looks like mastercoin will be moving at a faster pace this year with the additional full timers
I'm so happy I . . .
. . . I think I just wet myself.
. . . I think I just wet myself.
Thanks for all the kind words guys (and the lol JR), good times ahead!
January 10, 2014, 12:36:06 AM
99.78 % consensus check.
https://masterchest.info/consensus.aspx
I'll recheck my exodus calculations.
Edit
exodus address dev msc is now recalculated based on the latest block.
only 4 valid msc send transaction as of 1/10/14
https://masterchest.info/consensus.aspx
I'll recheck my exodus calculations.
Edit
exodus address dev msc is now recalculated based on the latest block.
only 4 valid msc send transaction as of 1/10/14
January 09, 2014, 09:36:38 PM
Bitoy (and others). The spec mentions that the amount used in a Selling Order should be reserved and thus removed from the balance. I did a consensus check between us and I think you are not doing that yet. Because of this its harder to compare numbers; could you check your output and see if you could build in reserved funds to your solution?
Hi Tachikoma,
I've deducted the selling order from the balance. Please check again.
http://mymastercoins.com/jaddress.aspx?CurrencyID=2
btw where is your test MSC json ?
January 09, 2014, 08:57:14 PM
Congrats Zathras!
Looks like mastercoin will be moving at a faster pace this year with the additional full timers
Looks like mastercoin will be moving at a faster pace this year with the additional full timers
January 09, 2014, 07:56:23 PM
Here's the latest dev update:
Master Protocol & #Mastercoin: Development Update 2 http://ow.ly/srmwa
Master Protocol & #Mastercoin: Development Update 2 http://ow.ly/srmwa
Quote
Developer Communications Mediums
Key Development Statistics
CTO Opening and Search
Security Auditor Opening and Search
QA and Testing of Wallets
Research & Development Updates
Key Development Statistics
CTO Opening and Search
Security Auditor Opening and Search
QA and Testing of Wallets
Research & Development Updates
January 09, 2014, 07:48:00 PM
I already got the chance to say it in person but I will say it again: Awesome news
Indeed!
While I did promise not to comment again on the main Mastercoin thread, and I do not intend to post on / follow the bounty thread a lot ... I want to say - this is so very great! We are building a real dream team here.
Welcome aboard zathras!
January 09, 2014, 05:42:47 PM
I already got the chance to say it in person but I will say it again: Awesome news
January 09, 2014, 05:39:29 PM
Cross post from the main thread:
Hey guys,
Having just finished up with our weekly dev sync con-call, I'm now pleased to publicly announce that I will be joining the project full-time!
The foundation has been working tremendously hard to attract quality talent to drastically speed up development and I can't express enough how excited I am to have the opportunity to dedicate significantly more time to Mastercoin. We have a great team working on the project and with a significant number of new hires coming on board too and getting involved the next few months should be an exciting time!
I will be ceasing my current role and transitioning to working full time on development on 24 Feb.
Thanks to the community for all your support to date
Zathras
Having just finished up with our weekly dev sync con-call, I'm now pleased to publicly announce that I will be joining the project full-time!
The foundation has been working tremendously hard to attract quality talent to drastically speed up development and I can't express enough how excited I am to have the opportunity to dedicate significantly more time to Mastercoin. We have a great team working on the project and with a significant number of new hires coming on board too and getting involved the next few months should be an exciting time!
I will be ceasing my current role and transitioning to working full time on development on 24 Feb.
Thanks to the community for all your support to date
Zathras
January 09, 2014, 05:24:41 PM
Bitoy and Zathras - do you folks have wallets available for testing with Test MSC? Bitoy, I know you have a wallet but last I had heard you were sorting out the SQL issues - Was that resolved? Zathras, I really like the looks of the sneek peak - any updates on opening the wallet for testing purposes? Thanks!
There is no public release (for my wallet) yet but it's coming (soon)
1. I need a way to generate bitcoin address with a private key. (Like bitaddress.org)
As you're .NET have a look at the code behind the Bitcoin Address Utility from casascius (https://github.com/casascius/Bitcoin-Address-Utility).
January 09, 2014, 11:59:26 AM
1. I use a ruby library bitcoin-ruby that can generate addresses, I'm sure your language of choose should have something like that.
2. Same
Now for some distributed exchange fun.
Bitoy (and others). The spec mentions that the amount used in a Selling Order should be reserved and thus removed from the balance. I did a consensus check between us and I think you are not doing that yet. Because of this its harder to compare numbers; could you check your output and see if you could build in reserved funds to your solution?
2. Same
Now for some distributed exchange fun.
Bitoy (and others). The spec mentions that the amount used in a Selling Order should be reserved and thus removed from the balance. I did a consensus check between us and I think you are not doing that yet. Because of this its harder to compare numbers; could you check your output and see if you could build in reserved funds to your solution?
January 09, 2014, 06:55:26 AM
Bitoy and Zathras - do you folks have wallets available for testing with Test MSC? Bitoy, I know you have a wallet but last I had heard you were sorting out the SQL issues - Was that resolved? Zathras, I really like the looks of the sneek peak - any updates on opening the wallet for testing purposes? Thanks!
Mymastercoins thin client wallet is at
http://mymastercoins.com/MyMSCWallet.aspx
I'm trying to remove reliance on bitcoind.exe. In order to do this
1. I need a way to generate bitcoin address with a private key. (Like bitaddress.org)
2. Sign transactions and send them (via blockchain.org pushtx).
Sample scripts greatly appreciated
January 09, 2014, 03:10:42 AM
Bitoy and Zathras - do you folks have wallets available for testing with Test MSC? Bitoy, I know you have a wallet but last I had heard you were sorting out the SQL issues - Was that resolved? Zathras, I really like the looks of the sneek peak - any updates on opening the wallet for testing purposes? Thanks!
January 08, 2014, 06:17:38 PM
Important update regarding the contest!
We had a board meeting recently, and a major topic was how we can encourage faster development of the distributed exchange. Wonderful progress has been made so far, and we want to reward that and encourage more progress, especially with several major competitors nipping at our heels.
With that goal in mind, the proposal was made that we pay out half of the bounty early, based on progress made through 1/22/2014 (two weeks from today). That leaves some time to polish up your work so far, and possibly engage in some testing and bug-finding on other people's implementations (per the rules, 50 BTC of the 150 are allocated for testers).
Realizing that this is a change from the proposed rules of the bounty (although, we believe, a positive change for everyone), we gave the primary devs a couple days to comment before announcing this, and with their feedback, we decided that this was the right move to accelerate things.
Thanks!
We had a board meeting recently, and a major topic was how we can encourage faster development of the distributed exchange. Wonderful progress has been made so far, and we want to reward that and encourage more progress, especially with several major competitors nipping at our heels.
With that goal in mind, the proposal was made that we pay out half of the bounty early, based on progress made through 1/22/2014 (two weeks from today). That leaves some time to polish up your work so far, and possibly engage in some testing and bug-finding on other people's implementations (per the rules, 50 BTC of the 150 are allocated for testers).
Realizing that this is a change from the proposed rules of the bounty (although, we believe, a positive change for everyone), we gave the primary devs a couple days to comment before announcing this, and with their feedback, we decided that this was the right move to accelerate things.
Thanks!
January 08, 2014, 04:08:22 AM
Bitoy, Grazcoin, Zathras; could you all give me your URL's for the test MSC verification API?
I want to prepare for the DEx consensus
Edit: Already mailed it out as well since I want this sooner rather then later.
I want to prepare for the DEx consensus
Edit: Already mailed it out as well since I want this sooner rather then later.
For Test MSC
http://mymastercoins.com/jaddress.aspx?CurrencyID=2
January 07, 2014, 10:21:54 PM
Shouldn't the recipient be 76?
You are correct 76. Therefore transaction is valid under p&d level 2. ( class a is draining my brain
January 07, 2014, 10:53:04 AM
Shouldn't the recipient be 76?
Jump to: