We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

25

You're hashing the hexadecimal representation of the first hash. You need to hash the actual hash -- the binary data that the hex represents. Try this: $ echo -n hello |openssl dgst -sha256 -binary |openssl dgst -sha256


23

It's just to get shorter addresses. Regular public keys are 65 bytes long, which is much too long to be convenient. Compressed public keys are 33 bytes and could potentially be used instead of hashes, though these are a little longer than 20-byte hashes. It also seems likely that Satoshi didn't know about compressed public keys or wasn't comfortable with ...


19

We don't know for sure, but the most popular theory is that a double hash was chosen to protect against length extension attacks.


18

What you are requesting is described as computing the Wallet Import Format for that private key: http://en.bitcoin.it/wiki/Wallet_import_format Using your example: 1.) Take a private key (Below is the HEX representation of binary value) 7542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C 2.) Add a 0x80 byte in front of it ...


17

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

Bitcoin uses double hashing almost everywhere it hashes in one of two variants: RIPEMD160(SHA256(x)) called Hash160 which produces a 160 bit output hashing the public key to generate part of a Bitcoin addresses SHA256(SHA256(x)) called Hash256 which produces a 256 bit output generating the checksum in a Bitcoin address hashing the block in a merkle tree ...


13

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

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 ...


10

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

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 ...


9

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) ) = ...


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

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 ...


8

You want to work with the digests, not the hex strings. Here's some Ruby: require 'digest' d = Digest::SHA2.new 256 d2 = Digest::SHA2.new 256 d << 'hello' d.to_s d2 << d.digest d2.to_s This will be the output from irb: 1.9.3p194 :001 > require 'digest' => true 1.9.3p194 :003 > d = Digest::SHA2.new 256 => #<Digest::SHA2:256 ...


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

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 ...


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

Bitcoin uses SHA256 followed by RIPEMD-160, which I'll collectively call HASH160. Good hashes have 4 properties: it is easy to compute the hash value for any given message it is infeasible to generate a message that has a given hash it is infeasible to modify a message without changing the hash it is infeasible to find two different messages with the ...


6

Ordering the bytes that make up a block so that you can hash them seems to be fairly complex, but if all you're looking for is an arbitrary string that hashes to something beginning with a few zeroes, you can search using a simple shell command: $ i=0; while true; do echo -n $i | sha256sum | grep -q '^000' && echo $i $(echo -n $i | sha256sum); ...


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:


5

There's no guarantee that you can solve a block just by adjusting the nonce. But there are other things you can change in a block that also change the hash. This question is pretty much an exact duplicate of your question.


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

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

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

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 ...


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