Bitcoin Forum
May 07, 2024, 03:02:42 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: SHA256d IC design question  (Read 954 times)
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1068



View Profile
March 27, 2018, 05:17:55 PM
 #41

A professional marketing guy? No, I’m not that kind of professional.  Smiley
But you are some sort of an insider, with access to the information about the most current tools and processes. Why don't you use to produce some useful information, even if you don't have funding for the fully separate mask set production?

Why don't you actually run some representative simulations, even some reduced-rounds non-compatible version of SHA-256?

Why can't you squeeze a single Bitcoin mining engine into paid-for but left unused free space on some unrelated project taping out? The same way that Heveticoin did, and in the spirit of the long history of placing various more-or-less useable Easter Eggs into established silicon products?

It would even be possible to do a complete power shut-off of the unused backup logic in ASICboost mode, to avoid the leakage of these logic parts. But it still consumes silicon area, which increases your production costs in terms of $/GH.

Halong has chosen a very aggressive way to implement ASICboost without any backup logic for a non-ASICboost mode. In this way they have enabled the full potential of ASICboost in terms of J/GH and $/GH.
Can you make an educated speculation as to what would be the underlying business strategy?

What is the technical merit of multiplying the complexity of the engine several times in exchange for the gains lower than the regular manufacturing tolerances?

Lots of ASICs get designed purely for non-technical reasons: copy protection, hiding of patent or license violation in a way that is extremely hard to reverse-engineer and litigate, etc.

I think there should be some constructive speculation that you could post without violating your NDAs, don't you think? Or maybe everyone at your company already knows that HyperMega is a pseudonym of their 1st VP of Sales, and everyone there already watches your back?

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
NODEhaven
Jr. Member
*
Offline Offline

Activity: 57
Merit: 12


View Profile
March 28, 2018, 02:51:12 PM
Last edit: March 28, 2018, 04:21:25 PM by NODEhaven
 #42

Can you make an educated speculation as to what would be the underlying business strategy?

What is the technical merit of multiplying the complexity of the engine several times in exchange for the gains lower than the regular manufacturing tolerances?

Lots of ASICs get designed purely for non-technical reasons: copy protection, hiding of patent or license violation in a way that is extremely hard to reverse-engineer and litigate, etc.

I think there should be some constructive speculation that you could post without violating your NDAs, don't you think? Or maybe everyone at your company already knows that HyperMega is a pseudonym of their 1st VP of Sales, and everyone there already watches your back?

I think the answer is more simple.  The originators of the project, if not engineers, may have seen any "easy" answer with ASICboost.  If the BPDL was always planned by Halong then that also answers the question as it requires everyone using ASICboost to release all patents and purchase rights for any IP that is licensed from third-parties for everyone in the BPDL.

https://blockchaindpl.org/licensev10

As far as optimizations of layout go, am looking at some different methodologies.

This one is interesting.  Not sure if their exact approach applies, but this 2017 paper shows power and efficiency improvements on the order of 300% for a modelled cryptographic implementation using asynchronous clocks.

https://www.sciencedirect.com/science/article/pii/S2090123217301170



2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1068



View Profile
March 30, 2018, 02:41:02 AM
 #43

This one is interesting.  Not sure if their exact approach applies, but this 2017 paper shows power and efficiency improvements on the order of 300% for a modelled cryptographic implementation using asynchronous clocks.

https://www.sciencedirect.com/science/article/pii/S2090123217301170
This paper is about a way of implementing GALS (Globally Asynchronous Locally Synchronous) logic. IMO it won't help at all for SHA256D. It could probably work for something like scrypt() which is a sandwich of two layers of PBKDF2 with Salsa20 in the middle. Fixed length SHA-256 like in Bitcoin is too trivial to be susceptible to such advanced optimizations.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!