Topic: [Group Buy]12 KNCminer Jupiter's 15 Sold [Closed] Jupiter Pool - page 7. (Read 75591 times)

I don't recall any major incoming transactions other than mining.  There were some that were small like .01 or something, but that's negligible.  When we decided to look at the blockchain incoming BTC, Larry reaffirmed that the only incoming transactions were from mining.

Hi agibby,

Since you helped to check the books, can you confirm that "mining income" indicated in the balance sheet is the income of the actual mining and does not include other incoming transactions?


Thanks

I had nothing to do with creating the "KNC Balance Sheet" spreadsheet.  I also had nothing to do with discovering/calculating the price adjustments, hosting penalties, etc.  At this point, I don't know how to answer your question.

Just guessing... could some of the 2.4325 gone to the hosting payment? 

I think Larry would need to chime in on this one...

I ask this again, and now more specific to one participant (it's me):
These are my transactions on the last sheet, that horrid mess on Ledger Jan 20/14:


There is no prorated share price adjustment transaction. Many other participants do have one.

Now have a look at the tab Updated Balance Sheet in the excel sheet KNC Balance sheet. Search my name, Turas and go to column O, prorated. I see an amount of 2.43256 BTC, being the compensation you calculated for me.
If I calculate the compensation, I get this: share price I paid(2.25) -/- the Cost per share(2.159223) * number of shares(25): 25 * (2.25-2.159223) = 2.2694. The compensation you calculated and the one I just specified differ.
1. Can you explain the difference ?
2. Can you show me the transaction in which you refund me the compensation you calculated ?
Thanks.

For example, the user's per share amount received would be lower if they had a hosting payment penalty.

Another example would be someone who took a loan out from Larry.  They wouldn't get dividend payments until their shares generated enough mining to exceed the loan amount.  Example in ledger: 1LUxZq3iEX3U5mSS7Te6XWGkjzffgbdwtS

Another example is a case where someone prepaid hosting and then received a refund from paying too much.  Their payouts per share would be higher. Example in the ledger: 1LocAtpDxpuc2YBmuHHwBGvSHgmVy5C54C

Please let me know if I need to be more clear.  Some people have multiple adjustments which really confuses things.



To clarify the ledger spreadsheet: each positive entry for each user is what needs to be paid out to them.  Each negative entry is the amount that was paid out.  After each dividend payment, the sums should all zero out.  If they're not zero, then there was some issue OR the person owes Larry (in which the mining income goes from their account to Larry on every payout).  Negative would be overpaid. Positive would be underpaid.  When we run the software, the ledger spits out positive balances for each address and will be their next dividend payment.  Then we issue the payment, collect the transaction id and plug it in again.  This run will show all 0s as the dividend payment just balanced their accounts.

There could be some instances where the user's balance is 0 (which is what it should be), but there was some bookkeeping error where credits to their account weren't showing up.  If you look at the ledger for your account and think something is off, by all means let us know ASAP.  A cursory overview by myself and Larry turned up some problems but I think we solved them all. 

Is this still the case for new dividend payments ?
Can you please explain this in detail ?
Are there still adjustments being made ?

One of your previous questions was the start date of mining, and could I verify.




In the very same post, when answering the question about how many coins have been mined at Gigapool, you write:



Here are Gigapool payouts   https://blockchain.info/address/1MuU5PysvNHiKxeFz9zBAqJcuNpuqDvuDt?offset=50&filter=0  use Ctl F to find  1EN3EqqQfqq484WNATFAMA13VXpJuJNv5c

That is all I can verify because www.mineb.tc is no longer available



BTW, regarding your statement

agibby has responded, I can ask the others to verify but understand if they do not want to reply

"price paid out per share" should have nothing to do with each member's "adjustments" due to loans, penalties, etc.
Dividend per share and "price paid out per share" is equal for each member of this GB. We need to be shown calculation on what dividend per share is and a separate calculation on how adjustment for each user is done.

It's just this simple.

Not if you understand that each person has a different situation depending on the adjustments they received.  You can be paid appropriately depending on adjustments but that per share amount would be different than someone who had no adjustments.

Hi agibby5,

Thank you for the feedback and for assisting this GB. I don't know if Soniq is paying you for clarifying the books (it is his duty to keep accurate and clear books) or you are just helping out, but thank you anyway.


We expect that all (not "most") members are paid appropriately. We have requested soniq to fix the calculations and publish the result so it can be verified.
As for now, there is still information missing and it's quite impossible for us to verify. Requested information has not been given.


This statement is in contradiction with previous note that "most members are being paid appropriately".


Has soniq indicate who "someone" will be and by when this will be done?

I have proposed that this operation is "outsources"; Tyrion70 has agreed he can do it, but soniq refused.
What is the plan?

I am sorry to say, it is a shame that the miners are almost reaching end of life and soniq is still trying to figure out a good way to calculate and pay dividends. 7 months have passed since this GB has been initiated.

Nevertheless, there is still time to get things fixed. But the willingness and commitment must be there.

Thank you

soniq requested I disclose that I helped him separate the GB addresses from his payment addresses in the bitcoin-qt client, go through the books and verify people's payouts are accurate, get the software from espen running to issue dividends in espen's absence, generate the bitcoin sendmany command to issue the last dividend, and generate a balance sheet including the mining income, expenses, and payouts to members. I'm pretty confident that most members are being paid appropriately.  The ones that have contacted us to look at it have been accurate for their situation.

There was one member severely overpaid because at one point soniq issued the exact same sendmany two payouts in a row... the first one had a large payout to bring him up to date and the second one had a matching payout which send him into being overpaid.  There aren't any on the list that are underpaid keeping in mind that a payout isn't triggered until the amount is .01 or more.

I think a good way to look at it is to get the total paid out so far, remove soniq's 2% commissions and divide it by the number of shares: ( 1029.83732157 - 26 )  / 780 = 1.286970925.  That's a rough estimate of what each share should have paid out to date.  However, there are numerous reasons why this wouldn't be accurate (share price adjustments, per member hosting payment adjustments, loans).  What I was surprised about is that the price paid out per share is different almost to each user and that makes calculating accuracy difficult.  Someone would have to go into each user and calculate the payouts per share and determine the reason for the variance (usually one or more of the reasons above).  



I think the reason why soniq is reluctant to change this style of reporting is that it's generated by espen's software which divides up the BTC amount and spits out the bitcoin sendmany command.  I think it's a little late in the game to stop using this software for calculations and reporting.  It's been used several times in the past and was the replacement for using Silfax's automated disbursement software which caused some problems with members not being paid correctly...through confusion of how to use the software or an actual bug (I think it's the former).  I've verified that espen's software is doing the right thing and have even made some tweaks and fixes to it.  The reason why we can't just divide the mining income by the number of shares is that there are adjustments that need to be made in order to bring everyone's cumulative payouts into balance.

Hi Soniq,

It is very unfortunate that your long reply has in fact not provided any additional data or any additional clarity on the books.

We got your message about the Norwegian police forensic expert, 2 software engineers and 100+ GB members verifying your transactions, but these statements are less convincing until clear and accurate data is available and posted here.

Such statements, not backed up by transparency and clear and accurate data, are raising doubts that something is hiding.


I have asked one simple question that will allow me to continue with verifying the books: "amount of bitcoin mined at Gigapool"
You have failed to provide an answer.

It is really unfortunate that, beside noticing lack of interest in managing this GB properly, we have to start questioning your honesty.


In the very same post, when answering the question about how many coins have been mined at Gigapool, you write:


Now, please let us know have the transaction been published and indicated in the balance sheet or you are still looking for these transactions now?
Please post them when you find them.

I have more questions, but let's take it step by step. Wit too many questions at once we may fail to clarify any.



BTW, regarding your statement
can you confirm if these people have verified the data you have shared with the GB members or perhaps there is some additional unpublished data they have verified.
Please also confirm their forums name or identities so we can verify with them, and please publish their reports and findings. I'm sure this with give you and us peace of mind.

And how do I see the number of BTC mined on bitminter ?
You can see them, go to My account, Transaction history and at the bottom get the monthly summary of mining income. Click on refresh after each change of the drop down box choices. Export them and collect them in a spreadsheet.

This spreadsheet is a mess, specially the Ledger Jan 20/14.
Stop using it and make use of the much simpler one I created for new dividend payments.

I urge those GB members to speak up and confirm this.

I will read your reply a few more times, but the first thing I notice is that you didn't answer my question about the refund for the price difference that is missing for some of the participants.

http://imgur.com/Ku1AYnN 

screenshot of portal access

In regards to all the other questions

I received access to KNC portal on Oct 09, I will upload a screenshot of the email later. This GB has over a 100+ different members in just about every time zone in the world. I was being examined very closely at the very beginning when KNC delivered the miners.

 Here is the history of Skype chat the minute the email from KNC arrived

[10/9/2013 9:05:03 AM] guess the eamil from KnC was premature, as no email to signal the start of mining or access to panel
[10/9/2013 9:05:24 AM] Joseph Thoenissen: https://portal.kncminer.com/
[10/9/2013 9:06:09 AM] Larry/soniq: thats good news, see if i can login with my KnC user

Also allowed a member of GB temp access to portal to confirm number of miners and to confirm technical issues that KNC was having. These issues were not unique to me as lots of KNC customers were posting in KNC forum about same issues.

The Skype chat was very active and everyone  on there knew to the minute almost when I received portal access, which was Oct 09.  And as this post suggests Jupiters  didnt reach  full mining capacity till Oct 11. https://www.kncminer.com/news/news-49

That is why I created this spreadsheet  https://docs.google.com/spreadsheet/ccc?key=0AtH6ASvoAExHdF9IcFh3QmQ2dEt4Zk5qT3lRUDFDTVE&usp=drive_web&pli=1#gid=24   This spreadsheet was created by me and and member of this group buy.  And the dates on the spreadsheet correspond to to portal access and full hashing rates attained.

As far as miner transparency you can go this address http://eligius.st/~wizkid057/newstats/userstats.php/1EN3EqqQfqq484WNATFAMA13VXpJuJNv5c  and if you scroll across the top it shows you each individual miner, their individual stats and here  https://bitminter.com/livestats/big  user soniq (their are no individual stats at Bitminter, but you can divide total hashrate there by 500 and will give you number of Jupiters) and the total miners is always 26 miners. Sometime the ratio has changed over the life of the GB, ie  13 at Eligius, 13 at Bitminter or 15 at Eligius and 11 at Bitminter.  Again these stats are available 24/7 for the life of the GB and I have over 100+ members in every time zone in the world watching at all times.  I dont know how it can be any more transparent than that?

Please take in account that the Jupiters do lose a chip or go down completely temporarily effecting the total hashing rate. KNC response times to these hardware issues varies.  

As far as you question about gigapool, at the beginning of the GB, Oct 14 only 5 days after receiving the Jupiters almost every GB member was watching very intently as there had not even been a dividend payment made yet. There was concerns about getting best hashing rate for the Jupiters and some members suggested trying different pools.  I tested Gigapool, and  posted to the forum I was doing so, So all the members could account for the 26 mining Jupiters.  I am looking for the transactions now.

Skype chat history regarding Gigapool

[10/13/2013 11:07:26 PM] Larry/soniq: https://mineb.tc/  have two Jupiters here
[10/13/2013 11:07:38 PM] Larry/soniq: no public access how ever
[10/13/2013 11:08:09 PM | Edited 11:08:26 PM] Larry/soniq: got them moved before portal collasped
[10/13/2013 11:08:45 PM] Larry/soniq: got to get sleep
[10/13/2013 11:08:55 PM] Larry/soniq: cat typoe
[10/13/2013 11:09:10 PM] Joseph Thoenissen: sweet dreams
[10/13/2013 11:09:15 PM] Larry/soniq: 996.31Gh/s
[10/13/2013 11:09:25 PM] Larry/soniq: for two Jupiters at other pool
[10/13/2013 11:11:55 PM] Larry/soniq: all miners at Eligius working at <100 GH/s

So after over 100+ members watching mining for over 4 months there has not been one instance of anyone asking where are all the miners?

The spreadsheets and ledgers for this GB  have been verified by a forensic scientist with the Norwegian police and two software engineers. All of which are members of the GB as well.  If there were any discrepancies, they would have been the first to blow the whistle and ask questions about what was going on.  I realize there is a ton of data, and takes a long time to go through it all. But me and three other GB members have spent weeks of time and thousands of dollars to make sure everything balances.

There is one member who had been overpaid, but there are still more dividends to be paid and it should balance by the end of the GB if no other dividends are issued to that member.

Another thing I made a point of, is hiring GB members to do any work I needed  for more transparency. Automated payment software,  software to calculate the JSON files and separating and balancing the wallets.  Has all been done by GB members.


So this is the information that is public

- number of Jupiters with trans ids
- amount per share and a debited or credited amount to each member
- a balanced spreadsheet showing all mining income and expenses
- ledger showing all dividend payments to all members
- Jupiters mining addresses with stats

Again I have hired  GB members to verify all this information and is available to the public  so they can verify as well.

Soniq in Skype: "I am creating a long psot to all you questions, it will be done shortly"

Soniq, are your not reading the messages posted on this forum or you have just decided to ignore all of us?