http://blockexplorer.com/tx/3387418aaddb4927209c5032f515aa442a6587d6e54677f08a03b8fa7789e688#o1

(This looks like change from a send from an active address being sent to the address which was paid by the genesis block)

Did older client software not generate random addresses to receive change and instead pick a random address in the wallet?

So you're saying that a small set of pool systems scales better than the idle CPUs of thousands of miners? Thats silly. As the txload rises miners can simply prioritize transactions based on their hash distance from some random value, allowing TX validation to scale far beyond what the pool could support.

Today the responses to take about 181 bytes on the wire.  Blocks are frequently about 4k, so at the moment difficulty would need to be 22 to send the whole block and use the same amount of traffic.  If it were compressed by only sending the TX ids, it would be 354 bytes/share for 10tx shares, or less then double now.

Someday in the future when blocks are 1MB (the largest size clients will accept today) the 'compressed' size will be 128032 bytes/share. Share difficulty would need to be ~750 to get to the _same_ traffic levels we have now.

This could all be further reduced by miners only sending incremental updates. So basically in that case it would only take resending each TX, along with one extra per per new block (~6/hour) to setup the root. Done this way it should do no more than 2x the current bandwidth, though it would take more software to track the incremental work per miner.  

But even ignoring all the things that can be done to make it more efficient: at current bulk internet transit prices ($2/mbit/sec/month) full 1MB shares would each cost the pool $0.0000064 each.

Assuming 2MH/J, $0.05, and an exchange rate of $6/BTC  GPU mining won't be power profitable past difficulty 10,000,000, even for people with cheap (but not stolen) power, assuming the current exchange rates.  At a share difficulty of only 12 this would be bandwidth costs of only about $5.33 block solved while sending full 1MB shares without any efficiency measures.  If you can't figure out how to make that work then I'll welcome your more efficient replacements.

(the formula for breakeven profitability is
diff = (719989013671875*exc*mhj)/(17179869184*kwh)
where diff is difficulty, exc is the exchange rate in $/BTC, MHJ is the number of MH per joule, and kwh is $/KWH)

As I write this deepbit is down and the network has gone 30 minutes without confirming a transaction.  This is nuts. I don't think the bitcoin community should continue to tolerate the reliability problems created by large pools.  You're free not to participate in an operating practice, but the network is also free to ignore blocks mined by pools which actively sabotage the stability and security of the network.

The pool should give you N addresses:

One for D=1 work, one for D=6 work, one for D=12 work. etc.

D=6 work pays 6 shares. Etc.  The reason for this is because your scheme uses a lot more bandwidth to transmit shares, but this is trivially corrected by increasing difficulty. But that would increase variance to unacceptable levels for slow miners.  By changing the address they pre-commit to a target difficulty and the shares will be credited accordingly.

The miner software can then bet setup so that it picks the diff that gets it close to 1 share per minute...which should end up being less bandwidth than currently used.

Also, while it would be possible to buffer shares while the pool was down and the pool could choose to pay for stales, I think thats actually a bad idea: it would allow you to get shares on network-offline hosts that aren't really contributing to the success of the pool... plus it would require more coding and storage for the shares.  Instead,  when the pool isn't reachable to accept shares you simply switch to using your own address for mining until it comes back.

Annnd... as we mentioned on IRC pools could still enforce sane behavior on miners (e.g. don't send 1MB blocks of crap transactions) by simply refusing to pay for shares that look like that. So the pool acts as a check on miner behavior, but it can't enforce secret rules since the miners will need to know them in order to conform.  This somewhat invalidates nanotube's #2 re-fee rules, but I think thats a good thing.  Pools don't get unilateral control but they get some influence and I think thats good.


Also from IRC, the logical place to put all this would be in bitcoind, not in a miner client. A simple modification to bitcoind would let you change the payout address... then you use normal miners against it.


(1) in order to get pooled payments, silly.

(2) Because you still submit 'shares' (though now with more data) in order to prove that you're working for the pool, same as now.

Okay—  so I was off by 0.36%, so sue me.

You misunderstood the argument.  Lets say that DB is 40%, slush is 30%, eligius is 20%.   You get 11% of the network hashing power, way less than half. Then you DOS attack those three pools. You now have 51% of the _remaining_ hash power.

This attack is much harder with less pool concentration.




Yes, your computer can't even see the work it's doing for the pool because the work is hashed, it only works on the block header.  But the pool could not be evil completely undetectably. There is an argument that it's much easier for a pool to undetectably skim from their users, so if they were evil they'd do that instead... but lots of arguments against big pools have been given here which don't require evil.

Yes. 150K LU  is not enough to fit an unrolled engine with internally pipelined adders. It's enough to fit _one_ unrolled engine, which you'd probably be lucky to get running at 100MHz (=100MH/s).     Maybe you could do some awesome stunts, depending on the platform and somehow get two in, though I don't see it.

If it's otherwise idle capacity, then fine— it would be profitable. But you're not talking about a huge competitive advantage for anyone yet, certainly not a huge short term competitive advantage.


Much more and it simply becomes easier to write it myself.  It's quite simple to write a SHA2-256 engine in verilog, though harder to get it going fast.

To someone who knows the tools and has the development kit handy, it's probably two days of work to get something basic going, though the skys is the limit on optimizations.  I'd offer the use of hardware, but the largest programmable FPGA I own is only 27K LU, which is too small to be interesting for this.

The reality is that someone will eventually do it for love or money and reality trumps capitalism.

Moreover, shaking confidence in the security of bitcoin by securing a large private advantage wouldn't be economically sensible for anyone developing this stuff in any case.

No, he should just increase the fees further.  He's already the most expensive and still the biggest— even if you make some downtime argument— 2% fee pays for 28 minutes/day in downtime— and deepbit has not been perfectly reliable either. I bet he could take 15% and still be at a third. 0_o

Win win.


The security concerns don't require the operators of the pool to be evil. They could be compromised, for example. And there have already been pool security compromises.

Adding to the security paranoia arguments the system reliability argument: If a pool has 50% of the hashrate and it goes down, then we lose 50% of our transaction processing capacity.  This would especially be bad in difficulty-cycles where hashrate had shrunk so that we were already behind 10 minutes / block.

-----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.