Topic: Can a Tx be mined first and broadcast later ? (Read 1119 times)

You are using words that don't seem to make sense.

You are saying that the miner needs to "broadcast the transaction just before broadcasting the block of transactions".  That's a bit like saying that if you want to drive your car to the store you need to drive your engine to the store before you drive your car there.

The miner certainly can broadcast the transaction by itself before he broadcasts the entire block of transactions, but he isn't required to. He can just send the block (which has the transaction in it).

Depending on the peers that the miner is communicating with there might be some importance to the order that the miner transmits the portions of the block, but that is a matter of communications protocol with the peer and not an intrinsic requirement for bitcoin's operation.


There is no need to transmit any transaction separately before broadcasting the solved block of transactions.

The header is 80 bytes.  It consists of:

• A 4 byte version number
• The 32 byte SHA256 hash of the most recently solved previous block header (this is what turns the blocks into a "chain)
• The 32 byte SHA256 merkle root of the transactions in the block
• A 4 byte timestamp (this is chosen when the block header is built and can be different from actual time by as much as a few hours)
• A 4 byte representation of the current difficulty target
• A 4 byte nonce

Since most of the network will already have most of the transactions from a block, there is an opportunity for faster propagation of blocks if the block header and merkle tree are sent first, and then peers are allowed to request the transactions that are in the merkle tree which they don't yet have.  In this way the miner doesn't need to broadcast all transactions, they just need to hand over the transactions that any peers haven't seen yet.  Each peer should not consider the block to be valid, or solved, until they have received all the missing transactions and can verify that the block and all transactions are valid.

Yes. True. I was not well aware about the Merkle tree formation through transactions, which led to my confusion. So, it seems, a block can be found that includes a Tx which is not in knowledge of any node. But, to get that block on chain, miner needs to broadcast the Tx just before the block.

I have a basic question here. You said...
I suppose, header for that block is represented by the block hash, e.g. 000000000000000005a01fa8684db141807c6a8f1ccbd7a58b0740f25f162e01. As the miner will also broadcast the block of transactions in that block, does he need to broadcast any Tx, that he created locally, separately before broadcasting the block of transactions ?

It is clear that you don't understand the mining process properly, nor do you understand what bitcoin accomplishes or how it accomplishes it.  Let's walk through this one step at a time:

1. Miner locally creates a Tx hash with confirmed unspent Tx output.

You're leaving out some details in what you are saying, but if I'm making the right assumptions, then so far you're doing ok.  The miner would create a transaction (not just a transaction hash).  I assume when you say "with confirmed unspent Tx output", that what you mean is that the inputs to the transaction are all valid unspent outputs that have been previously confirmed in an earlier block in the blockchain?

2. Miner finds a block.

Ok, you're starting to stray from reality here just a bit.  The miner doesn't "find" a block.  They "create" a block.  As part of the creation of a block they create an 80 byte block header that includes a merkle root representing all the transactions they've chosen for their block.  Then they search for a valid nonce for that block header to "solve" it.  Changing any transaction in the block would result in a new merkle root, so they would need to "solve" it all over again.

3. Miner adds the locally created Tx to the Tx list of that block.

Ok, now you've gone completely off the rails.  Part of the process of "creating a block" is to choose the transactions that will be part of the block.  That has to be done before the block is solved.  If you change the transaction list, then you've changed the block and the new block is no longer solved (until you solve it again).

4. Miner broadcasts the block.

Ok, once the block is solved, the miner can broadcast the block.

5. Miner broadcasts the Tx.

And now you've gone off the rails again. The transaction is part of the block.  It is a "block of transactions" and a header for that block.  You can't broadcast a block of transactions without broadcasting the block of transactions.  That doesn't even make sense.  Perhaps you are asking if the miner can broadcast just the block header?  I suppose you could, but peer nodes and other miners aren't going to be able to validate the miner's block until they receive all the transactions.  Therefore, they won't (or at least shouldn't) consider it to be a valid block until the transactions are braodcast.

Absolutely not!  Adding a transaction changes the merkle tree and therefore the block header.

Completely possible, in fact, probably has been done before. However, they will still need to broadcast the transaction with the block in order to make the block valid since nodes validate all of the transactions included in a block.

But, my question was different. I am not saying block broadcast to be delayed. I am saying Tx broadcast to be delayed. The process I am saying is as follows...

1. Miner locally creates a Tx hash with confirmed unspent Tx output.

2. Miner finds a block.

3. Miner adds the locally created Tx to the Tx list of that block.

4. Miner broadcasts the block.

5. Miner broadcasts the Tx.

Is the above process possible ?

A miner doesn't have to braodcast the block as soon as he solves it if he doesn't want to.

However, if a miner does not broadcast the block immediately, he risks some other miner broadcasting a block first and causing the unbroadcast block to become orphaned.  This would result in the miner of the orphaned block losing the entire block reward. It would also mean that the miner's transaction would need to be mined into a new block in order to be confirmed.

Is it possible for a miner to create a Tx locally, include it in a block he has mined and boradcast it later ?