2 x 800 PTS - Generate Unspent Output Set every day at midnight GMT [PAID]

[drekrob]

I would realy like to get around parsing the whole bitcoin blockchain. I assume getting the ags masterbook from some other service is no option here?

[drekrob]

Hmm i always wondered what you would do with ags from pts only but i think i just misread the first point...
well back to coding it is...

[lakerta06]

I think I'm done

Where is the AGS for BTC donations?

[bytemaster]

I think I'm done, reindexing another time right now and will be crosscheck data after that, but everything looks good so far.
http://parseproto.feinarbyte.de/
https://github.com/DerKorb/ParseProto

This looks very good... though the QR background makes my eyes have trouble focusing

[drekrob]

I think I'm done, reindexing another time right now and will be crosscheck data after that, but everything looks good so far.
http://parseproto.feinarbyte.de/
https://github.com/DerKorb/ParseProto

[bytemaster]

I am very excited to see how rapidly you all are making progress! 

[drekrob]

http://parseproto.feinarbyte.de/
Its parsing the blockchain again right now, that should fix the last issues i had with ags distribution. Also i need to clean up the interface, cache results for better performance and stuff like that...
But basicaly it should do what it is expected to.

[BrownBear]

http://78.47.213.56/

It's still catching up index-wise but should be done in a few minutes.
Please note that it is sometimes disagreeing with AGS-explorer due to the issues we discussed before, namely that AGS explorer is not giving all the AGS to vin[0] but distributes it. Other than that neither me nor DreKrob could find any inconsistencies any more (so far) in my data set. His method and dataset looks pretty solid as well but has some issues still.

Installation instructions and source for the web interface can be found on github in the folder resources/. Please use at own risk!

[drekrob]

I just compared my calculations of pts and ags balances with BrownBear and our results match within 0-1 satoshi. I still need to code the genesis block and improve the interface, but im almost done.

[BrownBear]

It's easily changed and makes my lifer in the interface easier. Tho I'm finished.

Let me know if you want a test page to look at it. The running webservice will take a few more days to set up everything.

[bytemaster]

One more thing: are you sure about the JSON output? I don't get the reason behind the array.

Why not do (one associative array)
{ "address1": balance1, "address2": balance2, ... }

Instead of
[ { "address1": balance1 }, { "address2": balance2 }, ... ]

Actually after looking at what I would be using to import this, the following would be better...

[ [ "address1", balance1 ], [ "address2", balance2 ] ]

I will be parsing this into a vector<std::pair<string,uint64_t> > which my auto JSON serialization routines for C++ would expect to be handled as above...
I recognize this is a changed requirement, so switching to it is not required to win the bounty, but it would make my life easier and thus accelerate development

[BrownBear]

I think I'm done. Values compared to AGS Explorer so far are equal within 1 Satoshi. I assume they are rounding, while I'm clipping (int).
Gonna rent a server after some more testing et voila!

[drekrob]

I fixed my problems with rpc so I guess I'm back to business. Also I'm pretty far down the road. I should hopefuly produce the full results soon.

[BrownBear]

One more thing: are you sure about the JSON output? I don't get the reason behind the array.

Why not do (one associative array)
{ "address1": balance1, "address2": balance2, ... }

Instead of
[ { "address1": balance1 }, { "address2": balance2 }, ... ]

[BrownBear]

Integer math won't save you there tho.
Example:

A spends 4 on AGS
B spends 3
-
Sum = 7
5000.0 AGS / 7 = 714.28571428[571...] (or ...9 if you're rounding up)

A gets 2857.14285714[285...]
B gets 2142.85714285[714...] or (...9 if rounding up)

Sum: 4999.99999999[999...] -> 1 satoshi destroyed. The more people in the AGS pool, the bigger the potential loss.

I'm using double's to calculate the AGS share, which have a similar precision to int64 (52 bit) and should be sufficient to keep the error small, but it can't be smaller than stated above unless we agree upon an algorithm for distributing the remainder. Just wanted to point out that there's room for (very small) errors creeping in.