Bitcoin Forum
September 27, 2024, 05:03:16 AM *
News: Latest Bitcoin Core release: 27.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Thoughts about Quantum Blockchain Technologies, QBT.  (Read 391 times)
NotFuzzyWarm
Legendary
*
Offline Offline

Activity: 3766
Merit: 2679


Evil beware: We have waffles!


View Profile
August 16, 2024, 12:06:29 AM
Last edit: August 16, 2024, 03:02:58 AM by NotFuzzyWarm
 #21

Quote
Where Mr Gardin shows what appears to be a BitAxe Hex,
So they're using one of the most under-powered miners as a test bed?
As for:
Quote
The Company has found that CGMiner, which is considered the leading operating system for Bitcoin mining, added elements of unpredictability to a number of processes, due mainly to the code being developed over the last 13 years by a large number of contributors, each adding a new elements to the mining software.
That's bullshit.
There was only 2 primary developers: -ck & Kano. They are the ones that did virtually all of the actual mining code. Yes, several other folks contributed things like network and USB coms and a few did drivers for some oddball miner chips but ALL code including the sub systems went by -ck/Kano for testing & approval before being added. Since -ck has long ago closed his support/development that leaves Kano as the sole remaining original primary dev for cgminer and the last outsider code Kano approved was drivers from -VH to support sidehack's original Compac USB stick miners. AFAIK the last major changes to cgminer was the code for using Stratum vs the original GetBlockTemplate method followed by version rolling used by ASICboost. Most of the 'new elements' QBT refer to are ASIC mining chip drivers - not changes to the mining code itself. Being drivers that code is only used for specific (and obsolete) chips and has nothing to do with the actual mining code.

That ^ however only applies to all code in the official -ck & Kano gits.

That is a key point because numerous folks have spun off their own unofficial variants of cgminer (mainly for altcoins) and quite frankly most of the forks are crap partly because folks behind the forks put in their own tweaks to suit their specific needs w/o caring about what other functions their new code breaks.

Wonder what QBT is going to come up with in the next few months as an excuse when they make no progress using ESP-miner + their vaporware code?

- For bitcoin to succeed the community must police itself -    My info useful? Donations welcome!  3NtFuzyWREGoDHWeMczeJzxFZpiLAFJXYr
 -Sole remaining active Primary developer of cgminer, Kano's repo is here
-Support Sidehacks miner development. Donations to:   1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr
BobsSocks (OP)
Newbie
*
Offline Offline

Activity: 19
Merit: 1


View Profile
August 16, 2024, 08:32:12 AM
 #22

Published via the regulatory news service,

https://www.londonstockexchange.com/stock/QBT/quantum-blockchain-technologies-plc/analysis

and now uploaded to their website.

https://quantumblockchaintechnologies.co.uk/investor-relations/regulatory-news
https://quantumblockchaintechnologies.co.uk/images/QBT_-_RD_Update_15_August_24.pdf

Quote
A decision has been taken, therefore, to migrate away from CGMiner to AxeOS (ESP-miner), a more recently developed and, in the Company’s opinion, a better designed public domain operating system software for Bitcoin mining devices. The Company has found that CGMiner, which is considered the leading operating system for Bitcoin mining, added elements of unpredictability to a number of processes, due mainly to the code being developed over the last 13 years by a large number of contributors, each adding a new elements to the mining software. Therefore, while CGMiner was initially used by QBT to achieve the porting of its Methods, its high-level of inefficiency has now been recognised and the change to ESP-miner has been implemented.

Considering that QBT approached CK directly for assistance,

https://x.com/ckpooldev/status/1773906971806298306

and depending on how you feel you might consider their words to be libelous in that rather than just accepting that they are rubbish they are calling the reputation of CGMiner and that of CK and Kano into doubt. Bear in mind that you, I and many others are aware of the link between QBT and CK along with all the moaning they have done about CGMiner.

Whilst CK suggested he did not wish to name them...

Quote
After thinking long and hard about whether I should name them publicly, I decided not to based on how CSW was able to cause endless pain on his bogus claims on bitcoin despite being nothing more than a psychiatric case with almost limitless money at his disposal.

He might consider contacting

aimregulation@lseg.com

who regulate the market QBT is listed on and asking them to get the company to publish a clarification or withdrawal along with an apology. Aim regulation will consider the request and treat it in confidence.

Quote
Wonder what QBT is going to come up with in the next few months as an excuse when they make no progress using ESP-miner + their vaporware code?

Perhaps OSMU should think carefully about the association with QBT before QBT fails with their kit and starts trying to destroy their reputation as well.

BobsSocks (OP)
Newbie
*
Offline Offline

Activity: 19
Merit: 1


View Profile
August 16, 2024, 03:45:51 PM
 #23

Quote
So they're using one of the most under-powered miners as a test bed?

Sorry about missing out the most excellent ROFL but as another thought.

Whilst QBT spend all of their time achieving nothing and think it's valid to blame world plus dog for their fail the latest RNS also appears to reveal why they are in permanent fail mode and the reason why no amount of trying other people's stuff only to slag them off when it doesn't work is kind of hidden in plain sight.

Quote
These limitations are mainly due to the speed and power consumption inefficiencies created by the designers, which impact the ability to use any arbitrary input to SHA-256.

Of course I may be wrong but QBT's AI superwhizz rubbish appears to rely on being able to stuff the arbitrary numbers they want into available ASICs and available ASICs won't let them do that.

The mention of speed and power consumption inefficiencies is just an attempt by the grifters to try and hide the real problem. They can't get their numbers into the ASICs so they are permanently f*kd.
NotFuzzyWarm
Legendary
*
Offline Offline

Activity: 3766
Merit: 2679


Evil beware: We have waffles!


View Profile
August 17, 2024, 12:16:08 AM
Last edit: August 17, 2024, 09:46:17 PM by NotFuzzyWarm
 #24

Close. It's not that the ASIC's won't accept the work - it's that their AI-generated 'work' cannot (ever) reliably produce the correct output when ran through the SHA256 logic embedded in the chips. As long as the input matches the required format they are more than happy to produce a result -- it just won't be one that results in a found block (=> current diff).

Problem is, part of finding a block requires that the data from the block header MUST coincide with the result produced by the mining chip(s) eg when presented with the same work inputs. Those inputs are the work that is sent to the miner by a pool or directly from a BTC node. The structure of a block header is an 80 byte binary data set and is: Version 4 bytes, Previous Block Hash 32 bytes, Merkle Root 32 bytes, Block Time 4 bytes, Bits 4 bytes, Hash Nonce 4 bytes. Given those inputs with the exact same values any sha256 chip will process it the same so results are verifiable.

ref mining details from Kano's pool help page https://kano.is/index.php?k=minedet for details on what that work consists of.

QBT seems to be trying to look at that data and through their majik AI recipe come up with a more limited selection of inputs to create the actual work sent to the ASIC's. Of course if their guesses are wrong - no block found... My guess is that the core problem they have is that they are computing random guesses like a shotgun - all over the board - vs standard practice of just stepping through all of the possible iterations of work that a miner does. Their 'complaint' against cgminer is that it insists on producing data to be sent to the chips that is strictly based on the work (they are called 'shares') sent to it by a pool (node)...

- For bitcoin to succeed the community must police itself -    My info useful? Donations welcome!  3NtFuzyWREGoDHWeMczeJzxFZpiLAFJXYr
 -Sole remaining active Primary developer of cgminer, Kano's repo is here
-Support Sidehacks miner development. Donations to:   1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr
BobsSocks (OP)
Newbie
*
Offline Offline

Activity: 19
Merit: 1


View Profile
August 17, 2024, 11:50:43 AM
Merited by NotFuzzyWarm (1)
 #25

Thanks for the added insight. You can take a guess that my lips were moving when I read through the link provided and your explanation and thoughts.

Just to be annoying and try to break this out for myself the first problem is that Bitmain keep rolling out new chips and no doubt keep changing the interface along with the architecture to keep everyone else on the back foot. I would not be surprised if that includes some sort of jiggery pokery within the controller firmware that might encrypt those communications and then they lock down their controller firmware to make things even harder. Everyone gets to suffer when they do this, as has QBT, because they have to reverse engineer that interface. Something Kano did with SideHack.

Base on the words from Kano, waves, and information elsewhere my simple scenario would be that the ASIC, containing a number of bitcoin specific hashing cores, is first loaded with the fixed numbers and is then given a Merkle Root and rolls the nonces through the full 32 bit range. There is a mention elsewhere that the BM1366 can roll something else other than the nonce but I'll stick with that. Depending on the number of cores then the roll will be offset to spread the workload across the cores in the ASIC. Things might be more complex in as much as you might go further and split the roll across multiple ASICs.

It kind of puts me in mind of the previous work on scheduling done by CK and how that might apply in this scenario as well as in the case of pool mining software. I've always thought that there must be some mechanism whereby the work has to be scheduled across the architecture, including pool, so that resources are not wasted by duplicating work. If that is kind of right then the network must be designed to optimise such scheduling and QBT don't get to moan about it. I might like to see some enhancements to a particular piece of FOSS. Just because I might think they could be a good idea I don't get to moan about others doing it wrong especially when I would not have a clue how to do it myself.

Let's take a leap of faith and accept that QBT's AI waffle is capable of spotting patterns in SHA256. Given the current crop of ASICs are designed to roll the nonce for themselves all QBT can do is roll and schedule the Merkel Route restricting the scheduling across cores or rigs or the network to the ranges their AI waffle thinks will have a higher likelihood of producing the right, an acceptable answer. This, according to my simplified version of things, is what the network is designed to do so they should just shut up and get on with it like everyone else does. There are no issues about the speed or efficiencies of such things that they get to moan about even if they think they can do it better.

There are no conceptual barriers to them proving their stuff works other than the possibility it does not work and they don't want proof it doesn't or it is a big fat nonexistant nothing being used to extract investment from mugs. All they can really bleat about, as they have done recently, is that they do not have the resources required to run their rubbish at a scale that will give a statistically significant level of proof. All the other moaning is just pants.
BobsSocks (OP)
Newbie
*
Offline Offline

Activity: 19
Merit: 1


View Profile
August 19, 2024, 06:33:23 PM
 #26

Thanks for the merit tick. I'm feeling fuzzy and warm.

This cropped up.

https://www.youtube.com/watch?v=0LepnkruI4o
https://www.youtube.com/watch?v=0LepnkruI4o&t=29s

Quote
And turns out that it's working perfectly so now the fan is turning it's now connected to a computer with a USB cable adapter and on the terminal with CG Miner

Is it possible that that means QBT wasted the last whatever time trying to get CGMiner to work with their rubbish but that was the wrong choice from the outset so having failed to get it to work and rather than sticking their hands up for their stupids they slagged off CK and the CGMiner community but now they still have to use CGMiner?

If so disgusting behaviour but priceless.
Pages: « 1 [2]  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!