Quote from: grazcoin on September 07, 2013, 06:29:27 AM

I am using 1377993600 as well, so I don't understand the difference in the results.

Here is my detailed calculation:
===================
1. check https://blockchain.info/address/1PA8qhEzW7to6EeqBAdhVZYGbVj2MfmN2n
2. The relevant tx is https://blockchain.info/tx/546a406a131089e7c2f27d34a93a4d27441d98d096404d6737c5ad5b5e61a09b
3. That tx was included in block 249498 which has timestamp (in the blockchain) of 2013-07-31 21:32:31
4. converting the block timestamp to epoch: 1375306351
5. calculate difference between tx and end date: 1377993600-1375306351=2687249 sec
6. calculate bonus percent: 10%*2687249/(3600*24*7)=44.432027116%
7. calculate total amount of mastercoins: 1600000000*100*(1+0.44432027116)=231091243385.6 -> 2310.91243386

I just assume you took a different timestamp for the tx.
It is important to note that the only relevant timestamp in the blockchain is the one of the corresponding block.
Any other "Received Time" is node-dependant value (e.g. one may get the tx few seconds minutes or even hours before of after blockchain.info, and there is no way to verify it), and that value should be ignored.

Thanks for the detailed breakdown. I found a reference in the code where I was not using my constant for the end date and this date was 1 second off. The result is now: "Bought 1600.0 Mastercoins and got a 710.91243386 Mastercoins extra.". Which I think should be the correct amount.

Now I finally have the same output I'm considering parsing the blockchain and get some real data on the transfers happening and actual balances of addresses.

Quote from: dacoinminster on September 06, 2013, 09:54:18 PM

15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk (which had the largest total input) should be the owner of those MasterCoins rather than 1G6F8aMJNp3zMG9L1DxDT3WjiUntJYwYka (which had the largest single input). MasterCoin-Explorer incorrectly credits the latter address with the purchase. I realize I need to be more clear in the spec about how to do this!

Ah; this was unclear to me. I have indeed been using the largest single one, this won't make the implementation easier. I think the spec could use one clear paragraph on how to parse the data with test vectors.

Quote from: grazcoin on September 07, 2013, 07:40:16 AM

Quote from: dacoinminster on September 06, 2013, 03:49:03 PM

I'm cool with that. I'm guessing block 255362 transactions would get a bonus of zero? It's possible that if you just used the same math, they'd actually get a small negative bonus!

Assuming we accept investments through block 255362, here is my proposed refund list: https://docs.google.com/spreadsheet/ccc?key=0AnnInaIJVqrtdGMteFNOWjBpWTNqd3BYbWUzdGVLMmc&usp=sharing

Block 255362 has the timestamp of 2013-09-01 00:00:58 which is after end date, so it should be also refunded.
If we change that, this would be already considered as a modification of the spec (and we would like to avoid that, like bitcoin avoids hard forks).

I have seen somewhere the suggestion that some early investors could send valid mastercoins to those addresses.

Although it's true that the spec mentions that all payments after 2013-08-31 will be considered invalid it does not tell us which time to use for this calculation. If we want to be precise then yes 255361 would be the valid answer. However people sending coins on 23:48 did so thinking they send the coins before 2013-08-31, which they indeed did. It seems more fair to use block 255362 since this would include all transactions _send_ before 2013-09-01. (and yes; perhaps 58 seconds of transactions that were sent after)