Thanks for quickly sorting the September payments and hopefully all fixed
for the future. Just for completeness I had a look back a couple of months:
For August, the 2016-08 data follows exactly the same pattern as September
(although the 1st group of 100 payments were split 10:90 or so, and
Hi, thanks for finding the problems and pursuing them!
Dňa streda, 19. októbra 2016 21:46:32 UTC+2 Cebderby napísal(-a):
>
> A quick update: just looked at the positions of the missing ones in the
> list of getPayments entries, and they aren't random after all, looks like
> entries 101, 151,
Yes we found an algorithm bug we had problem with transactions we paid
addPayments(0, 100); +
addPayments(101, 150); +
addPayments(151, 200); +
addPayments(201, 250); +
addPayments(251, 300); +
addPayments(301, 350); +
addPayments(351, 400); +
addPayments(401, 450); +
addPayments(451, 500); +
A quick update: just looked at the positions of the missing ones in the
list of getPayments entries, and they aren't random after all, looks like
entries 101, 151, 201, 251, 301, 351, 401, 451, 501, 551, 601. (But the
51st looks ok...)
Cebderby
On Tuesday, 18 October 2016 17:35:22 UTC+1,
Thanks for your reply Victor,
I did a comparison of the user totals from the 'getPayments' data at the
end of the json reports file
with the totals paid in the 12 transaction files, so those very tiny
(<0.0001 BTC) amounts were
already disregarded; I assumed they weren't paid so it's great if
Hi,
1. Download page is fixed and now returns proper json to downoad (error was
related that this is not an html page).
2. You are right, we don't pay to invalid address (I believe we contacted
the person to change it) and we can't pay small payments cause the payment
system doesn't allow.
We
