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

[ripper234]

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!

[1714829052]

1714829052

[1714829052]

1714829052

[1714829052]

1714829052

[prophetx]

Here's the latest dev update:

Master Protocol & #Mastercoin: Development Update 2 http://ow.ly/srmwa

Developer Communications Mediums

Key Development Statistics

CTO Opening and Search

Security Auditor Opening and Search

QA and Testing of Wallets

Research & Development Updates

[Bitoy]

Congrats Zathras!

Looks like mastercoin will be moving at a faster pace this year with the additional full timers  

[Bitoy]

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  ?

[Bitoy]

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

[zathras]

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!

Congrats Zathras!

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.

Thanks for all the kind words guys (and the lol JR), good times ahead!

[zathras]

I added an issue with a suggestion for the updated P&D rules specification for the spec to helpfully make it all clear once and for all.

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

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

Revised

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

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!

[grazcoin]

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:

• 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

[Bitoy]

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)

 

[Tachikoma]

Zathras's post about the P&D clarification.

Great post and it might solve our issues; I'm just afraid it might not solve all ambiguity. I think the P&D order is important because depending on what way you try to parse it first the recipient address might differ. I think the best way to see if your clarification holds up is to meet on IRC for the hackathon and discuss the remaining transactions and how the specs(-modifications) would answer them.

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:

• 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

The reason I'm probably not matching is because I do it per second. I think we agreed somewhere in the thread Exodus should be calculated per on each block found using the block-date. I'm not doing that yet. I will be doing that during the coming hours so hopefully it should be online before the hackathon starts.

I will be in #mastercoin / ##mastercoin in a few minutes to work on the consensus stuff. If you are already available please drop by as well so we can discuss things there.

[grazcoin]

The reason I'm probably not matching is because I do it per second. I think we agreed somewhere in the thread Exodus should be calculated per on each block found using the block-date. I'm not doing that yet. I will be doing that during the coming hours so hopefully it should be online before the hackathon starts.

I will be in #mastercoin / ##mastercoin in a few minutes to work on the consensus stuff. If you are already available please drop by as well so we can discuss things there.

I don't think that calculating "per second" is the issue, since such a calculation would end up to a higher sum, and you have got a lower sum.

[grazcoin]

https://masterchest.info/consensus.aspx shows now -129.34% (negative number)
It seems like MyMastercoins is way out of sync.

[grazcoin]

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)

BitBoy/Zathras -
Can you please give a link to the source code that calculates the available reward of exodus address?
I would like to compare and nail those differences.

[Tachikoma]

I'm on IRC now.

I think we need to pick a source and write down in the spec the source we use for the amount of seconds in a year.

I used: 60 * 60 * 24 * 365.25 but I guess we need to decide on the seconds amount. 

[grazcoin]

I'm on IRC now.

I think we need to pick a source and write down in the spec the source we use for the amount of seconds in a year.

I used: 60 * 60 * 24 * 365.25 but I guess we need to decide on the seconds amount. 

Why not just take the exact number and not an estimation?
http://wiki.answers.com/Q/How_many_seconds_are_there_in_a_year
31556926

[Tachikoma]

Agreed; that's fine. I will make a pull request to add it to the spec.

[Bitoy]

https://masterchest.info/consensus.aspx shows now -129.34% (negative number)
It seems like MyMastercoins is way out of sync.

Sorry accidentally pushed the "reset database" button.  It's now back    


For the Exodus Coins Generated I used the following formula

        Time1 = $Time of latest block in seconds
        dBlockDateTime = DateAdd(DateInterval.Second, Time1, New DateTime(1970, 1, 1, 0, 0, 0))

'Calculate number of seconds from September 1,2013 to Latest Block Time
        SecondsFromSept12013 = DateDiff(DateInterval.Second, #9/1/2013#, dBlockDateTime)

        Dim Gencoins As Double = (1 - (0.5 ^ (SecondsFromSept12013 / 31557600))) * 56316.23576222
        Gencoins = Round(Gencoins) to the nearest 8 decimal

Edit

OK will change   31557600 to 31556926

[Tachikoma]

Graz; difference between us is really small now.

Code:

      time_difference = (exodus_time.to_i - Mastercoin::END_TIME.to_i) / 31556926.0
      self.balance += ((1-(0.5**time_difference)) * BigDecimal.new("56316.23576222")).round(8)

Where exodus_time is the time from the latest block and Mastercoin::END_TIME is 1377993600.

Bitoy: We are actually synced up, so I guess we might both be wrong

I'm stepping out to get some dinner; bbiab

[Bitoy]

Yes Tachikoma, finally we are synched to the last msc.
11040.08115172

Grazcoin I think is just a block time away from synching 11039.54172323

( It's 2am here.  I'm going to zzzz =)

Edit
Grazcoin the difference is only 0.000000004.  Maybe you rounded to 7 digit instead of 8?
11040.7003806
11040.70038056

[Tachikoma]

Dev Mastercoin clarifications pull is here: https://github.com/mastercoin-MSC/spec/pull/34