Clipse, are you currently working on the stats code? I am mining at bonuspool with 5GH, but the stat page displays 0GH with number of submitted shares not moving

Yes, thanks for the clarification.

I added the formula for IPO price calculation to post #2, along with some pre-IPO statement that was requested via PM.

As for PUREMINING, I also do not get why it is that much overpriced. From reading the contracts, it is just a mining bond for 1MH/s at 100%PPS (i.e. exactly what I am going to offer), yet it is traded at 60% premium. I like it as it pushes the average price up , at the same time I'm unsure if there is something I have missed. If you know more or have an explanation, I'm okay with removing PUREMINING from the price calculation formula.

Thanks. Added an initial section to second post. Please feel free to ask for further information.

--reserved--

FAQ & user requested information

---

References, Reputation and Trust
I am not social in the virtual world. That is due to the rule I am strictly following to not disclose personal information into a network that never forgets. As a consequence, there are no Facebook, G+, LinkedIn, Tweets, Blogs or whatsoever profiles I can refer to.

The trust I am going to provide to investors is based on two core aspects: first, I've got a real life that is highly dependent on my reputation and second, I am not seeking for anonymity. In fact, my nick is my real name and if you visit my research track where I worked before here, you'll find my full name. Google me, I'm unique worldwide. You'll find most entries either referring to some research papers I wrote or to Linux kernel development, for both I had to build up reputation based on a long and steady track record. That is what allows me to earn my and my family's living and even 21M+1 BTC won't tempt me to risk my real life's fundament.

In the Bitcoin community there are

• some developers who can prove I'm real (ckolivas, kano)
• some lenders who currently hold four digit amounts of my BTC liquidity (pirateat40, ineededausername, hashking)
• Matthew who took my payment for 12 issues of Bitcoin Magazine without delivering any so far
• Cablez who manufactured cables to connect my BFL Singles to a gold PSU
  
• Clipse whose BonusPool most of my rig is mining for (check my stats with my forum nick here)
• GLBSE that verified my ID and my email address

As stated above, GLBSE is not going to verify my non-existing FaceBook an LinkedIn profiles. They also won't verify my phone number (it is a VoIP based one) and my home address (Switzerland does not belong to the list of countries that are verified).

If you feel you need more information for your due-diligence, please PM me or post your request in this thread.

---

IPO price calculation
With the existence of already established mining bonds the initial price will be set to match the averaged ROI of those minus an IPO discount of 10%.

It will be calculated as follows (based on the 5Day averaged price at GLBSE):

As of time of writing (2012-05-07, 14:00): (0.625/2.1 + 1.53/5 + 0.493 + 0.336 + 0.323) / 5 * 0.9 = 0.35 * 0.9 = 0.316

---

pre-IPO sales
Investors interested in buying one or more blocks of 50 bonds before IPO please PM me.

There are no additional discounts for pre-IPO sales, the price per bond is calculated with above formula at day of sale.

---

---

Changelog
2012-05-06: added 'References, Reputation and Trust' as requested by BinaryMage
2012-05-07: added 'IPO price calculation' and 'pre-IPO sales'
2012-05-09: updated GLBSE email and home address verification

Zeta Bitcoin Mining: Perpetual mining bond, previously traded at GLBSE, ticker ZETA-MINING

---

---

News

---

2013-01-37: Done.
2012-12-04: All claimed shares bought-back; Operation closed
2012-11-25: Investors' list received from GLBSE, Payments restarting
2012-11-12: Claim Process closing, Buy Back Offer
2012-10-20: GLBSE recovery: Claim Process open
2012-10-14: recovery plans after GLBSE closing
2012-10-07: GLBSE closing down
2012-09-08: swaps for ASICMINER shares executed, bonds recalled => 4000 left outstanding
2012-08-24: voluntary offer to investors to exchange shares for physical hashing power or ASIC securities
2012-07-10: FPGA boards delivery
2012-05-28: dividend payments & upcoming expansion
2012-05-19: bail-out period ending & dividend calculation
2012-05-17: GPU deactivation & external FPGA mining contract
2012-05-14: what's next?
2012-05-13: successful IPO
2012-05-13: finalized IPO details & added projected ROI figures
2012-05-05: initial announcement

---

GLBSE recovery: Claim Process open
Please send me an e-mail to the address given in my forum profile specifying

• your GLBSE account name
• number of ZETA-MINING bonds you hold
• address where dividends should be paid to (paper wallet address or at least one you have the private key of)
• optional: e-mail address to be used to contact you for confirmation / updates (if not reply-to address)
• optional: anything you have available to prove your claims (screnshots, trade information, etc.)

---

FPGA Boards Delivery
The 50 Cairnsmore1 Quad-FPGA boards pre-ordered at Enterpoint have been delivered. The FW and bitstreams are still in development status and as a result the boards are currently rather used for testing than for mining.

When projected final performance is reached, a total of up to 30GHps will be offered to the public.

---

Dividend Payments & upcoming Expansion
Since GLBSE has no support for automated pre-scheduled dividend payments, I will process the manual payment early when I am away from keyboard at the defined payment time (Sundays at 13:00 UTC).

Expansion is on the horizon with the Quad boards' anticipated shipment within 2 weeks. 75% of the added hashing power will be offered to the public by issuance of new bonds. The bonds will be priced at market value. Investors interested in buying blocks of 50 bonds please contact me via PM.

---

Bail-out Period ending & Dividend Calculation
Dividends will be paid Sundays at 13:00 UTC, with the first payment scheduled for tomorrow May 20th. I set up a Google Docs spreadsheet for weekly dividend calculations here.

Right before the dividends are paid tomorrow, I will remove the bid wall I set up for the first post-IPO week to allow investors a bail-out at no cost. I'll be glad if you stay invested with me, but if you feel unsure, do not miss to place your sell order in time.

---

Replaced GPUs with external Mining Power
Most GPU rig that turned to operate inappropriate in my setup has been deactivated, leaving ~6GH/s (mainly in BFLS) active.

Until the FPGA Quads are delivered, the issued bonds are additionally backed by external mining power. Find it mining with 6.5+GH/s at Ozcoin's Top20 or round-share stats.

---

Coins Collected - What's next?
With the IPO capital collected, the next obvious challenge is how to re-invest in mining power extension quickly. Besides GPUs that would be available immediately but already had their times and will not be considered for expansion, today any FPGA based mining rig has a lead time of 8+ weeks. Since second hand availability is either zero or only at rip-off prices, there is no practical way for instant expansion.

I have 50 Cairnsmore1 Quad boards ordered from the first batch. Enterpoint promises to have them ready for delivery within June. If they keep up with that (or with even small delays) that is the earliest most occasion to extend FPGA based mining power. The available IPO capital will be invested fully into this order.

Until then, 750 coins are reserved to provide the bail-out bid walls in the post-IPO week and for market liquidity thereafter. The remainder of ~1500 BTC has been converted to fiat and is reserved to fund the expansion.

---

Sucessful IPO
The IPO was successful, all bonds were sold at IPO-price. Due to high demand from large scale investors 2500 additional bonds has been issued within an hour after IPO.

Thank you all for your trust and your will to invest in a long-term Bitcoin future.

I grant all investors a free bail-out period to get back your invested coins without any loss for one week after the IPO, i.e. I will keep an according bid wall active until 2012-05-20.12:00 GLBSE time.

---

IPO Details Finalization

• IPO price: 0.295 BTC
• availability: 650 bought by pre-IPO investors, available to the public at IPO: 4350

ROI projections
This is basically a do-the-math-for-you of the formula defined by Meni here, based on the IPO price of 0.295BTC and current difficulty of 1.733M:

• weekly income per bond: 86400 * 7 * 50 * 10^6 / (1733207 * 2^32) = 0.00406 BTC
• weekly ROI: 0.00406 / 0.295 = 1.38%

---

Initial Announcement

Folks,

I've been with Bitcoins for almost a year now. While finding that agglomeration of brilliant people in this community and learning so many new things is exciting, I reached a point where I am investing too much (in terms of money and time) to continue it as a hobby project. With the ups and downs (including the past numerous incidents) we had so far, I gained enough confidence that Bitcoin will survive in the long run and got motivated to extend my leisure-time involvement to a serious business.

As one core component of that business I am going to significantly increase my mining capabilities from currently 7.5GH/s to a target of at least 1% of the global hashing power by the end of 2012. Right now I am negotiating with an established FPGA-board manufacturer for a license program to be able to gradually add FPGA based hashing power at prices competitive to the current best ROI-efficient devices.

The upfront investment to produce 50+ Quad boards and add ~40GH/s with that approach is quite huge and I therefore want to spread the risk and collect some coins for investing with issuing ZETA-MINING bonds  at GLBSE. The contract is basically equivalent to existing ones (sorry gigavps and amazingrando for copy-pasting), i.e. you buy 1MH/s at 100% PPS and get paid with your portion of mined coins once a week. I'm not adding further details here, assuming all potential investors already know. Feel free to ask for additional info you would like to see as part of the contract.


Since my Zeta Bitcoin Mining business is explicitly planned for growth, I add the following statements:

1) Issued hashing power
At any time I will issue no more than 75% of the available hashing power. The remaining portion will be used to
  a) cover operational costs
  b) provide liquidity to the secondary market
  c) fund expansion
  d) cover operation risks (e.g. downtime)

2) Growth
All coins collected by issuing bonds are invested 100% in growth, i.e. used to buy more mining equipment.

3) Sustainability
Long term competitive operation is assured by minimizing operating costs. ROI calculations for new equipment are performed for an operating time of 18 months and assure  to remain competitive with latest generation devices.

4) Operational costs
Initially the operational costs are limited to the electricity that I am going to pay out of my pocket and from my portion of the coins mined. As soon as upon growth infrastructural investments become required, bond holders will have to vote whether to accept fees to be deducted from their dividends.

5) Liquidity provision
I will provide liquidity to the secondary market to some extent by placing ask and bid walls at each side of the averaged trading price. This is not to drive the market but to increase investors' confidence in the bond by assuring they can bail out for a reasonable price.


IPO details

• date: May 13th 2012
• bonds to be issued: 5000 representing 5GH/s
• price: cut-off will be set at IPO day at (5-day 1MH/s average of other mining bonds) - 10% discount

That's for the details. Apologize if I forgot some important points, but I'm learning (how often do you sell your securities outside the Bitcoin world ) and will add them incrementally.


Thanks for your interest,
zefir

I guess he meant the number of PCIe6 connectors per PSU is limited, i.e. a somewhat standard one has maybe 1-2*PCIe6 but 8*Peripheral. You'd need to split the PCIe to power up to 4 Quads.

Thanks. But after this didn't help I looked deeper and it was something completely different. In short, do: to get rid of that component that kicks in after boot and interferes with cgminer.

If you mean my setup, no. It's one cgminer instance operating 5 BFL Singles (plus 3 GPUs) with 4 of them running full speed at ~815 with no throttling and the problematic one at ~715 on average, no matter how I try to add external cooling. I'd assume the conductivity from chips to heatsink is problematic, but I'm not going to dismantle it and void warranty unless someone experienced that you can recover a throttling one by e.g. re-applying thermal grease. The heatsink is tightly fixed, BTW.

If you put the irony out of your post and seriously state that you provide some kind of insurance, that would change something. Otherwise 20% MPR uninsured does not sound better than 18% MPR 25% insured (PPT.C bought at 1.1).

I have some coins with established lenders and while it is true there is a potential MPR of 56% (1.5% daily), I'm fine with getting up to 15% guaranteed. If you offer 20% insured, hurry up and get some larger wallet to accommodate my coins.

I see. But in the log I posted above there was obviously no attempt to get work from the secondary pool for 40s, even it was evident that main pool is inactive.

Anyhow, as you said, it's a pool issue and not up to cgminer to handle it. Thanks.

Would it be too aggressive towards pools to request more work than you actually work on? My layman approach would be: I know I have e.g. 4GH power and will need new work once a second. As soon as work is given to a device, immediately ask primary pool for more (instead of waiting for a device to do so) and if that one does not respond within 600ms, ask backup pool(s). The cost for such an pro-active approach would be that you ask for more work than you can handle, but you would not have to wait that long to see some pool is dead.

As for my cgminer version: you're just too fast/active , it is from 24h ago and includes the pool scheduling improvements you added for 2.4.0. Can't catch up pulling with the speed of improvements you add.

Con, as you read in Clipse's thread, there are still problems with cgminer operating at bonuspool.

I don't understand how the pool scheduling works, but reviewing my log-files I noticed some issue:

I see that connection got lost to bonuspool initially at 06:41:35, but the switch to the backup poo happens almost 40s later with GPUs and BFLs idling in between. This happens continuously and causes total hash-rate to be 20% worse with bonuspool than e.g. ABCpool. I was assuming that the pool scheduling assures that there is always some work available, i.e. it is pre-fetched and ready when a device needs fresh work.

Is this a bug or a feature? If it's a bug, would a more verbose log help you to isolate the problem? (cgminer is latest GIT source, BTW).

My throttling device's front LED toggles for around two seconds every 3 minutes or so. Whether this is the down-clock phase or the time where it stops mining I don't know, but from the effective hashrate it is more the down-clock (2/180 idle cycle time won't make up for the 15% hashrate drop I have).

My attempts to circumvent throttling have been futile so far. Along with the suggestions made by other users in this thread I let it mine outside over night at < 14°C. No matter what, the 12h+ average comes down to ~715MH/s. I'm therefore pretty sure something went wrong when the heatpipe was mounted (the other 4 devices are always at ~815, no matter what). Look at the ztex thread: people are achieving significant speed improvements with different thermal grease / heatsinks combinations or the process how they are applied. Since no one tried that for BFL Singles so far, I'm not going to brick mine trying. I'll wait for EasyMiner and if that's not fixing it, mine goes back to BFL (it is at < 832MH/s - 10%).

Sh*t, spent half a day finding that out last week and didn't post (thought its my messed up Ubuntu 11.04 installation and didn't want to spam the thread). I appended
to /etc/modules to be handled correctly at module loading time.

Now that you have some FPGA boards to play, you maybe came along the problem that they are not detected after a reboot when cgminer is executed from the autostart section. Every now and then I see that only some of the attached 5 BFLs are running after a machine restart, but work all when I manually restart cgminer. I guessed the USB initialization is not fully done yet when cgminer is started and added some additional delay of 30s before it is executed - but still some Singles are missing.

Is there some event that all USB initializations have been processed in Linux to check before cgminer is started? Other than grep-ing dmesg for ttyUSBx ?

As reported in another thread, the latest GIT updates improved cgminer performance with Clipse's bonuspool noticeably. With 2.3.6 my router had hundreds of active connections to the pools, now there are max. 20.

If you're mining with bonuspool, you should try and build cgminer from latest GIT sources.

This might be pure coincidence with the efforts you are currently making to stabilize your pool, but with a cgminer build from latest GIT I have a noticeably better experience.

With the previous cgminer-2.3.6 my miner was falling back to the secondary pool most of the time during last few days. Plus I noticed that my router reported hundreds of active connections to the pools. With the latest updates Con added (reuse of existing connections, network scheduling improvements) that number came down to like a dozen and I'm back at your pool more reliably.

You'll need to pull the latest updates from today and build cgminer for yourself, or wait for 2.3.7.

I already tried dismantling the case of the throttling one along with what was suggested by the other users. Nothing did really help, i.e. the time between the start of mining and first throttling varies with the attempts, but once it starts it does it with same frequency, resulting in a long-term hashrate of 710-730MH/s.

The best I got so far was a result of pure monkey testing: I turned the upper fan and put it back into the housing. Instead of blowing out the heat-pipe's hot air to the top, it now sucks the fresh air from there and pushes it through the heat-pipe and the VRMs to the side exhausts. It's just a trial-and-error result and people familiar with thermal design might argue this is stupid, but it works for me.

Received, Thanks.

Im not into #bitcoin-otc and can't increase your rating there, sorry.

Thats at least some helpful information.

To understand the SW side it would have been more interesting to know what exactly happens during throttling, i.e. does it just stop hashing but remains accessible (e.g. for temperature readout), or is it completely gone during that phase. Never mind, it will take me some time but I'll find out myself.

As for EasyMiner, I'd like to try the demo version you mentioned above to have it as reference, if possible.

Thanks.