Obviously the former. really really really really really lucky. In fact, I might instead think it's more likely that you've found a weakness in SHA-256 and are able to generate preimages fast.

And by the same token if the network goes a day without a result, whats more likely ... that an astronomically unlikely run of bad luck happened— p=2.8946403116483e-63  a one in a wtf-do-they-have-a-word-for-that event—  or that it lost hashrate or had some other kind of outage?

We had block gaps with combined one in a thousand chances given the expected nominal rate and at the same time big pools were down and their operators were saying they were suffering an outage.  But you say we know nothing about the hash rate?

*ploink*

We're not measuring any outcome.  We're measuring a small set of outcomes.

If I send you a block header and you come back with a solution at the current difficulty how many hashes did you do before you found it?   The most likely answer is 18,678,355,68,419,371  (I changed this number after my initial post because I'd accidentally done a nice precise calculation with the wrong value for the current difficulty )

Maybe you did one hash, maybe you did 1000 times that.  But those cases are VERY unlikely.  Far more unlikely than the error that would be found in virtually any measurement performed of any physical quantity.   So we can easily specify whatever error bounds we like, and say with high confidence that the work was almost certainly within that range and that the chance of the result coming from chance is small— just as if we were comparing the weights of things on a scale (though the difference in process gives a different error distribution, of course).  Because bitcoin solutions arise from such a fantastically large number of fantastically unlikely events— giving a fairly high overall rate, the confidence bounds are fairly small even for a single example.

E.g. at the normal expectation of 10 minutes, we'd expect 99% of all gaps to be under 46.05 minutes and our average rate has been faster than that.  So you're asking us to accept that there were multiple p<1% events but not a loss of hashrate when at the same time the biggest pool operator is obviously taking an outage which is visible to all.  OOooookkkaaay...

I think you don't actually know what a measurement is.   If you ask everyone coming into the emergency room complaining of stomach pains "Did you eat cucumber in the last 24 hours?"  is that not a measurement?  Even though the results will be be contaminated by noise and biases?   If the census randomly selects 100,000 houses out of a million to get demographics from, is this not a measurement?

In this case we know the hashrate by virtue of the network reporting when it finds a block.  This is a measurement of _well_ defined process with explicable behavior and we can speak with certainty about it.  Unlike my silly examples its not subject to much in the way surprising biases or unknown sources of noise. (Because, e.g. if broken clients diminish our hash rate— thats not a random effect we'd wish to exclude) about all there is to worry about is how you time the blocks: If you time from the blocktimes you're subject to node timestamp stupidity if you measure locally you will be subject to a small amount of network propagation noise. But bitcoin propagation time is miniscule compared to the average time between blocks.

Regardless, If the expected solution rate is r  then the proportion of times in which a block will take longer than x is e^(-1/r*x).

Moreover, the particular process at play here has its maximum likelihood value at the mean. So you don't have to do any fancier math than taking an average to reach the most accurate measurement possible given the available data.

So, e.g. if we see long gaps then we can say with very high confidence that the _measurement_ being performed by the network is telling us that the hashrate is almost certainly low.

As far as the timestamps go— yes, bitcoin network time can be wonky. So don't pay any attention to it. If you have a node with good visibility you'll observe the blocks directly.

I'm not making assumptions based on "those graphs". I'm looking at the highly improbable gaps between blocks that can only really be justified on the basis of large hashrate graphs. e.g. times 50 minutes or longer has a p-value of .0067 if the expectation is 10 minutes— lower considering that we'd been running a rate higher than one per ten minutes.

Unrelated, it's no "No one has any idea"— Those graphs _are_ a measurement but of a noisy process, however the process in which coins are found is well understood, and you can easily draw confidence intervals based on the known distribution and the number of points in the average. I'll nag sipa to do this. It would be reasonable.

Yup.

And 24 hours after beginning that policy they were at >40% again according to their claimed hashrate.  Though their figures are no longer displayed on bitcoinwatch.

Based on comments I've seen by newbies on IRC it seems that a lot of people erroneously believe that mining is a race and that they enjoy some significant advantage by being on the largest pool…

I think may be misunderstanding what I meant by 'trivally'.  I can't do it in under a day, for example.  Using EC2 prior to spot pricing I cracked RSA-512 for about $160 for the sieveing step and then did the linear algebra at home. in the total of about ~40 hours.

It only takes about 4gb memory or so for the linear algebra. On some random _single core_ machine, e.g. not using the MPI block-wiedemann you can extract a candidate solution in an hour or two once you've done enough sieving.

I can do the whole process at home in about three days now— though I'm perhaps a bit more overpowered compared to most homes.

I'll gladly prove this to you in private (e.g. by signing a message using a key or two I previously compromised from the pgp well connected set), if you'll share confirmation of this with the forum.

The point being— RSA-512 is too weak for any non-ephemeral usage, and yet even if bitcoin was using it right now it wouldn't be completely fatal to the system, but sure as hell would be if the public keys were disclosed. E.g. The coin at 1PZjfkLZBT7Q3UFmyEWH8QtuzTMi3MUiBj would be mine by now if the system used RSA-512 and the public key were disclosed. But without they public key I'd still be stuck even though I can compromise RSA-512.


Modified Shor's algorithm on the EC discrete logarithm problem of n=256bits takes a system of around 1500 error free q-bits (god knows how many for a error correcting system) and something like 6e9 operations (http://cdsweb.cern.ch/record/602816/files/0301141.pdf). I was _abundantly clear_ than I am not claiming that there _currently exists_ an effective attack, and that the benefit was purely a theoretical reduction in brittleness. At the same time no one of any repute is arguing that large scale quantum systems are physically impossible, we just don't know how to build one yet.

Publickeyhash raises a point I hadn't considered: I'd thought of the collision attack as being both a full collision across the big composite hash _and_ a ecc compromise, I hadn't considered the possibility of colliding to a weak key.  Thats interesting. I'm cluessless about how common weak keys would be on the curve bitcoin uses.

Apparently not.  It hasn't been healing when these big pools keep going down— we lose hashrate, and most doesn't come back until the pool does. In spite of the concerns for the stability and security of the bitcoin network— and in spite of actually losing money due to downtime and higher fees— people continue to use deepbit.

As I write this it's back to ~40% even after the outages a day ago.

There is a lot less reason to suppose that the NSA, or anyone else, can currently generate collisions on RIPEMD160(SHA256()) then can shortcut ECDSA.

I mean— we already know how to compromise ECDSA in about 4 billion operations. It's "Just an engineering problem".

As others have answered, it's a more secure way of making addresses shorter.

However— it does have a theoretical security benefit:  It makes bitcoin a little less brittle against weak but semi-practical attacks on ECDSA.

E.g. imagine if bitcoin used RSA-512 for signatures today.  RSA-512 is horribly week, many people (including myself) have cracked it on their own at home.  Even so,  if this weakness was known bitcoin users could change practices to only ever send once from an address (transferring all value to a new address) and so an attack would have to be performed in the narrow window between the transmission of the spending TXN and the mining of the block (or somewhat longer if also coupled with a high hash power attack).   This is _much_ harder, and while I can trivially crack RSA-512 at home or using EC2 I don't believe I could pull off that attack.

It's likely that when there is some practical attack on ECC it will creepy up slowly— initially taking a very long time and a lot of resources. When this happens concerned bitcoin users could move to more conservative practices (especially for large stores of wealth) while the long process of upgrading bitcoin happens.

This isn't what an actual attack needs to look like.

Lets imagine that I am evilMChacker with my 400,000 strong playstation 4 botnet or whatever, enough to have more hash power than the honest network. You are joeblow interested in selling a shiny new Lamborghini.

At block 300000, I transmit a transaction (X) for our agreed on price of 2 BTC for the car.

Simultaneously, I spin up my 400,000 playstations to start mining block 300001— they include transactions like normal but instead of transaction X they include transaction Y  which is a payment to myself using the same coins as X spends.   Once the playstations find 300001 they do not announce it, they continue working on 300002... If the rest of the network found 300001 in the meantime they just ignore it (as well any other blocks the network found).  They keep merging in new tx from the network (though not any that conflict with Y, of course), but they do not announce and they never pay attention to blocks found on the main network. They just mine quietly in secret.

In the meantime, you count up the confirmations— 1, 2 ... 6  ... 100.  Okay, you're pretty confident that your transaction is guarded against reversal you hand over the keys. As I drive off cackling evilly into the sunset I send the final command to my botnet:  "As soon as you're three blocks ahead of the main network, announce all your blocks and self destruct"

Maybe moments later... hours later ... days ... weeks ... whatever.  _Eventually_, because it has more hashpower, the evilMChacker chain will be three (or any amount) longer than the main chain and the blocks will be released causing a single sudden reorganization.

The ever so slight sucking sound you hear is those precious two bitcoins leaving your wallet (and those of any dependent transactions) and ending back up in mine.

No amount of flap dampening solves this.   And besides,  see RIPE-378, in the context of routing flap dampening is now considered harmful and I think the exact same thing would apply to dampening chain splits.  When you dampen a split, you'll often end up on the wrong side, in which case you'll end up flapping towards all your peers whenever you do finally re-converge, thus causing them to dampen you and so on.  

I think the claim that you can do this search without knowing the private key is surprising and dubious.

I'd be interested in hearing more about how you propose to do this.
 

Some highly technical thing that most regular people will probably answer wrong (meaning, in a way that won't get them the behavior they will later wish they got) and which must be answered every single send?  MEH.

People can't be expected to think through the consequence of every transaction. Sometimes you won't realize until long after the fact that you really wish some payment or another had been more anonymous. The system should try to avoid creating situations the user will regret if it can.

How about just keeping track of when backups were taken via the formal backup function and whining at the user once they get low on keys which have been backed up?

Once the encrypted wallet support is in— how about integrated online backup support?… if there was a feature integrated in the client I'm sure there would be no shortage of people selling backup services that accept a few bitcents in exchange for keeping a copy of your encrypted wallet in some web accessible place.

These things would solve more problems and be much more user friendly than some complicated decision with every TXN.

Promoting bitcoin == MAKE MONEY FAST  does us no service.  It makes bitcoin sound like a scam— in fact, promoting it that way makes bitcoin into a scam.

I downvoted. Shame on you.

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.