21
Introduction
AsicBoost speeds up Bitcoin mining in general (for ASICs and CPUs alike) by reducing the frequency of computing one part of the SHA-256 calculation.
A Bitcoin block header is 80 bytes long. It fits in 2 blocks for SHA-256 hashing. It gets hashed into a 32-byte value, then hashed again (1 block) to get the final value that is compared to the ...
15
From trying to design my own ASIC---I got as far as having a simulated but not completely debugged Verilog implementation---I can tell you how mine would have worked. Whilst I have not checked, the design choices seem so obvious to me that I doubt anyone would do it differently.
The inner loop of the mining process is a double SHA-256 hash of data where ...
13
This really helped me understand it:
A solo miner increments Nonce until it overflows. Then it increments extraNonce and resets Nonce. extraNonce is located in the coinbase transaction, so changing it alters the Merkle root. extraNonce is reset based on the time.
12
What do the mining workers do differently then if they would be mining
solo?
A miner that is mining within a third-party pool doesn't need the entire block chain. In fact it doesn't need to be connected to any peers of the Bitcoin network. These miners work entirely outside of the network and could technically just need to communicate to the administrator ...
11
I'm not sure it was. When the network started operating (and Satoshi was pretty much the only one mining), blocks weren't found every 10 minutes. For example, the first 2016 blocks were found in 24 days rather than 2 weeks. Normally this would cause the target to go up but it can't go above the hardcoded max target, so only in block 32256 in December 30 2009 ...
11
SPV mining is the term commonly used for 'less-than-full-node-validation' mining. It usually means that miners skip the verification of the block and the transactions within, and immediately start mining a new block referencing the just-solved block header. However, since they don't know what is in the last block, they have to mine without any transactions (...
10
The time between consecutive blocks follows the exponential distribution, with mean (roughly) 10 minutes. This means that the variance is 100 minutes^2.
10
I got linked this question.
I made a tool which includes a component that allows one to simulate mining:
http://yogh.io/#mine:last
It's not entirely accurate; it doesn't support BIP 34, so the block height is not reflected in the coinbase tx, and it's still got some bugs. Currently in alpha. But it can give you some pointers.
It'll construct a block on ...
9
When does a miner decide to stop collecting transactions and start calculating hashes to try to win?
I am confused about whether a miner chooses to wait for more transactions (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?
Yes, they can begin mining as soon as they see the previous, and update the block template with new ...
8
Tim S. pretty much covered it, but I wanted to 2 great resources which have been very helpful for myself and many others:
Ken Shirriff's blog has a few Bitcoin mining related posts which use Python code to great effectiveness; whilst Bitcoin Mining The Hard Way is probably the most useful, there's also some novel use cases where Ken tries Bitcoin mining by ...
8
There’s no such thing as a block without a coinbase transaction. Even if the block reward plus fees is zero, it is still a mandatory transaction at the start of every block, it just pays nothing.
7
The expected time (mean) for a new block is of course 10 minutes, assuming constant hashrate, and no block propagation time.
The tricky part is that there is no such thing as a point in time. You can only ask only for an interval.
Let's illustrate this. First it is important to not fall for the Gambler's fallacy. Luck has no "memory". Thus if no block has ...
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
I wanted to start mining bitcoin from the genesis block
I'm pretty sure regtest will let you do that.
why wouldn't the peer just let me mine on my own chain and not broadcast my results to anybody?
Because that would be pointless. You're not confirming transactions, and you won't get rewarded for your mining. Your chain will probably be overwritten the ...
7
First of all, when 1 second has passed, the miner can just increment the timestamp in the header. This already gives us 4 Ghash/s rather than 4 GHash/block.
When this is not enough, and the nonce range is exhausted before a second has passed, the miner builds a new proposed block with a hash to search through. Specifically, the very first transaction in the ...
7
There are two assumptions in your question that aren't completely correct.
1) Each node would then require 68 minutes to find a proof of work (trying 2^52 hashes).
The process of finding a new block is not a linear task of work that needs to be accumulated. Rather it is a random process. Instead of a pile of work you are going through that has a fixed size,...
7
Contrary to the name the proof of work used in Litecoin is significantly more difficult than SHA256 to verify (it slows sync times noticeably), while simultaneously not achieving it's goals of being only able to be mined on a CPU, or a GPU depending when you read the pitch on their website. It offers very little resistance to being mined on a GPU or ASIC, in ...
7
I'm not sure that a guide as basic as you describe is even possible. It depends on what exactly you mean. Mining itself isn't too complicated to read and understand, but writing a start-to-end app that can be used for mining means writing a full node. That is very complicated.
Writing a Bitcoin miner from start to end involves not only collecting ...
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 ...
5
All block hashes start with a certain number of zeroes by design. The nature of a hash is that knowing something about the output does not help you figure out what the input is supposed to be (at least in theory). So in short, no.
5
No. Your premise is wrong. There is no guarantee a solution exists in a range. If a miner exhausts a nonce range he changes other components of the block header. Mining is a Poisson process with each hash attempt independent of any others.
Hence, there is nothing to gain with this particular kind of collusion. Of course, pooled miners enjoy less variance ...
5
The term ASIC is not associated with software but hardware. It means Application-specific integrated circuit and we should call it processor. For comparison with FPGAs, see for example Xilinx's site.
Typically you need some mining software like cgminer or bfgminer. With these software you should use various types of "processors" to mine with. The most ...
5
When the nonce range is exhausted, miners change the extraNonce field of the generation transaction. This changes the Merkle root in the header and allows a new range of nonces to be attempted.
Since the Merkle root is 256 bits, this can be repeated indefinitely.
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
Changing the timestamp is one way, but the more scalable method is to change the "extraNonce" field of the generation transaction, which changes the block header's Merkle root.
5
The attacks are against a "poor man's" version of SHA-256, where less rounds are performed than in the real SHA-256. They are useless for breaking SHA-256 itself, and more so for the double SHA-256 used in Bitcoin mining.
Also, what would be most useful for mining is a preimage attack, and those are much harder than collision attacks. You can see in the ...
5
I'm reproducing figures 2 and 3 from the paper below to provide an alternative interpretation.
Fig 2:
Fig 3:
Historically, mining is composed of an inner loop (red) and an outer loop (green). Each run through the inner loop, the nonce is incremented. This affects only Chunk 2 and causes all of the blocks in red to be re-evaluated. You can only do this 4 ...
5
Most simple and foreseen reason:
Bitcoin's blocktime is set at 10 minutes,
while Ethereum has a block every 10-20 seconds, making it much faster.
See Ghost protocol, https://www.cryptocompare.com/coins/guides/what-is-the-ghost-protocol-for-ethereum/
So no, bitcoin will probably never be able to match Ethereum's speed. ( In it's current state)
(Unless ...
4
This process, generally know as forking, creates two parallel chains that are incompatible, that is, there will be some transactions that will be valid against one chain but are not valid against the other.
If there are parallel branches, a miner might keep track of both of them. Once a chain is rejected, transactions in that chain are checked against the ...
4
The mining pool coordinates the workers. Think of it like a lottery. If you and your friends all buy tickets in the lottery the group has a better chance of winning. To be fair in the lottery example everyone should be rewarded proportional to the amount of money spent on tickets. So if there are 20 tickets for the pool one person purchased 10 and two people ...
Only top voted, non community-wiki answers of a minimum length are eligible