Well there is a way if you know both the plaintext and the encripted form of a message. But anyway, I'd like to see some kind of proof that bitcoin transactions can be used for that.
Yes, but what you are brute-forcing is set: block and random number to get hash that start with defined number of zeroes. That's it. No other use. No brute-force of communication. It does not even help to brute-force passwords.
Oh dear. I think the OP might need to tighten his tin foil hat a bit...
I gave his arguments a fair shake, though. Using it as a brute force tool seems... Like it wouldn't work with how it's set up right now, right? As in, yeah, it's solving RSA (or whatever, I can't remember) -- but only for the particular configuration the Bitcoins protocol uses. And only one specific key length, etc. Am I on the right track here? If so, then the entire thesis is invalid.
Yes. The hash you have to crack is padded with 0s at the start. I'm hazy on how hash difficulty actually adjusts, but that's the idea. For more, see https://en.bitcoin.it/wiki/Difficulty
Mining even does not have anything to do with asymmetric cryptography (which is in case of bitcoin ECDSA).
In all, mining is quite orthogonal to how the whole protocol works, it is just some computation that satisfies that it could be somehow tied to block contents, it's difficulty can be tuned and it's result can be quickly verified.
someone is just experimenting with deploying wordpress blogs, filling it in with an off-the-cuff conspiracy theory instead of lorem ipsum.
at first i found these claims embarrassing for being wildly uninformed.
in no way is the protocol obfuscated. there are many successful reimplementations, and there was recently a "lets formulate and publish a transaction manually" post here on hn.
in no way does a standard transaction incentivise using "the full mining power" of the network towards cracking a key pair. at a stretch, an address which has spent inputs and still holds a balance is vulnerable to public key factorisation (i don't know if that's the right term for elliptic curve key pairs), but there is no incentive to publicise the private key for anyone who finds it.
> although I am not an expert on cryptography, I am an expert on software and the products of software groups
the author is not named anywhere. the about page is the template "This is an example of a page." filler.
now i find it embarrassing that i mistook any of it as something meant to be taken seriously.
Why is this even on the first page? Don't feed the troll, anyone?
> I believe that any forensic analysis of the bitcoin protocol would reveal the same results as I have posited. [sic]
Which assumes there has been no such thing to this date, which I doubt. This post is riddled with "likely" and "I believe" and stuff like that, and he came up with all that after reading a blog post by some guy explaining the protocol. I'd have thought that it'd take more than a couple of random accusations to reach the first page...
Still, given that we can attach arbitrary data to transactions, and the easy accessibility of the various services with which we can look them up, the whole network does make for a nice replacement for your CnC server, doesn't it?
The bitcoin protocol is not obfuscated. That's how protocols look like. It's actually a fairly simple and straightforward protocol compared to others.
As a means to outsource SHA256 cracking it would be patently useless. To crack a hash you need a collision. Bitcoin mining doesn't produce collisions, it produces "hash is smaller than target" results. But even if you'd assume there'd be a value in that answer, it's still useless, because you can't dictate the hash of the previous block (which is included in the hash of the current block), and you can't dictate the transactions of a block a miner would include (which also go into the hash). Since you can neither dictate input nor output nor get a collision answer, it'd be a pretty stupid tool for attacking SHA256.
It would also be useless as a means to attack EC-hashes, since miners don't try to guess these, and the flavor of EC-hashes used in bitcoin is unique, it doesn't overlap with the ones usually used in TLS.
See this is the reason why people who're not programmers shouldn't comment on things todo with programming. Especially if you've never designed and implemented a protocol, you shouldn't comment on protocols. If you've never used cryptographic hash functions, you shouldn't comment on them. If you've never understood the bitcoin mining process, you shouldn't comment on it. As a general rule of thumb, don't comment on things with conclusions, you can't support, because you have no clue.
You know you don't substantiate your claims to experience or your "analysis" of the protocol in any way.
So your sole acumen far as can be determined is setting up a blog and reading another bloggers blog entry. Yeah, tons of experience there.
So, I've been writing software for close to 20 years, and I've been doing it for a living every for the last 15 years, 6 of which I've been doing that as a freelancer.
For the record, I only wrote PHP twice in my life, once when I was a wet behind the ears noob back around 18 years ago, and once when I was forced to do it on a short snippet around 8 years ago.
By this logic, git (which calculates sha1sums of various things) is a "cryptographic botnet" to calculate lots of hashes as well. Stupid article. Flagged.
I had initially considered that the "open source" nature of bitcoin might leave little room for malicious payloads, but when I started delving into bitcoin subculture, the pervasive presence of a wide diversity companies involved in ASIC manufacturing and chip fabrication gave me pause.
Specialized hardware is anything but open, and the overhead to fabricate chips is not insignificant.
Manufacturing rack-mounted rigs, and programming FPGAs might be within the reach of small-time, chincey, fly-by-night companies, but I'm not so sure about nanometer scale LGA packaged chips.
This part right here doesn't exactly dispel my suspicions:
The Bitcoin scripting language [1]
You might expect that a Bitcoin transaction is signed
simply by including the signature in the transaction, but
the process is much more complicated. In fact, there is a
small program inside each transaction that gets executed
to decide if a transaction is valid. This program is
written in Script, the stack-based Bitcoin scripting
language. Complex redemption conditions can be expressed
in this language. For instance, an escrow system can
require two out of three specific users must sign the
transaction to spend it. Or various types of contracts can
be set up.
The Script language is surprisingly complex, with about 80
different opcodes. It includes arithmetic, bitwise
operations, string operations, conditionals, and stack
manipulation. The language also includes the necessary
cryptographic operations (SHA-256, RIPEM, etc.) as
primitives. In order to ensure that scripts terminate, the
language does not contain any looping operations. (As a
consequence, it is not Turing-complete.)
So we have people purchasing expensive, networked, internet-enabled black boxes and USB sticks, and a complex, specialized scripting language, well-specialized to take advantage of, and/or encourage the donation of spare GPU power.
Given the image at the bottom of the OP's blog article, consider the author's paranoia, specifically with regard to hardware bitcoin mining, via Application Specific Integrated Circuits (ASICs) which, by definition, are not open source. Certainly not to most common users, and certainly not without substantial effort.
...and just to stoke further paranoia (why not?), consider that even a hobbyist artisan hardware hacker (such as Ken Shirriff) might be thwarted from understanding the inner workings of a reverse-engineered processor die:
If you don't audit your network traffic, or perhaps lack the skill to do so, and the only metric you use to measure the validity of the machine (that's executing arbitrary code on your network) is the balance of your bitcoin wallet going up, then how would you know that your hardware isn't built with dual purpose?
If you're wallet balance rises within the approximate tolerances of an arbitrary expectation, and you're financially compensated accordingly for just letting it cycle, would you question the behavior of the appliance?
Given the premise that no one can truly know the precise moment a block will be discovered through mining, how can anyone be sure that their hardware miners are 100% honest, regarding their activities?
He does have a point about there being inconsistencies in the protocol. It's a pretty ugly binary protocol.
That said, the work done by Bitcoin miners is totally useless for bruteforcing anything except double SHA256 hashes, which AFAIK is not used anywhere besides Bitcoin and derived cryptocurrencies. It's certainly not useful for brute forcing ECC keys.
22 comments
[ 2.1 ms ] story [ 51.8 ms ] threadI gave his arguments a fair shake, though. Using it as a brute force tool seems... Like it wouldn't work with how it's set up right now, right? As in, yeah, it's solving RSA (or whatever, I can't remember) -- but only for the particular configuration the Bitcoins protocol uses. And only one specific key length, etc. Am I on the right track here? If so, then the entire thesis is invalid.
In all, mining is quite orthogonal to how the whole protocol works, it is just some computation that satisfies that it could be somehow tied to block contents, it's difficulty can be tuned and it's result can be quickly verified.
Given the transparent nature of bitcoin transactions, it could however be used to track, cartography underground transactions.
at first i found these claims embarrassing for being wildly uninformed.
in no way is the protocol obfuscated. there are many successful reimplementations, and there was recently a "lets formulate and publish a transaction manually" post here on hn.
in no way does a standard transaction incentivise using "the full mining power" of the network towards cracking a key pair. at a stretch, an address which has spent inputs and still holds a balance is vulnerable to public key factorisation (i don't know if that's the right term for elliptic curve key pairs), but there is no incentive to publicise the private key for anyone who finds it.
> although I am not an expert on cryptography, I am an expert on software and the products of software groups
the author is not named anywhere. the about page is the template "This is an example of a page." filler.
now i find it embarrassing that i mistook any of it as something meant to be taken seriously.
anyway, i'm done here. bad post.
> I believe that any forensic analysis of the bitcoin protocol would reveal the same results as I have posited. [sic]
Which assumes there has been no such thing to this date, which I doubt. This post is riddled with "likely" and "I believe" and stuff like that, and he came up with all that after reading a blog post by some guy explaining the protocol. I'd have thought that it'd take more than a couple of random accusations to reach the first page...
Still, given that we can attach arbitrary data to transactions, and the easy accessibility of the various services with which we can look them up, the whole network does make for a nice replacement for your CnC server, doesn't it?
As a means to outsource SHA256 cracking it would be patently useless. To crack a hash you need a collision. Bitcoin mining doesn't produce collisions, it produces "hash is smaller than target" results. But even if you'd assume there'd be a value in that answer, it's still useless, because you can't dictate the hash of the previous block (which is included in the hash of the current block), and you can't dictate the transactions of a block a miner would include (which also go into the hash). Since you can neither dictate input nor output nor get a collision answer, it'd be a pretty stupid tool for attacking SHA256.
It would also be useless as a means to attack EC-hashes, since miners don't try to guess these, and the flavor of EC-hashes used in bitcoin is unique, it doesn't overlap with the ones usually used in TLS.
See this is the reason why people who're not programmers shouldn't comment on things todo with programming. Especially if you've never designed and implemented a protocol, you shouldn't comment on protocols. If you've never used cryptographic hash functions, you shouldn't comment on them. If you've never understood the bitcoin mining process, you shouldn't comment on it. As a general rule of thumb, don't comment on things with conclusions, you can't support, because you have no clue.
So where did this code "come from"??. Cue grasshoppers and frogs.
Im so glad its up on github though. Makes me feel warm and fuzzy all over.
So your sole acumen far as can be determined is setting up a blog and reading another bloggers blog entry. Yeah, tons of experience there.
So, I've been writing software for close to 20 years, and I've been doing it for a living every for the last 15 years, 6 of which I've been doing that as a freelancer.
- My linkedin page: http://www.linkedin.com/in/pyalot
- Github: https://github.com/pyalot
- Twitter: https://twitter.com/pyalot
- My blog: http://codeflow.org/
- Some other stuff I do: http://webglstats.com/
- Specifications I published: http://www.khronos.org/registry/webgl/extensions/WEBGL_depth... http://www.khronos.org/registry/webgl/extensions/OES_element... http://www.khronos.org/registry/webgl/extensions/EXT_texture... http://www.khronos.org/registry/webgl/extensions/EXT_frag_de... http://www.khronos.org/registry/webgl/extensions/EXT_sRGB/ http://www.khronos.org/registry/webgl/extensions/proposals/E...
For the record, I only wrote PHP twice in my life, once when I was a wet behind the ears noob back around 18 years ago, and once when I was forced to do it on a short snippet around 8 years ago.
Your creds are? (nill?)
Specialized hardware is anything but open, and the overhead to fabricate chips is not insignificant.
Manufacturing rack-mounted rigs, and programming FPGAs might be within the reach of small-time, chincey, fly-by-night companies, but I'm not so sure about nanometer scale LGA packaged chips.
This part right here doesn't exactly dispel my suspicions:
The Bitcoin scripting language [1]
[1] https://news.ycombinator.com/item?id=7162153So we have people purchasing expensive, networked, internet-enabled black boxes and USB sticks, and a complex, specialized scripting language, well-specialized to take advantage of, and/or encourage the donation of spare GPU power.
Given the image at the bottom of the OP's blog article, consider the author's paranoia, specifically with regard to hardware bitcoin mining, via Application Specific Integrated Circuits (ASICs) which, by definition, are not open source. Certainly not to most common users, and certainly not without substantial effort.
...and just to stoke further paranoia (why not?), consider that even a hobbyist artisan hardware hacker (such as Ken Shirriff) might be thwarted from understanding the inner workings of a reverse-engineered processor die:
https://www.schneier.com/blog/archives/2013/09/surreptitious...
https://www.schneier.com/blog/archives/2008/04/designing_pro...
https://www.schneier.com/blog/archives/2008/10/designing_a_m...
If you don't audit your network traffic, or perhaps lack the skill to do so, and the only metric you use to measure the validity of the machine (that's executing arbitrary code on your network) is the balance of your bitcoin wallet going up, then how would you know that your hardware isn't built with dual purpose?
If you're wallet balance rises within the approximate tolerances of an arbitrary expectation, and you're financially compensated accordingly for just letting it cycle, would you question the behavior of the appliance?
Given the premise that no one can truly know the precise moment a block will be discovered through mining, how can anyone be sure that their hardware miners are 100% honest, regarding their activities?
I can't help wondering if this is someone's science project.
He does have a point about there being inconsistencies in the protocol. It's a pretty ugly binary protocol.
That said, the work done by Bitcoin miners is totally useless for bruteforcing anything except double SHA256 hashes, which AFAIK is not used anywhere besides Bitcoin and derived cryptocurrencies. It's certainly not useful for brute forcing ECC keys.