5

A transaction could go unconfirmed indefinitely. The order in which transactions are confirmed is decided by miners, and generally they will be incentivized to include only the highest fee-rate transactions, to maximize their revenue. Even a low fee-rate transaction may eventually confirm, once the mempool clears out. But there is no guarantee of this, ...


4

The hash is a result of computing two rounds of SHA256 on the block header. If you set the hash yourself, when other nodes try to verify the hash by performing the aforementioned computation, it will not (however, there is an infinitesimal chance) result in "63 zeros followed by a 1". I suggest reading about hash functions. The only reliable way to create ...


3

What do you mean by "decode"? A hash algorithm is a one-way function. The hash-function takes some block header information (timestamp, nonce, a hash of all transactions) and returns such a hexadecimal value. There is no way to "decode" such a hash. Its reason is just to identify a unique block (and deciding wheather someone gets the block reward or not). ...


3

I don't think there is a site that will show you this information, but it is fairly trivial to find out. Here's an old Bitcointalk thread that discusses this: https://bitcointalk.org/index.php?topic=29675.0 Here's a python script that will calculate it for you. You will need a bitcoind for it to connect to: from bitcoinrpc.authproxy import ...


3

It's the sum of difficulty targets, not the individual difficulty scores. Therefore, two blocks at the same blockchain height are always the cumulative weight (unless we're in a longer blockchain fork across a difficulty reset). If it were individual difficulty scores, this would open the door for all sorts of gaming, e.g. selfish mining after finding a ...


2

I believe what merklexy wanted to know is how to get information about the block. And the answer is, you cannot get details about the block from its hash. If you have access to the bitcoin command line interface (bitcoin-cli) then you can simply execute bitcoin-cli getblock 00000000000000000045c639280aee532c5b12b03c80bfdec7aae674fd8246e0


2

I improved on this to print the lowest 50 block hashes as well as their heights and the dates they were generated: from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException import datetime # rpc_user and rpc_password are set in the bitcoin.conf file rpc_user = "user" rpc_password = "password" rpc_connection = AuthServiceProxy("http://%s:%s@127.0....


2

Yes, it is. That is the hash of the block header, so it is used as an identifier for that block, and is used to reference it in the next block in the same way that a hash of a transaction (txid) is used to refer to that transaction.


2

The leading zeroes is what makes altering block data hard. One of the things that makes a block valid is that it's hash is less than some predetermined value. For simplicity, this can be thought of as the hash has to have some predetermined number of leading zeroes. However making such a block meet that requirements is hard and being able to do so proves ...


2

It doesn't matter which nonces you test or in what order that other than you need to avoid testing the exact same block header twice (since that would obviously be a waste of time). It's useful to test all the nonce values since if you don't test them all you will need to update extranonce more often, though not critical. Even though miners increment their ...


1

There is no explicit marker that identifies a hash as being related to a transaction/block, but as mentioned by OP, there is an implicit assumption that can be made, due to the difficulty target for blocks that is imposed by the network’s nodes. Pragmatically, this means that a hash with an improbably low value could be assumed to be a potential block hash....


1

This is not possible, both are sha256 hashes, and contain no markers as to their origin.


1

Increasing the nonce size would not increase or decrease the expected block time. The block time is maintained via the difficulty adjustment algorithm, which adjusts the network difficulty according to the apparent time it took for the last 2016 blocks to be found. How quickly blocks are found can thus be used to estimate how many hashes/second the ...


1

As @stewbasic succinctly pointed out in a comment: The miner does not pick a hash. The miner picks a header, from which the hash is computed. The block hash is the digest of hashing the block header with SHA-256d. This digest must meet the difficulty requirement when interpreted as a number, and since it's unique is also used as an identifier for the ...


1

The problem is that you are hashing the string of the hexadecimal representation of the bytes of the block header, not the bytes of the block header itself. You need to hash the bytes of the block header itself. You need to set everything as a byte array, not a string. So you would have something like this for the entire block header all together: Byte[] ...


1

giving them a number H(studentID||Bi) where Bi is the ith block header in the Bitcoin blockchain.Would the scheme be me more secure if you instead used H(studentID||Bi-1|| Bi)? For this purposes of this question, the bitcoin header Bi = H(Bi-1 || other stuff). Under a black box assumption of H()'s behavior, the two schemes are practically equivalent. You ...


1

Altering data in a Bitcoin is hard because it requires a lot of dedicated cost. The confirmation of a transaction or data implies that it is committed to the blockchain with a valid proof-of-work, which is a specific form of a cost-proof. Proof-of-Stake (opportunity cost), Proof-of-SpaceTime (memory) can all be reduced to dedicated cost-proofs. Let's ...


1

As I understood, in the block hash, the amount of zero's is the nonce, No, that is incorrect. The nonce is a value in the block header, which is then hashed. By changing the nonce, a new block header is effectively created which has its own unique hash. Then the hash is recomputed for each value until a hash containing the required number of zero bits ...


1

The "consensus algorithm" you are referring to is predicated on the "hash guessing" you are trying to eliminate. If we skipped "hash guessing," the resiliency and reliability of the blockchain would be completely destroyed. This question assumes at least 2 false premises and cannot be meaningfully answered.


1

Look at these numbers in binary. A hex digit is 4 bits, so 7 in hex is 0111 binary, 3 is 0011, 1 is 0001. You can see that 7 is the largest hex digit in which the most significant bit is 0; 3 is the largest hex digit in which the two most significant bits are 0; and so on. Yes, you can get this same value by taking the log2 of the hash value and ...


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