-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I will gladly match Chris Acheson's bounty of 10BTC on his terms.

A basic FPGA miner isn't a lot of work and it would be a fun project
for someone who hasn't done this kind of work before.  A _fast_
fpga miner which will achieve competitive performance would be a decent
accomplishment.

I think it's important to the health, security, and public confidence
in bit coin that a few large private parties do not retain a substantial
long term advantage in their ability to control the hashchain.

Making sure that the public has the lowest cost access to the mining
state of the art should be helpful for this purpose.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3SruYACgkQrIWTYrBBO/p58wCfYeGrfT9ptb/bOapN0zJ0Dt9J
XFoAoMuISTUBUGqeOqJc1TBesyG6e0Fh
=WAwq
-----END PGP SIGNATURE-----

Your figures are wildly off.  A ununrolled miner takes about 90K LU, and a internally pipelined one that can reach high clockrates is probably more like 180K LU.  Millions of gates.   This pushes you into the most expensive FPGAs currently available just to get good performance...

FPGAs are great for H/j  but not H/$ at the moment. The upcoming generation of FPGAs may improve this somewhat.  The number's you're describing aren't really realistic except via fully custom asic with NREs in the million dollar range.

Has anyone considered assembling a hardened vending machine (perhaps a retrofitted change machine) into a device that converts USD to bitcoin?

You'd put them in publicly accessible places. Person walks up and scans a QR code of a wallet ID off a phone or from a printout (speech recognition is out due to mixed case, most likely),  then stuff money into it.  It prints a receipt (including a QR code of the TX itself, to guard against network problems) and sends money to you on the network.

Bill validators don't appear to be very expensive.  While I don't think this would be a profitable business on its own any time soon (and would only be interesting in a few major cities right now) it might be something worth operating for the sake of increasing the viability of bitcoin.

Going the other direction (BTC->$) has some extra complications— requiring a retrofit of an more costly atm and having instant gratification problems since waiting around the machine for a block confirmation would suck (and not waiting would almost certainly be exploited).

BTC->$ doesn't solve the more urgent issue of "I want to use this BTC thing but can't get any money in it before I lose interest, because mining now has high upfront costs", but $-> BTC sure does.

Hard to give any kind of security review without seeing the source—  but a few comments:

Users choose terrible passwords almost universally. It's silly to blame them because they're not changing.   As a result, if you're encrypting something using a password without strengthening you are going to basically be insecure. Please use password strengthening.  I recommend scrypt (http://www.tarsnap.com/scrypt/scrypt-1.1.6.tgz) which is described in this paper: http://www.tarsnap.com/scrypt/scrypt.pdf

The size of someone's wallet leaks information because it grows as you get/send TX but not otherwise.  Someone with access to the "cloud" storage file sizes could potentially backtrack an ID to a user by correlating the change in backup size with activity on the ID.  This is really hard to prevent completely, but it's quiet easy to drastically reduce the amount of information available: Before encrypting pad the size up to some increment.  This will hide some the least significant bits of the size, which have the most entropy. A rounding increment of 4kb wouldn't even use any more space on many filesystems, though a larger one will provide more confidentiality.

Other projects with similar security requirements have been struggling with this too.

http://google-opensource.blogspot.com/2009/03/thandy-secure-update-for-tor.html

It's more subtle than you might initially expect. I advise against reinventing the wheel here.

It's not continuous because once a block is going your share of it doesn't change much, assuming everyone keeps a mostly constant rate.

It jumps right after getting a new block because the initial stats are noisy and dominated by the miners luck in finding shares at that moment, also because the rate changes that happened late in the last round are no longer diluted by lots of pre-existing shares.

It would also be neat to follow the blockchain and add up all the eligius payouts for the address on the same graph.

Had basically the same thought—  but you're missing the fact that all the storage we use is not a bit error channel, but is instead a block-erasure channel:  The disk already has a strong ECC per block and if it fails the whole block is unreadable.   Failing sectors on disk are not uncommon.   The busses we carry data over can get bitflips but it's really rare.

There are many tools for FECed archiving against erasure channels: E.g. the vdmfec software here: http://members.tripod.com/professor_tom/archives/index.html


But really, the wallets are so tiny that I don't see any reason for not simply keeping many copies. It would have a lot less software complexity: e.g. it would only take a few lines of code to make the client keep 1 "before last write" and 52 "weekly" old copies of your wallet.. and only about 5MB space assuming that your wallet is 100KB.

Someone showed up in the #bitcoin channel freaked out a few days ago because their wallet.dat just disappeared with a lot of coin in it.  We convinced him to shutoff and use a rescue disk with file recovery tools. He got it back— the file was fine, just deleted.  Looked to me like his disk was on the way out and after hitting an error writing an update the wallet got unlinked.  (perhaps there isn't enough error handling in the client software).  Obviously backups are critical but the software should do all it can even in the face of careless users, and adding backup copies would do a lot to guard against stupid..

Every worker is frequently sending their password in clear over the internet, anyone with access to sniff the network between you and the other end at any point can easily get it. Also, deepbit doesn't use https for the management screens either, so a similar (if somewhat reduced) risk exist there.

This is why services which have no accounts are good.

I can also attest first hand to the fact that witcoin makes an effort to determine that the listed entities are actually affiliated with the listed addresses.

 

I use the CLI interface with the current software and I had no idea the GUI didn't display/accept full precision!

It works fine on the backend.


One problem with the current decimal point location is that after more deflation a typo wipes out your lifesavings.

Perhaps the client needs a maximum TX size setting? (that triggers a nasty warning if you exceed it?)

Amateurs.

My Sapphire 5850s are doing 341 MH/s with an 852 core clock.

Recipe:
 Headless linux
 SDK 2.4
 Use AMDOverdriveCtrl to allow low memory clocks
 DISPLAY=:0.0 aticonfig --adapter=$1 --od-setclocks=852,284
 phoenix.py -q 2 -k phatk DEVICE=$1 AGGRESSION=13 WORKSIZE=256 VECTORS BFI_INT
Sensor 0: Temperature - 60.00 C (though I have the fan set high)

I wrote a script to sweep memory speeds and kernel configurations to find the highest rate settings.  I found that memory being exactly 1/3rd core was a big speedup for me. YMMV, if that works for you I'd like to know— I don't know if thats some chance property of my hardware or something more fundamental.

I understand that the phatk kernel is not a win unless you're on SDK 2.4

My cards aren't stable at 900. I'm skeptical of ~875, thus the 852.  Next time I take an outage I'll try flashing the bios to nudge the voltage a little.

This is probably the case— I have consistent 20ms ping times to Eligius.

Luke is in the process of setting up geographically distributed access points to the pool for the very reason you've cited. He's been soliciting for testers in Europe on IRC this evening.


Only likely to help if your local network is congested and the source of the issues. Sounds like a good plan in any case.

People posting numbers from 2.1 appear to be lower than mine on 2.4.

I don't know what you consider regularly.

Here is my personal share timings for the past 13 hours (before that I had a locally induced outage from upgrading the mining kernel):

(I use an instrumented miner which records all its shares)

Because shares gaps come from an exponential distribution with an expected value of 10.8 (397.6MH/s), the noise and some spikes are expected but 99.990% of the share gaps should be under 100 seconds, though one above 100 is expected to happen randomly every other day or so. The spikes here at 271 and 302 seconds I know to be real outages due to logged RPC errors.

Yesterday I see one 184 second and one 104 second outage, also with logged errors.

At least in my case the reduction in stale shares (from about 2% to 0.1%) that I was seeing on deepbit trivially compensates for the 0.48% I've lost in the past two days on Eligius due to outages, not to mention the overhead. I don't have great logs of my own induced outage prior to two days.  Your connectivity may vary.

I'm in a position to speak objectively about this as I log all my found shares.

More data would helpful, but it's only run for a few hours. Ideally I would have collected data from two cards in parallel over the same time to isolate network effects, instead I'll just exclude the extreme outliers (>90s).

Using the 1814 shares before the change and 1814 since the change on a single node (the 5870), I found that the mean time between shares before was 11.127  seconds and the mean time after was 10.8.  This difference is not large enough to make the 95% confidence intervals assuming an exponential distribution, and a permutation test finds only p=0.369, so with this amount of data I can't say it made it better for _sure_ but it's certainly more likely than not, and it's also very unlikely to have made it worse.

10.8 seconds at difficulty 1 implies 397,688,225 h/s and 11.127 implies 386,000,973 h/s, which is basically what the tool shows... well, a little less— it looks like the performance was overstated a bit before and its less so now?

(The formula for hashrate from share gaps is 281474976710656/(65535*seconds)=h/s)

User makes a 0.01 payment using a 0.02 coin in a no fee transaction. They get 0.01 change.  The TX is low priority.
(TX: c9bdcc0ba07812c76e6c6635049f0b55b628a4c3321b02ab4317d79273861232)

Two days later they make a 36BTC transaction, they include a nice fee.  The change gets used.  The TX is hung waiting on the unconfirmed 0.01 contributor. It's something like an hour old now and it's still unconfirmed as I write this. Based on the ages of the other unconfirmed TX like the blocking one, it might take seven days to clear.
(2e74980e03fc0e3ca3c73379f07661afada17cf2103e196bb59345409a6945c8)

Maybe the client could try harder to help the users avoid spending unconfirmed coin, but it seems to me that the miners should group all the TX involved in a dependency, add up the sizes and the fees, and apply their criteria to the group as if it were a single TX.

Otherwise we can expect more holdups as the QOS for no-fee transactions continues to decrease.

On 5870 900/300 383.17 -> 398.16
On the 5850s 852/284  327.12 -> 340.90

CLI:
DISPLAY=:0.0 python phoenix.py -q 2 -u http://15xWuDHSyKzpvp6FacGKXijBeaaaYhKWSi:x@pool.bitcoin.dashjr.org:8337/ -k phatk DEVICE=$1 AGGRESSION=13 WORKSIZE=256 VECTORS BFI_INT

SDK 2.4

While screwing around with memory settings previously I found that having an integer ratio of clock to mem made a fair improvement, around 3MH/s with the old kernel vs being near but not quite.  I wasn't sure if this was chance or something substantive, but considering that I'm seeing better improvements (and performance) than some others I thought I'd mention it.

Phateus, you have my thanks and a donation of a day worth of the income improvement your code brought me.

If my friend and I were only going to live ~40 days I'd hope we could find something better to drink than beer!

Ha. So due to a screwup earlier, about 100MH/s of my capacity was offline.  Since it wasn't much, I probably wouldn't have noticed until tomorrow morning but I happened to load your page and saw that the MH/s rate looked a little lower than expected. 

I just sent you 0.21 BTC, the expected BTC return from 8 hours of 100MH/s. I at least owed you that much. Thanks!

If heating is a non-trivial part of your electric expenses then you should be using gas (much power cost per therm than electric heating),  and/or an electric heat pump (greater than 100% "efficiency").   

Because of this, even with heating as a consideration mining will never be free, unless you can make some sucker pay for it for you.