What happen when 2 transactions with one doublespending the other reachs the same block?

Let’s have 2 transactions. The second one is duplicating Input of the first one.
Both have very high fees so they are selected by miner to be included in the same block but before passing validation (because it makes no sense to validate transactions if they aren’t included in the block after because the fee is too low).

Which is the transaction is going to be rejected by not being included in the block ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?

And where is the code in Bitcoin core handling this ? I mean which source files and lines ?

doublespend

user2284570

Posted 2019-04-23T21:40:10.523

Reputation: 189

So it’s the case of duplicate inputs for 2 different transactions in the same block. – user2284570 – 2019-04-23T21:41:32.553

Answers

Which is the transaction is going to be rejected ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?

Generally speaking, miners will choose the transaction that has the highest fee, but they are not obliged to. In fact they don't need to mine any of your transactions if they don't want to.

Both have very high fees so they are selected by miner to be included in the same block.

No, the miner must choose 1 or zero not both, otherwise the block they create will be invalid if it contains a double-spend. Invalid blocks will waste the miners time and money as they will be rejected by the network.

And where is the code in Bitcoin core handling this ?

Sorry, can't help with specific location.

Jonathan Cross

Posted 2019-04-23T21:40:10.523

Reputation: 1 130

1@user2284570 that is incorrect. I think you're mixing up what 'validate' means. Every node on the network that hears about a new tx will validate it before relaying it to network peers. Likewise, miners will validate each transaction before the add it to a block template that they will mine one. Once the miner finds a valid block, the transactions they added to it are said to be confirmed. So there is a difference between valid and confirmed. In fact, an otherwise valid transaction may never be confirmed (perhaps it paid too low a fee, or was not seen by miners, etc). – chytrik – 2019-04-24T01:19:49.853

@chytrik what I mean is miners don’t process the whole mempool and then includes transactions with the best fees in the block : they only check those which pay enough fees to be included. – user2284570 – 2019-04-24T12:44:36.243

1@user2284570 if a transaction is in the miner’s mempool, that means they have already validated it. So yes, miners do ‘process the whole mempool’ first – chytrik – 2019-04-24T16:09:03.047

@chytrik no! The mempool don t check for double spends which are in the mempool. And as the process of nodes is not serialized unlike the block generation process this wouldn t makes sense. So in the case of the mempool double spending checking is performed only against coins in the ledger not on transactions not yet mined. – user2284570 – 2019-04-24T16:41:27.753

2@user2284570 Just repeating this claim does not make it true. As everyone is already telling you: all transactions in the mempool are already validated, or they wouldn't be in the mempool. Miners typically select from this set of valid transactions that maximizes feerate. – Pieter Wuille – 2019-04-24T16:45:30.427

2Regarding double-spend checking: Bitcoin Core maintains two "views" of the UTXO set; one from just confirmed blocks, and one from blocks + everything in the mempool. New incoming transactions are fully validated against the latter (they're allowed to spend unconfirmed outputs). When a new block comes in, the mempool is reconciled with it (removing transactions that were confirmed or now conflict with the new block). – Pieter Wuille – 2019-04-24T16:47:37.830

@PieterWuille but I m not merely repeateating, this is you who are wrong. But said otherwise, checktxinputs in validation.cpp uses haveInput which only read from disk cache or from disk directly not in the mempool. And for reference https://bitcoin.stackexchange.com/a/37534

– user2284570 – 2019-04-24T17:09:47.003

2@user2284570 CheckTxInputs is passed a CCoinsViewCache object in AcceptToMemoryPoolWorker, which is backed by a CCoinsViewMemPool object, which in its turn looks up transactions in the mempool. – Pieter Wuille – 2019-04-24T17:43:58.863

@PieterWuille this is nonsense. Even then what happens when submitting 2 new transactions using the same inputs to 2 different unconnected nodes considering network latency ? There are several nodes, this block generation which serializes the process. – user2284570 – 2019-04-24T17:47:39.603

2@user2284570 If you can't have a civil conversation about this, I'm done explaining. There are lots of interesting details to learn about how all of this works, but you seem to reject everything knowledgeable people try to explain. – Pieter Wuille – 2019-04-24T17:51:03.023

@PieterWuille and finally an example of what I’m saying.

– user2284570 – 2019-04-24T17:55:16.003

1@user2284570 that example involves situations in which some miners would not accept certain transactions into their mempool, it does not show more than one tx in a certain miner’s mempool spending the same inputs. As people here have attempted to explain to you, such a situation is not possible. Note that each node maintains its own mempool, and that is part of how double spend txs can be published. Double spent inputs can not exist validly in a single node’s/miner’s mempool. – chytrik – 2019-04-24T20:43:20.217

Both have very high fees so they are selected by miner to be included in the same block. Before being validated of course. Because it makes no sense to validate inputs if they aren’t included in the block after. – user2284570 – 2019-04-23T21:57:08.830

2@user2284570 no, a transaction is validated before it is added to a block, that is how blocks are built: From transactions that are known to be valid, as a whole. It makes no sense to only check to see if they are valid after mining a block, that would be a waste of resources. – chytrik – 2019-04-23T22:00:30.180

@chytrik I’m talking about fees. Transactions are validated by the miner only if they pay enough fees to be included in next block. – user2284570 – 2019-04-24T00:25:37.667

Every transaction included in a block must be valid in order for the block to be valid. An input can only be spent once, any attempt to spend it again would be invalid.

So in your example, the entire block would be invalid and thus rejected by the network. Nodes that hear about and attempt to validate the block would get to the second transaction, see it is invalid (because one of its inputs was already spent), and reject the entire block.

Generally, miners will choose the transaction that pays them the most. The bitcoin-core rules for relaying transactions are separate from this, so they aren’t of much consequence in the real world. A miner could easily run their own modified software that builds blocks in a way they like. Even if a transaction isn’t marked RBF, there is nothing stopping a miner from including a higher paying transaction they heard about instead.

chytrik

Posted 2019-04-23T21:40:10.523

Reputation: 10 276

No, I was meaning which is the block the miner will reject if he/she uses Bitcoin core. Because of course miners rejects transactions that attempt to double spend. – user2284570 – 2019-04-23T21:52:05.090

I added a bit to my answer, hopefully that helps. – chytrik – 2019-04-23T21:58:06.903

I am going to interpret this question from a different angle: If a node were to receive a block with two transactions that spend the same input, which transaction will it return to the mempool and which will it discard?

When a node receives a block that contains two or more transactions that spend the same inputs, the block would be marked invalid and thrown away entirely. None of the transactions in that block would be considered confirmed and any transaction that was already in the mempool will remain there. A transaction was not in the mempool but was in the block will not be added to the mempool.

As such, when the node receives this invalid block and validates it, when it determines it to be invalid, it throws away the block and does nothing. It does not change the UTXO set and it does not change the mempool. This means that if any of the conflicting transactions were in the mempool when the block is received, it will remain there. If none were, none of those transactions will be added to the mempool.

So if one of the conflicting transactions paid a higher fee, but the lower fee transaction was already in the node's mempool, the lower fee transaction would stay in the mempool and the higher fee one thrown away with the block.

The code for this behavior is here. ConnectBlock takes a CCoinsViewCache which is a cache for the UTXO set. This cache only writes out the changes made to it when its Flush() function is called. ConnectBlock will return false because the block is invalid and as such, this function will return here before Flush() can be called here. So no changes will be made to the UTXO set.

Furthermore, that early return due to an invalid block means that the mempool update will not occur either. The call for the mempool update here will not be reached because of the early return and thus the the transactions that were in the mempool at the time the block was received will remain there, and the ones that weren't in the mempool will be thrown out along with the block.

Andrew Chow

Posted 2019-04-23T21:40:10.523

Reputation: 40 910

I’m talking about rejection done by miner which I don’t know because if I’m correct such invalid block rejection is performed in CChainState::ConnectBlock in validation.cpp at UpdateCoin which ensure next input check will take into account coins spent by transactions in the same block. – user2284570 – 2019-04-24T10:18:31.247

2The check for whether an input exists is done in CheckTxInputs which is called in multiple places, including ConnectBlock as well as AcceptToMemoryPoolWorker. It is not just checked when a block received; it is always checked whenever a transaction is received, whether that is in a block or over the network as an unconfirmed transaction. – Andrew Chow – 2019-04-24T17:46:35.700