Hot answers tagged

21

Another way to look at it is to take a look at a recent block that was mined, for example, block 388368. Looking at this block on blockchain.info, you can see that the hash for this block is: 0000000000000000021ff110a589e44f56979254a204557311204f803910fdfa It took roughly 10 minutes for all of the miners (doing a combined 700,000,000 giga-hashes per ...


15

The wiki claim that this is to prevent birthday attacks is wrong. If you can successfully execute a birthday attack on a single call to the hash function, you get a successful birthday attack on the second call. This is easy to see as having hash(x) == hash(y) implies hash(hash(x)) == hash(hash(y)). If you really wanted to guard against this, you would do ...


12

The wiki answers this. TLDR: to prevent against birthday attacks. Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While ...


11

With a look up table you can avoid calculating the hash of a given input twice. Indeed, the block chain can be considered as a giant look up table, but one with very special forms of inputs: It links blocks and transactions to their hashes. Though, why should someone choose a transaction or block as her password? Further, why would an attacker even try to ...


10

These charts show the approximate network hash rate on the left axis: http://bitcoin.sipa.be/ We know the network adjusts for 25 new bitcoins per 10 minutes. Together this provides enough info to give an approximate answer to your question: hashes per bitcoin = (network hash rate) / (25 BTC per 10 minutes) = (180 * Th / s) / (25 * BTC / (600 * s) ) = ...


10

Like others have said, the wiki claim of this preventing birthday attacks is wrong. Rather, this was meant to prevent against length extension attacks. From https://crypto.stackexchange.com/a/884/56797: SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their excellent book "Practical Cryptography" (later updated by Ferguson, Schneier, and ...


10

I think Satoshi was not aware that the hashing routine could be optimized by the use of a midstate when he first created bitcoin. If you look here, you can see that the first version of bitcoin that had the midstate optimization built into the miner was version 0.3.5 (it says 0.3.6 in the post, but you can see where someone quoted him that the post first ...


10

I got linked this question. I made a tool which includes a component that allows one to simulate mining: http://yogh.io/#mine:last It's not entirely accurate; it doesn't support BIP 34, so the block height is not reflected in the coinbase tx, and it's still got some bugs. Currently in alpha. But it can give you some pointers. It'll construct a block on ...


10

Secp256k1 was designed to be a 256-bit size elliptic curve without cofactor and admitting an efficient endomorphism for optimization purposes. The choices of the relevant parameters are derived from these criteria. P is selected allow a more efficient implementation on general purpose computers. See Solinas' paper on Generalized Mersenne Numbers. We don't ...


9

F29E9187 are indeed the first four bytes of the double sha256 of the bytes: 802CF24DBA5FB0A30E26E83B2AC5B9E29E1B161E5C1FA7425E73043362938B982401 In order to check this, you need to compute the double sha256 of this array of bytes. However, as already discussed, passing the string 802CF2... to the hash function will not yield the right answer, as this ...


8

Hardly. Whilst you are correct that what people are doing is a massively parallel search for double-SHA256 hash collisions to hash outputs near zero, you can only take advantage of the result if you actually find a collision. So how often can we get a collision? If it were not for Bitcoin, with 2^256 possible inputs and the hash believed to not have any ...


8

echo -n "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6" | sha256sum Gives: 32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce echo "...


8

The problem is that you're treating the pubkey as string data. What you need to do is treat it as raw binary hexadecimal. If you use fileformat.info and calculate it using Binary Hash hex bytes you do indeed get 600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408.


8

Not that other answers are wrong here, but just to approach your confusion from another angle: SHA256 hashing algorithm, which produces alphanumeric hashes. That's not true. The hashing algorithm produces a stream of bytes. Only when you display that bunch of bytes on your screen it's common for it to be in hexadecimal (containing "alphanumeric" ...


8

You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding. However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction ...


7

Let's disect this function call: void sha256(struct sha256 *sha, const void *p, size_t size) First we realize that the return value is void which means the function does not return the sha256 of the data. However we see that the first argument struct sha256 *sha is a pointer to a sha256 struct with the name sha. This suggests that the pointer that we pass ...


6

It's not unevenly distributed. The reason it appears that way in the graphs above is because the x-axis is plotted in logarithmic units. Here's what it looks like in linear units:


6

People often talk about SHA256 like it's a single operation, but it isn't. Rather, the input is broken up into 64-byte chunks, and then each chunk is put into a compression function. The state of the hash partway through hashing something does not depend on future parts of the data. Since the nonce is found in the second chunk, changing the nonce doesn't ...


6

Arvind Narayanan and Jeremy Clark wrote an excellent paper about that: Bitcoin's Academic Pedigree. I recommend reading the paper in full, but the following briefly summarizes the paper's content. Linked timestamping/verifiable logs Bitcoin borrows the blockchain data structure from Bayer, Haber, and Stornetta which described a very similar data structure in ...


5

You could easy manipulate a pool to wreck havoc on other SHA256 coins if you owned it or managed to gain access. You don't even need to be a large pool, some altcoins are really small and vulnerable. It has affected other coins before, where a pool or a large miner created trouble solely by mining a smaller altcoin. Feathercoin hit by massive attack Only ...


5

All block hashes start with a certain number of zeroes by design. The nature of a hash is that knowing something about the output does not help you figure out what the input is supposed to be (at least in theory). So in short, no.


5

When the nonce range is exhausted, miners change the extraNonce field of the generation transaction. This changes the Merkle root in the header and allows a new range of nonces to be attempted. Since the Merkle root is 256 bits, this can be repeated indefinitely.


5

I think what most people making the 51% attack argument for memory hardness miss is that the base unit is meaningless when you're talking about percentages. Whether your mining algorithm is implemented with ASICs, consumer hardware or well-trained Rhesus monkeys it matters little - to launch a 51% attack you must amass enough ASICs, consumer hardware or ...


5

The attacks are against a "poor man's" version of SHA-256, where less rounds are performed than in the real SHA-256. They are useless for breaking SHA-256 itself, and more so for the double SHA-256 used in Bitcoin mining. Also, what would be most useful for mining is a preimage attack, and those are much harder than collision attacks. You can see in the ...


5

As you noted, the logarithmic scale skews it right, because the number of nonces within log(10, nonce) > 9 is 3 times larger than log(10, nonce) < 9 The other factor that might skew the nonces on your chart is that a pattern in the nonces on the blockchain doesn't necessarily mean that it's caused by a problem in the mining algorithm. As a trivial ...


5

The hash is not alphanumeric, it's hexadecimal, that is base-16. You can convert that to a decimal number. In your case: 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 = 102987336249554097029535212322581322789799900648198034993379397001115665086549 The actual bytes are actually base-256 (8 bits to a byte), but it's relatively easy to ...


5

I've read simplistic descriptions of mining as simply incrementing the nonce until a solution is found, but I've also read much more detailed explanations which would imply much more is involved. Even if only the nonce is changed in the input, the pool would still need to assign each miner a unique nonce to try after each submission, no? Miners do change ...


4

If you don't want to compute the key manually, there's a useful command-line utility for this called bitcoin-tool: $ ./bitcoin-tool \ --input-file <(echo -n 'Hi guys!' | openssl dgst -sha256 -binary) \ --input-format raw \ --input-type private-key \ --network bitcoin \ --output-type private-key-wif \ --output-format base58check \ --public-...


4

For the second round of sha256, you need to hash the raw binary output from the first round, not the textual version. A sha256 hash is 256 bits, or 32 bytes. Thus for the second round you should be hashing a piece of data that's 32 bytes. When hashing a hexadecimal string as the literal input for the second round, your data is 64 bytes. Try a hashing tool ...


4

There are a multitude of reasons. As @ThePiachu mentioned, there is a theoretical 2^60 bit attack that is possible on SHA-1, meaning that the algorithm is weaker than designed. RIPEMD-160 was designed in the open academic community, in contrast to the NSA designed SHA-1 and SHA-2 algorithms. It is worth noting that Satoshi could've used SHA2-256 twice and ...


Only top voted, non community-wiki answers of a minimum length are eligible