37

The Mining Algorithm is as follows: Step 0 - Retrieve the hash of the previous block from the network. Step 1 - Gather a list of potential transactions known as a "block". This list of transactions comes from the peer-to-peer bitcoin network. Step 2 - Calculate a hash for a block of potential transactions along with a random number. Step 3 - If the hash is ...


28

The difficulty is already to the point where it requires over a quadrillion hashes to solve a block. 2^32 is only 4 billion. Fewer than one in a billion times will there be any nonce that makes the block valid. A miner simply has to try every possible nonce on a different block. He can vary the coinbase, the transaction set, and/or the block timestamp. Any ...


20

From the wiki: A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you. Whenever a node connects to another node, it gets a UTC timestamp from it, and ...


15

When you generate a block, the generation transaction (the one that creates new coins) has an attribute called coinbase. It's a special value you can put anything you want in to make the block unpredictable to others (and this is good). So, naturally, you can put text in this attribute, although most just put mining-related information that is not human-...


13

To add a bit to the other answers: Imagine if the protocol required that timestamps increase. Now imagine somebody mines a block with a timestamp a minute in the future as far as you can tell. What do you do? If you try to mine blocks with the timestamp you currently believe is correct, your blocks will get rejected (since they'd have a timestamp earlier ...


11

Alright, I finally managed to fix my bugs and get a full roundtrip. Here is an example for a full communication with a Pool. I don't explain everything in detail as the API description can be found elsewhere. a) Suscription {"id": 1, "method": "mining.subscribe", "params": []} {"error": null, "id": 1, "result": [["mining.notify", "...


11

Blocks contain a header, and headers are chained, so blocks are chained also. Note the merkle root from your question: this attaches the transactions in the block to the header, making them a logical combined unit: That is, you can't attach an arbitrary block to an arbitrary header---each header only attaches to one set of transactions. You are correct ...


10

When miners try to compute a block, they pick all transactions that they want to be added in the block, plus one coinbase (generation) transaction to their address. They may include any transaction they want to form a tree of transactions later hashed into the merkle root and referenced into the block's header. It is to note that for a block to be accepted ...


9

Nonce is a 32 bit arbitrary random number that is typically used once. In Bitcoin's mining process, the goal is to find a hash below a target number which is calculated based on the difficulty. Proof of work in Bitcoin's mining takes an input consists of Merkle Root, timestamp, previous block hash and few other things plus a nonce which is completely random ...


9

There's 2 versions of ASICBOOST: Overt where miners use bits in the version number as extra nonce space Covert where miners "mine" merkle trees with 4 bytes collisions The overt version is very easily detectable, whereas the covert one isn't. To mine these merkle trees for the overt version, miners need to shuffle the transactions in the block. Without ...


8

The version is wrong: I have 02000000 But the one that appears on the block is Version 0x20000000 Doing the formatting: 00000020 Calculating the hash of the block: from hashlib import sha256 import hashlib header = "...


7

The code isn't optimal especially not on the merged mining side. Currently there is no optimal method to handle both block chains without a more advanced miner-pool communication protocol. Excluding merged mining issues, latency is a large factor. When a block change occurs every single miner's effective hashing power is zero until they begin working on ...


7

Dan Kaminsky explained his method and motivations for inserting images into the blockchain at a talk at Black Hat USA 2011 - the relevant slides (12 -20) from the presentation can be found here. His basic method was to create transactions with lots of outputs and to include the message in ASCII, in pieces, in the receiving address field of the output ...


7

At least one mining pool deliberately sets timestamps 6 minutes in the future and Block 145045 appears to be from Eligius (the generation transaction is split into multiple addresses).


7

The Bitcoin Lottery used an SHA256 hash of the two most recent blocks to generate random data and to my recollection there were not too many complaints about that method they chose. In any case it's only good for 256 bits of questionably random data every 10 minutes (20 if you don't reuse blocks) so there are probably better entropy sources, such as the ...


7

Once a miner has found a block, how easy it is for him to add or remove a tx included in that very block? It is impossible. The solved block depends on every byte of transaction data, nothing can be changed. It is important that it be this way. What if I could broadcast a solved block but leave out the transaction where I sent coins to someone else, ...


6

I believe the timestamp is based off of the machine hosting the bitcoin client that submitted the block, and variance is allowed as not everyone has their computer time synched properly.


6

The number of hashes a miner has tried in the past does not affect the probability that a miner will get the correct hash in the next immediate calculation. Thus, it does not matter for the miner from an efficiency viewpoint if he starts work on a new block since the probability of getting the correct hash is exactly the same as if he kept working on the old ...


6

It would not break the algorithm. As the inventory vector of the described new block would be a duplicate of an already known block, no other node would request this block. It would just be ignored, as if never discovered in the first place. Everybody else would still be hashing away happily, obsoleting the block eventually. Tough luck for the miner, he'd ...


6

As an example of how to build a block header, here's a short Python program that calculates this block header's hash: #!/usr/bin/env python3 import urllib.request import json import binascii import struct import hashlib ux = binascii.unhexlify hx = lambda bin: binascii.hexlify(bin).decode('ascii') # Load testing data in json format from blockchain.info ...


5

The timestamp exists so there will be a permanent record of when the block was found. The timestamp needs to pass some sanity tests for the block to be considered valid. One of the key uses of the timestamp is in calculating difficulty retargets.


5

You assume that there exists (exactly?) one block for each work unit. This is not true, there are many variables (timestamp, nonce, transactions in a block, extranonce inside the block's coinbase transaction, ...), and all of them influence the block's hash. Each hash has a chance (as of October 2013) of less than 1 in a billion billion (1.15*10^18 to be ...


5

Whether or not there is a solution depends on the contents of the block as well as the possible values of the nonce. The transaction block can be altered if necessary which essentially means you get another 32 bits of nonce values to try. There is an additional component of a transaction block called the "coinbase" that can be altered without altering the ...


5

There was a very interesting talk at Chaos Communication Camp this year on this topic. IIRC, you can store arbitrary information in bitcoin transactions, since they actually contain "programs" specifying how the transaction should be verified. Information on the 'scripting' interface can be found here. See section 2.3 for details on imbedding messages.


5

There is proof of concept work in progress right now to solve this problem. Basically by creating hub nodes capable of handling many thousands of connections. These hub nodes are in fact a proxy backed by a real satoshi bitcoin daemon. This will relieve standard bitcoin nodes from a lot of the connections being used up by these 'selfish' nodes and allow ...


5

A block is checked in two places: First, it's checked before a miner starts working on it, and second, it's checked by every other node before accepting the block as valid.


5

The issue here is with: (block.nVersion < 3 && nHeight >= consensusParams.BIP66Height) Your block has version 2, but I assume the block you are trying to download is higher than BIP66Height so it rejects it. Its very difficult and requires a lot of expert know-how to modify the source code of a coin, and it sounds like you probably don't ...


5

but I am going to take a slight guess that this has something to do with miner voting to show what the consensus is for a future change? No. There are currently no active consensus change proposals. These version numbers are likely due to a mining optimization known as ASICBOOST. This optimization is due to a quirk of SHA256 and Bitcoin's block header ...


5

They aren't really necessary. The reason that they are included can only be known by Satoshi, and AFAIK, he did not state why he chose to include nBits in the block header (or many other things that are just arbitrary). This is one of the many things that Satoshi chose to do and no one really knows why. It remains in the block header today because removing ...


4

I think if this became extensive, this would destabilize the entire network. Since nobody wants that, it won't become extensive. The most fundamental thing the client does is decide what the current valid block chain is. Suppose I see two competing hash chains on the network. How can I know which one I should follow? The answer is to first make sure both ...


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