38
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 ...
14
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
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 ...
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
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 ...
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
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 ...
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 ...
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
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
...
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 ...
7
How strict are the time validation rules?
Very.
If the next block is mined more than 2 hours after the current block, would this not stall the blockchain?
No.
It doesn't break the rule "Full nodes will not accept blocks with headers more than two hours in the future according to their clock."
Nor does it break the rule "Must be strictly ...
6
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.
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
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: ...
6
I think you have a misconception about what this clause means:
Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
You appear to be interpreting this as, if a new block is more than two hours later than the previous block, then do not accept it. That is incorrect. This clause is not about gaps in time ...
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
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
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/...
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
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 ...
answered Jul 27 '13 at 13:48
Christopher Jon Mankowski
12.2k11 gold badges56 silver badges124 bronze badges
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.
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible