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 ...
13
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 ...
12
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", "...
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 ...
10
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 ...
9
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 = "...
9
There is no requirement that blocks have a timestamp after the previous block. The only requirement is that the timestamp is greater than the median timestamp of the last 11 blocks. So this means that a block can have a lower timestamp than its parent, within a certain bound.
This happens because miners do not have perfectly in sync clocks. There can be ...
8
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 ...
8
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 ...
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, ...
7
nBits cannot be changed at all. Its value must equal the (compact encoding of) the target value for that block, which is determined entirely by the predecessors of the block. In other words, if the prevblock hash is given, so is nBits.
nVersion: can be modified arbitrarily, though its value is subject to interpretation under BIP34 (requiring it to be at ...
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
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
...
6
nTime: blocks must have a higher timestamp than the median of the 11 previous blocks, and a lower timestamp than two hours in the future of the validating node's own clock. Assuming a regular block interval of ten minutes and a correctly set local time, the block can therefore be stamped between about one hour in the past and two hours in the future.
nBits: ...
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
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
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
You can get this info from blockchain.info, by simply adding ?format=hexto the end of the relevant URL.
For example, here is a recent block (height 509,244):
https://blockchain.info/block/0000000000000000000635bda771916ca727db53fea5441508f7161386e066be
And here is the raw data for that block, in hex:
https://blockchain.info/block/...
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
There were many good answers to this question. After reading through them, I'm going to take a stab at the answer as well.
The coinbase field of the coinbase transaction (as it is called) is really just a scriptSig which doesn't have to pass any validation about its contents (except that it is less than 100 bytes, and the newer BIP34 requirements). Satoshi ...
4
My guess: It seems clear that Satoshi didn't expect pooled mining.
In a world without pooled mining, you'd simply have each piece of mining hardware capable of up to 4 gigahashes per second (GH/s) use its own public key, guaranteeing that it produced a unique coinbase transaction output. The time field can be updated every second, so the nonce can be reset ...
4
From the protocol rules, there is no such thing as an extra nonce.
There is only a 32-bit nonce in the block header (which can be iterated over very quickly), and up to 100 arbitrary bytes in the coinbase input. The block generation code inside the reference client has traditionally put an 'extra nonce' in those arbitrary bytes, but the contents can be ...
4
An analogy for mining would be the following:
You are at a lottery booth. The lottery booth has 1,000 lottery tickets in a bowl (which are always mixed perfectly). There is only one ticket with a prize in the bowl. Every time somebody buys one lottery ticket, the booth owner prints a new ticket and adds it to the bowl, replacing a loser with a new losing ...
4
The difficulty is stored in the block in the Bits field. When any server receives a block, one of the things it does is check if the value in this field is correct. If it's not a block where the difficulty changes, it must have the same difficulty as the previous block. If it's a block where the difficulty changes, then it must have the correct difficulty ...
4
This is what I do:
Connect to peer
Set bloom filter
Send 'getblocks' message
Send 'getdata' message with MSG_FILTERED_BLOCK set for any new blocks
Note that 'getblocks' returns a list of block chain hashes from the specified starting point, not the blocks themselves. Then 'getdata' returns 'merkleblock' messages instead of full blocks. The peer follows ...
4
From the original Bitcoin paper:
... we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work ...
4
Map Reduce isn't the best idea, because distributed mining is solved and works well. The magic of mining is described here, and when that is complete that Bitcoin protocol allows for 25 new Bitcoins to be send to any address. This is encapsulated into a block that is either accepted (and used as the "previous" block), or rejected, for example if the ...
4
To the best of my understanding, it's just that the blocks are stored in a different order. Headers first synchronization makes use of parallel downloads and the blocks are downloaded (and then stored) out of order. It used to be the case in older versions that blocks were downloaded and then stored in order, so that's whey they added the comment to the ...
Only top voted, non community-wiki answers of a minimum length are eligible
