For small amounts (less than a few BTC) nothing changes much. For higher amounts, you will add a lot more hashing power if you deposit for ASICs than depositing in current technology. This may change the speed at which you will get your rewards. It will start later, but it will end sooner.


True, and as I stated a few rows above, for small amounts there will be not much difference and it's possible to invest with FPGAs, when ASICs will be deployed, you will benefit too. But if you are going to invest, let's say 100 BTC, it's better to wait depositing or depositing using ASICs. The current promotion (on which I will deposit 50% of the deposited amount, if > 10BTC) makes it worth to invest now instead to wait for ASICs to be ready.


After November, the only meaning you have to invest in ASIC instead of waiting for them to be ready is that deposits will be fulfilled in "first come, first served". If there will be much more deposits than available hardware (first batch), only the first ones will become active, others will have to wait for further batches.

Hope it's clear now... if you have any other question, just ask.

I apologize for the late answer, I have been out during the weekend. It seems that bitcoind crashed and caused these problems. Now everything is fixed and working as usual. All deposits seems to be credited correctly now.

If there are any other missed deposit transaction, please report it to me, including the TXID, through a PM. If you aren't registered on this forum, an email ( info@pyramining.com ) will do.

You're missing the 0.5% transaction fee, that helps me cover administration costs. It's explained in the F.A.Q.

I apologize if I didn't understand the question correctly. The interval is almost random: each time Pyramining receives a payment from one of its pools, and the transaction is confirmed, the amount becomes available for distribution. The distribution procedure is launched hourly, and it kicks in if there are any credits available.

It has already been explaned several times, and it's also written inside the FAQ. Payouts are automatically made each time your balance reaches 1.00502512 BTC (subtracting 0.5% fee = 1 BTC). If it's the last payment (example: it remains 1.83 BTC to complete the account), payment will be delayed until the full amount is reached.

Not that much, it's about 6kW in total, it keeps the room warm during winter! :-)

Write me a PM with the account label, and I will see why the deposit isn't recognized as ASIC.

I thought about the plan to support ASIC deposits and Pyramining in general. Instead of just giving a bigger starting bonus to ASIC deposits or create my accounts under random existing accounts, I am planning to do the following:

For accounts that have a sum of ASIC deposits of at least 10 BTC, deposited before 30th November 2012, I will create an account using them as sponsor and deposit 50% of the ASIC deposits amount in it, up to a total of at least 2000 BTC (coming from my personal funds). If the total amount to deposit will be bigger than 2000 BTC, deposits will be scaled down proportionally.

The budget of 2000 BTC is guaranteed, but it may increase.

This opportunity is valid also for existing deposits.

I set a threshold to 10 BTC because it would take a lot of time to create accounts and deposit 0.005 BTC for hundred deposits of 0.01 BTC. :-) I hope you also agree that it's reasonable.

If you already deposited under 10 BTC and you want to take this opportunity, you can make another deposit on the same account in  order to reach a total of at least 10 BTC.

Advantages:
- Overall hashing power is increased, old FPGA accounts will not be a "burden", to the advantage of everyone.
- ASIC early adopters will get 5% bonus increase for my referral / deposit.
- ASIC early adopters will have a faster ROI (speedup due to 15% of my mined BTC going to the sponsor).
- I will get this investment back together with you.

It has been already explained, if you invest normally, you add _now_ fpga power and you start earning mined bitcoin. If you wait for ASICs to be ready, or invest an amount with the format x.xxxx1111, you will add ASIC power.

Of course when ASICs will be put into production, all new investments will be made with ASICs.

All accounts will benefit from ASIC infrastructure when it will be operative.

Old deposits won't slow down ASIC revenues by much, since I expect that when ASIC will be installed FPGA hashing power will represent less than 10% of the ASIC hashing power and our infrastructure costs less than 90% of competitors one, making Pyramining the best choice anyway. In the case that after some days (let's say 10) from the ASIC installation deposits won't reach at least 10 times the FPGA hashing power, I will personally invest the difference making deposits to random sponsors in Pyramining, to speed up things.

I'm still working on this, but actually the priority is on ASIC development.

Actually P2Pool performances with FPGA units is quite poor due to high stale rate. I have a small % of miners pointed there, but the most part is elsewhere. Moreover, altchains have a really low value, so low that I don't think that merged-mining makes such a difference, it doesn't pay even the cost of setting up and testing the software. However I accept advices, if my opinion on merged mining is wrong.

The payout would be sent as soon as the sum of all pending rewards (of all the deposits) reaches 1BTC. If the total rewards including bonus are < 2BTC, then you would get only one payout when the reward is complete.

Since I don't know when BFL releases, I can't say if we will come out before or after. And your question has not much sense: of course we will try to be ready as fast as possible. As I already stated, our units will be ready between december and january. Difficulty will rise so fast and there are so many pre-orders out there that when ASICs will become available, nobody will get "huge profits". Of course the first ones will have a slightly higher profit at first, but it will be for a short time and I don't think it will be that great.

Web service restored, blockchain data backed up. :-)

On other machines it runs correctly, but they handle a lot less addresses/transactions, and yes, I tried to download the blockchain from scratch, but the issue appeared again.

Of course. Database and wallet.dat are exported and backed up hourly, keeping several copies (several > 50). Whole server is backed up daily. Sources are managed with GIT on a private repository. The repository is backed up on a daily basis too. The only thing I didn't spend much time on was backing up reliably the blockchain because it can be downloaded anytime. However I see it's taking a lot of time, so I am planning reliable backups of it, too.

I already reported the problem on the 0.7.1 thread ( here ). I did the upgrade with confidence because I never experienced any problems in doing it until now. Next time I will do several tests before upgrading again. Also I am going to take a backup of the sane blockchain after it finishes to download it again, so should it happen again for any reason, I will not need to download it entirely.

Currently, backups of the blockchain have been done without stopping the bitcoind process and it seems that it leads to integrity problems. The problem doesn't apply to the wallet.dat because I export it with the dedicated command before backing it up.

I am experiencing some problems after upgrading from 0.6.3 to 0.7.1 on the bitcoind that I use to process pyramining deposits and payouts. It is running on Linux (OpenSuSE 11.2).

My upgrade procedure:
- stopped 0.6.3 bitcoind
- replaced binaries with 0.7.1 ones
- started 0.7.1 bitcoind

At first, I had to download again all the blockchain because for some reason it was displaying the message "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.", and I didn't find out how to repair it.

After the blockchain has been downloaded, it started working as expected, but after about 20 hours, I found it hung up and unresponsive. No way to stop it or kill it, even with -9.

After a reboot it started and worked well for a couple of hours, then the same trouble appeared again.

Environment:
ATOM D2500 dual core (64bit arch), 4GB/ram, 60Gb SSD, 100mbit/s ip connectivity, OpenSuSE Linux 12.1.
wallet.dat is around 200MB in size.

Behaviour: after working normally for few hours, it freezes. Debug log displays RPC commands, but they never return any result.

I am currently downgrading to 0.6.3, I will keep an eye open to see if the issue disappears using this version.

I expect that the issue will be solved in a few hours. On other computers bitcoind 0.7.1 is running smoothly so I am afraid that this problem depends on the huge wallet.dat (~200MB).

Of course if this problem goes away with the previous release, I will write to the developers in order to let them know about this trouble.

I am afraid I have to restore the previous version, 0.7.1 is not stable enough. I have to keep the site offline a bit more.