Thanks for the info. If a source within the EU for simple (to the tune of 1 BTC) ASIC devices existed, so I wouldn't have to explain to customs officials what an ASIC is (or worse, what Bitcoin is and why they cannot have an invoice, or why the value is denoted in a currency which changes in value over 10% per day), I would be interested. :)

Would be interested in shipping cost estimates to Estonia.

Hmm. Whatever it was, it was temporary. At some point, I briefly managed to establish a GetWork connection, and now I seem to have obtained a (so far) stable Stratum connection... all OK here.

Has anyone experienced recent difficulties with connecting to stratum.mining.eligius.st?

I have full internet connectivity as far as I know and can test...

...yet mining stopped about 3 hours ago, and netcat (upon trying "nc -v -v stratum.mining.eligius.st 3334") tells the following:

For me, it was not a race to get a refund.

My logic was simple: I did not dare to place my order before I has ascertained that BFL could *manufacture* ASIC miners. Having that confirmed via LukeJr in the beginning of April, I placed an order... not a big one though.

Next I hoped that Butterfly Labs could start delivering products (including the Little Single, which I happened to order) in appreciable volume before I would exit PayPal's 45-day buyer protection envelope.

Unfortunately, tough luck, that didn't happen... thus on day 43 I notified BFL that unfortunately, I would have to cancel my order, and notified PayPal (by opening a dispute) that I was asking for a refund from the merchant due to non-delivery. Some 4 days later, BFL issued a refund and an additional 5 days later, my bank credited the approximate sum (plus/minus transaction and currency conversion fees) back to my account.

Issue resolved. Unfortunately, this avenue for obtaining ASIC hardware didn't work for me. I keep mining with my GPUs and will explore other options.

Confirmation process worked fine here, and on a fairly unusual browser (Mozilla Seamonkey 2.17). No script blocking tools installed.

Not yet, but maybe in future. :)

I would go for: produce solar power -> mine bitcoins when batteries are full -> warm up water with waste heat -> heat rooms with leftovers from that (dump outdoors in summer).

As far as I understand, the scenario to be feared would happen, if the following chain of events happened:

1. bitcoin value can be foreseen to increase vastly
2. holding bitcoin is foreseeably more profitable than spending bitcoin
3. a point is reached where creation of new bitcoins has almost stopped
4. additionally, a point is reached where few transactions occur with bitcoins (holding is profitable, after all, so everyone expects their money's value to increase)
5. transaction fees are not sufficient for miners to make a profit
6. miners start requiring higher transaction fees
7. transactions become more expensive to make
8. fewer transactions are made
9. miners start leaving
10. with less miners, there is less security (easier to mount attacks)
11. attacks start succeeding

...and at this point, either value drops and it becomes reasonable to circulate bitcoin instead of holding it, or attacks succeed to such a degree that confidence in the Bitcoin system is lost.

In an ideal world, people realize the possibility of such a chain of events, and avoid holding unreasonably large amounts of non-circulating BTC. Circulating BTC is not harmful to network health, as it can be "taxed" by transaction fees and offers incentive for miners to secure the block chain. If the block chain is sufficiently secured, attacks will not sufficiently succeed, and confidence in the system is not lost.

P.S. As a sidenote, some bitcoin clones are trying to rule out the possibility of runaway deflation by implementing a demurrage fee (all holdings gradually leak away to miners, approximating inflation at a controlled rate). I actually consider this a safer bet than Satoshi's, but unfortunately the only credible project trying to do this (freicoin) is operated by a foundation which wants to control and distribute 80% of the initial money supply, and as an opponent of planned economy, I will keep my distance from their project until they've successfully done this or finished trying.

Nope. Unfortunately I didn't know about it yesterday, and besides, this particular mining rig will have to host other applications too, so perhaps a standard Debian is better for it too.

Thanks for pointing it out, however -- on the next machine which is basically nothing but a PSU, mainboard and 5850 GPU (once I get a spare 5850), I'll definitely try this approach, a bootable USB stick sounds like a sensible way to reduce power consumption. :)

Got my first Debian Linux (squeeze) based rig online and working, so I have a completely Microsoft-free system now. :)

Materials I found helpful:
- the starting post of this thread
- this post: https://bitcointalk.org/index.php?topic=3359.msg47174#msg47174

The hardest part for me personally, as it was mostly undocumented, was understanding that I need to start "cgminer" as a regular user (not root) and issue the commands from a local X session (not SSH).

Before that, I was vainly trying to understand why the following error occurred:


As soon as I changed to user instead of root, and local console instead of SSH, all the things which should have, started working.

If I were them, then from the viewpoint of ("need to meet a hash rate target by any means available") I would choose to ship extra single-chip boards. Re-designing is a burdensome process with no guarantee of timely success.

You can view the hashing progress of any miner in the Eligius mining pool, including that device. And provided that wizkid's statistics don't lie (they certainly don't lie about my own 5850 working at 340 Mhash/s)...

...then Luke-Jr's ASIC been working at a steady 25 GHash/s speed for 2 days now. The stats are public:

http://eligius.st/~wizkid057/newstats/userstats.php/1CdcYVP4T4hjHwt353pEnGHrigeDLvuvZL


...as for all the other issues, I would also like to know more about how things are going, and I understand that waiting for half a year to reach this point must be quite frustrating.

When placing bets for money rather than mere fun, I would like people to be especially careful about the conditions they formulate. There is a fine but very real difference between "yes", "no" and "syntax error".

In this case, the title of the bet and the content of the bet resolve to different outcomes. No instructions, knowable to participants at the time of placing their bets, have been provided regarding what should be done in this case.

This leaves room for creative interpretation, which in my opinion, should disqualify the bet itself. I think "draw" is a reasonable decision, just like "when in doubt, do no harm" is a reasonable principle.

Then we have approximately the same plan. I was likewise holding off until proof of something that works, and entered the queue yesterday, having seen Luke-Jr's testing report (I trust him enough to mine on his pool for a while already, so I might as well trust data he posted).

This is not my only recourse, though. Adding a 7970 too, in case of delays or inconveniences.

Heh, I just realized that and came back to say that all was indeed OK -- it showed the confirm button when I loaded the site from the link received in e-mail when the time the transaction started.

I was used to the old system (my last trades on Bitmarket before the current one were in September), where the "Send BTC" button would be always visible.

(So I sent an e-mail saying that all was OK to the buyer and the administrator too. Sorry for any hassle. I hurried because the downtime delayed me somewhat and forgot about the link in e-mail. :) )

For me, the situation is a bit different, but the cause is probably the same.

I have a transaction which I'm supposed to confirm, having received the wire transfer, but the "confirm" button is not available, only the "cancel" button.

I also notice that the fee percentage has been changed multiple times, at first it was 0.25%, at the moment it appears to be 0.4%. Perhaps this is the reason? (Fee percentage was raised while transaction was pending?) Specifically regarding the fee percentage, I think it would be better to confirm any changes with the user. I realize it's low currently, but for some people, at some point, a higher fee might become unacceptable, so after every change, a reasonable policy would be to ask for confirmation.

I can only confirm that it's down from my perspective too:

I've been watching this situation with no small concern.

I did not lose any money (never kept significant amounts in deposit), but I could have.

Regardless, to entirely cease using the site while others try to negotiate a solution to recover from m4v3r's misuse of funds and all which followed...

...to entirely cease using it seems like discarding useful work and functionality. So I will, for the time being, attempt to resume using the site, but for very small trades only, whilst keeping an eye on the forums to check for any complaints by other users, and to see whether the attempt to salvage the site and repay users their funds is proceeding or not.

P.S. For more info, consider taking a look here:

https://bitcointalk.org/index.php?topic=5441.0

I have been a persistent user of their service, so far without problems. Last time I used their marketplace was about two months ago. Fortunately I don't have any pending transactions or bitcoins frozen in deposit.

I hope it's a technical hiccup of reversible nature.

Perhaps to blackmail? Perhaps because their botnet was not allowed to mine on the pool? Perhaps for some other reason, possibly rational in a fashion, possibly quite irrational. Perhaps just to test their offensive abilities. Perhaps because they couldn't break anything else, but were paid to break something, so they have to fulfill their part of the deal?

Either way, since I need to use IPv4, I donated a little amount to the pool's account to help cover any costs resulting from this inconvenience, and temporarily switched to my backup plan, that is, solo mining.

I'll try to get on IRC by evening (UTC).