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 ...
21
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 ...
16
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 ...
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
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.
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
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
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
