Hot answers tagged

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 ...


23

Merkle roots do not verify transactions, they verify a set of transactions. Transaction ID's are hashes of the transaction, and the Merkle tree is constructed from these hashes. It means that if a single detail in any of the transactions changes, so does the Merkle root. It also means that if the exact same transactions are listed in a different order, ...


22

Answer shamelessly stolen from stackexchange: Difficulty encoding is thoroughly described here. Hexadecimal representation like 0x182815ee consists of two parts: 0x18 -- number of bytes in a target 0x2815ee -- target prefix This means that valid hash should be less than 0x2815ee000000000000000000000000000000000000000000 (it is ...


20

Please note, this answer was written in Februar 2015. The debate has significantly evolved since then, but I haven't gotten around to updating this answer, yet. I'm sorry, this kinda turned out less brief than it started. TL;DR: Very briefly, it is an issue of opposing ideologies: Proponents wish to provide a common good to everyone and believe the ...


19

Why is this limit present? 1. To Maintain Consensus There has to be clearly defined rules about which blocks are valid and which are not for the network to agree. Obviously no node will accept a block that is 10 million terabytes, it would be near impossible to download even if it were valid. So where do you set the limit? And what if one node sets their ...


18

Merkle roots are stored in Bitcoin block headers so as to enable efficient membership proofs for transactions in a block, which are necessary for Simple Verified Payment verification (SPV) nodes that only store block headers and not block contents. It is misleading to say that "Without the Merkle root in the block header, we would have no cryptographic ...


16

Short answer: Yes, there's a limit but it depends on transaction size, not count. Basic summary of blocks Miners are incentivized to put as many transactions into a block as they can with fees. The more transactions, the more fees the miner collects, and that can mean an extra coin on top of block rewards. A block gets bigger as more transactions are added,...


16

The incentive to mine on the currently longest chain is that there is a risk to the dishonest miner that honest, non-mining nodes may have already propagated the first block and hence reject and not propagate the second block found at an equal block height. As Proof of Work is not reusable this leads the dishonest miner to waste resources.


15

The initial statement is correct. The blockchain is the list of all solved blocks, essentially the ledger of all transactions completed in the Bitcoin network. Each block contains (among a few other things) a list of transactions. When you do a transaction, it is not destined for a specific block. You merely publish your transaction to the network and it ...


15

Transactions are broadcasted by anyone in the system and at random intervals. Which transactions, of all the ones broadcasted, are included is very dependent on the miner, as he/she is the one who groups them up and includes them in the block. As Nate noted below, there is also a 1MB block size limit which limits how many transactions can be included in a ...


15

I don't know anything about Multichain so I'm not sure if this is the answer you're looking for, but here's one answer that might help you. The interesting thing about proof-of-work (Nakamoto) blockchains is that they enable a constantly-changing set of unknown nodes on the internet to achieve consensus under certain assumptions about the adversary (i.e., ...


14

As long as the block reward is much higher than the transaction fees, this is totally not an issue: mining isn't an incremental process, it's a bruteforce probabilistic one. I.e. in a single moment your chance of solving a block isn't higher if you have been mining that same block for some time: the chance is always the same. Hence, once a block is relayed ...


14

There is only one (Bitcoin) chain, and the Genesis Block is the first block in that chain. This block was created by Satoshi Nakamoto as the first link in the blockchain. It is hard-coded into the refernce Bitcoin client. To create it, it was "mined" like every other block, except it was at the minimum difficulty level, and contained arbitrary data. The ...


14

Pieter's answer is good, the chainwork value is the expected work amount in the chain, expressed as a 32 bytes integer, for the double SHA-256 hashes calculation work. The chainwork is used to identify the correct chain, the biggest chainwork value means the strongest or the correct chain. By the way, Satoshi didn't initially realize that choosing the ...


14

I assume this question is about Bitcoin Core's internal operations. This description is valid for version 0.8 and later (up to 0.14 at least). One part of the system deals with the active chain, which is the longest valid chain of blocks (stored in $DATADIR/blocks) that we know of. This active chain gets blocks appended to - and occasionally removed when ...


13

The absolute limit is the size of the block, which is currently hard-coded at 1,000,000 bytes. Each transaction takes up a variable amount of space, but ~250 bytes is about right for a simple (one-input one-output) transaction. However as soon as a block is solved it is not possible to extend the block by adding in more transactions, as the proof of work ...


13

Proof-of-stake mining is similar to Proof-of-work at a technical level. It involves a sort of lottery, similar to proof-of-work, but the difficult of this lottery is weighted depending on how many coins you are staking. The overall process for "attempting" to mine a PoS block is like so: Add a coinbase transaction, and a staking transaction (in most coins, ...


13

Generally speaking, a larger block leads to more computational resources (tx validation, bandwidth, storage, memory) required for each person who wishes to validate newly confirmed transactions. Higher validation cost lead end-users to rely on/trust centralised services to "validate" their transactions. Larger blocks require more time to propagate in the ...


12

Blocks are identified by their hash. This means that in your story, in Jan 2017, when B gets broadcast, any node that it is advertized to will think "I already have this block", and ignore it. However, when we consider block hash collisions to be a realistic situation, there is another issue that may arise: If two blocks with the same hash and the same ...


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

Miners have a long-term investment in the health of the Bitcoin network. If Bitcoin collapses, then their expensive ASICs are worthless. Miners particularly need Bitcoins to remain valuable over the long term because their hardware produces Bitcoins over time. If nobody includes transactions in blocks, then Bitcoins would be useless and therefore worthless. ...


10

The magic number is not something specific to bitcoin. Magic numbers are used in computer science for both files and protocols. They identify the type of the file/data structure. A program receiving such a file/data structure can check the magic number and immediately know the supposed type of that file/data structure. This is what the Unix/Linux command ...


9

The simple answer: no. The not to simple answer: extremely unlikely. Miners hash an input block, in the hopes of getting a result that satisfies the difficulty requirement, i.e., has a certain number of zeroes in front. Now the possibilities for the miner to vary the input are quite large. There is the 4 byte nonce, there is the order transactions are put ...


9

The chainwork value is really just the total amount of work in the chain. It is the total number of hashes that are expected to have been necessary to produce the current chain, in hexadecimal. Converting 0000000000000000000000000000000000000000000086859f7a841475b236fd to decimal, you get 635262017308958427068157, or 635262 exahashes. At june 2014 hash ...


9

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 ...


9

Disclaimer: I proposed a partial solution myself to this problem (BIP 143, see below). Did the miner collude with the creator of the transaction? Yes, because they are the same person. It's a transaction that consumes a ton of dust outputs, and converts them to fees, which the miner claimed. I doubt that the intention was to cause problems; it may just ...


9

Blocks in Bitcoin, as they exist in the blockchain, don't actually contain a confirmation field. When you query for a block in bitcoin-rpc or similar, additional information is added to the block based on your client's knowledge of the current state of the blockchain. A pure block contains only five fields (some of which have sub-fields): Magic number (to ...


9

However this is JSON, I imagine I can't use it to verify the nonce. You can. You can build the block header using the data at the beginning of the JSON object and then hash that. Of course it would be easier to get the block hex, which you can get by going to the block hash on blockchain.info and appending ?format=hex to the url. For example, for the block ...


9

(This data is current through block 535276.) Based on block timestamps (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1. The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and 15324. For "shortest"...


8

You're thinking that mining a block is a single long computing process, like computing the trillionth digit of pi or something like that. This is wrong. Each attempt at solving a block takes almost no time at all, and each attempt is independent of the others. Miners make many attempts every second. Each attempt has a very small chance of solving the block. ...


Only top voted, non community-wiki answers of a minimum length are eligible