 Show Posts
|
|
Pages: [1] 2 3 4 5 6 »
|
Genauere specs zu den ASICs von Cointerra habe ich hier gepostet: https://bitcointalk.org/index.php?topic=300775.0Der Einfachheit halber hier die Kopie: Foundry: Global Foundries (Dresden), 28nm HPP process
Taktfrequenz: 1.4 GHz (Mindestqualität) bis 2 GHz (maximal)
Die Größe: 10mm x 10mm
Package Größe: 3 dies pro package, 300 mm2 die-Fläche
Hashkerne: 120 pro die, 360 pro package
Hashkern-Architektur: optimierte SHA256 pipeline
Hash rate: 504 GH/s (@1.4 GHz) bis 720 GH/s (@2 GHz)
Hashdichte: 1.68 GH/s/mm2 (@1.4 GHz) bis 2.4 GH/s/mm2 (@2 GHz)
Stromverbrauch: 300 W (@ 0.765 volts), <0.6 W/GH/s
Tape-out: 1. Oktober-Woche
Chassis: 4U rack mount.
Kühlung: Wasserkühlung von CoolIT Systems, Canada. Ausgelegt auf 400 W pro
chip. 3x high speed 12cm Ventilatoren am Rücken des Chassis.
Das Chassis wurde von 2U auf 4U vergrössert, um besseren Airflow und die
leiseren 12cm Ventilatoren (im Vergleich zu 9cm) zu ermöglichen. Die Anzahl
Boxes im Rack ist im wesentlichen durch den Stromverbrauch limitiert, nicht
durch die Höhe der Box.
Logistik: Bei Global Foundries wurde ein 'expedite process' bezahlt, der den
Fertigungsprozess von 90+ Tagen auf 65 Tage reduziert. Die chips werden somit
in der ersten Dezember-Hälfte erwartet, shipping in der zweiten
Dezember-Hälfte.
1200W ist also der reine Chip-Stromverbrauch, nicht der der gesamten 2 TH-Box. Gruss, Timo |
|
|
|
Hmmm kommt mir komisch vor. Schon klar das die nicht so bekannt sind in D. Wir lassen uns halt so schnell nix vormachen  Spass bei Seite: Ich mag mich an nen Beitrag hier im Forum erinnern, in dem bewiesen wurde das Bilder die Cointerra gezeigt hat nur geklaut und etwas verändert wurden und man aufgrund dieser Tatsachen und einigen anderen Ungereimtheiten von einem Scam ausgegangen ist. Mag evtl. nicht zutreffen und die Versprechungen werden gehalten und man war einfavh zu faul Fotos zu machen, aber ich bin vorsichtig! So nebenbei: Ich finds so witzig wie alle im Dezember liefern wollen. BFL hat hier gute arbeit geleistet :p Ich nehme doch mal an, dass für Bilder auf der Webseite ordnungsgemäß bei einem Bildprovider bezahlt wurde. Da das Produkt in Entwicklung und bald in Fertigung ist, kann es logischerweise keine Bilder davon geben. Wer "Bilder" sehen möchte kann sich dieses Video von einer FPGA-Simulation ansehen: http://cointerra.com/cointerra-demonstrates-working-fpga-releases-additional-chip-details/Im FPGA sind 2 von den 360 Hashkernen und die Taktfrequenz ist 1/10 der Taktfrequenz des ASIC. Es wurde zunächst auf eligius gemint (Statistik http://eligius.st/~wizkid057/newstats/userstats.php/1P17UueqcMDw2P8FWv8Ny4ryGopicQmJPN), danach im testnet als solo-miner (auf dem screenshot im Video zu sehen, zB Block #106507 at Thu, 19 Sep 2013 14:52:32 GMT). Ich weiss nicht, was du meinst mit der Lieferung im Dezember. Wir wollen so schnell wie moeglich liefern und das ist eben im Dezember. Was genau hat die Firma mit B damit zu tun? |
|
|
|
|
Hallo deutsche Mining-community.
Es hat den Anschein, als sei Cointerra in Deutschland nicht so bekannt, und
könnte deshalb einen deutschen thread gebrauchen. Deshalb fange ich hier mal
mit einigen technischen Spezifikationen an, die Cointerra gerade veröffentlicht
hat.
Foundry: Global Foundries (Dresden), 28nm HPP process
Taktfrequenz: 1.4 GHz (Mindestqualität) bis 2 GHz (maximal)
Die Größe: 10mm x 10mm
Package Größe: 3 dies pro package, 300 mm2 die-Fläche
Hashkerne: 120 pro die, 360 pro package
Hashkern-Architektur: optimierte SHA256 pipeline
Hash rate: 504 GH/s (@1.4 GHz) bis 720 GH/s (@2 GHz)
Hashdichte: 1.68 GH/s/mm2 (@1.4 GHz) bis 2.4 GH/s/mm2 (@2 GHz)
Stromverbrauch: 300 W (@ 0.765 volts), <0.6 W/GH/s
Tape-out: 1. Oktober-Woche
Chassis: 4U rack mount.
Kühlung: Wasserkühlung von CoolIT Systems, Canada. Ausgelegt auf 400 W pro
chip. 3x high speed 12cm Ventilatoren am Rücken des Chassis.
Das Chassis wurde von 2U auf 4U vergrössert, um besseren Airflow und die
leiseren 12cm Ventilatoren (im Vergleich zu 9cm) zu ermöglichen. Die Anzahl
Boxes im Rack ist im wesentlichen durch den Stromverbrauch limitiert, nicht
durch die Höhe der Box.
Logistik: Bei Global Foundries wurde ein 'expedite process' bezahlt, der den
Fertigungsprozess von 90+ Tagen auf 65 Tage reduziert. Die chips werden somit
in der ersten Dezember-Hälfte erwartet, shipping in der zweiten
Dezember-Hälfte.
Fragen werde ich gerne beantworten, kann aber nur höchstens einmal pro 24h hier
reingucken.
Grüße,
Timo
|
|
|
|
|
Sold.
I have a Jupiter miner for sale that ships on day 1 of KNC's shipping queue, which is expected to start in September or October.
Please PM me with an offer in $ (excluding VAT).
|
|
|
|
If the protocol breaks (is interrupted) after the server has signed and returned the refund transaction (T2) to the client, the server has to blacklist its input (the hash of T1) indefinitely, or am I overlooking something? Otherwise the client can replay T1 at a later time, after the locktime of T2 has passed, and refund to himself before the protocol is terminated. At least the server has to keep track of the timelock used in T2. What does the implementation do?
[..] Now you feel betrayed by the merchant and publish the very first full reimbursement but the merchant has time until the timeout of A expires to publish any lower reimbursement that you signed and that overrules all prior Bs. [..] I think you were describing why the protocol is safe for the client (buyer), while my concern was whether it is safe for the server (merchant). Anyway, Mike made this clear to me now. |
|
|
|
If the protocol breaks (is interrupted) after the server has signed and returned the refund transaction (T2) to the client, the server has to blacklist its input (the hash of T1) indefinitely, or am I overlooking something? Otherwise the client can replay T1 at a later time, after the locktime of T2 has passed, and refund to himself before the protocol is terminated. At least the server has to keep track of the timelock used in T2. What does the implementation do?
The server generates a new key each you open a channel and requires it be used. So you cannot replay T1 like that. When you present it to the server in order to open up the new channel it will notice it's using the wrong key. Ok, so you mean the rejection of such a replay happens in step 6 of the wiki description, after the server has seen T1 completely (not only it's hash) and when the server doesn't find his freshly generated key in there? |
|
|
|
|
If the protocol breaks (is interrupted) after the server has signed and returned the refund transaction (T2) to the client, the server has to blacklist its input (the hash of T1) indefinitely, or am I overlooking something? Otherwise the client can replay T1 at a later time, after the locktime of T2 has passed, and refund to himself before the protocol is terminated. At least the server has to keep track of the timelock used in T2. What does the implementation do?
|
|
|
|
I have a pre-order for 10x Jupiter from the 1-500 batch for sale: Date: 9 Apr 2013 09:08:35 +0000 From: reviews@kncminer.comTo: -redacted by request- Subject: Order product KncMiner Store Order ID: 265 The desired goods: KNC Bitcoin miner numbers 1-500 Quantity: 10 Name of the customer: Timo Hanke Email: -redacted by request- Phone: +4924153807945 About how to transfer the order into your name see this post from Sam from kncminer: if you do sell your order number all I will need is an email from both parties and I will do the rest, they will get your queue placement. it can’t however be for more than your registered amount of boxes and we will not split preorders into multiplies Sam@kncminer.comWill accept escrow. Please email me with offers. It is your responsibility to pay timely before Monday, June 10, 18:00 CET, which is kncminer's deadline. Auction will close within a few hours. |
|
|
|
|
Still available as of now.
|
|
|
|
If we have P_i=HMAC(I_L,P)*G+P they can't do that.
Did you mean P_i=HMAC(HMAC(secret),P)*G+P and reveal HMAC(secret) for the linkage proof, as you suggested in post #228 ? So the company wouldn't be able to workaround the issue with Q:=P+r*G because they couldn't compute an x such that P_i==HMAC(x,Q)*G+Q ? Yes, that's exactly what I meant. You can either use the I_L as it was before, from I:=HMAC(chaincode,P||i), and plug that into P_i:=HMAC(I_L,P)*G+P, or redefine I_L := HMAC(HMAC(chaincode,i),P) and do P_i:=I_L*G + P, as you like. |
|
|
|
1. Can we reserve more than one bit of the number i for different kind of derivations, not only the highest bit? This would allow addition other kinds of derivations or tweaks of existing ones in the future.
Adding more flag bits is certainly possible, but we can extend the length of the serialized i value in that case, so the only thing that needs to change is the serialization format. Do you mean to change the serialization format even for the two derivations that we have now? Like add another byte? If smartcards have a problem with SHA512, they'll have a huge problem with ECDSA.
Ok. And third, can you change I = HMAC( cpar, Kpar || i) in the public derivation to I = HMAC( HMAC(cpar,i), Kpar) ? I see the provability of the link as a quite an important property (cf. #228). That provability argument is interesting, but can you come up with use cases? iddo and you asked about use cases. Say a company has two departments A and B that have publicly known pubkeys P (for A) and Q (for B). They receive incoming payments on derived keys P_i and Q_i. At the end of the fiscal year the company wants to prove their balance sheet to an auditor. They want to prove to the auditor that A had this amount of income, and B that amount of income. I am assuming they don't want to give the chaincodes to the auditor. So for each i they tell the auditor the multipliers I_L such that P_i=I_L*G+P, and also the multipliers such that Q_i=I_L*G+Q. Right? No! The company can set up P and Q from the beginning so that they can decide at the end of the fiscal year to which department they like to associate each individual incoming payment. Dividing the incomes however they like between A and B, as long as they don't exceed the total sum of course. If we have P_i=HMAC(I_L,P)*G+P they can't do that. The "setup" works like this: The company picks P and r and sets Q:=P+r*G. Say P_i = I_L*G+P. If they want to associate P_i to P they give the auditor I_L, if they want to associate P_i to Q they give the auditor I_L-r instead (never both, of course, because then they blow up). |
|
|
|
|
How does it depend on the choice of hash function?
I guess this is something purely theoretical, right?
|
|
|
|
You can prove that you know c_par such that both (I_L,I_R)=hash(c_par, K_par, i) and K_i=I_L*K_par, without revealing c_par itself, via zero-knowledge computational integrity (PCP) proofs.
Really, you can zero-knowledge prove that you know a preimage of a hash? |
|
|
|
BTW, there has not been a compelling argument for making I_L in type-2 depend on Kpar either. IMO this just closes a door, is completely unnecessary, and even complicates reasoning about the security of the whole scheme. But ok, let it be as it is and close that discussion now, as time pressurizes before the conference. Pieter, can you please address these three points: 1. Can we reserve more than one bit of the number i for different kind of derivations, not only the highest bit? This would allow addition other kinds of derivations or tweaks of existing ones in the future.
5. It is certainly possible to do everything with HMAC-SHA256 alone. For instance, if you need two values like (I_L,I_R) you can do I_L=HMAC(secret,0) and I_L=HMAC(secret,1). The question is, does it reduce dependencies of the code, code review, etc. to be worthwhile?
All this might get implemented on smardcards one day. I really don't understand why you'd want to rely on a new, second hash function here, SHA512. Entropy is _not_ a reason. And third, can you change I = HMAC( cpar, Kpar || i) in the public derivation to I = HMAC( HMAC(cpar,i), Kpar) ? I see the provability of the link as a quite an important property (cf. #228). BTW, the function I will propose for payer-derived payment addresses (which is basically just a deterministic wallet of the payee in the hands of the payer) will be K_derived := HMAC( m, K_base) *G + K_base where m is the (hash of the) invoice or contract that is being paid for. This would fit nicely together, as it would be the exact same function just with m substituted for HMAC(cpar,i). We could re-use code as well as security reasoning. |
|
|
|
Btw, it is my intention with Armory to do exactly what you just said is out of scope. There's no reason to optimize the case of multiple wallets coming from the same seed, because most of the time you don't ever want a single device seeing all the keys. You want your phone to create one key, your computer to create another key, completely independently. In the case of a big organization, you want different branches to create their wallets independently, and swap pubkey-chaincode pairs. Exactly: swap chaincodes. If they swap their chaincodes anyway they could just as well use the exact same one. (It doesn't make a difference securitywise if they do.) Plus, if there's, say, a vulnerability in one of the devices' RNG, you'd prefer that it only affect one piece of the multisig wallet.
That's an argument, indeed. Plus, a party may not want to rely on another party's entropy but prefer to use it's own. There's a lot of possibilities there. While there may some use cases where keys are generated on the same device, that's far from guaranteed. In fact, I think it's the opposite, if we want to promote security best practices.
Yes, lot's of different ways. I'm just saying prepare for the fact that chaincodes will get re-used across different pubkeys. Whether it's for multisigs or some other purpose. Even if it's not the default behaviour for multisigs and even if you don't promote it in any other way, people might still find applications for it and do it. Chaincodes are only semi-secret after all. |
|
|
|
- get the basescript with GetCScript(id)
Where does the CScript from if you don't know the other keys in the first place? P2SH transactions do not contain the actual (public) keys anyway, so whatever you do, you need some metadata about the P2SH script in your wallet. I don't see the problem with extending this with the individual BIP32 public parent keys (if you need to be able to access the entire chain of multisig addresses in the first place). I mean you do have the other keys, of course, inside the CScript. But that doesn't necessarily mean that the other keys are present as entries of their own in the key database. HasKey() will still return false for the ids of the individual pubkeys of the script, unless you imported them individually. My impression was you wanted to stay as close as possible with current key/address handling and in particular wanted a map addr -> chaincode. The easiest multisig generalization (in terms of handling) would be one chaincode per multisig address. Matter of taste I guess. Individual chaincodes per pubkey in a multisig can do potentially more, like combining different pubkeys from unrelated chains into a multisig. But that's far beyond scope of BIP 32 I assume. With one chaincode per address there is no handling issues and you can trivially implement derivation from a multisig address with very few additional lines of code. |
|
|
|
|
