Hot answers tagged

36

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


9

The minRelayTxFee is a full-node setting. It specifies a lower bound for the fee rate the node requires from a transaction. Only transactions with a fee rate above the bound will be added to the node's memory pool and relayed to other nodes. As it is not a flat fee, but a fee rate, it is relative to the transactions size. Each node can set its own policy. ...


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


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

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

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


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.


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

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


5

The upcoming release of the Bitcoin.org client, version 0.7, includes: getrawmempool


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

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


4

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


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

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


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

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

It is not too difficult to check the low-fee transactions in large blocks with block-explorer. Follow the link https://blockchair.com/bitcoin-cash/transactions?q=block_id(479479)&s=id(asc) and press Load more... link several times. There are a lot of one-input-to-one-output dust transactions like https://blockchair.com/bitcoin-cash/transaction/...


4

Zero- and low-fee transactions aren't relayed by default. If you attempt to broadcast one over the Bitcoin peer-to-peer network, most nodes won't pass it along for you (and they might even "ban" you by refusing to relay any of your transactions for a while). However, such transactions are still valid, and it is perfectly legal for a miner to confirm such a ...


4

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


3

There are a few issues with this proposal: No transaction could ever be confirmed in less than ten minutes. We already have plenty people up in arms that choose to rely on zero confirmation transactions. Waiting at least ten minutes would increase confirmation times. Every node has their own mempool and they don't necessarily match. Every node receives ...


3

The newest version of bitcoin core 0.12 introduced a feature called replace by fee. This can be used to issue a transaction with a higher fee spending coins that have not yet been picked up in a block. This can be used to send funds in a stuck transaction to a new address and the hope is that by including a fee this will get picked up by the miners faster ...


3

Without verifying the transactions themselves, there's no guarantee that the transactions you get from either method are valid. Nodes can lie about what transactions they have in their mempool, for example, and send you gibberish. On the flip side, nodes also don't have any obligation to send you transactions that they have. There are non-standard ...


3

If you're looking for unconfirmed transactions without loading the blockchain, you're going to have to trust someone since you can't verify the transactions yourself. Probably the easiest way to get these transactions is by using a third-party API service. Blockchain.info provides a very good one here: https://blockchain.info/unconfirmed-transactions?...


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