Using an ASIC for something other than mining

[thebest866]

Hi, my question might seem ridiculous but I still need to ask this question

Is it possible to use an ASIC miner for searching for data using another programming language like php?

This idea came up due to the speed that an ASIC can perform in comparison with a CPU.

Please advice.

[1715018733]

1715018733

[1715018733]

1715018733

[1715018733]

1715018733

[1715018733]

1715018733

[1715018733]

1715018733

[NeuroticFish]

Hi, my question might seem ridiculous but I still need to ask this question

Is it possible to use an ASIC miner for searching for data using another programming language like php?

This idea came up due to the speed that an ASIC can perform in comparison with a CPU.

Please advice.

An ASIC is not a common purpose computer. It's a device that can do one thing. Its chips can do only one thing. ASIC means application-specific integrated circuit and this basically tells the full story. The only application for a bitcoin ASIC miner is to mine Bitcoin and a few altcoins that have the same mining algorithm. And that's all.

So the answer for you is: no, sorry.

[BitMaxz]

Actually, you can if you can make a program for ASIC chips to run for brute-force or search data but the speed is different compared to mining.

I suggest you read this "Why Bitcoin Mining ASICs Won’t Crack Your Password"
It will tell you how they try to use ASIC chips on brute-forcing the only problem is it's very slow. And ASIC chips are not designed for cracking it was created only for mining.

[grllatoken]

ASICs have a chip designed to do bitcoin mining, that's all it does.

Although this chip could be programmed to perform other tasks, it would all depend on the calculations that need to be performed.

[ranochigo]

Although this chip could be programmed to perform other tasks, it would all depend on the calculations that need to be performed.

ASICs can't be reprogrammed.

The design of the chip only optimizes it for one task. If the task isn't SHA256D mining, or any other specific mining algorithm for that matter. If you need anything else, then you need an entirely new chip.

[PrimeNumber7]

Actually, you can if you can make a program for ASIC chips to run for brute-force or search data but the speed is different compared to mining.

You can't make a program for an ASIC that mines bitcoin in order to run for brute-force or search data.

My understanding is that bitcoin ASIC miners will take input data and calculate the data's hash, using a specific hashing algorithm. That is what the ASIC chips are capable of doing.

I am not sure how "locked down" the firmware of most ASIC miners are, so I don't know how trivial it would be to modify the software that a bitcoin ASIC uses.

So if you had the hash of something, and had some general idea of the input value, you could theoretically repurpose a bitcoin ASIC to try to brute force the input value of a hash. You would obviously need something to generate a large number of candidate input values to check against.

If you had some other reason why you needed to calculate the hash of a large volume of input data, you could theoretically repurpose a bitcoin ASIC to do that as well.

[pooya87]

So if you had the hash of something, and had some general idea of the input value, you could theoretically repurpose a bitcoin ASIC to try to brute force the input value of a hash. You would obviously need something to generate a large number of candidate input values to check against.

You most probably won't be able to do that either even if the hash algorithm was SHA256 because bitcoin ASIC miners are designed to hash a 80 byte block header twice and there is a lot of optimization that takes place for that type of input. Using an arbitrary input here is like trying to turn a big bolt with a tiny wrench.

[PrimeNumber7]

So if you had the hash of something, and had some general idea of the input value, you could theoretically repurpose a bitcoin ASIC to try to brute force the input value of a hash. You would obviously need something to generate a large number of candidate input values to check against.

You most probably won't be able to do that either even if the hash algorithm was SHA256 because bitcoin ASIC miners are designed to hash a 80 byte block header twice and there is a lot of optimization that takes place for that type of input. Using an arbitrary input here is like trying to turn a big bolt with a tiny wrench.

Bitcoin miners will have to hash the block header twice, but are the chips in bitcoin ASIC miners designed to hash input exactly twice? Or do they take the 80 byte block header as input, hash it once, and take the output of that hash calculation as the input for a second hash calculation and return the output of the second hash calculation?

The latter would be something along the lines of as follows:

Code:

import hashlib
def single_hash(block_header):
    for _ in range(2):
        block_header = hashlib.sha256(block_header).hexdigest()
    return block_header

I honestly don't know the answer to the above, however, my intuition is that ASIC chips are designed to perform a sha256 hash calculation, and the software tells it to hash the block header twice.

[pooya87]

Bitcoin miners will have to hash the block header twice, but are the chips in bitcoin ASIC miners designed to hash input exactly twice? Or do they take the 80 byte block header as input, hash it once, and take the output of that hash calculation as the input for a second hash calculation and return the output of the second hash calculation?

The latter would be something along the lines of as follows:

Code:

import hashlib
def single_hash(block_header):
    for _ in range(2):
        block_header = hashlib.sha256(block_header).hexdigest()
    return block_header

I honestly don't know the answer to the above, however, my intuition is that ASIC chips are designed to perform a sha256 hash calculation, and the software tells it to hash the block header twice.

I can't answer that but what I know is that the method you explained is extremely slow compared to what we can do instead.
You see hashing a fixed 80 byte input that only changes at the end (nonce) can be heavily optimized. For example when hashing it we have 3 SHA256 blocks, a 64 byte block that doesn't change, a 16 byte block that changes and another 32 byte block that also change per nonce round. So we can precompute the first block hash and reuse it in the next 2 blocks. That cuts the cost by roughly 33%.
In fact ASIC boost uses a somewhat similar approach to this to gain optimization.

In other words you shouldn't think of bitcoin ASICs as devices that compute SHA256 but as devices that mine bitcoin.

[PrimeNumber7]

I can't answer that but what I know is that the method you explained is extremely slow compared to what we can do instead.
You see hashing a fixed 80 byte input that only changes at the end (nonce) can be heavily optimized. For example when hashing it we have 3 SHA256 blocks, a 64 byte block that doesn't change, a 16 byte block that changes and another 32 byte block that also change per nonce round. So we can precompute the first block hash and reuse it in the next 2 blocks. That cuts the cost by roughly 33%.
In fact ASIC boost uses a somewhat similar approach to this to gain optimization.

My understanding is that the sha256 hash of "some data" cannot be used to calculate the SHA256 hash of "some data_some more data"

My understanding is that the incremental changes to the input data make it easier to pass data into the ASIC chips.

With regards to someone trying to brute force something that is hashed via SHA256 -- someone would likely try all permutations of input data in order (BFS). So they would check "passw0rd1" then "passw0rd2", "passw0rd3" etc. So only so much of the input data would change each time a new SHA256 hash is calculated.

[garlonicon]

My understanding is that the sha256 hash of "some data" cannot be used to calculate the SHA256 hash of "some data_some more data"

It depends on the format of your data. If you have single sha256, then your message is splitted into 512-bit chunks, so if you have some 64-byte password (or if your whole password is located somewhere in the first 64-byte block), then you can compute IV for your last block and do single block hashing, in this way you can extend unknown message of arbitrary length if you can compute correct IV for that. So:

Code:

SHA-256(IV,first_block)=second_IV
SHA-256(second_IV,second_block)=final_hash

If you can somehow make your first_block a constant value (for example because of constant password prefix), then you can easily compute second_IV, and then update only second_block.

So they would check "passw0rd1" then "passw0rd2", "passw0rd3" etc.

You can do that if your "passw0rd" is in the first block and a part of it is in the second block, so that your "nonce" is in the right field of the second block, exactly where block header nonce is located, then by mining fake block headers you would mine your passwords instead. In practice, if you can turn your password into correct 80-byte block header, then you can mine it.

But there are many problems related to that:
1) timestamp before nonce is also changed
2) difficulty can be used for some kind of comparison (or a single byte from difficulty, just to know how many bytes in your hash have to be zero)
3) by default, you will not get a password that hashes to some specified hash, but a password that meets the target and where your hash has many leading zero bits
4) your hash is double SHA-256, not single SHA-256
5) you have to turn your password into 80-byte header, if you need only SHA-256(password), then it may be difficult (unless your users use block headers as their passwords)

[ranochigo]

With regards to someone trying to brute force something that is hashed via SHA256 -- someone would likely try all permutations of input data in order (BFS). So they would check "passw0rd1" then "passw0rd2", "passw0rd3" etc. So only so much of the input data would change each time a new SHA256 hash is calculated.

The nature of ASICs is that they are highly specialized, which means that it is practically impossible to change it otherwise. Each chip has a specific function, for example BM1385's datasheet[1] has a UART portion that specifically details the data that should be communicated to the chip itself. If an ASIC is as optimized as it gets, which I suspect it does, anything that doesn't have to do with mining will be eliminated.

If you need it to be able to be reprogrammed, you have to use FPGAs.

[1] https://bits.media/images/asic-miner-antminer-s7/BM1385_Datasheet_v2.0.pdf

[larry_vw_1955]

The nature of ASICs is that they are highly specialized, which means that it is practically impossible to change it otherwise. Each chip has a specific function, for example BM1385's datasheet[1] has a UART portion that specifically details the data that should be communicated to the chip itself. If an ASIC is as optimized as it gets, which I suspect it does, anything that doesn't have to do with mining will be eliminated.

If you need it to be able to be reprogrammed, you have to use FPGAs.

[1] https://bits.media/images/asic-miner-antminer-s7/BM1385_Datasheet_v2.0.pdf

luckily for bitcoin miners bitcoin has never changed its pow algo. if it ever did, they would be screweed bigtime. billions of dollars of hardware going to landmines....