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 ...
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", "...
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 ...
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 = "...
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
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
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
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
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 ...
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
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
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
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
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
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
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 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
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
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
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 ...
4
It could have been done that way, at the cost of increasing the amount of space it takes to store and send block headers. It seems like block header storage was a big concern for Satoshi, (there's even a section in the whitepaper about it) but it's turned out to not matter very much.
Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes?
Yes,...
4
There are indeed many new transactions every second. The way miners deal with it is two-fold:
If an appropriate proof-of-work is found on any merkle root, simply publish that block and any transactions that did not make it into the block go into the next block (assuming sufficient fees)
Otherwise, calculate a new merkle root every so often (varies per miner,...
Only top voted, non community-wiki answers of a minimum length are eligible
