BitShares Forum
Other => Graveyard => Marketplace => Topic started by: bytemaster on February 11, 2014, 04:33:46 pm
-
I am looking for someone to setup and maintain a web service that will generate the unspent output set from BitShares PTS as a .json file of the following form
{ "blocknum" : N, "blocktime" : timestamp, "moneysupply" : supply, "balances" :
[ {"PTSADDRESS1":TOTAL_BALANCE}, {"PTSADDRESS2":TOTAL_BALANCE}...] }
I will pay this bounty twice for two people that produce independent implementations hosted on independent servers and publish their source code and a HOWTO set up a similar service on a brand new server.
I will pay $3 per day in PTS that the service has 100% uptime AND produces accurate data, this will be paid monthly for the next year.
I will pay a 120 PTS sub-bounty for someone to replicate the work of the two independent implementations and host a mirror for 1 year paid out at 10 PTS per month.
The .json file should be made available for any day as of the last block found before midnight GMT
The .json file must be available by noon the next day.
Multiple outputs payable to the same address should be summed to result in a single entry
The purpose of this bounty is to make it easy for anyone to create a snapshot and launch a new DAC honoring PTS and also to provide an independent audit of PTS balances in our genesis blocks.
I would also like this service to capture the cumulative master book for AGS donations each day and generate a .json file of the same format.
Lastly I would like the service to produce a genesis block every day based upon a web-form that specifies the percentage of the money supply that should be allocated to AGS and PTS. It should be in the same format as the AGS and PTS balances.
We will allow for several days of operation to verify the services are indeed producing the same results. Until two independent implementations produce identical results no one gets paid. This applies to the AGS data as well. A mistake I made last time was not having a means to validate / compare results. So if you pull your data from agsexplorer or angelshares.info then I suggest you find a way to produce identical results. Two services that both use the same AGS source are not fully independent.
-
I've written two PHP scripts to accomplish that.
JSON file honoring the defined form: http://q30.protoshar.es/pts/pts_unspent.json
Source code published on github: https://github.com/vertoe/pts-unspent
HOWTO set up a similar service: https://github.com/vertoe/pts-unspent/wiki
Note, the database is currently being filled as the blockchain is being parsed.
PuCPcTzHDpsWrVEdBrC5F53qrxfdiUXk62
-
I managed to do it in nodejs
https://github.com/DerKorb/ParseProto/
Just moving this from my localhost to my web server right now.
Requires a local instance of protosharesd running.
-
url for json will be : http://feinarbyte.de:1027/data
-
patience, young padawan, there is a bounty for two of us ;)
-
need to download the blockchain first
-
+5%
-
I'm also about to complete this bounty. Mine is a modification in protosharesd which will output the json data every day.
Since I'm the third, I'm unsure whether I should get a server for this or not, but either way I can replicate one (or both) of the above.
Here's the fork of protoshares:
https://github.com/BrownBear2/ProtoShares
This version will create a new json file in the specified location (-unspent path/to/file.json) whenever the first block of a new day has been received according to the blocktime.
-
well i shall continue with this tomorrow, I have been up way to long... If anyone feels like doing the daily genesis block i would not mind.
-
I've written two PHP scripts to accomplish that.
JSON file honoring the defined form: http://q30.protoshar.es/pts/pts_unspent.json
Source code published on github: https://github.com/vertoe/pts-unspent
HOWTO set up a similar service: https://github.com/vertoe/pts-unspent/wiki
Note, the database is currently being filled as the blockchain is being parsed.
PuCPcTzHDpsWrVEdBrC5F53qrxfdiUXk62
Missing AGS and how do I specify the day... I should have access to every day (after the launch), not just the most recent day.
-
Missing AGS and how do I specify the day... I should have access to every day (after the launch), not just the most recent day.
Ok, will adjust the script to output daily results and create AGS integration. I've overread that part.
Daily JSON is enough or do you want to be able to get the result on the basis of a specified block?
-
Missing AGS and how do I specify the day... I should have access to every day (after the launch), not just the most recent day.
Ok, will adjust the script to output daily results and create AGS integration. I've overread that part.
Daily JSON is enough or do you want to be able to get the result on the basis of a specified block?
I am fine with the status of the last block timestamped for each day GMT time. This will line up with the AGS for that day and make everyone's life easier.
-
I'm also about to complete this bounty. Mine is a modification in protosharesd which will output the json data every day.
Since I'm the third, I'm unsure whether I should get a server for this or not, but either way I can replicate one (or both) of the above.
Here's the fork of protoshares:
https://github.com/BrownBear2/ProtoShares
This version will create a new json file in the specified location (-unspent path/to/file.json) whenever the first block of a new day has been received according to the blocktime.
So far no one has completed the bounty and delivered a complete working service that meets all of the requirements. In the event that multiple people complete within 3 days of each other the award will go to the two solutions we consider most robust, well documented, and accurate.
We will allow for several days of operation to verify the services are indeed producing the same results. Until two independent implementations produce identical results no one gets paid. This applies to the AGS data as well. A mistake I made last time was not having a means to validate / compare results. So if you pull your data from agsexplorer or angelshares.info then I suggest you find a way to produce identical results.
-
I just noticed that my method might not work after all. The bitcoind/protosharesd api i'm using outputs only unspent outputs via rpc. So every donation to the angel adress that got already spent again is not listet and thus i wont ever be able to get accurate results. So good luck to you two in claiming this bounty, my solution disqualified itself.
-
My code now spits out unspent tx out for any day you like as well as a file containing an entry for everyone who donated to the angel share address.
Lastly I would like the service to produce a genesis block every day based upon a web-form that specifies the percentage of the money supply that should be allocated to AGS and PTS. It should be in the same format as the AGS and PTS balances.
Can you expand on that part a bit, please?
I will do further testing to ensure data validity and set up a server soon.
-
My what a good opportunity for us all to take a moment and hash out genesis block spec:
https://bitsharestalk.org/index.php?topic=1738.0
-
By genesis block I mean data in the same format as above but pulling it all together.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
I'm still not 100% sure about the genesis block, but I think I might know what you want ^_^
A different problem arose tho:
When multiple addresses donate to AGS together, how am I supposed to fairly and accurately calculate which address donated how much? The obvious answer would be to give every address AGS relative to the amount that address spent, but then we get rounding errors.
I've looked at agsexplorer to find out how it's done there and saw that they just remove fees and other outputs in the transactions from the highest staking input address and ignore the resulting unfairness.
Example: http://www1.agsexplorer.com/balances/1GwqVEwMiwEwifRaLnRB14CJQ4rjqaJmvR
200mBTC where spent, the 17.82203 mBTC of fees and change where simply subtracted from 1EmFGWtWgAF8ZjDHHMZPqRZvSboLjWEY2r's angel shares.
Assuming that all inputs belong to the same person, the unfairness wouldn't matter, but if there was any scenario where two people could donate in the same TX (multisig?), one of them would get less AGS.
Is this how it's supposed to be handled or should a different approach be taken? If so, which?
EDIT:
Even worse, agsexplorer seems to do this rather indeterministicly:
http://www1.agsexplorer.com/balances/1KHXpgQLeLgMTZmP5JVss5XX55UUTFunPP
https://blockchain.info/de/tx/d2b64a6d2e3860bfc6f37774bad6e7c4bfbc1ea63716de4bc146188f8e63e61e
In that transaction, address 1Q4isu8WRDn8Withk4GhM4vbeKNdRcq7TH leaves empty handed. To get comparable results, we need a clearly defined way to distribute the AGS.
-
I'm still not 100% sure about the genesis block, but I think I might know what you want ^_^
A different problem arose tho:
When multiple addresses donate to AGS together, how am I supposed to fairly and accurately calculate which address donated how much? The obvious answer would be to give every address AGS relative to the amount that address spent, but then we get rounding errors.
I've looked at agsexplorer to find out how it's done there and saw that they just remove fees and other outputs in the transactions from the highest staking input address and ignore the resulting unfairness.
Example: http://www1.agsexplorer.com/balances/1GwqVEwMiwEwifRaLnRB14CJQ4rjqaJmvR
200mBTC where spent, the 17.82203 mBTC of fees and change where simply subtracted from 1EmFGWtWgAF8ZjDHHMZPqRZvSboLjWEY2r's angel shares.
Assuming that all inputs belong to the same person, the unfairness wouldn't matter, but if there was any scenario where two people could donate in the same TX (multisig?), one of them would get less AGS.
Is this how it's supposed to be handled or should a different approach be taken? If so, which?
EDIT:
Even worse, agsexplorer seems to do this rather indeterministicly:
http://www1.agsexplorer.com/balances/1KHXpgQLeLgMTZmP5JVss5XX55UUTFunPP
https://blockchain.info/de/tx/d2b64a6d2e3860bfc6f37774bad6e7c4bfbc1ea63716de4bc146188f8e63e61e
In that transaction, address 1Q4isu8WRDn8Withk4GhM4vbeKNdRcq7TH leaves empty handed. To get comparable results, we need a clearly defined way to distribute the AGS.
I remember bytemaster said somewhere in this forum "The first address in the tx gets all the AGS" first meaning the first in the blockchain data.
-
Is the first reliably the same first for everyone? Yes, right, otherwise the sig would change!?
-
I am maintaining agsexplorer.com. We credit AGS shares to each input proportionally at the moment. As bytemaster clarified that the first input address will be credited AGS. We are in the middle of changing the algorithm and update will be released within days. It took us last week solving data source stability issue, setting up backup server and data sources. Hopefully agsexplorer.com won't be suffering from inaccurate data source any more.
EDIT:
Even worse, agsexplorer seems to do this rather indeterministicly:
http://www1.agsexplorer.com/balances/1KHXpgQLeLgMTZmP5JVss5XX55UUTFunPP
https://blockchain.info/de/tx/d2b64a6d2e3860bfc6f37774bad6e7c4bfbc1ea63716de4bc146188f8e63e61e
In that transaction, address 1Q4isu8WRDn8Withk4GhM4vbeKNdRcq7TH leaves empty handed. To get comparable results, we need a clearly defined way to distribute the AGS.
You are right. This is clearly a bug in the data source that leave 1Q4isu8WRDn8Withk4GhM4vbeKNdRcq7TH empty handed in current algorithm. I will investigate and make sure it's not a problem in new algorithm
-
How do you spread the coins evenly? (what's the PTS word for satoshis? ^_^)
If you use divisions you'll inevitably end up with rounding error:
// example:
//
// inputs: A: 10, B: 20, C: 23
// donation: 15
// change and fees: 38
//
// rewards: 0.28301887 * input
// A: 2.830 = 3
// B: 5.660 = 6
// C: 6.509 = 7
// +-----
// 16 !!! one coin more than input
Do you have a link to an address/tx where it has been spread evenly?
Edit:
This one is the latest multi-input donation I found, it still distributes the coins by what looks like first-come-first-serve:
http://www1.agsexplorer.com/balances/1HkQzFX7g42kDkPk5GziNb1MrdxmQRvWoy
-
Will work with donschoe to work it out. Thanks for pointing it out.
-
We assume all addresses belong to same person.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
meaning first-come-first-serve? It needs to be defined somehow or we're all gonna get different results.
Atm. I implemented it in the lakerta06 quoted you: vin[0] get's all he spent, vin[1] is next etc. until the assigned AGS equals the amount of PTS sent to the angel share address.
-
Vin[0] gets it all as if all vin[0...n] inputs came from vin[0]. There is one deterministic key per trx that gets the ags.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
I found another inconsistency problem. Maybe you already defined a solution for this as well:
Dates in the blockchain can be incosistent, for example, these are the dates of some early blocks:
block height: 4127 2013-11-06
block height: 4128 2013-11-06
block height: 4129 2013-11-06
block height: 4130 2013-11-07
block height: 4131 2013-11-07
block height: 4132 2013-11-07
block height: 4133 2013-11-07
block height: 4134 2013-11-06
block height: 4135 2013-11-06
block height: 4136 2013-11-06
block height: 4137 2013-11-07
block height: 4138 2013-11-07
block height: 4139 2013-11-07
block height: 4140 2013-11-07
block height: 4141 2013-11-07
block height: 4142 2013-11-07
block height: 4143 2013-11-07
block height: 4144 2013-11-07
This makes it hard to determine when exactly one day ends and another starts (this also seems abusable in general). How to handle it (if possible without looking into the future)?
-
I found another inconsistency problem. Maybe you already defined a solution for this as well:
Dates in the blockchain can be incosistent, for example, these are the dates of some early blocks:
block height: 4127 2013-11-06
block height: 4128 2013-11-06
block height: 4129 2013-11-06
block height: 4130 2013-11-07
block height: 4131 2013-11-07
block height: 4132 2013-11-07
block height: 4133 2013-11-07
block height: 4134 2013-11-06
block height: 4135 2013-11-06
block height: 4136 2013-11-06
block height: 4137 2013-11-07
block height: 4138 2013-11-07
block height: 4139 2013-11-07
block height: 4140 2013-11-07
block height: 4141 2013-11-07
block height: 4142 2013-11-07
block height: 4143 2013-11-07
block height: 4144 2013-11-07
This makes it hard to determine when exactly one day ends and another starts (this also seems abusable in general). How to handle it (if possible without looking into the future)?
The official answer to this is that you ignore the order of the blocks and merely look at the timestamp to allocate. No need to draw a line. If the days overlap then they overlap. There is a 2 hour tolerance in the bitcoin codebase. Anyone donating in that 2 hour window is at the mercy of the miners to determine what day the block gets included in.
-
It would be way easier to implement if we would instead say the first change of daay is final, no going back in date. With your approach i have to do a cache for the last 2 hours of blocks. Any chance of changing the definition?
-
It would be way easier to implement if we would instead say the first change of daay is final, no going back in date. With your approach i have to do a cache for the last 2 hours of blocks. Any chance of changing the definition?
I believe using the first day change may be acceptable and is less ambiguous.
-
I suspect you are also right. The goal is to sync with ags and that means sticking to the time stamp of the block and ignoring order.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
So rather than using the first day Change. Use the last day change as the snapshot block for pts.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
Ok this means data will only be available after 2am
-
I just realized this brings up yet another issue:
I implemented AGS to be counted by the date resulting from the blocks time as discussed above, BUT:
The unspent TX out for protoshares has the same problem due to AGS: when does the day officially end? In this case, we cannot account blocks with a lagging date to the date it says it would be since obviously blocks depend upon each other, so ignoring the blocks with a newer date doesn't (reliably) work.
Example:
Block 1234 - Jan 6th: A sends B 10PTS
Block 1235 - Jan 7th: B sends C 5PTS
Block 1236 - Jan 6th: B sends A 5PTS
Result by ignoring 1235:
A got 5 PTS
B got 5 PTS
Actual data:
A got 5 PTS
B got 0 PTS
C got 5 PTS
It can also lead to inconsistencies where somebody would have negative PTS.
-
They are partially related through the BTS genesis block that we're asked to create, which should include AGS and unspent PTS TX (if I understood that correctly). But I guess this inconsistency is tolerable. It could happen that somebody for example send money to AGS on the last day and gets more BTS because in the first "new day" block he still has unspent PTS while the AGS he gets from a later block with an earlier timestamp is counted.
-
Yeah, it's either first or last determining the day. I'd like to stay with first tho, since I've already implemented this now. ;)
-
Hey everybody,
just wanted to let you guys know that I'm also working on an implementation for this, and have been for a couple days now. I'm not done by any means yet, but I like what I have so far. I've uploaded the work in progress to a github repo at
https://github.com/seeekr/pts-unspent
So far what's implemented (with a couple bugs still left, like the issue that's been discussed here regarding "flapping blocktimes") is the calculation of unspent pts by day, as originally requested. It outputs the info in the desired format, but doesn't contain anything beyond that yet, not even a server to have some kind of web UI for requesting and navigating the information.
It's built in node.js and is using protosharesd/bitcoind to get blockchain information and works with that to calculate unspent outputs and the balance by address.
There's still a bunch of work to do until it meets the bounty criteria and I intend to keep at it 'til it's done. I'm new to BTC/PTS development so it took some time to figure out how to navigate this environment, but I'm starting to understand stuff which is good :)
As of now I can't add anything to the discussion here, other than to agree with the last posts here regarding the desired rule for which block should constitute the last one of the day. I don't care much about how we should do this specifically and I don't have a strong opinion on this since I don't fully understand AGS and the connection of the PTS balance to it.
I do have a couple of questions that I'll need answered that I think are irrelevant for the other active devs here since I'm new to the cryptocurrency/equity thing here and have some learning and catching up to do :)
-
Good luck! This bounty turned out to be quite more complicated than anticipated. If you have questions, just ask.
-
Good luck! This bounty turned out to be quite more complicated than anticipated. If you have questions, just ask.
Looks like I priced it well then :)
-
I wouldn't mind a bit of an increase ^_^ it's way more work than 3x a wallet implementation. But maybe you're lucky and I'm pot committed already ;)
-
They are partially related through the BTS genesis block that we're asked to create, which should include AGS and unspent PTS TX (if I understood that correctly). But I guess this inconsistency is tolerable. It could happen that somebody for example send money to AGS on the last day and gets more BTS because in the first "new day" block he still has unspent PTS while the AGS he gets from a later block with an earlier timestamp is counted.
The only hard requirement in my book is that the AGS donations are counted based upon timestamp of the block and that both independent implementations agree as to which block constitutes 'midnight' on a given day. This means that your production of the block and stats probably has to wait until 2 hours after midnight to be sure no blocks are produced with an old timestamp.
If two independent implementations agree to a deterministic block (first or last time change) for the end of the day then that is fine with me.
-
I've changed the algorithm now to do it like this:
When the first change in day in the blockchain appears the AGS file is written. If another block comes along later with a reverse day change (day -1), it's scanned for AGS updates and written if required.
This means, there will be output at 0:06 every day, but it can change for up to 2 hours later. The ProtoShares are counted to the first forward day change (day +1) in the chain. Afaik DreKrob is also working on it using this approach, since he found a way to use RPC after all. My implementation can be pulled into protosharesd/-qt and run via command line parameter (-unspent).
My webinterface will be a using html/javascript. This keeps setup easy.
Please tell me if I got this right:
You can input the day you want to calculate the genesis data for and the percentage of the total money supply for the new currency that is supposed to be distributed amonst AGS holders. The script then allocates 10% of the new currency to all PTS addresses according to their balance and x% (the previously set amount) of the new currency to all AGS holders according to the size of their donations.
The result will be a json file that contains each PTS address and the percentage that they are supposed to get. ( [ { "address": number between 0 and 1 }, ... ] )
-
The inputs to generate the genesis block should be:
1) Total Share Supply
2) % allocated to PTS
3) % allocated to AGS
4) It would be really awesome, but not required, if the user could specify a JSON object of balances to be divided up for a 3rd category (custom to their DAC)
The result should be a JSON object with all of the balances calculated and ready to use.
-
4) is doable, I think
-
I wouldn't mind a bit of an increase
*cough* ;)
(http://i.cubeupload.com/7MT1GT.png)
-
Looks great....
-
By the way, what about rounding errors when distributing AGS daily? It's tiny but existing.
-
By the way, what about rounding errors when distributing AGS daily? It's tiny but existing.
Ideally everything would be calculated with integer math and thus the rounding errors will be deterministic. They are what they are and I will consider two outputs to be identical if they are within 100 satoshis of each other.
-
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.
-
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 }, ... ]
-
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.
-
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! :)
-
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 :)
-
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.
-
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.
-
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!
-
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.
-
I am very excited to see how rapidly you all are making progress!
-
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/ (http://parseproto.feinarbyte.de/)
https://github.com/DerKorb/ParseProto (https://github.com/DerKorb/ParseProto)
(http://i.cubeupload.com/VorcSr.png)
-
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/ (http://parseproto.feinarbyte.de/)
https://github.com/DerKorb/ParseProto (https://github.com/DerKorb/ParseProto)
This looks very good... though the QR background makes my eyes have trouble focusing :)
-
I think I'm done
Where is the AGS for BTC donations?
-
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...
-
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?
-
when clicking on http://parseproto.feinarbyte.de/
i got malware warning from bitdefender... normal!?
-
Just want to make sure this isn't overlooked: How are allocations for Keyhotee Founder AGS handled?
-
Just want to make sure this isn't overlooked: How are allocations for Keyhotee Founder AGS handled?
Great point... they get 10000 AGS divided among them, Stan and I will produce this list. So the AGS percentages should assume an additional 10,000 AGS and simply reserve it for founders.
-
http://ptsags.quisquis.de/
Data files are currently being uploaded and may not be complete yet.
I haven't compared my numbers to anyone else's yet (I've already noticed an off-by-one in my date calculation... :-/ ), so there may be some debugging waiting for me tomorrow. Also some fine tuning, documentation and setting things up on my server. Oh, and including the keyhotee founder's shares in the calculations.
I'm planning to publish my source code under a proprietary license at first, moving to GPL only if I receive the bounty. I hope that's OK for you.
BSD if you receive the bounty... sure.
-
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?
It is fine if you get it from another source so long as it is not the same source as the other implementation because I want independent checks.
-
i will be using the blockchain.info api then
-
I added btc donations to ags addresses via api call to blockchain.info.
Also i have no idea why I am flagged malware and bitdefender isn't exactly generous with information about that either but it seems that my whole domain got flagged. A client of mine had a compromised wordpress installation once, maybe that's the reason.
-
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/ (http://parseproto.feinarbyte.de/)
https://github.com/DerKorb/ParseProto (https://github.com/DerKorb/ParseProto)
(http://i.cubeupload.com/VorcSr.png)
Can we get the ability to enter the percentages as numbers rather than just sliders? The sliders don't even provide feedback as to which percentage was chosen.
-
http://78.47.213.56/
The data here should be correct and accurate. BTC data is currently from blockexplorer, but my indexer is going through the actual blockchain right now (takes ages to download as usual) to get a very accurate seperate data source. That data will be available tomorrow.
The AGS allocation from Keyhotee you discussed before: you can add it as custom file in my solution. Is that good enough or do you want it to be affected by the actual AGS slider and worked in somehow? If so, how?
-
It should be affected by AGS slider... I will provide a JSON input set that contains extra AGS allocations that you can then add to your existing numbers prior to scaling?
-
Sure, no problem. Just need the specs (I guess same format as above?)
-
Sure, no problem. Just need the specs (I guess same format as above?)
Yep.
-
Just as a note: I use integral as well. I compute the AGS with int128 and then round down to int64 / satoshis.
To print I print the int64 and put a decimal point at the correct position.
-
That's because of the properties of AGS and how they're divided on Jan 1st.
-
The ags_ files have a total of less than 5000 for that reason. (there are files for 2013-12-26+)
The accumulative file was using the wrong total before, so thanks for making me aware of that.
-
did you try to compare it with my data?
-
I submited a false positive ticket to bitdefender, I hope they also give me any information why i was flagged.
-
You should be able to download multiple files, i will check into the digits issue.
-
I fixed the bug with decimal places.
I'm using chrome and for me, if i go back from the dowload the button is active again. If the button still is changed after a reload its kind of odd as i change it with javascript.
-
Yeah i do it on the fly. I figured this isn't a service that will be used by many people very often so i didn't cache the files but i already prepared everything for caching and will probably add that. I now fixed the bts import but i'm still missing a few addresses due to a bug in blockchains api. Will have to build a workaround for that. Should be only a handfull of addresses though.
-
I moved my service to a new server:
http://178.63.85.22/
The other one was a wimpy virtual server. I'll shut it down soon.
We're gonna use this one as the jenkins build server as well.
BTC's are still parsing.
-
My project is completed. All numbers match up. BTC/PTS to AGS works. Keyhotee file can be added in webform. Documentation is in github folder resources/ btw. There's a small bug in the bitcoin patch in that folder atm, I will resolve that tomorrow since I have to leave right now.
-
Bitdefender removed the warning.
-
This looks very good :)
-
I changed my BTC source to blockexplorer as blockchain.info api randomly misses timestamps for a few blocks. Are you going to supply us with the file for the founders soon bytemaster?
-
I changed my BTC source to blockexplorer as blockchain.info api randomly misses timestamps for a few blocks. Are you going to supply us with the file for the founders soon bytemaster?
We do not have all of the public keys for the founders. I am content if you just leave a single placeholder ["FOUNDER", 10000] entry.
-
I just noticed that you wanted to parse the data in uint64_t, would you prefer satoshi amounts instead of PTS/AGS/BTC amounts (aka int vs. float)? I can swap it easily.
-
I just noticed that you wanted to parse the data in uint64_t, would you prefer satoshi amounts instead of PTS/AGS/BTC amounts (aka int vs. float)? I can swap it easily.
I am loading it as floats... so that is no problem.
-
Is it claimed already? I may try to do this
-
I have a large cluster of servers lying un-used.
If the developers who've completed this would like to replicate it - I am up for partnership.
My servers are globally located, have DDOS protection and are high one ends.
Fit in perfectly for this
-
Is it claimed already? I may try to do this
Not yet claimed... but I believe two people have completed this bounty and we will be reviewing it in the next day or so for completion so we can pay out before the 28th.
-
Is it claimed already? I may try to do this
Not yet claimed... but I believe two people have completed this bounty and we will be reviewing it in the next day or so for completion so we can pay out before the 28th.
So useless for me to try?
-
Is it claimed already? I may try to do this
Not yet claimed... but I believe two people have completed this bounty and we will be reviewing it in the next day or so for completion so we can pay out before the 28th.
So useless for me to try?
I said I would pick the best 2, so if you are going to try you will have to do better and faster than the existing two...
-
For the fellow developers
I'd like to offer 10 dedicated servers for this project for an entire year for a share of the bounty (although only 3 are actually needed -the rest can be used for other projects)
I will also be using the How To to set-up the same on a third and 4th server
Servers will be split globally
Locations am looking at - USA,Tokyo,Ireland and Sydney
I lost 1000 PTS recently, and I guess this can be one way to recover it :)
-
Is it claimed already? I may try to do this
Not yet claimed... but I believe two people have completed this bounty and we will be reviewing it in the next day or so for completion so we can pay out before the 28th.
So useless for me to try?
I said I would pick the best 2, so if you are going to try you will have to do better and faster than the existing two...
better.... and get it ready by 28th
-
Not yet claimed... but I believe two people have completed this bounty and we will be reviewing it in the next day or so for completion so we can pay out before the 28th.
better.... and get it ready by 28th
better and get it ready by tomorrow
@bytemaster:
I think pc also completed it by now, so it's three people already.
-
Yeah, i think you two were the ones considered done. I had a few little bugs to fix, but my site should be working by now and all the results are cached aswell. (I'm caching them at 3am each day) I compared all my results with brownbear and there have been no inconsitencies.
If you need a script for testing you can use this (just insert the two json codes with a= and b=):
ao = {};
bo = {};
console.log("Checking", a.balances.length, " entries in a vs", b.balances.length, "entries in b");
for(i in a.balances)
ao[a.balances[i][0]] = a.balances[i][1];
for(i in b.balances)
bo[b.balances[i][0]] = b.balances[i][1];
for(add in ao)
if(!bo[add])
console.log(add, "is missing in b");
for(add in bo)
if(!ao[add])
console.log(add, "is missing in a");
var diff = 0;
for(add in bo)
if(ao[add] && Math.abs(ao[add]-bo[add]) > 0.0001)
console.log(add, "differs. Value in a", ao[add], "- Value in b:", bo[add], diff++);
-
My project is completed. All numbers match up. BTC/PTS to AGS works. Keyhotee file can be added in webform.
After fixing a bug wrt the BTC-AGS shares my numbers now match yours - with the exception of the keyhotee file.
My solution is to simply include a dummy address in the AGS share with a balance of 10k AGS.
@bytemaster: please clarify how you want to have this handled.
More precisely: my *raw* numbers match yours, except for rounding. Your genesis balances have more than 8 decimals - apart from that our results seem to match if I use the following keyhotee founders file with your generator:
{"blocknum": 286424, "blocktime": 1392681068, "moneysupply": 10000, "balances":
[
[ "KEYHOTEE_FOUNDERS", 10000 ]
]
}
http://ptsags.quisquis.de/
http://ptsags.quisquis.de/howto.html
Good job... I am reviewing this bounty now to pay it out....
-
I moved my service to a new server:
http://178.63.85.22/
The other one was a wimpy virtual server. I'll shut it down soon.
We're gonna use this one as the jenkins build server as well.
BTC's are still parsing.
This service looks nice.
-
I have reviewed the following services:
http://parseproto.feinarbyte.de/
This service looks nice but appears to be non-functional, moving the sliders does not update the percentages and thus I lack proper control. I have disqualified it for this reason.
http://178.63.85.22/
This service by BrownBear seems to be the most user friendly and thus wins the bounty. Please provide a PTS address.
http://ptsags.quisquis.de/
This service seems to be functional and quite simple / utilitarian. Also very nice. Please provide a PTS address.
All payouts will be made prior to the snapshot. If anyone has posted any mirrors please let me know.
-
Please have another look into this, my sliders work correctly i just failed to update the displays. I can fix this in a few minutes.
I think disqualifying me for a minor display bug seems a bit harsh after the amount of work i put into this.
Edit: fixed it
-
Please have another look into this, my sliders work correctly i just failed to update the displays. I can fix this in a few minutes.
I think disqualifying me for a minor display bug seems a bit harsh after the amount of work i put into this.
Edit: fixed it
I pointed out that issue a week ago and asked you to allow numerical inputs rather than just sliders. From my perspective you admitted that the others beat you to it and I had assumed you decided to stop investing time in it.
-
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/ (http://parseproto.feinarbyte.de/)
https://github.com/DerKorb/ParseProto (https://github.com/DerKorb/ParseProto)
Can we get the ability to enter the percentages as numbers rather than just sliders? The sliders don't even provide feedback as to which percentage was chosen.
FYI... this was when I first pointed it out to you.
-
I am really sorry, that post must have slipped my attention. Disqualifying my solution looks totally understandable from that point of view. I noticed that bug the first time today.
-
I have reviewed the following services:
http://parseproto.feinarbyte.de/
This service looks nice but appears to be non-functional, moving the sliders does not update the percentages and thus I lack proper control. I have disqualified it for this reason.
http://178.63.85.22/
This service by BrownBear seems to be the most user friendly and thus wins the bounty. Please provide a PTS address.
http://ptsags.quisquis.de/
This service seems to be functional and quite simple / utilitarian. Also very nice. Please provide a PTS address.
All payouts will be made prior to the snapshot. If anyone has posted any mirrors please let me know.
We will be pointing one of our domains at this soon and will then link to it from our website.