What transactions didn't make it to the Bitcoin blockchain?

[averied]

Bitcoin,I want to transfer some Amount so I broadcast a transaction that is picked up by miners. So if my transaction get's in 2 different currently processing blocks by different miners and one of them is mined into the blockchain, the second miner's block is dropped.

My transaction did, but also some transactions did not make it to the mined block.

How does the protocol know which transactions made it and which didn't? Another way of asking, how is a transaction "marked" as mined so if it's still floating in the p2p network, miners know that this transaction is already in the blockchain.

[bob123]

Bitcoin,I want to transfer some Amount so I broadcast a transaction that is picked up by miners.

You broadcast a transaction which will be in the mempool of the nodes until a miner decides to include your transaction into a block.

So if my transaction get's in 2 different currently processing blocks by different miners and one of them is mined into the blockchain, the second miner's block is dropped.

Blocks are not 'mined into the blockchain'. Mining simply means to create a valid block.
If 2 blocks get mined at the same time (very uncommon, but possible), the NEXT block will decide which one is valid.
The longest chain is the actual valid blockchain.

Small example:
Miner A and miner B do mine block nr. X at the same time. They both broadcast it into the network.
A portion of the miner in the network did receive block X from A and are trying to build the next block upon this block.
Another portion of the miner did receive block X from B and are trying to build the next block upon this block.

Now, miner C (who did mine using block X from A) found a block (X+1) and shares it.

The whole network now accepts this chain (Block X from A --> Block X+1 from C) as valid chain since it is the LONGEST valid one.
Block X from miner B will get discarded by the nodes.

How does the protocol know which transactions made it and which didn't? Another way of asking, how is a transaction "marked" as mined so if it's still floating in the p2p network, miners know that this transaction is already in the blockchain.

A transaction is not 'marked' as mined. Blocks are being mined (created).
A transaction is being confirmed by being included into a block.

So, once a block is being mined which includes your transaction, it is considered as a confirmed transaction (Amount of confirmations = 1 + Number_of_blocks_mined_after_your_TX_got_included).

[averied]

Thanks, Amount of confirmations is a interesting concept I didn't know about. However, I would like to know what happens tecnically to a transaction that is accepted by a mining block that gets discarded because another miner has submited a valid block.

Example
1. Tx1 is broadcasted
2. Tx2 is broadcasted
3. Miner1 gets Tx1 and Tx2
4. Miner2 gets only Tx1
5. Miner2 submits a valid block
6. Miner1 discards current block and starts mining a new one

At this point, how does the protocol work? What happens to Tx2? Does the original broadcaster re-broadcast Tx2 because he finds that his transaction is not in the last valid block? or does it work some other way?

7. Miner3 submits a valid block.

If I understand well, Tx1 has now 2 confirmations.

[bob123]

Thanks, Amount of confirmations is a interesting concept I didn't know about. However, I would like to know what happens tecnically to a transaction that is accepted by a mining block that gets discarded because another miner has submited a valid block.

Example
1. Tx1 is broadcasted
2. Tx2 is broadcasted
3. Miner1 gets Tx1 and Tx2
4. Miner2 gets only Tx1
5. Miner2 submits a valid block
6. Miner1 discards current block and starts mining a new one

At this point, how does the protocol work? What happens to Tx2? Does the original broadcaster re-broadcast Tx2 because he finds that his transaction is not in the last valid block? or does it work some other way?

Your example actually isn't an 'example' for discarded blocks, since Miner2 is the only one who does create a valid block (1. - 6.).
Since TX2 has never confirmed in your example, all nodes which did receive TX2 still relay it and keep it in their mempool.
Whether Miner2 does decide to (maliciously?) ignore Tx2 doesn't matter. It will still get relayed through all nodes (and therefore also every miner) in the network.

7. Miner3 submits a valid block.

If I understand well, Tx1 has now 2 confirmations.

IF Miner2 did include Tx1 into the block he has created in 5), then yes.

[averied]

Last question, (hope so)..

So.. how does Miner1 know that Tx1 was included in the last valid block submited by Miner2. Is there any stage in the protocol where Miner1 will separate transactions that were included in the last valid block and those that did not, so they get relayed and included in the new processing?

[HeRetiK]

Last question, (hope so)..

So.. how does Miner1 know that Tx1 was included in the last valid block submited by Miner2. Is there any stage in the protocol where Miner1 will separate transactions that were included in the last valid block and those that did not, so they get relayed and included in the new processing?

As soon as Miner1 gets the blockchain update from Miner2 (directly or via their peers) it starts validating the new block and clears out any transactions in its mempool that are now deemed invalid (eg. Tx1).

However validating the new block takes time and the miner keeps on hashing in the background, so there's a short timeframe where Miner2 will assume that every transaction in its mempool is potentially invalidated (ie. confirmed) and thus work on an empty block until the previous block has been fully validated. That is due to the fact that accidentally adding an already confirmed transaction in a block would make the whole block invalid and thus the miner would lose its block reward while empty blocks are not associated with any such risks.

This is why empty blocks tend to appear when a blocks are found in short succession. Note that this behaviour is dependent on the implementation of the mining software and is not specified by the Bitcoin protocol itself.

[averied]

This is why empty blocks tend to appear when a blocks are found in short succession. Note that this behaviour is dependent on the implementation of the mining software and is not specified by the Bitcoin protocol itself.

Excellent!! Thanks for explaning. I'm very much interested in this part of the protocol. Does anyone know where in the bitcoin core project source code  (https://github.com/bitcoin/bitcoin) is this part implemented?

[HeRetiK]

This is why empty blocks tend to appear when a blocks are found in short succession. Note that this behaviour is dependent on the implementation of the mining software and is not specified by the Bitcoin protocol itself.

Excellent!! Thanks for explaning. I'm very much interested in this part of the protocol. Does anyone know where in the bitcoin core project source code  (https://github.com/bitcoin/bitcoin) is this part implemented?

Bitcoin Core's mining loop can be found here:
https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mining.cpp#L106-L152

However it's pretty much a leftover from the CPU mining days so I don't think it's still being used on mainnet. Also I'm rather unfamiliar with Bitcoin's codebase, so someone else may correct me.


The most commonly used mining and mining pool software can be found here:
https://github.com/ckolivas/cgminer
https://bitbucket.org/ckolivas/ckpool

A codebase with which I'm even less familiar, but it may point you in the right direction.

perchè è stato eliminato il mio post? geni se non date una motivazione non potete farlo

I guess because you posted in Italian. Please keep your posts in English on the general boards and leave non-English post in the respective local boards only; such as the one for Italian: https://bitcointalk.org/index.php?board=28.0