Well, payments can still be made in BTC to each person - it's easier, publicly auditable, and I'm guessing everyone prefers BTC. What I meant is that the value of the debt should be kept in USD. (Eg: If shakaru paid 10 BTC just now, he now owes $47.50 less).

+1 for imsaguy.

BTC address for repayment: 1E269gXpDoGT5bF2NnBqFHqrq4AJ1fU9rf

The number of mining days I've lost is 85 so far, and with 10 days of my contract remaining I'm getting 600Mh/s out of 2GH. So my estimated total lost at the end of my contract is 92 days of 2 GH/s mining. (92 / 183) * 750 USD = 377 USD due.

One thing I disagree with is fixing the debt in BTC based on the current exchange rate. There are essentially two options for repayment: (1) repay the expected output of each mining contract, in which case the amount should be fixed in BTC regardless of exchange rate, or (2) refund the initial USD paid for the contract. I believe most of us have chosen (2), since it reduces shakaru's debt load at the current BTC rates. But in this case, I think we should keep the amount owed in USD, and every time some BTC is paid back, use the spot price to determine how much the debt has been reduced by. Keeping the debt in BTC is risky for shakaru if BTC rates shoot up, or vice versa if BTC crashes.

I would be fine with a refund in this manner as well, for the fraction of my contract that hasn't been fulfilled. Obviously this would have to be denominated in USD (even if paid in BTC).

Alternately, I have a python script that computes the expected BTC output between any two dates for a given GH/s. I'm happy to punch in numbers or just provide the script if we're going down that route.

Edit: SOLD!

Hello folks,

I'm selling the pictured Transcend 32GB MicroSD card. Used for 7 months on my Nexus One, worked great, don't need it any more. $25 shipped in the US, payable in BTC only (@ mtgox last). Can ship first to trusted members, or use escrow if required.

I had a 6 month 2GH/s contract starting in Aug 2011. The contract has been (and is still being) partially fulfilled. As per agreement with shakaru, I keep account of the daily shortage in hash-rate and corresponding BTC owed. As of today, I'm owed exactly 132.5 BTC and 12 days of remaining mining time.

But gpumax will only direct hashing power to "trusted" pools, if I understand correctly, making it useless for this purpose.

Peter, maybe you lost a lot of money trading. But why are you trying to cover up your tracks by deleting posts and taking down your websites? Surely you could have done this in a more graceful, transparent manner. You have always been very responsive in PMs with me before, and this new behavior does not seem fitting.

Please consider publishing a final statement of accounts for all your funds, no matter how little their balances. And please sign this statement with your PGP key (this one, for example) to prove your identity. This is the least you could do for your customers and share-holders who once trusted in you.

No, I think you misunderstood. You need to literally set HISTIGNORE='*walletpassphrase*' - don't substitute 'walletpassphrase' with your actual passphrase. Since you need to type in the word 'walletpassphrase' on the command line when supplying the passphrase to bitcoin, bash won't write that particular command to the history. I think gmaxwell's example makes it pretty clear. Thanks for the useful tip, gmaxwell!

Do you think this is better?

user's estimated DGM reward for next block * expected number of solved blocks in 24 hours based on yesterday's average pool hash rate?

Edit: Meh, I don't think this really works either, unless the cross-round leakage parameter is 1.

You can break that down as:

num_seconds_per_day = 86400.0
probability_of_a_hash_solving_a_block = 1 / (2^32 * difficulty)
btc_per_block = 50.0

So the expected btc you'll get per day = num_seconds_per_day * hash_rate * probability_of_a_hash_solving_a_block * btc_per_block.

Wait, why won't this simple formula work?

btc_per_day = 86400.0 * (hash_rate / 2^32) * (50.0 / difficulty)

Of course, it's subject to variance, but maybe the expected BTC per day is what Thiago is looking for? IMO, this would be more useful than seeing what I earned in the previous 24 hours.

That's cool. Regular status updates would help keep your customers more at ease.

Do you have an update or ETA on when all your hardware will be back online?

Inaba, do you keep records of the number of stale shares submitted as well? It would be very useful to see these figures on the block history table, for mining contract accounting purposes. Per worker stales would also be a useful stat.


You could implement something like yourbtc.net - 3% donation for "VIP membership", which pays out for blocks without waiting for 120 confirms. I'm sure some people would up their donations to get this.

This is probably because of the recent increase in the pool hash rate, so there are more people competing for the reward. We should also be solving blocks a bit faster now because of this.

Tough luck, amazingrando! Would you care to reveal the pools you were using, so that other users of those pools can be on high alert, check their payout addresses, change their passwords, etc?

goxsh is a pretty neat command line interface.

+1 m86 - I sent BTC first and promptly received a 23andme testing kit.

Man, I had no idea of this !@#$ that you guys have been going through, tough times. If you feel like running these contracts is more trouble than it's worth, I'd be open to a cancellation (or say a downgrade in hash/sec) with a pro-rated refund of the initial charges. You don't have to feel obligated to run my contract to completion if you're going to shut down operations after that anyway.

Didn't find the support address online for the last hour or so. I've already sent all the withdrawal information as two emails and a support ticket - shouldn't that be enough? If there's some information missing in there, let me know.