Don't confuse retail with "cost", do you think KNC is paying $3/GH for the hashrate they are putting online themselves?

I agree that 10x in three months is pessimistic, but 6x is what 2%/day suggests— and thats what we've been averaging for some time now (http://bitcoin.sipa.be/growth.png).  It can't continue forever, of course, but long enough to prevent profit for everyone buying at $3/GH delivered months from now? I absolutely think it can.

None of the antminers I've received showed the slightest evidence of being used. The reason they are dropping prices is that they're selling these things near or beyond the boundary of profitability, and so as more hashrate increasing days go by they need to lower the price to keep it from being an obvious loss to everyone.

I didn't see a way to transfer the coupons, how do you do it?

And would also create a concrete incentive to delay your block announcement when the block you have is a likely winner.

I'm fairly sure this has been proposed before and debunked.

They'll recognize r when they see it in the network.

Yup. Unless you get into touchy feelies soft valuations of your contribution to the Bitcoin network security (which you probably shouldn't unless you're running and mining on your own node), there is no scenario where a miner which produces less in Bitcoin than you could have had instead is to your advantage.

I only wish the reduced rate had come with better than anticipated power usage instead of the reverse.

I think the point there is that the claim that they're shipping is a currently unsubstantiated. People with early orders, who would have expected to have heard something, seem to have heard nothing so far.

It doesn't matter (and for some curves— e.g. ones where the x^2 term is non-zero, though IIRC in scep256k1 there isn't a tidy LSB pattern, some 32 bit LSB patterns are unused entirely). About half of the X values are not points on the curve, but this is accounted for in the order of the group. There are ORDER points on the curve, and the private keys 1..ORDER-1 uniquely map to them.  Lets say that all the X values were even— they're not— but lets say— it doesn't matter since any search is already limiting itself to valid X values, e.g. any statement about the security already excludes the points which are not part of the curve, which can't be reached by any private key, and which wouldn't be included in any key search.

It's not possible. Though the fact that you can 'search from both directions' is why 256-bit ECC has 2^128 security. Rho is an enormous speedup but the parameters are chosen to make it irrelevant.

I think I've pointed out the fraud in this thread clearly enough.  The impression was made that this tool was able to find the private keys of some portion of random keys enough for shill demonstrations in this thread.   I posted 200,000 keys with a substantial bounty for giving me the private key of any one of them.  Evil, where is my private key?  You said your software takes a few minutes— please either solve one of the keys I posted or admit that you cannot and that people have been mislead by this thread.

But, of course, there isn't. The group is complete, all $ORDER points are reachable by multiplying the generator from 1..$ORDER-1. Some points _can't_ be more likely than others as a property of the curve with a uniform input, or otherwise some points would be unreachable (obvious by the pigeonhole principle) and the order would be less.

All it does is reaffirms is that the world is full of fuzzy headed reactionary thinkers, unscrupulous parties, and pump-and-dumpers looking to cash in on hysteria.

Itod, you realize that the software you're running is indistinguishable from a cracker of EC keys, right?  I mean— no real reason to believe that anyone will find anything, but...

If he has anything at all then he can demonstrate it by cracking any one of the 200,000 keys I posted as a bounty and collect a bunch of coins from me.

What I was responding to was someone asking about testing if a key is "weak"— it's pointless, if any non-infinitesimal fraction is weak (e.g. by being generated from private keys known to an attacker) all keys are weak.

There is no such thing as a weak key in secp256k1. If any non-trivial fraction of uniformly selected keys are weak then all keys are weak because there is a simple bit of algebra to convert an attack on a non-trivial fraction of random keys into an attack on any specific key.

The crappy and super slow implementation of ECC arithmetic linked to on that website checks keys generated against a couple thousand 32 bit values. (Why use a slow thing like that if you've supposedly got some amazing gpu thing). My guess was that he's using this as bait to get people to run that program and the values that its looking for are all 'near' high value keys.

Or other wise it just another lame market manipulation attempt. Either way, ... if he actually can crack something I welcome him to go solve any of the 200,000 keys I listed and collect his bounty.

Thanks for decoding his JS, I'd just ignored it.

The thread has several instances of newbie accounts providing single pubkeys which evil claims to crack e.g: https://bitcointalk.org/index.php?topic=421842.msg4800547#msg4800547

Encoding 'in the blockchain' is pretty much the absolute last thing you want to do for pretty much any question.

What you're describing also has the bad property that you can't prove the connection without disclosing the private key.

It also suffers from bad key management since coins will be assigned to non-backed up ephemeral keys which could be loss.

It also doesn't create strong evidence that the receiver of the coins actually knew of their existence... e.g. I fail to give you the private key, then I spend the coins myself, then I say you didn't live up to your side of a contract you never saw.

There are proposals for pay to contract which are much better, but they still have the data integrity issues.

The payment protocol supports x509 signing for non-repudiation of invoices, which is I think mostly what the OP wanted.

Nah, coincidental. The only reason I put a limit at all is so I wouldn't feel ethically obligated to hold onto 50 BTC beyond that point in time.

So you claim you can crack some random keys provided by people on the forum? Oh really.

Well here, I'll make it very profitable for you then:


Full message at https://people.xiph.org/~greg/keysfun.asc

Surely if you can crack a single key provided by a person in the thread cracking any one of 200k keys should be a cinch.

So you claim you can crack some random keys provided by people on the forum? Oh really.

Well here, I'll make it very profitable for you then:


Full message at https://people.xiph.org/~greg/keysfun.asc

Surely if you can crack a single key provided by a person in the thread cracking any one of 200k keys should be a cinch.

This is indistinguishable from a ECC cracking tool.

After reading the source code, it appears to me that you're using this crap as a cover to try to trick people into performing computation for you in an attempt to crack a couple thousand selected keys.

Unfortunately its impossible to determine which keys you're attempting to crack because its possible to cryptographically blind the cracking process (e.g. the matches are against key + s*G for some s known only to you).

It's pointless and a waste of time, but I guess you figure so long as other people are doing the computation for you that its worth doing.

It's doubly hilarious that you claim to have (and offer to sell) a GPU tool that can compute keys a "terra-tries per second", and yet you'd ask people to waste their time crunching with this rubbish python EC implementation.