Hot answers tagged

40

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 ...


12

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, ...


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

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 ...


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

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 ...


6

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


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

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

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.


6

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. ...


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

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

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

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 ...


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

So far, no released versions of Bitcoin Core exist that store the mempool on disk. That's why it's called the mempool; it's a pool of unconfirmed transactions kept in memory. Version 0.14 is expected to introduce automatic dumping of the mempool to disk at shutdown.


4

You should use full nodes on both sending and receiving end Sending Tx Use the -connect option to broadcast your tx through selected neighbours. Use https://bitnodes.21.co/ to find neighbours. Use the wallet commands in bitcoind and send a transaction to address in your own wallet Receiving Tx Use -walletnotify option in bitcoind to get notifcation of ...


4

You can't, and you don't have to. Since Bitcoin Core 0.14.0, the mempool is saved to disk at shutdown, and read again in the background at startup. This helps in quickly establishing a realistic mempool to help with fee estimation and compact block relay. However, time likely has passed since the mempool was saved and when the import happens. New blocks ...


4

bitcoind has a debugging option named mempoolrej. You can enable this by adding debug=mempoolrej to your bitcoin.conf file. This debugging options tells bitcoind to print out information about the transactions that it rejects from the mempool, including why. You can thus enable this option and tail and grep the debug.log file looking for the string was ...


4

At the time of the question, Bitcoin Cash mempool had 917 transactions, and the Bitcoin mempool only had 8.1k. yes from ABC getinfo says "version": 140400 You're running an outdated version of Bitcoin ABC. 140400 translates to Bitcoin ABC 0.14.4, but the current release is Bitcoin ABC 0.14.6. Mandatory two-way replay protection was introduced either with ...


4

No, there is no way to do that. However you could make your mempool smaller and that would have a similar effect. The mempool has its own minmempoolfee. The in-practice minrelayfee is the maximum of the -minrelaytxfee and the minmempoolfee. The minmempoolfee will change when the mempool becomes full, and decreases when it has space. So if you set your -...


4

You can use the ZMQ interface to receive a ZMQ notification when a new transaction is received. You can have it give you the txid, the raw transaction, or both.


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