Too long mempool chain ошибка

I am using bitcoind json rpc api to send bitcoin to multiple bitcoin addresses. I am using sendrawtransaction. When i have 24 unconfirmed payments sent from my account, i can’t send anymore because i get this error :

64: too-long-mempool-chain

I have increased the maxmempool to 1500 but it still doesn’t fix it.

root@B2:~# bitcoin-cli getmempoolinfo

    {
      "size": 3946,
      "bytes": 1789073,
      "usage": 6043088,
      "maxmempool": 1500000000,
      "mempoolminfee": 0.00000000
    }

I use Ubuntu on a 32GB RAM , 4TB HDD server.

Any ideas on how to fix it ? I want to be able to create for example 300 unconfirmed transactions and not to receive that error.

Разобрался в чем дело — может кому поможет в будущем.

Обменник, который отправил мне биткоины на кошелек bitcoinru.org имел длинную цепочку неподтвержденных транзакций — это и не дало отправить далее мои биткоины, пока транзакция не получила подтверждение и не была включена в блокчейн. Нужно было просто подождать.

Плюс тот обменник, с хорошими отзывами кстати, еще низкую комиссию установил за перевод, а сеть биткоин была на тот момент сильно загружена и все это дело сильно затянулось.

Comments

…error messages

76dc547 gui: create tx, launch error dialog if backend throws runtime_error (furszy)
f4d7947 wallet: coin selection, add duplicated inputs checks (furszy)
0aa065b wallet: return accurate error messages from Coin Selection (furszy)
7e8340a wallet: make SelectCoins flow return util::Result (furszy)
e5e147f wallet: refactor eight consecutive 'AttemptSelection' calls into a loop (furszy)

Pull request description:

  Work decoupled from #25806, which cleanup and improves the Coin Selection flow further.

  Adding the capability to propagate specific error messages from the Coin Selection process to the user.
  Instead of always returning the general "Insufficient funds" message which is not always accurate to what happened internally.
  Letting us instruct the user how to proceed under certain circumstances.

  The following error messages were added:

  1) If the selection result exceeds the maximum transaction weight,
     we now will return:
  -> "The inputs size exceeds the maximum weight. Please try sending
  a smaller amount or manually consolidating your wallet's UTXOs".

  2) If the user pre-selected inputs and disallowed the automatic coin
     selection process (no other inputs are allowed), we now will
     return:
  -> "The preselected coins total amount does not cover the transaction
  target. Please allow other inputs to be automatically selected or include
  more coins manually".

  3) The double-counted preset inputs during Coin Selection error will now
  throw an "internal bug detected" message instead of crashing the node.

  The essence of this work comes from several comments:
  1. bitcoin/bitcoin#26560 (comment)
  2. bitcoin/bitcoin#25729 (comment)
  3. bitcoin/bitcoin#25269 (review)
  4. bitcoin/bitcoin#23144 (which is connected to #24845)

ACKs for top commit:
  ishaanam:
    crACK 76dc547
  achow101:
    ACK 76dc547
  aureleoules:
    ACK 76dc547
  theStack:
    ACK 76dc547 🌇

Tree-SHA512: 9de30792d7a5849cae77747aa978e70390b66ee9d082779a56088a024f82e725b0af050e6603aece0ac8229f6d73bc471ba97b4ab69dc7eddf419f5f56ae89a5

…ssages

76dc547 gui: create tx, launch error dialog if backend throws runtime_error (furszy)
f4d7947 wallet: coin selection, add duplicated inputs checks (furszy)
0aa065b wallet: return accurate error messages from Coin Selection (furszy)
7e8340a wallet: make SelectCoins flow return util::Result (furszy)
e5e147f wallet: refactor eight consecutive 'AttemptSelection' calls into a loop (furszy)

Pull request description:

  Work decoupled from bitcoin#25806, which cleanup and improves the Coin Selection flow further.

  Adding the capability to propagate specific error messages from the Coin Selection process to the user.
  Instead of always returning the general "Insufficient funds" message which is not always accurate to what happened internally.
  Letting us instruct the user how to proceed under certain circumstances.

  The following error messages were added:

  1) If the selection result exceeds the maximum transaction weight,
     we now will return:
  -> "The inputs size exceeds the maximum weight. Please try sending
  a smaller amount or manually consolidating your wallet's UTXOs".

  2) If the user pre-selected inputs and disallowed the automatic coin
     selection process (no other inputs are allowed), we now will
     return:
  -> "The preselected coins total amount does not cover the transaction
  target. Please allow other inputs to be automatically selected or include
  more coins manually".

  3) The double-counted preset inputs during Coin Selection error will now
  throw an "internal bug detected" message instead of crashing the node.

  The essence of this work comes from several comments:
  1. bitcoin#26560 (comment)
  2. bitcoin#25729 (comment)
  3. bitcoin#25269 (review)
  4. bitcoin#23144 (which is connected to bitcoin#24845)

ACKs for top commit:
  ishaanam:
    crACK 76dc547
  achow101:
    ACK 76dc547
  aureleoules:
    ACK 76dc547
  theStack:
    ACK 76dc547 🌇

Tree-SHA512: 9de30792d7a5849cae77747aa978e70390b66ee9d082779a56088a024f82e725b0af050e6603aece0ac8229f6d73bc471ba97b4ab69dc7eddf419f5f56ae89a5

…hain"

f3221d3 test: add wallet too-long-mempool-chain error coverage (furszy)
acf0119 wallet: return error msg for too-long-mempool-chain failure (furszy)

Pull request description:

  Fixes bitcoin#23144.

  We currently return a general "Insufficient funds" from Coin
  Selection when we actually skipped unconfirmed UTXOs that
  surpassed the mempool ancestors limit.

  This PR make the error clearer by returning:
  "Unconfirmed UTXOs are available, but spending them creates
  a chain of transactions that will be rejected by the mempool"

  Also, added an early return from Coin Selection if the sum of
  the discarded coins decreases the available balance below the
  target amount.

ACKs for top commit:
  achow101:
    ACK f3221d3
  S3RK:
    Code review ACK f3221d3
  Xekyo:
    ACK f3221d3

Tree-SHA512: 13e5824b75ac302280ff894560a4ebf32a74f32fe49ef8281f2bc99c0104b92cef33d3b143c6e131f3a07eafe64533af7fc60abff585142c134b9d6e531a6a66

I’m going to be completely honest, I don’t totally know what I’m doing I have tried sending money from my bitcoin.com app to a different wallet many times (in bitcoin), but every time I try to send it I get the error message «too long mempool chain». I guess I’m asking someone to please explain to me in layman’s terms what that means, why I’m all of sudden getting this error message, and how can I resolve this issue?

I feel so confused right now, I truly don’t know what to do and since apparently in the US you can’t withdraw directly from bitcoin app, and because it’s not letting me send to any address, I feel like I’m screwed.

See: HowTo_run_PoP_Miner, PoP_Reward_Summary

TLDR

See: PoP_Reward_Summary for general guidelines on how PoP rewards work. This article is more technical about getting rewards with the PoP Miner.

Here’s a good process for anyone who wants to PoP Mine:

1. Get a syncing version of NodeCore first (obviously a big deal, hence we’re very focused on the low-memory version)
2. Run the PoP miner with a high-enough fee, checking the BTC block explorer. You want «Time until confirm» to be < 30 minutes.
   1. Run a single instance
   2. First try the «mine» command before automating with a cron job
   3. Try a low frequency like mining every 5 minutes (rapid mining may cause a deadlock on the local miner)
3. Let PoP run for 5 hours (it takes time for 500 tVBK blocks)
4. Check viewrecentrewards

If after that, still no reward —> please send log files

Overview

This is a high-level overview of how PoP rewards work. This page answers «if you do X, you have a good chance of getting greater-than-zero reward.» It does not try to predict exactly what the reward would be, or the exact BTC needed for that reward (as this is due to constantly changing market forces and issues with the BTC difficulty adjustment algorithm that appear roughly once a month). The exact mechanics are not linear, and there is some luck involved (particularly during abnormal conditions on the BTC network, which happen occasionally).

First, read HowTo_run_PoP_Miner to see the basic operations of the PoP Miner.

PoP Mining works by:

1. Encapsulating an «endorsement» of a VeriBlock block in a Bitcoin transaction, submitting it to the BTC network, and waiting for it to be included in a BTC block
2. Submitting a «Proof-of-Proof» (PoP) transaction to NodeCore that proves your Bitcoin transaction was included in the BTC blockchain
3. Receiving a reward for your PoP transaction, which is paid out 500 blocks after the VeriBlock block you endorsed

There are several variables involved in a successful mine and reward payout:

• The most important factor is the timeliness of your Bitcoin transaction’s inclusion in the Bitcoin blockchain. A Bitcoin transaction that is included in the first possible block is always rewarded the best. The reward tails off sharply for inclusion in subsequent blocks and eventually has no value at all.
• The control mechanism the miner has over this timeliness factor is the Bitcoin transaction fee. The higher the fee (per kb) paid, the more likely the transaction will be included sooner.
• The PoP reward is for the block that was endorsed, which is generally the most recent block on the VeriBlock network at the time when you began a PoP mining cycle (not the block the proof-of-proof transaction appears in). The total PoP reward is split between all the endorsements. Therefore, the more endorsements of a given block, the lower the reward per endorsement will be.

Make sure to set your ncpop.properties file (these are example numbers, actual numbers will vary), and restart the PoP miner after saving your changes:

#A safety stop-gap. This is the absolute maximum total fee you are willing to pay for a Bitcoin transaction
#An average PoP transaction is ~285 bytes or 0.285 kb, multiply 'bitcoin.fee.perkb' x 0.285. Your bitcoin.fee.max value must be at least this much.
#Measured in satoshis
bitcoin.fee.max=8000

#Something high enough to win (increase this if your BTC transactions are appearing "unconfirmed" on a block explorer after a new BTC block occurs)
#Measured in satoshis
bitcoin.fee.perkb=20000

What should the BTC Tx fee be?

There is not an exact answer. Some game theory and risk is involved, and as other Bitcoin transactions increase their per-kb fee, the per-kb fee you will need to pay to compete for inclusion in the earliest block will increase accordingly. Also note that a high BTC fee does not guarantee inclusion in the next BTC block; random factors like a BTC miner’s refresh time, network latency, etc. can also play a small role.

There is a spectrum of fees:

Check what the recent BTC fees are on a blockchain explorer. Take for example the following PoP transaction on tBTC (testnet BTC): https://www.blocktrail.com/tBTC/tx/8dbba547dd15907c5eb4757bfa061c7a62b900a020557fde60b19b6e2967cf7d. The Fee / KB is 0.00498592. The miner who sent this PoP transaction had the setting ‘bitcoin.fee.perkb= 498592’ in their ncpop.properties file. Consider increasing or decreasing that value given your risk threshold and your observations of other PoP transactions on the network and their corresponding per-kb fees.

https://www.blocktrail.com/tBTC

Common reward questions

How can I see my reward?

In the PoP Miner, run the command viewrecentrewards

Also run listoperations to view the current running operations and their status.

I mined PoP, but saw no reward

PoP is rewarded 500 blocks after the endorsed block. At an average of 30 seconds per block, this is about 4.5 hours. So first understand that rewards won’t come for ~4.5 hours after your mine operation.

1. Make sure that your NodeCore instance is in sync with the latest block —> you should be able to run NC_CLI getinfo on your NodeCore instance.
2. Ensure that a BTC was submitted by the miner (if no transaction was submitted, there are likely other factors to address)
3. Make sure that your Bitcoin transaction has actually been confirmed in a block
4. Try to determine the timeliness of your BTC’s transaction’s inclusion. The BLOCKTRAIL BTC explorer, for example, includes a field Time until confirmed on the transaction detail that is a helpful gauge of timeliness.
5. If you are seeing PoP mining failures, check your PoP miner logs for suspect lines, see: #Log Troubleshooting
6. If still not seeing a reward, jump on our telegram channel or submit a github issue.

My transaction is on BTC blockchain, but I got no reward

Even if the PoP Transaction is on BTC, it may be in the «danger zone» where it took too long to be rewarded.

If the «Time until confirmed» is > 20 minutes, there is risk of not getting rewarded.

The way to increase chance of reward is to increase BTC transaction fee such that it is in an earlier block.

The status shows «Done», but I did not see a reward yet

«Done» is a good sign, it means it made it through the mining life cycle.

Similar to PoW mining, «Done» means there is nothing left for the Miner to do.

Check the PoP command: viewrecentrewards (HowTo_run_PoP_Miner#viewrecentrewards) to see reward status at this point.

A reward could be coming, or it is possible due to other reasons listed, that the mining operation finished without reward.

I still do not see a reward

If everything else is covered, then this should be a rare situation.

Do not run multiple instances of the same executable

Do not mine too frequently

If the same log shows two mining operations kicked off at the exact same time — something is probably wrong — try running a single instance with one ‘mine’ command.

2018-08-15 10:00:00 INFO [miner] ... [aaaa7e51] Mining operation is now: RUNNING
2018-08-15 10:00:00 INFO [miner] ... [bbbb85c1] Mining operation is now: RUNNING

Is my PoP Transaction on the BTC network?

If you PoP mine, you should relatively quickly (within minutes) see an output like so:

INFO: Received pending tx '9268a8e9890993a81ac035c6ea8f69d0ad059b09078a73a7b4bb86514a5858aa', pending balance: '2.906723 BTC'
...
MINER: [2aaef35f] Submitted Bitcoin transaction: 9268a8e9890993a81ac035c6ea8f69d0ad059b09078a73a7b4bb86514a5858aa
MINER: [2aaef35f] Mining operation current action: Waiting for transaction to be included in Bitcoin block

And you should be able to see that on any BTC block explorer (this example uses BTC testnet), such as:

https://www.blocktrail.com/tBTC/tx/9268a8e9890993a81ac035c6ea8f69d0ad059b09078a73a7b4bb86514a5858aa

Who is winning PoP?

This is publicly available from the Explorer.

Looking at the «PoP payouts for this block protecting other blocks» section, one can see the addresses and block for which rewards were paid out:

Avoid these common problems

• If the BTC is too low, then the BTC transaction will not be accepted, and there will be no PoP reward
• If the PoP Miner is not connected to a synced version of NodeCore, then the PoP transaction is not guaranteed to go through
• Submitting a chain of 20+ unconfirmed transactions. As each new Bitcoin transaction consumes an unspent transaction output, you can only submit so many in a row without confirmation before peers reject the transactions outright. This manifests generally in two scenarios:
  • Submit too many transactions inside a Bitcoin block interval. If a normal Bitcoin block time is 10 minutes, and you submit more than 20+ transactions in that window, you’ll be unable to continue submitting new transactions until some of your transactions eventually confirm.
  • Submit transactions with too low a fee that they just are not getting confirmed and a backlog accumulates. Again, if you reach 20+ transactions without confirming, you’ll be unable to submit further.

Troubleshooting

Standard Troubleshooting Process

If you still cannot see PoP rewards, please follow these steps:

1. Run single instance of PoP Miner
2. Run single mine command
3. Give it a high BTC fee (high enough to ensure it's on BTC block explorer with confirm time < 10 minutes)
4. Is there a PoP transaction ID?
5. Does it go through all 9 phases listed here (note the whole process may take 5 hours): https://wiki.veriblock.org/index.php?title=HowTo_run_PoP_Miner#PoP_Mining_Lifecycle. (If not, what was the last phase)?
6. Can you send the specific BTC transaction ID and PoP Id, along with the PoP Log file?

Log Troubleshooting

The PoP miner produces two log files.
bitcoinj.nodecore-pop.log logs the behavior of BitcoinJ—the underlying SPV-level wallet library that the PoP miner uses to communicate with the Bitcoin network.
veriblock.nodecore-pop.log logs the behavior of the PoP miner itself—activities like running a new mining command, statuses returned from BitcoinJ about the state of a transaction, info about connectivity to NodeCore, etc.

If you are not receiving PoP rewards and have already set your fees at market-competitive rates as explained above, look for common errors.

bitcoinj.nodecore-pop.log

Received Reject: tx (txid) for reason ‘too-long-mempool-chain’ (64)

Explanation: You have performed too many PoP transactions (generally >20) in a row without any getting confirmed by the BTC network (due to low fee and/or too-fast PoP mining rate), and the BTC network is temporarily rejecting any additional PoP transactions from you until some of your previous PoP transactions on BTC are confirmed.

Troubleshooting steps: Try increasing your PoP miner’s configured fee (see Overview for an example of how to do so) and/or decreasing the frequency at which you PoP mine (generally not recommended more frequently than once every 3 minutes per PoP miner instance)

Waiting for 10 peers required for broadcast, we have 7 …

Explanation: The BitcoinJ library is having difficulty connecting to enough available peers to confirm that your PoP transactions are properly propagating across the network

Troubleshooting steps: Try lowering the aggression of any firewall between the PoP miner and the internet, check the BitcoinJ logs for any indication of repeated connection failures to peers, and try restarting the PoP miner.

Explanation: BitcoinJ is having difficulty in getting all of the requisite context block headers to allow the VeriBlock blockchain to validate the PoP transaction in question. This is usually the result of the difficulty bomb in BTC being exploited (which resets the mining difficulty to 1 and results in several orders of magnitude more BTC blocks per unit time than expected).

Troubleshooting steps: Check a popular BTC block explorer like [1] and look at the block times. If blocks are coming in at a rate faster than roughly once every minute, then the extreme block time is likely the culprit (and you may need to wait a day for it to adjust if several subsequent PoP mining operations also fail). If blocks are coming in at a normal pace, then try closing the PoP miner, deleting the
bitcoin-pop-testnet.spvchain file, restarting the PoP miner, and attempting to mine again.

Appendix

Useful sites for PoP Rewards

https://bitcoinfees.earn.com/ —> «Predicting Bitcoin Fees for Transactions»