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": ...
11
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 ...
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
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 ...
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
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 ...
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
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 ...
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
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
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 ...
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
Directly committing to the nbits allows you to determine how much work was used to produce the header statelessly before looking for (or fetching) information about prior headers.
This can help fend of DOS attacks sending junk headers to force you to do work determining or fetching their ancestors.
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
Block timestamps are not very accurate and are allowed to be up to several hours off. It is difficult for a decentralized network to come to an agreement on an official time.
Reasons that it might be inaccurate are different system times, lag, and also miners often change the time by small amounts once they have tried all possible nonces. This allows them ...
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
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
There is a fair amount of leeway in the block timestamp. The timestamp for block N must be greater than the median network time, which is calculated as the median of the past 11 blocks, and also less than the network time + 2 hours, where network time is calculated based on the node's system time, as well as the median time reported by the node's peers.
Only top voted, non community-wiki answers of a minimum length are eligible
