@Cain
more from that month
Got this error for the first time: "There was an error sending your funds Error: "Error: the transaction was rejected by network rules. too-long-mempool-chain, too many descendants for tx" Here's the transaction that's causing the problem. https://explorer.bitcoin.com/bch/tx/e0d9fab5568e79324df5f2ad2d6a4d3ec569e93c59377a48e90ec6feab6ea385
7 comments
I dont know why. But me also having same problem for 1st time. We wish read cash solve this issue.
It just means you have done 50 transactions without a new block. We once had a bounty that actually wants to remove the chain limit, but ABC, being themselves, decided to settle on 50 when Bitcoin Unlimited had it as 300 already.
Removing the chain-limit would be good in many ways. ABC claims it would lead to significant increased maintenance costs for node developers and no one was offering to fund the increased maintenance. I believe them. BU does take chances and it seems they have been willing to move away from the "core" software that is used in the regular maintenance of BCH. I suspect BCHN (part of the BU team?) may have committed to removing the limit and Mr Ver may be supporting them, in part for that reason. I feel BCHN will promise this sort of stuff to take over BCH. Will they do the maintenance long term? I hope so.
BCHN's most have once-ABC contributors, one of the original trio of makers are in BCHN, the other being micropresident and Amaury. Although I personally think that having an unlimited chain does need maintenance, I think it's merely a mempool maintenance, since it's a chain of transactions. Also, by the way, BCHN doesn't have it.
I haven't tried yet to transact today due to no power and slow internet connection. But hopefully Read.cash settle the problem as soon as possible.
I have also the same problem and I dont know why it happened. I will check the link to know about more of it.
I think this happens when over 50 related tx's are trying to get into a block. Usually SLP tx's, I believe. BCHN will probably fix this. ABC claims it would lead to significant increased maintenance costs for node developers and no one was offering to fund the increased maintenance. I would guess that is a reason Mr Ver is pro BCHN (I think he feels strongly about this issue). They promise anything without a need (or plan?) to follow through on the maintenance.