the unlock codes were leaked:

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

The unlock codes were leaked:

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

For those who have a Mtgox yubikey and now wish to unlock it and re-program it for other purposes, the unlock codes have been leaked:
http://www.sendspace.com/file/in4ss6

Search for your serial number (as printed on the dongle) in the txt file downloadable at the above link (ignore/delete any obviously dodgy exe files that are downloaded at the same time). And then use the tools from http://www.yubico.com/products/services-software/personalization-tools/use/ to reprogram.

The entry ending in A relates to slot 1, while that ending in B relates to slot 2.

I discovered this via this page: http://crypto.stackexchange.com/questions/14809/any-use-for-now-defunct-mt-gox-yubikey. I have no idea who/how/when this was leaked.

While this list allows the yubikeys to be unlocked and re-programmed, assuming yours is listed (and mine was) - it is not a leak of the stored keys in the device.

If you had funds at MtGox when it eventually died, then obviously you should think about whether you really want to re-program your yubikey - as at some level it allows you to to prove ownership of your account there.

I should now have replied to all PMs about this - if I missed you then please resend.

A few have been sold, and there are a few offers outstanding - I'll update remaining numbers over the weekend.

Having watched a few other threads of FPGAs being successfully sold, I think its time to test the market with this selection:

6 BTC each:
2 x Ztex 1.15y [each with 4 x Spartan XC6SLX150]

1.5 BTC each:
37 x Ztex 1.15x [each with 1 x Spartan XC6SLX150]
3 x Ztex 1.15d [each with 1 x Spartan XC6SLX150]

1 BTC:
1 x slightly temperamental Ztex 1.15x [with 1 x Spartan XC6SLX150] - the USB connection to this one seems to terminate sporadically (sometimes repeatedly within a few minutes, sometimes its fine for a week) it needs to be rescanned before it works again. I altered the Ztex java file to rescan automatically when it detects a disabled device, but that is not 100% foolproof.

0.23 BTC:
6 x 12V 10A PSU with separate 8-way splitter [can power 8 Spartans]

0.11 BTC:
1 x 12V 5A PSU wired to 4-way splitter [can power 4 spartans]
2 x 12V 5A PSU to single barrel connector [can power 4 spartans - either a single 1.15y, or if you get a splitter then multiple 1.15x or 1.15d]

If you only want one 1.15x/1.15d then I'm sure I have some suitable 12V 1A PSU that I can find, for 0.06 BTC.

USB cables will be provided if desired with the FPGAs.

If you buy >4 devices, then I will also provide an appropriate number of 7-way Belkin usb hub(s).

The PSU can be provided with suitable UK power lead, you'll have to source your own if you are outside UK.

postage will be at cost from the UK.

escrow if desired via an agreed provider at the buyer's expense.

In all this is ~10GH.

I will see how much interest there is before deciding whether to proceed, as if there is only interest for a few devices, then I will not bother to sell any.

My opinion only, as I've not yet sought advice. As a miner, I think you have a choice how you account for it:

1) Treat the mined BTC as income based on equivalent GBP value at the time you acquired it. Any subsequent rise in the value before you exchange the BTC for goods or GBP would be subject to capital gains tax. (e.g. you mine 1 BTC at a time when it is selling at £10, you must record that £10 as income and pay appropriate income tax. If you sell that 1 BTC at a later date, when they are worth £80, then you must record a capital gain of £70 and pay appropriate capital gains tax).

2) Treat the mined BTC as income based on the equivalent GBP value at the time you exchange the BTC for goods or GBP. (e.g. you mine 1 BTC at a time when it is selling at £10, but you sell it a later date, when they are worth £80, you must record income of £80 and pay appropriate income tax).

In either case, you should be able to offset the initial cost of the equipment and an appropriate proportion of your electricity and broadband costs against the income tax due - i.e. you pay income tax on the profit.

An advantage of option 1, is that  capital gains tax can be lower than income tax, but a disadvantage is that even if you don't actually sell the BTC, then you must still pay the tax.

I don't think you can get away with just treating it as capital gains from zero value, because that is simply not the case. The coins had a clearly derivable value at the time you acquired them, so it is like receiving a benefit in kind, or compensation, or income. Anyway, if you did try to treat it as entirely being capital gains, then I don't think you could offset the electricity/equipment costs.

sign up as a "merchant" with bitpay.

You can then cash in your bitcoins to a bank account for 2%, or 2.99% if you want to guarantee the exchange rate.

Sorry, no exciting method.

For the controller I use Xilinx iMPACT (exactly as Glasswalker decribed).

For the FPGAs I tried to use Xilinx iMPACT, but unfortunately the free version does not allow me to flash the PROM associated with the LX150 (as that FPGA requires the pay version of the software). Hence, I used xc3sprog.

I've done both my boards now (both pre-50) with no issues. After doing the controller, I unplug USB and power, set switch 3 OFF, all others ON. Attach power, wait, then attach USB.  I then run xc3sprog with the -j option to verify I can see the JTAG chain. I then flash 3,2,1,0 in that order using the standard command for each.

I'm running xc3sprog on the Enterpoint supplied Cairnsmore VM under VMware player on Windows 7. But, I have also previously flashed the FPGAs on a linux box directly without issue. The only time I had issues with the flashing was when running the very first revision of the controller I think (i.e. the one it shipped with).

Early days, but after flashing this to a pre-50 board that was giving lousy results with anything but the twintest bitstream, I am now seeing the best numbers I've seen for this board:

 ICA 0:                | 368.3/370.7Mh/s | A: 77 R:0 HW:0 U:  2.42/m
 ICA 1:                | 373.4/373.8Mh/s | A: 68 R:0 HW:0 U:  2.14/m
 ICA 2:                | 374.4/373.1Mh/s | A: 78 R:0 HW:0 U:  2.45/m
 ICA 3:                | 374.0/372.5Mh/s | A: 86 R:0 HW:0 U:  2.70/m

NB - this is one board - you add all USBs with this bitstream (and ignore the MH, just look at the U)

Obviously, this is only half an hour in. But looking good so far. Thanks.

There are so many unknowns in this, that for the protection of both sides, you need to clarify what the cancellation terms are going to be.

Especially if you are still considering any kind of lottery style random prioritisation of orders - whereby people may place extra orders with the intention of cancelling the lottery losers.

Assuming the product development is successful and you actually reach the shipping stage, the rate at which you ship is going to change the payback time, and (the more sane) people will redo their sums and reconsider their orders.

No. I get the same error as you when trying the SPI flash.

I have an early board as well.

Try programming with:

SW1 1 off, 234 on [ I actually had 1 on during programming, but not sure if this was necessary]
SW6 all on

SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on


And then run (without powering down inbetween) with the same config.

For the twin_test.bit only program 0 and 3.

Seems to have worked for me. I'm using the standard cgminer.

It seems to be faster and you now get a green light when it finds a nonce!

For what is worth. I received two boards and am running 64 bit Win7 and used the standard cgminer build (I got them before they put up their cgminer version).

First board worked OK after installing the drivers. Plugged in second and couldn't get it working. Kept getting the received 0000000 message.

Eventually, I rebooted and then they both worked fine first time after that.  There is something hypnotic about watching the blue light flash when it finds a share.

Not sure how you know which 2 of the 4 enumerated ports to give to cgminer, but for me it was the higher two ports for each board.

I'll add my voice to the praise for Enterpoint. Great performance to turn around the hardware for this product in such a short span of time - and when you have one in hand you'll see that it it feels a very robust professional offering (no offense to other vendors whose product I also have, but this actually does feel very industrial in quality).

Give them some time and the software side will follow.

How can they go negative? The only way I can see is if one of those blocks occur around the same time as a manual payout is being done.

In any case, if they should go negative then I don't see how the pool is any worse off - as accepting that abnormal block has reduced the pools payout liability.

OK, that makes sense - I missed the bit where you said payments had been suspended.

If I understand correctly, a user producing such blocks can't be altering the payouts (or all their shares would be being rejected) - so they are just submitting late/messing up altering timestamps. So I wouldn't try to write complicated routines for such an abnormal case. In virtually all cases when you get a block like this it is going to be paying out to correct addresses which will not be taken negative by the payout. So I'd aim to accept in these cases.

However, I don't really like solution 1, as that seems exploitable by somebody who wants a chance of get their payout multiple times, by delying their submission should they find a block.

Looking at blockchain.info, after the block you dsicussed, I see two other blocks today that appear to be Eligius blocks, which are not showing up on the eligius.st under found blocks:

http://blockchain.info/block-height/181845
http://blockchain.info/block-height/181839

They both payout to the address normally included on Eligius payouts (   18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B ) so I don't think they are just relayed blocks, that blockchain is incorrectly tagging against Eligius.

In fact they have payed out the full 50 BTC to that address.

Has that dodgy block confused the code somehow?

Edit: In fact, looking at that address a bit more, it has picked up a couple of other 50 BTC payments over teh last few days whilst we have been running with a long payout queue:

http://blockchain.info/address/18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B

Absolutely not suggesting anything improper - just hoping that there is a code error contributing to our poor luck over the last few days.

Anyone any experience with no-registration mining and autopayouts?

I've been using 50btc as a backup pool for the last week, connecting with a bitcoin address as username and have earned a small credit of ~0.15 BTC which I can confirm via the API.

However, the site states it will auto payout once you pass 0.01 BTC (not that I really want such small payments) - but my balance has sat unpaid for a few days now.

Does it ever autopay, or has the payout threshold changed?

While I don't want tiny payments, there is no point using it as a backup pool if it is not going to pay.

Yes p2pool is running locally, but approximately every 10 secs the work you are doing is invalidated by long polling (which is delayed by your latency). So, my miner spends my latency time, working on invalid work.

Likewise, every time you get a share that p2pool reports to the rest of the network, it is delayed by your latency. So high latency increases the chances someone elses share will turn yours into an orphan/stale.

Someone with better connectivity and latency on p2pool can achieve better efficiency than me.

I came to the conclusion that is was adversely affecting me when using p2pool - but that works slightly differently to most pools and is more latency sensitive.

you can speed up the initial sync by downloading the blockchain from
http://eu1.bitcoincharts.com/blockchain/
see https://en.bitcoin.it/wiki/FAQ#How_long_does_.22synchronizing.22_take_when_the_bitcoin_client_is_first_installed.3F_What_is_it_doing.3F