I've been glancing through the Bitcoin Core code, but it'll take me awhile to piece everything together. Hoping someone can drop some knowledge to help speed things up  My question is, during initial block sync, Bitcoin Core connects to a bunch of nodes. Okay. Now it needs to find the main chain. So say we send to a bunch of them (  . Say some of them are lying and have fake chains. So the you get back from different peers ends up being different. Which chain do you choose to download? Suppose there are several fake chains you get presented with, and 1 real chain. How do you tell them apart without downloading all of them? Maybe the fake chains have more work for awhile, and then (eventually) less work than the real chain? What if the real chain has more work for awhile, but then less for a bit, until it eventually overtakes much later in the height. What's the logic that allows you to find the real chain in those scenarios? One thing I've thought of so far is to keep track of, say, 8 header chains. Call repeatedly on all 8 of your peers, potentially forming a variety of header chains. Do that until you've exhausted all potential chains. This should only consume ~320MB of disk space right now, so easy enough. Find the longest (most work). Start downloading the blocks for it. If you ever encounter an invalid block, store that block's hash in an invalid database, ban the peer that gave it to you and any peers that broadcast that header as part of their responses. Delete that header chain. Now begin downloading the next longest chain. So forth and so forth until you find the longest valid chain. You should eventually find it, because each time you find an invalid block you ban at least 1 peer and thus connect to 1 new peer. So you'll sniff around the network until you find a trustable peer. The only failure in that logic I see is if all 8 peers have totally valid, but truncated chains. Presumably you could continually swap at least 1 peer every hour or so, and eventually find the real chain. But watching Bitcoin Core's network logs, it looks like it begins calling to download chains immediately after it gets its first back. So is it doing more-or-less what I describe above, but just begins downloading the current best header chain optimistically? I suppose the worse case there is it'll have wasted bandwidth and have to throw away a bunch of blocks. Thanks! |
|
|
|
The question is whether people would trust a smaller site to protect their privacy when they prove ownership of large quantities of Bitcoin. The only information I get from "voters" is a Bitcoin address, a signature, and an IP. There's not much privacy to be lost there (besides, I don't log IP with the votes). If users are concerned about IP, they can just hit the site through a proxy/Tor. There's also the fact that the economy doesn't have to dictate everything, because that would favour richer people. Yeah, I've struggled with this. Thing is, though, Bitcoin as it exists today is already dictated by Proof of Stake. For those who believe that miners control Bitcoin, Proof of Work is just a proxy for Proof of Stake. A really poor proxy. The more money you have, the more mining power you can buy. But Proof of Work puts a layer of ASIC between, which is why it's a poor proxy. For those who believe the economic powers of Bitcoin control the network (ala BIP148), that's also a proxy for Proof of Stake. The economic powers are usually also the ones with a lot of coin. It'd be nice if we had a Proof of Person system. 1 vote per human. Democracy. But that's not feasible in a decentralized system. So we ultimately depend on alternatives, most of which are just forms of Proof of Stake. You can cheat mining power, you can manipulate the number of full nodes, but you can't fake Proof of Stake. |
|
|
|
I just finished the alpha version of www.BitcoinVoice.comThe recent debates about SegWit, Hardforking, etc and concerns about astroturfing led me to look for some way to cut through the bullshit. I wanted to build a platform where we could gauge the Bitcoin community's opinions, but in a way that's verifiable and meaningful; immune to astroturfing. So I've spent the past few weeks putting together BitcoinVoice. Basically it's a list of polls, and anyone can vote in them. Votes are cast using Bitcoin signatures, so they can be verified. Each vote is weighted by the balance of the associated address. Proof of Stake without protocol changes! I'm calling this an alpha release. It works just fine, but ... it's ugly as hell Sorry! Feedback, comments, etc are totally welcome! Please let me know what you think. I really hope this can be useful! Thanks for reading! NOTE: The friendly folks over at #bitcoin informed me that a similar site already exists over at bitcoin.com ... which I didn't know about. I guess ... at least BitcoinVoice isn't bitcoin.com? |
|
|
|
|
Thank you for the update, blackarrow.
|
|
|
|
I don't think you would have been able to put both rigs on a single circuit even if they had achieved the original 0.6w/gh. 0.6w/gh would allow 2TH to work off a normal (20Amp) household circuit safely. So yeah, I suppose you could undervolt and do it, but that seems a waste. I'd rather run off two circuits and overvolt. |
|
|
|
From BA:
27/02/2014 - Production Update Thank you for posting the update, goozman96. 0.75W/GHs will be about 1.17W/GHs at the wall (80% efficiency on the ASIC voltage regulators, and 80% on the PSU). That's ~2300Watts for the X3, which is well over what a household circuit can muster. Little hobbyists like myself are going to have to put half the X3 on one circuit, and half on another. |
|
|
|
Minion ASIC - Tapeout complete
23/02/2014: We are happy to report that VeriSilicon has completed our Minion ASIC yesterday and taped out to Global Foundries today.
Black Arrow is working hard to improve the existing designs of our miners and ensure that the pre-ordered miners will be assembled and dispatched immediately after the chips arrive from the factory.
Congratulations! |
|
|
|
nor do I think he could be called a scammer for selling software, unless he is lying about something. The current title of his thread is: "[WTS] OpenCL Based, Optimized BTC Private-Key Cracker with Sources [WITH VIDEO]" The first post says things like: And who knows, this tool is giving you good chances to get one of these lost 10 MILLION US$ accounts This project is [...] to recover lost private keys. Working on real bitcoin network with real addresses and real coins. This again shows you that there is an infinite number of weak bitcoin addresses. The only thing in the first post of that thread that indicates that this isn't what people think it is, is the following: Randomly generated Bitcoin Adresses are used (however they are all special-weak). Which is incredibly confusing, but alludes to the fact that the program only works on special keys that no one is likely to ever find in the wild. So, if all that isn't misleading, I don't know what is. I guess if what he's doing is acceptable, I might as well sell my "OpenCL Based, Optimized BTC Miner with Sources, 10 TH/s". It works with any SHA-256 Proof of Work (however they are all special-weak)! You could crack that 10 MILLiON US$ chain of blocks! |
|
|
|
Here's what's going on. Evil-Knievel has pre-computed a couple points on the secp256k1 curve. Specifically points where the exponent is of the form 2**N. (see 1,2) He then wrote a program, the "cracker", that can search the area around those points. If a Bitcoin key-pair lies close to one of those points, his program will find it. This isn't dangerous. It's improbable (~impossible) that any uniformly random Bitcoin key-pairs are weak to his pre-computed points. The secp256k1 keyspace is, for all practical purposes, infinitely large. It doesn't matter if Evil-Knievel had a gabillion-gajillion pre-computed points and all the computing power in the universe. His approach still wouldn't crack a normal Bitcoin key-pair. To me, having just read Evil-Knievel's thread, it sounds like he's insinuating that there is danger here. He's insinuating that a uniformly random Bitcoin key-pair has a reasonable chance of being tractably close to one of his pre-computed points. There is no reasonable chance of this, and his claims are ridiculous. The thread should be closed as a scam, because he's asking for money on misleading premises. If he has nothing to hide, why was his HTML generator obfuscated? I'll help and de-obfuscate the generator for everyone. Here's the algorithm: Pick a random N, [128, 255].
Pick a random M, [1, 20000000].
Spit out 2**N - M as a private key.
See the problem? He just needs to take a generated public key, add G to it ~20,000,000 until it matches one of the 128 pre-computed keys (which are of the form 2**N), and BAM the private key is "cracked". This doesn't make Bitcoin weak. It never will. It's a rainbow table attack. But mankind will never have enough computational and storage power to make rainbow tables work against secp256k1. As for the bitprobing.com "project". That's a load of bollocks. If you don't believe what the experts have to say about ECDSA, that's fine. But go learn group theory and number theory first, before asking the public to help run unsubstantiated "experiments." I know these forums are intentionally soft-modded, and appreciate that to an extent. But it's times like these I wish the forums were more aggressively moderated so that Evil-Knievel could just be banned for misleading and scamming people. (1) Actually, he fscked this up. He interpretes the decimal result of 2**N as hexadecimal. (2) 2**128 is 340282366920938463463374607431768211456. Interpret that as a hexadecimal private key and you get a public key of 04864f29af3191e135f5c78499271961f2313110fb2a296bf072733475529da1fb4d5cef64d1212 a946775bfb2db5319fb618089ae8806d618f44d68d3bdb18650. The least significant 32-bits of the X coordinate is 0x529da1fb. That matches one of the constant in his script. I assume the rest match similarly. |
|
|
|
|
@vs3, I'm not much of an analog guy, but isn't it difficult for a QFN package to evenly distribute 50 watts of clean power? I was under the impression that BGA style packages are used for A) large pin counts, and B) power distribution. Point B being salient here. BGAs allow you to get caps closer to the die. And with designs like mining chips, power distribution is key.
Again, I'm not an analog guy. I suppose BlackArrow could chime in here, but honestly I think they have more important things on their mind. Time to market is so much more important than getting the cost of PCB and assembly down.
|
|
|
|
We've added preliminary renders of how (half of) X3 will look like.
Very sexy, thank you for the update! |
|
|
|
|
Okay, I tried tweaking the cgminer.sh script to setup my board with a PLL setting of 0x01,0x68. Power consumption did not change. I also tried 0x00,0x68; again no change. This was tested with a restart of the service. I haven't tried a reboot (would need to modify the BBB's flash or something). It's possible the PLL settings can be set only once per power-cycle, but that'd be a bit out of the ordinary.
|
|
|
|
Take a look in /etc/init.d/cgminer.sh and you will have your answer to why nothing changed. Awesome, thanks for the heads up. I knew I should have done a more thorough grep of the firmware... I'll take a look, and maybe I'll *gulp* tweak those values. |
|
|
|
|
Well I bit the bullet and tweaked the 0x86 register on one die. I tried a few different values, 0x0168, 0x0068, and 0x01ff. initc did not seem to throw any errors, and everything hashed like normal. I did not notice a difference in power consumption on any of the settings, so I can only assume the hash clock was not affected.
So ... there goes that theory.
|
|
|
|
EEPROM Checksum AlgorithmI finally reverse engineered the algorithm KNC is using to checksum the ASIC board EEPROMs. I had initially thought it was just SHA-256, but a quick try with that failed. After digging into the code my original hypothesis proved correct, it's SHA-256, but KNC has ... taken some liberties with SHA-256. It's pretty confusing code. First, the checksum function is completely broken unless the data being checksummed is a multiple of 64 bytes (the data in the EEPROMs is). Second, they use SHA-256 without any padding. Third, they use SHA-256 with their own KNC flavored initial state. Their initial state is the ASCII representation of "KnCMiner placeholder SHA256 init". I've recreated the important bits of the algorithm in Python: # SHA-256 implementation copied from pypy/lib_pypy/_sha256.py, which is licensed under the MIT license:
# https://github.com/pypy/pypy/blob/master/lib_pypy/_sha256.py
# https://github.com/pypy/pypy/blob/master/LICENSE
import struct
SHA_BLOCKSIZE = 64
SHA_DIGESTSIZE = 32
def new_shaobject():
return {
'digest': [0]*8,
'count_lo': 0,
'count_hi': 0,
'data': [0]* SHA_BLOCKSIZE,
'local': 0,
'digestsize': 0
}
ROR = lambda x, y: (((x & 0xffffffff) >> (y & 31)) | (x << (32 - (y & 31)))) & 0xffffffff
Ch = lambda x, y, z: (z ^ (x & (y ^ z)))
Maj = lambda x, y, z: (((x | y) & z) | (x & y))
S = lambda x, n: ROR(x, n)
R = lambda x, n: (x & 0xffffffff) >> n
Sigma0 = lambda x: (S(x, 2) ^ S(x, 13) ^ S(x, 22))
Sigma1 = lambda x: (S(x, 6) ^ S(x, 11) ^ S(x, 25))
Gamma0 = lambda x: (S(x, 7) ^ S(x, 18) ^ R(x, 3))
Gamma1 = lambda x: (S(x, 17) ^ S(x, 19) ^ R(x, 10))
def sha_transform(sha_info):
W = []
d = sha_info['data']
for i in xrange(0,16):
W.append( (d[4*i]<<24) + (d[4*i+1]<<16) + (d[4*i+2]<<8) + d[4*i+3])
for i in xrange(16,64):
W.append( (Gamma1(W[i - 2]) + W[i - 7] + Gamma0(W[i - 15]) + W[i - 16]) & 0xffffffff )
ss = sha_info['digest'][:]
def RND(a,b,c,d,e,f,g,h,i,ki):
t0 = h + Sigma1(e) + Ch(e, f, g) + ki + W[i];
t1 = Sigma0(a) + Maj(a, b, c);
d += t0;
h = t0 + t1;
return d & 0xffffffff, h & 0xffffffff
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],0,0x428a2f98);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],1,0x71374491);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],2,0xb5c0fbcf);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],3,0xe9b5dba5);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],4,0x3956c25b);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],5,0x59f111f1);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],6,0x923f82a4);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],7,0xab1c5ed5);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],8,0xd807aa98);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],9,0x12835b01);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],10,0x243185be);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],11,0x550c7dc3);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],12,0x72be5d74);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],13,0x80deb1fe);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],14,0x9bdc06a7);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],15,0xc19bf174);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],16,0xe49b69c1);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],17,0xefbe4786);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],18,0x0fc19dc6);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],19,0x240ca1cc);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],20,0x2de92c6f);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],21,0x4a7484aa);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],22,0x5cb0a9dc);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],23,0x76f988da);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],24,0x983e5152);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],25,0xa831c66d);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],26,0xb00327c8);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],27,0xbf597fc7);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],28,0xc6e00bf3);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],29,0xd5a79147);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],30,0x06ca6351);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],31,0x14292967);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],32,0x27b70a85);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],33,0x2e1b2138);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],34,0x4d2c6dfc);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],35,0x53380d13);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],36,0x650a7354);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],37,0x766a0abb);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],38,0x81c2c92e);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],39,0x92722c85);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],40,0xa2bfe8a1);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],41,0xa81a664b);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],42,0xc24b8b70);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],43,0xc76c51a3);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],44,0xd192e819);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],45,0xd6990624);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],46,0xf40e3585);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],47,0x106aa070);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],48,0x19a4c116);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],49,0x1e376c08);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],50,0x2748774c);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],51,0x34b0bcb5);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],52,0x391c0cb3);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],53,0x4ed8aa4a);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],54,0x5b9cca4f);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],55,0x682e6ff3);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],56,0x748f82ee);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],57,0x78a5636f);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],58,0x84c87814);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],59,0x8cc70208);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],60,0x90befffa);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],61,0xa4506ceb);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],62,0xbef9a3f7);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],63,0xc67178f2);
dig = []
for i, x in enumerate(sha_info['digest']):
dig.append( (x + ss[i]) & 0xffffffff )
sha_info['digest'] = dig
whole_data = "4131303030303037424245434600000000000000000000000000000000000000000000000000000000000000000100000800000000000000ffffffffffffffff003084005687840174fa8402c03484038f7a860001d1860101d1860201d1860301d18500db118501b7d785023cce85033d1ce7e375f7fe6521ea8991253ae7ed".decode ('hex')
sha_info = new_shaobject ()
sha_info['digest'] = [0x4b6e434d, 0x696e6572, 0x20706c61, 0x6365686f, 0x6c646572, 0x20534841, 0x32353620, 0x696e6974]
sha_info['data'] = [ord (whole_data[i]) for i in range (0, 64)]
sha_transform (sha_info)
sha_info['data'] = [ord (whole_data[i]) for i in range (64, 128)]
sha_transform (sha_info)
for i in range (8):
print "%08X" % sha_info['digest'][i]
whole_data in the code above is a copy of the data off one of my ASIC board EEPROMs (without the first 32 bytes, which is the stored checksum). The code prints the calculated checksum, which matched the EEPROM I tested. So, yay, but it really makes me wonder what the KNC developers were doing. I can understand not doing the padding and only working on multiples of 64 bytes; the devs probably had higher priorities. I just don't understand the initial state thing. The real SHA-256 initial state values exist within initc. It's just that the checksum function overwrites them. Wonky. Progress UpdateWe can use this to update our EEPROMs and have initc accept the checksum. I still don't know how to make sense of the PLL configuration data, but some progress is better than none. I also manually decompiled the write_eeprom function of initc. It's nothing special though, I can craft modified EEPROM data by hand easily and just use the command line to write it. Regarding the PLL configuration data. When write_eeprom is building a new EEPROM image it first fills the buffer with random data (calling rand()). This explains why the padding on all the EEPROMs was garbage data. I'm not sure why they do it, though. It leads me to believe, though, that KNC's developers may have a habit of filling unused data with rand. Perhaps the PLL 0x84 and 0x85 registers are unused in the current ASIC revision? Maybe they were used by their FPGA prototype(s). Most importantly, perhaps only 0x86 is important, and is simply a multiplier value (or two 8-bit values, Multiplier and Divider). I don't know what the chip's input clock frequency is, so it's hard to make an educated guess about how to interpret the current setting. That theory could be tested by adjusting the 0x86 registers of the PLL data and ... seeing what happens. Though if the theory is wrong, doing so could potentially set the chips a blaze. I don't personally want to try that (yet) ... if anyone with bigger balls than I wants to do so, feel free to try... I'll continue decompiling initc to see if there are more hints as to the meaning of the PLL data.
|
|
|
|
|
Someone was kind enough to share their EEPROM dumps with me. The basic structure for the PLL data is the same; 4 sets of 3 values. The values for "0x86" are still always 0xd101. The other values, though, continue to appear random.
So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
|
|
|
|
Since KNC themselves have released no information on how to overclock our units. I have started hacking the firmware myself to achieve that goal. Here is what I have learned so far. TL;DRI have not yet succeeded in discovering how to change the hashing clocks. It appears possible. The VRM voltages should be easy to adjust over I2C. Though I do not recommend it, yet. initccgminer itself adjusts neither the voltage nor the clock. Instead, there is a program called "initc" that runs on start-up. The code for this program is not currently available. This program appears to be responsible for a whole host of tasks. It runs various self tests on the unit, loads the FPGA's bitstream, checks system configuration, etc. Based on what I have seen poking around, (this is conjecture until confirmed) it is also responsible for setting up the VRMs, and the per-die PLLs. Per Board EEPROMIt seems that every ASIC board has an EEPROM on it. This EEPROM contains a checksum, serial number, PLL configuration data, a failure flag, and I'm not sure what else. Only about 128 bytes of data or so. They can be read like so: "cat /sys/bus/i2c/devices/X-0050/eeprom | hexdump -C" where X is 3, 4, 5, 6, 7, 8. I have a Jupiter, so I have 3,4,5,6. The checksum is the first 32 bytes. I don't know what algorithm they're using for checksum. I would have thought SHA-256, but that didn't seem to match. Luckily it doesn't matter; we can just mod initc itself to calculate the checksum for us, when the time comes. The PLL configuration data is 48 bytes long. It's located at 0x60 in the EEPROM. The first two bytes is the data length (48 bytes), and is not included in the length. There appears to be 3 16-bit numbers for each PLL, with the addresses 0x84, 0x85, and 0x86 associated with them. There are 4 PLLs per ASIC board, since each chip has 4 dies in it. One of the numbers is always 0xd101. The others I haven't figured out. They appear to be completely random, which is odd. It's entirely possible that they are encrypted somehow, if KNC had intended to restrict our ability to overclock. If anyone has some insight here, that would be appreciated. I know that initc loads this data, verifies the size of the PLL configuration data, and checks the checksum, but I haven't yet reverse engineered the parts of the code that would actually use this data ... if it's used at all. I'm guessing the data is pushed to the ASICs over SPI. Phone HomeI also discovered that initc contacts http://192.168.100.1:8080/%s?beagleserial=%s. I don't know under what circumstances it does so, nor all the combinations of strings it'll format that with. My guess: it is either part of factory set-up or their hosting facility. Each miner, on bootup, contacts a master server to retrieve pool information and such. Either this always happens, only happens once, or only happens when some flag is set. But we won't know for sure until I finish reverse engineering the program. This part of it isn't my priority though. Reverse Engineered Source CodeI've manually de-compiled about 10% of initc so far. It sure would be nice if KNC just released this code  This will have to suffice in the meantime. I'm hoping initc manipulates the PLL configuration data, so we can gain more insight into its format. At the very least, it'll be nice to know what this program is doing as a whole. My EEPROM Dumpsroot@Jupiter-6AB:~# cat /sys/bus/i2c/devices/3-0050/eeprom | hexdump -C
00000000 75 22 4a 27 1b d8 26 f5 fc c5 0c 5c 28 23 28 63 |u"J'..&....\(#(c|
00000010 4d 6c 01 9f 00 55 a2 4c 79 d9 73 62 d3 db 51 27 |Ml...U.Ly.sb..Q'|
00000020 41 31 30 30 30 30 30 37 42 39 41 30 45 00 00 00 |A1000007B9A0E...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 04 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 0d f1 84 01 c9 e7 84 02 f9 14 84 03 |.0..............|
00000070 91 65 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.e..............|
00000080 01 d1 85 00 c2 cd 85 01 f5 31 85 02 eb 66 85 03 |.........1...f..|
00000090 03 01 aa 28 91 14 a0 64 12 16 f1 e5 a6 5d 1b a5 |...(...d.....]..|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/4-0050/eeprom | hexdump -C
00000000 5d 90 81 61 21 96 61 2f 79 aa da 0e b0 c2 97 1b |]..a!.a/y.......|
00000010 96 a4 82 86 a3 eb cb 11 68 87 a0 6c a1 c6 ab d6 |........h..l....|
00000020 41 31 30 30 30 30 30 38 30 30 31 36 33 00 00 00 |A100000800163...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 94 50 84 01 82 5c 84 02 29 a8 84 03 |.0...P...\..)...|
00000070 ab 7b 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.{..............|
00000080 01 d1 85 00 e6 d0 85 01 57 f8 85 02 60 5b 85 03 |........W...`[..|
00000090 b0 48 a7 af 63 41 fd 14 5e 7c f5 95 66 47 59 d0 |.H..cA..^|..fGY.|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/5-0050/eeprom | hexdump -C
00000000 5b 59 fc 0f 94 ab a3 d7 d8 7c 91 6b a5 29 d6 51 |[Y.......|.k.).Q|
00000010 4a 0f d6 6b e6 35 5e a5 a4 59 04 5f f1 26 1e 19 |J..k.5^..Y._.&..|
00000020 41 31 30 30 30 30 30 37 42 42 45 43 46 00 00 00 |A1000007BBECF...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 |................|
00000050 08 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 56 87 84 01 74 fa 84 02 c0 34 84 03 |.0..V...t....4..|
00000070 8f 7a 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.z..............|
00000080 01 d1 85 00 db 11 85 01 b7 d7 85 02 3c ce 85 03 |............<...|
00000090 3d 1c e7 e3 75 f7 fe 65 21 ea 89 91 25 3a e7 ed |=...u..e!...%:..|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/6-0050/eeprom | hexdump -C
00000000 7d 1c cb 21 6e a1 4a ad 65 29 bf af 12 de a3 cd |}..!n.J.e)......|
00000010 76 93 dc e7 0f 8c 28 33 5f 49 b2 86 81 b4 19 d4 |v.....(3_I......|
00000020 41 31 30 30 30 30 30 37 42 41 35 38 41 00 00 00 |A1000007BA58A...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 04 10 00 |................|
00000050 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 f3 49 84 01 cb 1e 84 02 d9 dc 84 03 |.0...I..........|
00000070 b1 58 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.X..............|
00000080 01 d1 85 00 cd 76 85 01 bd b6 85 02 fc f6 85 03 |.....v..........|
00000090 e9 05 cb d2 3f 91 df 4e ac 30 d4 32 25 65 26 e7 |....?..N.0.2%e&.|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
If anyone wants to dump theirs as well, I would be interested in comparing the PLL configuration data. There's also EEPROMs at 0-0050 and 1-0054. One of those is an EEPROM on the Beagle board, I believe, and just contains the Beagle's serial number. The other one I believe is on the IO board. |
|
|
|
For the same reason I'm offering up this other tidbit I ask, because it looks to me like Infinity's facebook, and domain, was created months after the quoted statement began appearing on blackarrow's website. Not to mention that Infinity's miner looks a lot like KNC's Mars prototype ... Point being, someone duplicating blackarrow's copy is not an indication of blackarrow's reputation. Your other tidbit, however, is unsettling... |
|
|
|
Why are you quoting the Infinity, Inc. scam? |
|
|
|
so asking someone to make some pretty renders of possible boxes tells me that you are focusing on the wrong stuff. You make a good and interesting point, though it's not related to the original topic of this thread. Anyway, I agree, the amount of time/effort a company spends on marketing a pre-order product could potentially be used as an indicator of the company's technical capabilities. In this case, I would argue that blackarrow probably already had an established marketing team as part of their company prior to their ASIC announcement. Since they're on payroll, might as well use them. For me personally, I find a company's history to be a better indicator of their merits than anything else. Like a person, you should always bet on a company not changing their habits. That isn't to say that they can't change, but more times than not they will repeat their mistakes. BFL is a prime example. It seems a lot of people forgot that they pulled their same shenanigans back with their original FPGA based product. From what I know of Blackarrow, their customer service has been stellar, but I recall them tripping on a few early delivery schedules with their Icarus clones (IIRC their FPGA supplier fell through). Their habits likely won't change, which is to say that I believe they will deliver (as you seem to agree), but may still run into trouble during their early shipping (as do most companies, to be honest). |
|
|
|
|
Show Posts
