Hot answers tagged

42

As of Bitcoin Core 0.14.0, these are the ways a transaction can leave the mempool: The transaction was included in a block. The transaction or one of its unconfirmed ancestors conflicts with a transaction that was included in a block. The transaction was replaced by a newer version (see BIP 125). The transaction was at the bottom of the mempool (when sorted ...


14

The minRelayTxFee specifies a feerate acting as a lower bound for a node's mempool. A node will not admit unconfirmed transactions below that feerate to its mempool and thus will not relay them to its peers. The minRelayTxFee is a configuration setting and can be specified by each node operator independently. The value only impacts unconfirmed transactions, ...


11

Each node maintains a separate, individual mempool. While the default limits its size to 300 MiB, each node operator can set their own value. Note that the mempool size limit does not pertain to the serialized data or the transaction weight of the queued transactions (which is what is written to the block and what you see listed on a mempool monitors ...


9

A large part of those transactions only needs to be kept for a limited time, in the order of 10 minutes. Once transactions are in a block they are removed from the mempool and the whole block is written to disk. However while the transactions are in memory they are actually consulted quite often. For every newly incoming transactions checks need to be done ...


9

Yes, Bitcoin Core will try resending the transaction until it confirms or is replaced. You can make it forget the transaction by starting Bitcoin Core with the option -zapwallettxes=<mode> Then, be sure to use the inputs in another transaction, because the transaction is still valid and might yet be confirmed. The only way to invalidate it is by ...


9

Mempool basics When a bitcoin user wants to pay another user, they craft an announcement to the whole network. This announcement takes the form of a transaction which specifies the funds that are being spent and the funds to be created. It also includes proof that the message was authorized by the owner of the spent funds. These payment promises are gossiped ...


7

There is no fixed expiration time for each node, but the default setting is 72 hours. https://bitcoin.stackexchange.com/a/43165/24926


7

In addition to Mark S.'s answer, since Bitcoin Core 0.12 there actually is an expiration in the mempool, which evicts unconfirmed transactions after N hours, where N is set by -mempoolexpiry, and defaults to 72 hours. This is not a reliable feature, as wallets (and really, anyone) can rebroadcast the transaction, but helps keeping the mempool fresh.


7

No, miners do not need the entire block chain to be accessible. Technically, they don't even need it at all. The blocks themself are only needed for rescanning wallets, reorganisations, and serving blocks to other nodes. That is why pruning them away will likely become viable in the future. What you need for validating blocks and transactions (a fundamental ...


7

First of all, there is no "The mempool". Every full node has an individual mempool, and as these contain no transactions that are already in blocks (confirmed transactions), by definition nodes cannot be guaranteed to have agreement about it. So, what you're looking at it blockchain.info's mempool, which may or may not be similar to that of other nodes. ...


7

The version of the mined block is 0x2fffe000 instead of 536870912. Many miners employ a strategy known as overt Asicboost. This strategy requires modifying the version number like the nonce, so we often see blocks that have strange version numbers. Only 194 transactions from the block template are in the mined block, e.g. ...


6

There is no cap on the maximum size of the mempool, nor a janitor which cleans up transactions which are not confirming. Loss of unconfirmed transactions isn't a problem as wallets are supposed to rebroadcast transactions if they don't confirm within a reasonable time frame, so it wouldn't be unreasonable to drop them in a critical low memory situation. The ...


6

Your answer assumes different nodes can have a consistent view of the mempool. If that were the case, we wouldn't need a blockchain at all, whose sole purpose is establishing consistency between different nodes' view of history. The reason this is not possible is due to the laws of physics. A transaction tx1 broadcast in Australia, which conflicts with a ...


6

It didn't goto zero. You can look at alternate sources https://core.jochen-hoenicke.de/queue/#2d . What happened most probably is that blockchain.info's node went down/rebooted momentarily.


6

Is there just one mempool or does each node keep a copy of the mempool? Neither. Every node has their own mempool of transaction they expect to see confirmed. It's not a copy as there is no consistency between nodes. From my understanding each node needs to keep a copy of the mempool. No, mempools are completely optional. You can configure your node to ...


6

Miners pick transactions from the mempool which is the queue of unconfirmed transactions. When there are fewer transactions waiting than would fit into a block, the block will not be full. The miner could create more transactions themselves, but that would be only useful if they wanted to send one themselves already in the first place, otherwise they'd just ...


6

There is no "the mempool". Each node has its own mempool. So in your example, each node would receive each of the transactions, possibly in a different order, and at different times. It is physically impossible for all three transactions to reach every single node at the exact same time. If we assume that none of the transactions signal for RBF and all of ...


5

'minRelayTxFee' is the node's minimum reward (BTC/KB) for a transaction "transmission" (relay). In the p2p network there could be a node (A) with a minRelayTxFee setted at 0,0001 and a node (B) with a minRelayTxFee setted at 0,0003. In the case of a transaction of 2 KB with a fee of 0,0002 , this tx will be included in the A's mempool and not in the B's ...


5

This is an interesting problem, one that has been studied and discuss within the bitcoin community quite a bit. The basic way to do this is to keep track of a normalized TXID alongside of the actual TXID used in the protocol. Then to calculate the normalized ID of a transaction, you serialize it: With the inputs' txids replaced by their normalized ...


5

Short answer: no, this is impossible. Longer answer: some transactions allow changing the inputs used (ANYONECANPAY inputs). It is also possible to have inputs which do not sign the outputs being created (SIGHASH_NONE). However, a transaction where all inputs are of this type, are worthless, as anyone could change the outputs to credit themselves instead. ...


5

Try the removeprunedfunds RPC command. It deletes the specified transaction from the wallet. … This will effect wallet balances.


5

On a long term average the number of transactions is limited to the number of transactions that can enter the blockchain-- so roughly 7tx/s before segwit and 14tx/s after segwit activates. But on a short term basis while the mempool fills or with transactions being replaced the rate can be as fast as your node can process transactions. On reasonably fast ...


5

Skimming the source code, I found the following reasons for a transaction to be removed from the mempool: It was included in a block A conflicting transaction (i.e. one which spent at least one of the same inputs) was included in a block Expired: it has been in the mempool longer than the time specified by -mempoolexpiry (default 336 hours) The memory pool ...


5

Do all the miners have one global pool filled with transactions Different full nodes have a different version of the mempool. Transactions are broadcasted to the bitcoin network on a best effort basis. If a transaction never reaches a node, it would not include it in the mempool. It would not learn about this transaction until it is included in the block by ...


5

To illustrate this let's imagine the mempool as big vertical list of transactions. Let this list be ordered by the feerate each transaction is paying, the higher the feerate the higher the transaction in the list. Miners will under normal circonstances take the highest virtual MB of transaction in this list/queue. This website is a good visualizer of this ...


5

The only place clear is used on the mempool is after all peers are down. Presumably there are references to it that you can't just leave dangling. See CTxMemPool::Expire in txmempool.cpp for how expiration works. It wouldn't be hard to modify that existing function to just remove everything at a particular point. I assume you're the author of http://people....


4

Bitcoin core does not provide this functionality (as far as I know). The mempool is where transactions are stored until they get put into a block. It would be hard to determine you had the correct mempool if you didn't keep track of the whole block chain, though. For example, someone could broadcast an older transaction, and you would have no way to ...


4

Yes, it is quite possible to successfully double-spend an unconfirmed transaction. Only about 20% of hash power today strictly mines the first transaction seen. Here is a chart showing the convergence to 80% success when the time gap between the two transactions is 15 seconds or more. I'll leave it to other resources to give details on how to use the ...


4

Every node owner can set their own policy for the mempool. The mempool is limited two-fold: With -maxmempool=<n> you can set an explicit limit of MB that it will not exceed. The default is 300MB. Transactions that don't surpass the minRelayTxFee are not added to your mempool. As statoshi.info has the mempool at 145MiB and ~11k transactions, it ...


4

You can increase the mempool size, if you have an interest in seeing transactions that likely won't confirm for a very long time, but you certainly don't have to. The mempool is sorted by feerate, and when the limiter kicks in, it removes the lowest feerate transactions. Since miners sort by feerate, and can include only a limited number of transactions per ...


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