I love a witchhunt as much as the next guy, but blackarrow already responded to this issue, and removed the images... SourcePicture of the X1 is an artist's impression. The original file was another Photoshop and not an actual still image. We have asked a graphic designer to help us with the images as we need to let our customers have an idea how the product will look like. This is how we intend the product to look like. As we are in production stage all we have now are artist's impression and soon rendered images with the proposal that was accepted and we go further with. However, also the rendered images will still be artist's impressions until we will have the machines in hand, out from the factory. Then and only then, we will be able to take still photos. We are afraid the process of creating a product follows this path.
Personally, I bought one of their units, just to see how it plays out. After chastising them for emailing me my account password in plaintext, of course ... (they fixed that immediately after I brought it up, so props there). |
|
|
|
Thanks - some question left for me now. You got a PSU for the boards??? I had no inside my box - ordered too a stack of 8. Hmmm - strange. Sorry for the confusion. I had a coupon from the burnin Avalon fiasco. It was enough to buy a few boards, but there was still some money left over. I used the leftover money to stock up on PSUs and Raspberry Pi's, since cryptx had those in the store. That's why I had the word "free" in quotes. |
|
|
|
|
[Warning, useless post]
Woah, woah, woah. Back that truck up there, buddy. You're quoting realistic specs, quoting a shipped before date, and offering a full refund if not shipped on time?
You'd best pack up and move onto a different market. We only buy from companies that over promise and deliver late 'round these parts.
|
|
|
|
Finally got my order on Monday. It's all set up and hashing. Funnily enough, I harvested the TP-Link router from an Avalon unit to give the Pi running my Fury boards a wifi bridge  Pros:- The board design is sexy.
- All the boards are running solid so far.
- Got a bunch of extra PSUs and Pi's for "free" (leftovers from the burnin coupon).
- The heatsinks are heavy enough to be used as a home defense weapon.
- cgminer is awesome.
- The boards fit together into a tower rig very nicely. Again, great board design.
- Had a bunch of fun getting them set up.
Cons:- Delivered middle of October, instead of early October.
- Missing 2 necessary jumpers.
- Missing 4 stand-offs; had to hack one of the fans on.
- None of the boards perform near 64GH/s. Why cryptx even promised 64GH/s using 16 bitfury is beyond me, let alone 80. The bitfury chips can't go up to 5GH/s; there's a flaw in their design that prevents it, so 80 GH/s per board is improbable. 64GH/s per board would be about as lucky as finding a four leaf clover.
- Paranoid the USB connectors were going to pop off the entire time I was putting the rig together.
- The through-hole soldering on all of the boards is horrifically bad. Nasty globs of solder, cold joints, flux residue splattered everywhere, etc. I cannot fathom even a novice could do this bad a job at soldering. The SMD work is fine; it's just everything that was hand soldered looks like hell.
- Poor public communication from cryptx. Not terrible, but not great.
Overall, I'm pretty neutral about the experience. I knew going in there would be lots of problems, but in my situation the refund was about the same as I was going to see as ROI on these boards so I preferred to get hardware. |
|
|
|
|
Thank you for the updates, btc_uzr!
|
|
|
|
|
Just updated to 0.95; seems to have fixed my problems. Went from 440GH/s, 16% errors, 900W to 530GH/s, 5% errors, 620W. Much better!
As I suspected, this update dropped my voltages from 0.92V to ~0.73V, thus the drop in power usage. Obviously they must have also fixed something else that corrected whatever hashrate issues units like mine were having.
|
|
|
|
Reporting my experience so far: I have one of the duds. v0.9.4, case off, box fan. Only 440 GH/s, ~16% error rate, and 900W. Using Bertmod 0.2 I was able to look at the voltages and such. Looks like my unit is being overvolted to 0.92V on all the modules. As far as I can tell the nominal voltage is 0.7V, so I think their firmware is choosing to overvolt to compensate for bad chip(s). So all the dies are pulling 50 Amps, driving my total power usage to 900W. I suspect that not all of the dies are bad; only some. But the firmware is indifferent to the particular needs of each die, and simply overvolts all of them to keep up the hashrate. If that's the case, I could see a future update which only overvolts the under-performing dies, reducing my overall power consumption. It's better than nothing, and I sincerely understand that KNC's schedule was extraordinarily tight. I commend them for meeting their goals on such an ambitious project. It's still disappointing to see some people getting good units, and others getting bad units, though EDIT: I poked around with the firmware. It seems that I was wrong about it setting the voltage to 0.9V automatically. Rather, it looks like it's that way from the factory; the firmware isn't setting the voltage. Though the screenshot here shows someone at 0.7V. So for whatever reason KNC is shipping some units at 0.7V and some at 0.9V. On top of that, unless the DC/DC modules they're using have changed, these are only rated for 40A. Mine are pushing 50A. ... I did discover, though, that it's possible to digitally tweak the voltage. Perhaps a future firmware upgrade will take advantage of that. I don't have the balls to try it myself manually. |
|
|
|
Brainwallet.org is borked. I commented on other issues with signing in this thread. Your issue is probably related. |
|
|
|
but is this what the default Bitcoin behavior is? What do you mean by "default Bitcoin"? You mean Bitcoin-QT? Bitcoin-QT picks a random integer in the appropriate range; it doesn't use SHA-256. So, it doesn't have this problem. Brainwallets use SHA-256. HD wallets use HMAC_SHA512. Are you referring to any of those in particular? The correct response, if using SHA-256 to generate a key, is to reject the key and try again. As pointed out though, it's all moot when writing an application. When writing a standard you'd want to get details like this right. But during implementation this isn't important, because the code you write to check for it will never trigger. |
|
|
|
I'd like to contribute some test vectors of my own.
The test vectors are fully canonical signatures with S components <= order/2. They contain both vectors were the S component had to be flipped and not flipped. Awesome! I just double checked them against my code, and they all look good. |
|
|
|
if you look at the current code in git master, it just subtracts order/2 when s > order/2 - pretty simple. Satoshi client git? Mmmm... https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L209 if (BN_cmp(sig->s, halforder) > 0) {
// enforce low S values, by negating the value (modulo the order) if above order/2.
BN_sub(sig->s, order, sig->s);
}
It doesn't subtract order/2. It's s = order - s. Another way, now used by bitcoin-qt git, is to make s < order/2. You mean s <= order/2, right? I'm a bit pedantic about this stuff... |
|
|
|
Tried both with the same result (invalid sigs). This works for me: if sig.s > (q / 2):
sig.s = q - sig.s
Where q is the order of the curve. Note that no modulus is needed for the subtraction. It would only ever result in an invalid value if s were 0, but s can never be 0 (forbidden by ECDSA). Here are my test vectors, updated with this rule: # Test Vectors for RFC 6979 ECDSA, secp256k1, SHA-256
# (private key, message, expected k, expected signature)
test_vectors = [
(0x1, "Satoshi Nakamoto", 0x8F8A276C19F4149656B280621E358CCE24F5F52542772691EE69063B74F15D15, "934b1ea10a4b3c1757e2b0c017d0b6143ce3c9a7e6a4a49860d7a6ab210ee3d82442ce9d2b916064108014783e923ec36b49743e2ffa1c4496f01a512aafd9e5"),
(0x1, "All those moments will be lost in time, like tears in rain. Time to die...", 0x38AA22D72376B4DBC472E06C3BA403EE0A394DA63FC58D88686C611ABA98D6B3, "8600dbd41e348fe5c9465ab92d23e3db8b98b873beecd930736488696438cb6b547fe64427496db33bf66019dacbf0039c04199abb0122918601db38a72cfc21"),
(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140, "Satoshi Nakamoto", 0x33A19B60E25FB6F4435AF53A3D42D493644827367E6453928554F43E49AA6F90, "fd567d121db66e382991534ada77a6bd3106f0a1098c231e47993447cd6af2d06b39cd0eb1bc8603e159ef5c20a5c8ad685a45b06ce9bebed3f153d10d93bed5"),
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15c58dfcc1e00a35e1572f366ffe34ba0fc47db1e7189759b9fb233c5b05ab388ea"),
(0xe91671c46231f833a6406ccbea0e3e392c76c167bac1cb013f6f1013980455c2, "There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them!", 0x1F4B84C23A86A221D233F2521BE018D9318639D5B8BBD6374A8A59232D16AD3D, "b552edd27580141f3b2a5463048cb7cd3e047b97c9f98076c32dbdf85a68718b279fa72dd19bfae05577e06c7c0c1900c371fcd5893f7e1d56a37d30174671f6")
]
Note that I added one more vector, since all of the existing ones resulted in s being larger than order/2. And here is the code I've been using to play around: import sys
import ecdsa
import hashlib
from types import MethodType
from ecdsa.util import number_to_string
from hmac_drbg import HMAC_DRBG
def sign_number_rfc6979 (self, number, entropy=None):
q = self.curve.order
x = self.privkey.secret_multiplier
assert (q.bit_length () % 8) == 0
# k = HMAC_DRBG (private_key || SHA256 (message))
entropy = number_to_string (x, q) + number_to_string (number, q)
drbg = HMAC_DRBG (entropy=entropy)
k = drbg.generate (q.bit_length () / 8)
k = int (k.encode ('hex'), 16)
# In strict RFC 6979, we should loop until a suitable k was found.
# However, such a condition occuring is ~impossible, and so we simply
# throw an error if it happens.
assert 1 <= k < q
print "Chosen k: %X" % k
sig = self.privkey.sign (number, k)
if sig.s > (q / 2):
sig.s = q - sig.s
assert sig.s <= (q / 2)
print "moop"
return sig.r, sig.s
sk = ecdsa.SigningKey.generate (curve=ecdsa.curves.SECP256k1, hashfunc=hashlib.sha256)
sk.sign_number = MethodType (sign_number_rfc6979, sk, ecdsa.SigningKey)
open ('sk.pem', 'w').write (sk.to_pem ())
message = open ("data", "rb").read ()
sig = sk.sign (message, hashfunc=hashlib.sha256, sigencode=ecdsa.util.sigencode_der)
open ("data.sig", 'wb').write (sig)
# Test Vectors for RFC 6979 ECDSA, secp256k1, SHA-256
# (private key, message, expected k, expected signature)
test_vectors = [
(0x1, "Satoshi Nakamoto", 0x8F8A276C19F4149656B280621E358CCE24F5F52542772691EE69063B74F15D15, "934b1ea10a4b3c1757e2b0c017d0b6143ce3c9a7e6a4a49860d7a6ab210ee3d82442ce9d2b916064108014783e923ec36b49743e2ffa1c4496f01a512aafd9e5"),
(0x1, "All those moments will be lost in time, like tears in rain. Time to die...", 0x38AA22D72376B4DBC472E06C3BA403EE0A394DA63FC58D88686C611ABA98D6B3, "8600dbd41e348fe5c9465ab92d23e3db8b98b873beecd930736488696438cb6b547fe64427496db33bf66019dacbf0039c04199abb0122918601db38a72cfc21"),
(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140, "Satoshi Nakamoto", 0x33A19B60E25FB6F4435AF53A3D42D493644827367E6453928554F43E49AA6F90, "fd567d121db66e382991534ada77a6bd3106f0a1098c231e47993447cd6af2d06b39cd0eb1bc8603e159ef5c20a5c8ad685a45b06ce9bebed3f153d10d93bed5"),
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15c58dfcc1e00a35e1572f366ffe34ba0fc47db1e7189759b9fb233c5b05ab388ea"),
(0xe91671c46231f833a6406ccbea0e3e392c76c167bac1cb013f6f1013980455c2, "There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them!", 0x1F4B84C23A86A221D233F2521BE018D9318639D5B8BBD6374A8A59232D16AD3D, "b552edd27580141f3b2a5463048cb7cd3e047b97c9f98076c32dbdf85a68718b279fa72dd19bfae05577e06c7c0c1900c371fcd5893f7e1d56a37d30174671f6")
]
print ""
for vector in test_vectors:
priv = ecdsa.SigningKey.from_secret_exponent (vector[0], ecdsa.curves.SECP256k1, hashfunc=hashlib.sha256)
priv.sign_number = MethodType (sign_number_rfc6979, priv, ecdsa.SigningKey)
print vector[1]
sig = priv.sign (vector[1], hashfunc=hashlib.sha256).encode ('hex')
print sig
assert str (sig) == vector[3]
print ""
The first part of it generates a random private key, writes that to sk.pem, signs the data read from the "data" file, and writes the signature to "data.sig". So the results can be tested against openssl: openssl dgst -sha256 -prverify sk.pem -signature data.sig data
|
|
|
|
So x=0, means y2=7, which has no solution for an integer y, so there is no point on the curve with x coordinate 0.
Same for x=1,2,3,4,... I think you can go on for a while before finding a solution that way. We aren't dealing with your ordinary, run-of-the-mill integers here. We're dealing with a finite field! y 2 = 1 3 + 7 has a solution (two, in fact). It's 4218F20AE6C646B363DB68605822FB14264CA8D2587FDD6FBC750D587E76A7EE. Square that number, modulus our prime, and you get 8. So yeah, G could have been selected as an obvious, nothing-up-my-sleeve number. It wasn't. I'd bet on it being some sentimental thing, like the hash of the author's name or something. |
|
|
|
Shenzhen, 26 September, 2013: Black Arrow is proud to announce that it has upgraded the specifications of its Minion chip to 100 Ghash (up to 128 Ghash when overclocked). Very cool. Congrats! |
|
|
|
Asking a user to come up with a password with sufficient entropy is a challenge. That is why key stretching should be used in any key derivative function. On a related note, I know of a way to harden weak passwords well beyond what a KDF could do. I might make a thread about it later. |
|
|
|
You don't immediately change your password when that happens? I would, but if their merchant package is emailing me my plaintext password in a welcome email, it's likely their merchant package is also storing the passwords in plaintext. I already don't feel comfortable sending large sums of money to a foreign company for a money printing machine; having an insecure website doesn't help me feel more comfortable. That said, I do have some respect for blackarrow. They've been professional from what I've seen, and have a decent track record. That's why I wanted to buy-in, even if the unit isn't going to ROI. I like buying cool tech and supporting cool companies. Consider my warning notice overly harsh, on purpose, so as to nudge them into beefing up security. |
|
|
|
And in the area's I am an expert, I would not stomp - like quite a few people did in this thread - on someone who obviously was not an expert, trying to figure something out. Certainly, but a lot of fields don't involve quite the same risks that cryptography does; doubly so when the cryptography is being used to secure large sums of money. No one is going to die from a bad theory about quantum gravity Also, cryptography is one of those strange scientific fields where we can't formally prove much of our work*. We can build "spherical cows" around the work, but that's about it (most of the time). Really, our best tools are history, paranoid minds, and big scary clubs to fend off the NSA. Because of those reason, the problem of sophomorism will be more prevalent 'round cryptography. |
|
|
|
|
WARNING: When registering for their website, your password gets emailed to you. A big security no-no. Nothing like feeling safe handing over a couple grand. I think I'll cancel my order.
Fixed.
|
|
|
|
Well, that explains what happened on my DHL tracking. It got me all excited too, saying it had been delivered  This is really quite disappointing; was hoping to get the new miners in in-time to replace the current power hungry beasts. Oh well. No hard feelings against the BitCentury team; I appreciate the full refund and I'm sure everyone else will. Thank you for the communication and professionalism. |
|
|
|
|
Show Posts
