Yes I picked up 4 of them recently and was extremely disappointed - the back of the cards heat up to the point that literally radiate heat off the back end in such amounts that it effectively cooks whatever's behind it.

I did end up getting 2 of them working allright in a board with 4x pcie - by loading them in the 1st and 4th slot... (the cpu in that one has water cooling so that's the only way I could get one to work in the top slot) when I tried single card in other systems they ended up overheating the cpu.

I also tried extending cables on one system, but I couldn't find a good configuration where the cards didn't blow too hot air onto another card... so I just gave up and sent 2 back.

At least with the reference coolers. (or iceq) they vent out the rear of the case... or in one direction. And the sapphire vapor-Xs seem to run much cooler in general and I had no problem slotting 4 of them into a system and just letting them go...

I have a few thoughts re:pricing.

What you've written above implies that you have different prices for each product / type of product. If incorrect please let me know.

In that scenario it really is in your best interests to have the price float relative to USD rate --- I'd hate to see you 'lose your shirt' during a market price crash.

That being said, you might attack the entire bitcoin fee issue as an upselling point. "If you're purchase at checkout is greater than X dollars you probably won't have to pay a bitcoin transaction fee!"

But I think the entire discussion might be moot... I assume you know that it will take some period of time to actually see any incoming tx on the block chain. (as long as 10 mins, and it would be really smart to wait longer for additional confirmations). I just don't see it working very well in an 'instant purchase' type of scenario... and that leads me directly back to keeping an account for the cx with a fiat amount and letting them fund it in whatever amounts they want to.

if it's optical it needs FCC cert re:emissions

Do yourself a massive favor and get an HIS (w/iceq) or a sapphire (w/vaporX) those gigabyte cards a craptacular re:convection off the backside.

I'm still laughing over the whole topic...

neither FCC nor UL certification is required... these things aren't broadcast devices. FCC compliance is required, but not the certification. That being said, since it's not ethernet connected it's just fine to ship these items. The only part that needs the cert is the power brick.

Assuming that sales was done through a pre-existing company who grows own silicon and they could ship *now*...

I'd take between 8 and 24 units @ 15k each

but the window is closing on this- because soooner or later BFL is going to re-open sales on rigs... and then that money's committed.

The thing is: I'm a customer - and enjoy watching josh smack down the liars and the morons. Too often people in general (and companies chasing 'customer satisfaction') resort to giving hugs and wiping various orifices of their customers with soft tissue paper.

If more of us were honest and willing to be vocal about it the world wouldn't be in nearly the state that it's in.

Keep it up Josh.

If he's every out of a job I'd hire him in a second based only on how he's abused idiots on here...

upon login a full screen pop-up where you click cancel or accept.

I couldn't say if it's scam or not - have to see if someone who's ordered gets a product actually gets one.

But I completely disagree, if they are doing this design and production where they appear to be - they need to keep their identities secret. That being said, I would like higher quality video and stable clear shots of everything (like the board) with wider angles so we can actually see something.

Please don't take this the wrong way doublec, I'm not trying to be mean or sarcastic here or anything, and do love the simplicity and elegance of your pool's website (which is the primary reason I've stuck around even when the pool has had issues or lower pps rate than other pools). But...

In traditional businesses most keep at least 3 months and 12 months of funding sitting around ready to be used... when a business struggles and has to go into credit to make payroll that's a sure sign that it's being mis-managed.

That being said:

I assume that you started out with some reserve to cover the pps payouts - and that over time that reserve has become depleted (either through growth or bad luck re:block generation). I also assume that you've been making some sort of income off the pool (otherwise why would you desire to continue at all). If both of those are correct then it comes down to mismanagement on the business side of things. Either through not taking enough control over the amount of hashing allowed at your pool (so you could keep smaller reserves) or through profit taking rather than building up your reserve as the pool hash-rate grew.

I am very sympathetic to either of these situations, it is a challenge that every business manager runs into sooner or later. The traditional ways of dealing with it are either taking a loan out to cover the operating costs needed (if you have faith in the process changes you'll make to fix it) or going out of business.

and while ~3000 btc would at current market value be a huge loan - I would consider funding your reserves. But of course, I'd have to be getting something in exchange, as well as being made aware on the entire process and how much income you're actually making or have made from the pool. If you aren't willing to disclose this information I have a couple of other ideas that we could go over on how to build up your reserve quickly (with the consent of your miners) in a fair way that I suspect most of them would be enthusiastic about.

But if the situation is different than I've described above, there's no point to you operating at a loss - just leave it as DGM and tell me to get lost.

LoL - exactly the reason to use offshore financial institutions to handle some portion of your btc <> fiat transactions. Anyone know the legallity of income earned outside of the US? My understanding of this issue says that unless you're transporting fiat into the country it wouldn't fall under income tax - but that good transported in may require you to pay tariffs on them.

Personally I like irreversibility as a feature of btc. I just think there was to be a way to do online rather than off - then once it's nailed down to take it offline via secure hardware wallets.

Interesting point, I hadn't considered this.

I would propose that in this scenario the fault is more with you using bitpay than anything else. Sounds like their service doesn't exactly fit your needs. Given the current state of services (bitpay, mtgox) - I think the most forward thinking thing here would be designing your own payment processing software to accept bitcoin as you would then have control over how it works and what features you need / want. Assuming that you could find a decent programmer to design this for you...

...the upside is, if you could manage to develop this, I bet you could resell on some basis to other people wanting to accept micro payments and thus fill a void in the market relative to what bitpay is providing (aka a vpos system where traditional merchants, rather than micro tx merchants can simply sign up and accept bitcoin). Maybe you will become the defacto 'pay with bitcoin' for micro transactions and customers could fund their accounts with you in large amount while you dole out micro payments through more traditional means to other merchants.

~

The other option would be simply using the pre-paid in higher dollar amounts, cutting bitpay out of it entirely and using your wallet software to manually cash out your bitcoins regularly. Not as attractive as it does expose you to some market risks re:exchange rate, but probably only needs minimal software design. Just a couple of scripts: 1 to generate a unique payment address for users to send btc to which is then pushed to your wallet, and another to verify that the address has been funded with correct number of btc.

Then your only issue is holding bitcoins for some period of time before selling them on an exchange somewhere.

If all that is too much trouble to setup/manage then you're back to a turnkey solution like bitpay.

Personally, I'd start with the web side accepting 5 and 10 dollar loads (or however much) and announce that you're working on an easier/better alternative... then go ahead and develop the backend software you need to do it right for your business model. Then work work work to make yourself into 'the micro payment enabling service'

~ (edited to add the following section)

The other option is to see if there's anything the dev's are willing to do relative to enabling micro-payments. This may coincide nicely with some other things that imo need to happen soon for bitcoin. The first is we need to drastically increase the amount of transactions the network is able to process per second in order to remain stable if mainstream adoption does ever occur. Having the tx rate the bankwire system is all well and good (and this is where we are now) but bitcoin is becoming more than that. Ideally I'd like to see us able to process thousands of transactions per second (visa for example does ~2000 per sec) so that growth doesn't make bitcoin unattractive.

It seems to me that one possible solution would be quite simple on the dev side of things. Just change the tx fee option to require only the data size be under a certian limit (we have this already) and that one rather than all of the output addresses receive more than 0.01 - this would allow small micro payments as long as the original address help more then whatever micro tx was being sent + 0.01btc, with the larger amount going to change address.

I agree with the the sentiment, I don't believe it's very helpful if a dozen other coins started pushing for mainstream adoption. But it could be extremely valuable re:media coverage if we could turn the focus from "is bitcoin a good idea" to "which crypto should you choose".

I don't worry so much about vendor adoption for 2 reasons. Companies like bitpay are out there growing like crazy... and if a business owner is asked by enough customers 'when are you going to accept bitcoins?' the business owner will want to start accepting them. Also I see the primary feature for vendors is 'no chargebacks' which is a huge issue for most retail businesses and seem to be an instant selling point to me.

Bitcoin has already found growth in the online services sector. Online Gambling, web hosting, etc and adoption by companies like wordpress and reddit.  So while we could as a community push for big existing companies to adopt, it seems to me that this is already happening and will continue to happen in cases where bitcoin makes sense for existing companies to use.

Eventually, someone is going to have to throw big money at some sort of hardware wallet and point of sale system to get that off the ground - if someone like a major pharmacy or chain store (7-11) were to start OTC bitcoin trades using a POS system provided by some bitcoin based company... that right there would solve all these problems.

Another potential route is to push content delivery systems (steam, origins whatever) to use bitcoin because of the drastically reduced fees... imo this is more likely the easiest route to go. Even something like zynga taking it as payment might be all it would need to everyone to start taking it.

But I think when it comes right down to it... there's nothing more important than the getting individual users to start using bitcoin (and asking the people they do business with to start accepting it also). In this vein I think it would be very interesting to see some numbers on the actual 'buying power' of bitcoin users as a whole. If we could show a vendor that basically "there's 10million geeks, potential customers who'll come look at your store / products if you accept bitcoin" that might be enough to get them to do it right there... even without some sort of POS system.

Yes. You're correct all outputs must be greater than 0.01 to and under 10k (or 1k?) to be zero fee.

So the best possible solution I see for you in this scenario is not doing a typical checkout where they fill a cart and then pay you. Instead I would suggest doing something along the lines of them funding their store account with "item packs" these item packs can be nicely sized in normal denominations ($5,$10,$20, etc). You can have the 'frugal' option be the lowest dollar amount that would get them up over 0.01 btc (right now 2 dollars).

So maybe a user is 'forced' to get a couple of extra items on your site (or save those credits for later). . . I doubt it will deter people from shopping there...

Guess I'm mining at backup pools until the pps side comes back. Always sad when a good pool can't stick to an easy to understand payment system.

A couple of things you may have overlooked.

This fee is only incurred when a transaction is over some length (someone toss out the numbers?). As I understand it the fee only occurs when you're combining multiple balances to make a larger payment into another address.

So if your customer is using multiple addresses to make up that 0.007 btc then he would be forced to pay this fee. Otherwise the fee is optional.

so I suppose in some situations the customer might be unable to send the btc to you without paying that fee... but I imagine that it would be rather rare because of the amount involved and most people are going to purchase $10 or $20 (or a couple hundred) worth of btc at a time... and miners are going to cash out of their pools in much larger amounts (imo) so likely won't be affected by this at all.

It could become a real problem at some point - but not within the next couple of years I suspect.

I'm following the logic up to the point where the hopper leaves the pool. (if the pool finds a block before he leaves everyone wins). Now assuming he's left... hash rate decreases... hopper has generated a large amount of shares...

I'm still not seeing how it decreases the chance of finding a block for the pool...  lets do some mental math here...

Assume pool hash rate is 100gh/s for non-hoppers. (average time to generate a block is ~4.5 days)
Assume that a hopper (or lots of them) bring another 10 th/s to the pool at the start of a round. (average time to find a block for hoppers if they just had a pool ~1 day)

How long are the poolhoppers likely to stay? less than 10mins on average before some pool finds a block somewhere and they all switch.

Assume 10 mins on average of hoppers mining at the pool.
Assume every hash generated was a valid share.

~

Case of average round:
Total shares for hoppers at pool over 10 mins  :     6,000,000,000 shares
Total shares for legit miners over the 4.5 days :   38,880,000,000 shares

So an average round, you have 15% of the total shares going to the hopper, and 85% of them going to the normal miners.
3.75 btc to hoppers.
21.25 btc to miners.

~

Case of extremely lucky round:
2 blocks back to back (and we'll even say 10 mins before that second block is found).

Total shares for hoppers     : 6,000,000,000 shares
Total shares for legit miners :     60,000,000 shares

so on this round the 1% of the shares are going to non-hoppers with 99% going to hoppers - who then probably stay at the pool until some other pool finds a block.
25.75 to hoppers.
0.25 btc to miners.

~

Case of extremely bad luck:

Takes 9 days to find the block.

Total shares for hoppers at pool over 10 mins  :     6,000,000,000 shares
Total shares for legit miners over the 4.5 days :   77,760,000,000 shares

7% of shares to hoppers, 93% to miners.
23.25 btc to miner
1.75 btc to hoppers

~

In the scenario of back to back blocks with a relatively long round length miners get an extremely small payment due to lack of shares. But this of a block they likely wouldn't have been able to generate so quickly without the pool hoppers hashing power.

In the average case miners lose 15% of the reward for the block to the hoppers.

In the case of bad luck the miners lose 7% of the reward to hoppers. As the round time extends the 'loss to hoppers becomes less and less.

~

Now I don't know if you noticed but these numbers are run as if the hoppers had 10 th/s. Is this realistic or is this greatly inflated? Imo it's greatly inflated since network hash rate is only ~80th/s...

My only point with all this is that it doesn't really hurt the legitimate miners in any real way, given the differences between their actually hashing and the inflated estimation of hoppers (2 orders of magnitude). Yes they lose in average round 15% of income - which they could just as well lose if the pool grows to 115gh/s --- while the pool loses the added income from more short rounds.

and if the pool hoppers are actually closer to 1% of network than 10% of network (which is what I suspect) then there's even less of an income loss for miners (1.5% and 0.7%).

So all you're really doing is limiting the potential benefits to the proportional pool of the occasional botnet or high hash rate hoppers hitting it.

Of course we can't know the actual percentage of hoppers... but it's an interesting thing to think about.

Interesting topic, I'll have to give it some deep thought.

My initial knee jerk reaction is to argue with the premise of it all being data mined... but then if we're talking about governments all they'd have to do is identify one person I've traded with and beat a user name out of them.

As far as that goes I guess I see your point. But I wonder if there isn't a solution on the block chain in the direction of more complicated and security aware wallet software that combined with single use public keys for all incoming transactions and some creative coin washing services... we could probably create a solution to this... or at the very least an obscurity that might effectively prevent the entire scenario.

would having to resort to an online solution make 'generated' coins extremely valuable... or even the tx fees paid out more valuable then the actual amount of coin?