That would change the hash of the block header, and most likely will render the new hash invalid. From what I understand, the timestamp is included in the block header before a hash is calculated.

Back to the topic question, there seems to be no specific value for 'every few seconds'. I'm wondering if the Wiki is correct, since a miner can simply add the current timestamp, start mining, and (when a hash is found within 10 minutes) publish the block. Agree on using the timestamp as an additional source in combination with the nonce.

Hi all,

Block mining is the fine art of hashing a block header. The block header contains, amongst other fields, a time field. This field contains a timestamp that is updated 'every few seconds', according to https://en.bitcoin.it/wiki/Block_hashing_algorithm and many other sources.

However, it is unclear what is meant with 'a few'. Is it 2 seconds? Or 10 seconds? Perhaps 42 seconds?
Also, is there any documented reference on the exact number of seconds after which the timestamp in a block is updated?

Thanks.

Fevir

Thanks, that's the details I was looking for

Hi,

A quick question. Assume that a block body contains several transactions (tx), and none of these transactions are of equal length. On bit level, transactions are represented by a set of 0 and 1. A set of tx will therefore result in a set of 0 and 1. Now, if a block contains multiple tx, how can the receiver of a block distinguish each transaction in the block body?

Thanks.

After some testing, yes, it needed another sort, thanks.

However, I seem to be getting only a single chain tip (the latest block), probably because I'm connected to a single node only. This is my output:
$ bitcoin-cli getchaintips
[
  {
    "height": 432407,
    "hash": "0000000000000000015ef5f0c0aba9e0697b38010b50eb0beaf7f795416440a6",
    "branchlen": 0,
    "status": "active"
  }


As an open question, what is the maximum number of Bitcoin blockchain tips (single fork) you ever observed?

Hi,

Thanks for your reply. Indeed, the 'bitcoin-cli getchaintips' command seems to be working.

Just to make sure to get it right, if I perform a (on Linux):
bitcoin-cli getchaintips | grep height | <some sed here, leaving only the numerical height> > <file>
and,
sort <file> | uniq -c | head

should provide an overview of the top 10 largest stale blocks of the same height?

Hi All,

A fork occurs when two or more miners separately create a block at approximately the same time. The Bitcoin blockchain then (temporarily) consists of two or more blockchain heads.

This site (http://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date) shows the length of the longest fork created on the Bitcoin blockchain.

However, if two miners separately create a block, a two-headed blockchain appears. If n-miners separately create a block, an n-headed blockchain appears. What is the largest value of n ever observed on the Bitcoin blockchain?

And is there a source where one can observe the average fork-height (n) of the Bitcoin blockchain?

Thanks,
Fevir

Thanks for explaining, I get it :-)

Thanks! Though as a malicious vendor, can I not 'push' the transaction of my 'customer', by just copying the transaction and broadcast it to the network?

Say, I send 10 BTC from my account (holding 20 BTC) ABC to a vendor's account XYZ. Right after that, I send 10 BTC from my account ABC to the same vendor's account XYZ (consider I'd like to buy 2 products). We now have transaction t1 and transaction t2, which seem identical.

Besides the practical point of creating 1 transaction holding 20 BTC from ABC to XYZ, can t1 and t2 occur in one (valid) block? If so, why doesn't the malicious vendor not re-submit t1 infinite times untill my account has been depleted?

Quick question on XCN: is it possible to create two transactions, from and to similar addresses with a similar amount of XCN?

More concrete, suppose I wish to buy two products from a vendor online. First, I create a transaction: A --> B, amount X
Then immediately after my purchase, I decide I wish to buy another product with the same price, soL: A --> B, amount X.

Now there's two transactions from account A, to account B, with amount X. Would that be considered valid (taking into account a scenario where one transaction is re-submitted)?

Thanks for your response. The main point of the idea stated above is to increase the number of transactions in a block, without the need of raising the blocksize, to ensure propagation time similar to its current implementation.

Transactions need to be send and propagated anyway, but why do this twice? First the actual transaction is send, second, the transaction is send in the block body. Larger transactions, say 100kb, also require a larger fee, as in the current Bitcoin protocol, I would not consider that a concern. Also, nowadays large-size transactions can be created and send, too. Actually, that supports the question, why send a transaction twice?

To recap:
-transactions can be of any size, but larger transactions require larger fees
-transactions are propagated within 10 seconds to 90% of the network, and stored in the mempool
-all valid transactions received are hashed (SHA256 / /SHA128)
-a block is max 1 MB, containing a header, and a body. The block body contains  hashes of the transactions. The block header also contains the Merkle root of the transactions of which the hash is included in the block.
-a block is mined, 600 seconds on average, send, and propagates in the network.
-the hashes in the body of a valid block are matched against the hashes in the mempool.
-the block is added to the chain, containing both hashes and transactions.

*blocks send in the network are 1MB only. <-- main point: keep the blocksize similar but increase the number of transactions in the block.
*block stored on the blockchain are 8.8 MB <-- perhaps optimization will decrease the block size

Need to clarify on that.

The size of the block created by a miner is 1 MB. The idea is that blocks of 1 MB are propagated faster then, say, 8 MB blocks, thus limiting the chance of a fork.
Once the block has been propagated, the block stored indeed is 8 MB. Though my guess is that this can be improved. The initial idea is increasing the number of transactions per block while keeping block propagation time stable.

With the many scalability discussions and proposals out there, I was wondering if anyone ever considered the following.

Current situation.
Blocks take an average of 10 minutes (600 seconds) to mine. Each block has a size of 1 MB (1.000.000 bytes (8.000.000 bits)), and each transaction is on average 250 bytes. So, each block can contain approximately 4.000 transactions. With an average of 600 seconds per generated block, 4000/600 = 6,6 = 7 transactions per second (tps).
Valid transactions are stored in the mempool. Bitcoin transactions propagate in the network within, say, 10 seconds to 90% of the network (http://bitcoinstats.com/network/propagation/).

Idea
Now, what if all nodes create a hash (SHA256 (each hash is 256 bits)) of each valid transaction received. Each mempool stores 1. the transaction and 2. its hash. A miner creates a block, but instead of collecting actual transactions in the block body, the block body contains hashes of the transactions. On average, each ten minutes a block is propagated in the network, and all nodes receiving the block match the hashes in the block body with the hashes (and their corresponding transactions) in the mempool. The mempool is cleared of those transactions (assuming no fork occurs), and a block is added to the blockchain containing a body with both hashes and transactions.

By doing so, each block can contain (excluding the coinbase transaction) 1 MB = 8.000.000 bits / 256 bits = 31.250 transactions. The number of transactions in a block is 7 times larger (edit: 14x with SHA128, almost 100 tps without tree optimization), without having to increase the block size.

Feedback
My guess is that, similar to Gavin Andresen's IBLT proposal (https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2) a possible concern is that mempools are not synced. In the above example, I'm assuming that the transactions of which the hash is included in blocks, are stored in mempools considering the 10 second transaction propagation time versus the 600 second block mining time.

Any thoughts?

Thanks for answering. So if we'd be able to store transactions outside of the chain, this would be for now a viable solution. Interesting, going to ponder on that :-)

Hi,

I was just wondering based on some rough figures, according to this site http://bitcoinstats.com/network/propagation/2013/11/23 it takes 8.3 seconds for a message to propagate to 90% of the network and transactions are stored locally in a node's memory pool. It takes 125.8 (say 130) seconds to propagate a message to 99% of the network. Every block is found at an average of 10 minutes (600 seconds). Once a block is created, it contains transactions that have been broadcasted to the network, so the assumption here is that once a miner starts mining a block it took 130 seconds to reach that miner, and the transaction still has 600-130=470 seconds to propagate through the rest of the network.

Each block contains approximately 4200 transactions (assuming an average transactions size of 235 bytes, depending on the signature, and a 1MB (1.000.000 in bytes) block size), which leads to (4200/600) approximately 7 transactions per second.

Now, what if each node creates a hash (say SHA256) of each valid transactions, and adds those hashes in a block. Each block can contain 8.000.000 (in bits) / 256 = 31.250 transactions, a factor 7 increase.

The miner broadcasts the block containing the hashes of transactions, and every other node verifies these hashes with its own memory pool in which the transactions and corresponding hashes are stored. If valid, the block is added to the chain, including the actual transactions in case of any forks occurring. Would that work?

Thanks! makes sense

Hi all,

I was wondering about the following scenario:

When a node receives two valid blocks, a fork occurs. Then, when a next block is found and send to that node, the longest chain will be considered as valid. This is the process called forking.

First question, at what rate does a fork occur in Bitcoin? With thousands of nodes mining, it seems that a fork must occur on a regular basis – are there any stats on how often a fork happens?

Second, knowing that Bitcoin uses a P2P network, assume there's a single connection that connects two parts of the network (a single point of failure in a P2P network). That connection fails for 24 hours, and the two separate networks continue mining. Both are working on their own version of the blockchain. Then, a smart network engineer fixes the cable and the connection is restored. Effectively, there are two versions of the blockchain and both are valid (for each part of the network). New blocks from network A are rejected by B (and vice versa), because the longest chain rule is applied. Instead of a 'fork', we have 'knife', cutting the network in half.

Second question, how does Bitcoin deal with such an issue (though theoretically, considering it's an P2P network)?

Cheers,
Fevir

Thanks! I'll see if I can create such a script.

Hi all,

Each block in the blockchain contains a nonce - a seemingly insignificant, yet important number for each block.

Assuming I'm running a full node and have a copy of the blockchain, what would be a (preferably easy) way to get a list (just plain text will do) of all nonces from the Genesis block up untill now?

Thanks!

Cheers,
Fevir