Hot answers tagged

4

I also believe I read that the signature part can account for 65% of the block size. This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the ...


4

What if after this phase the first miner or more than 51% of them decide to keep the current production rate ? Do their block will be refused like if they had produced a wrong block ? Exactly. This is no different than if a miner (or a majority of miners) created blocks which paid out anything more that 12.5 BTC today: the network would simply ignore the ...


4

Would you please clarify the reason behind the invention of Blocks? When determining who owns what money, the ordering of transactions becomes important. If I only have $10, and then tell both Alice and Bob that I paid $10 to them, who will rightfully own the $10? Some sort of clock/timestamp is needed, in order to determine who received the payment first, ...


4

The process of a transaction being created and included in the blockchain is as follows: The sender creates, signs, and broadcasts the transaction All Bitcoin full nodes, including miners and regular users, receive the transaction and validate it by making sure it follows the Bitcoin protocol rules Nodes temporarily store the unconfirmed/yet-to-be-mined ...


3

What you are referring to are stale blocks. Orphaned blocks are one for which the previous (parent) hash field points to an unknown block or to a block not yet processed by the local node. Since Bitcoin Core follows headers first approach, block headers are downloaded and validated first before downloading the block data. As a result, full nodes will never ...


3

Its the time the wallet was last synchronized to, it won't know about any transaction changes in or out past this time until it has been loaded again by a synchronized node. It has nothing to do with your transactions specifically.


3

Blocks include more than just those 3 variables. One of the most important ones is the merkle root. This is the hash of all of the transactions in the block, in a particular order. If different transactions are included or they are included in a different order, that merkle root is going to be different. So if each miner has a different merkle root, then ...


3

No. Block data is written (appended to) blk*.dat files whenever a block is received from the network (assuming things like PoW and a few other sanity checks pass). As blocks are received in parallel from multiple peers, their order on disk ends up being chaotic. Undo data is written when a block gets fully validated. As full validation requires validation ...


3

The cap on the block size excluding witness data is 1000000 bytes. There is no cap on block size including witness data. Instead, there is a limit on the block weight at 4000000 weight units. Depending on the composition of the block, 4000000 WU can correspond to anything from 1000000 bytes to close to 4000000 bytes (including witness data). But a block ...


3

how can I make sure that this block that my node received is a valid block Bitcoin Core will only announce (through ZMQ) blocks that change the tip of the best-known valid chain. This implies they together with all their ancestors are fully valid. and it is not an orphan block At the time it is announced, you know that it is part of the best-known valid ...


2

combined together to get the penultimate hash which together with the nonce That's not correct. The "penultimate hash" is the merkle root. The nonce is not part of the merkle root at all. That is part of the block header and is hashed along with the merkle root and several other things in order to get the block hash. This merkle tree structure is ...


2

which, as I understand it, makes some data (until 2017?) real without verification. You understand incorrectly. Firstly, the assumevalid blocks is updated at every major release, so it is at most a couple of months out of date for the most recent release. For Bitcoin Core 0.18.0, the assumevalid block is ...


2

There really isn't any "starting over" in mining, because mining is effectively progress free, like a lottery and unlike a race. Nothing is lost when updating the transaction list, other then the negligible amount of processing needed to make the new list and bandwidth to communicate it. The miner will include the additional transactions whenever it gets ...


2

There are no real rules, per se, just various optimizations. ASICs are fast. They can burn through the entire 2^32 possible nonces for a given block in seconds, which requires miners to use the extra nonce field in the coinbase transaction to generate a new block header (since altering the coinbase transaction changes the merkle root) and try again. This ...


2

Since the time between those blocks is so small (from 593576 to 593577 was only 16 seconds) a miner wouldn't have many transactions to add to the block they are mining (there just haven't been many transactions on the network within that period of time). Also, mining is random, if you happened to mine a block, wouldn't you want to get the block reward even ...


2

Yes, in general node A will send the entire block with all transactions in entirety to other nodes for them to validate. The receiving nodes will receive an entire block with everything in the block header and every transaction in the order that is required by the merkle root and they will validate everything in that block. There is a network optimization ...


2

The question at this step is: does the wallet app perform any kind of transaction validation that requires to check the whole history of the blockchain at this level ? It depends on the wallet. In general, a wallet will likely do some validation as a sanity check to ensure that the transaction they create is valid and will be accepted by nodes on the ...


2

Each non-pruning full node (peer) stores a complete copy of the blockchain - pruned nodes store a complete copy of the current state, but may not have all historical blocks available. When a node validates a transaction or a block, it is only validating it against its local view of the blockchain - this means that looking up data is pretty fast, since all ...


2

When a miner validates a block, does the block contain all transactions in Bitcoin for that time period? See this question for info about the structure of a block. A block can contain up to 4,000,000 weight units worth of transactions. So the miner can select transactions to include in the block, up to this limit. Generally, the miner will select the ...


2

A reindex will not redownload the block. However, after safely shutting down Bitcoin Core, you can delete the block file containing that block. When you start it again, you will need to reindex, but once it gets to the blocks that you deleted, it will redownload them.


2

The formula is correct - a halving occurs every 210000 blocks. If the average time between each block is exactly 10 minutes, you wind up with a total time of about 3.995 years. However, if blocks are mined slightly slower, you will take slightly longer than 4 years - if they are mined faster than 10 minutes, it'll take less than 4 years to get to the next ...


2

AFter halving, the reward goes down by 1/2, some miners may find it is unprofitable to mine thus shutting down their mining operation. However, the network difficulty remains the same until the next difficulty adjustment, which is every 2016 blocks (14 days approximately). Thus, the block time will increase to > 10 mins per block until the next difficulty ...


1

For one, there is no JSON block format - different APIs have different ways of interpreting and displaying a block in a JSON response, and none of them will ever match the block size. Your mistake appears to be saving the actual hex block as text. 1996396 = 2 * 998198 You must write the data as an actual binary file. i.e., write 12 as the byte 0x12, ...


1

For this task, it's better to run a full-node with the transaction indexing txindex=1. Then you can get the number of confirmations from the txid of a transaction by calling: bitcoin-cli getrawtransaction "txid" true and checking under the field confirmations. If you have jq installed you can call for example bitcoin-cli getrawtransaction ...


1

To put it simply, blockchain is essentially a history of transactions, with built in measures to confirm that this transaction history cannot be altered. That being said, transactions can be either spent or unspent. Spent transactions are transactions that have already been used as inputs in another transaction. Unspent transactions are transactions that ...


1

When miners build valid blocks with transactions, they put in significant amount of compute work to generate a hash of the block header that meets the difficulty requirement. Blockchain is a chain of blocks where each block header references the hash of the header of the previous block. The hash of the block header is calculated using all the elements of the ...


1

he is inputting any arbitrary values, in order to get a value that can be hashed into something with certain preceding zeros. When he got that value, he put that value into the blockchain and generate a new block. It happens in reverse. First the miner builds the new block itself. Then builds its header, then hashes that header. Also what the miner looks ...


1

The timestamp is set by the miner and is part of the data hashed for the Proof of Work. So it is set at the time the miner begins hashing a particular header and searching for a nonce for it.


1

Hashes don't actually 'change'. When you add a transaction to a block you are creating another block. It's like an author published a book and then next year printed a new edition with an extra comma in the page 36 and the fans said he released a 'new' book. It doesn't make sense for books but for blockchain every bit counts.


1

Full nodes validate everything. A miner must be running a full node. Not all full nodes are miners, but all miners are full nodes. A full node validates everything in a block; it validates the transactions, it checks the block header is correct, and checks the Proof of Work is correct. So in the validation process, full nodes (and thus miners) will verify ...


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