-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mempool out of sync #400
Comments
What version of bchd are you using? |
0.16.5 |
Unfortunately this keeps happening. BCHD happily reports that transaction is accepted, doesn't broadcast it further, responds as if transaction exists... Happened today with 858f20eeffb834ee6ba88a09d6b4fcb0b0d379d5efcd0a0bddca65e6c6153513 (nowhere to be found), also quite a few daily reports from people who send money to someone and then later (after a restart) the money disappears. Happens daily. How can we find out the root cause? These transactions were affected (we have the hexes, so that means that BCHD accepted them): 858f20eeffb834ee6ba88a09d6b4fcb0b0d379d5efcd0a0bddca65e6c6153513 Unfortunately, it seems that BCHD has already restarted, so I can't find the information about them anymore. We can we do? (My mailbox is now full of people (these transactions were to ~400 people) panicking that their money was stolen - there's a notification that they got the money, but the money is now gone... after BCHD restart, when mempool was reset) |
The fee for tx was calculated by BITBOX Here's a similar transaction: https://blockchair.com/bitcoin-cash/transaction/ca7b6388346eed0e29b4e9c3907c813bb09b911c387426cbc1919b7da1d445c6 Size: 3,625 Fee: 0.00003662 BCH. So the failed transactions probably had a similar fee. So, it doesn't seem to be a fee issue. It doesn't only happen with big transactions - sometimes transactions with just a few inputs-outputs fail. (By "fail" I mean that they are accepted by Is there a way to enable verbose logging in BCHD maybe? |
Even more failed/non-relayed transactions today: Hundreds of people affected. Email blown away. What can we do? |
Finally, caught one in the act:
When we first sent this transactions (via GRPC SubmitTransaction), we've got back this:
So, the transaction was accepted. If we go to https://explorer.bitcoin.com/bch/search/2f2f022d3579356a20ec985e4bdb9d30f8982b95cf2ca4e82771b71d454f6aca We can see that the transaction did not reach the network: If I try to SubmitTransaction again (though this time via Swagger over GRPC), I get:
So, this transaction is in the mempool, but not broadcasted. Finally, I went to https://rest.bitcoin.com/#/rawtransactions/sendRawTransactionSingle I get:
Ok, let's decode and see the inputs
Here's the
If I submit it to BCHD I get:
If I submit it via rest.bitcoin - I get:
Now, I'm kind of stuck. I found this: https://updates.cryptoapis.io/?lng=en&page=5
But this doesn't really help. A double spend? How? The parent of this transaction is:
and indeed, we can see this transacation on BCH network and we can see that The order of sending was:
This means that "get utxos" (GRPC call to the same node) got us How is this possible? |
To be clear: |
Hex of
|
Ok, talking to @blockparty-sh it seems that in this particular situation a restart was a root cause:
I think this is actually a problem of its own (getting UTXOs while node is syncing :( ), but it seems that it is unrelated to the original problem. |
Thanks for all the info, we will definitely be looking into this! |
Next time this happens, dump out the output from https://explore.cash, this uses the same node and can display the tx even if other nodes on the network don't see it! |
Yes, there is a way to enable much more verbose logging. I am going to enable it tonight on my server. Just start bchd with My guess is that upstream peers don't like the transaction for some reason. Have you tried broadcasting any of these transactions through bitcoin cash node or bitcoin abc? Want to help you figure this out! Also how quickly are you sending these transactions? Are they one right after another? Is there a delay between sends? |
The problem is that these "bubbles" appear randomly. It's very hard to predict when and why. My hunch is that they might be due to low fees, especially if users ignore the maximum we recommend and set the amount manually (thereby creating a low fee transaction). But I thought #382 was supposed to solve that, but we've seen these bubbles after that too. The problem with catching "sources" (hex representation) of user transactions is of course with the fact that they broadcast it themselves (via js) directly to the node, so we don't really have any way (currently) to catch and log that. I'll see, maybe I can add something. |
It would be great if we could get more sample transactions that are stuck. That would ease our debugging immensely! |
I also have CRAZY logging enabled on my node now, so debugging these should be easier and I am logging every INV interaction between my node and its peers! |
Thank you, Josh! We'll have to wait for another report from users. I got some reports today, I replied to get some additional info, but still waiting for responses. I'll inform you when I have anything new. Thanks again! |
Happened in last 24 hours. explore.cash can't find either. Thanks! I figured out that we have paid upvote TXIDs, so I can check them against rest.bitcoin.com, so I can easily find missing ones, at least here. |
Some fresh transaction that happened on BCHD, but haven't been propagated:
|
I don't see any of these transactions in my logs even in debug mode.... very strange. Any chance we can start getting the full tx payload so we can analyze those? Also @cpacia if you have some time I would love help debugging this for our biggest user =) |
I was hoping we could do without the full TX, since these actually are send browser-to-GRPC, so I have to create a completely new logging channel for this, but since we don't have any choice... |
Me, too. I turned up the logging level on my node to debug and I assumed this would be trivial to track. Unfortunately I don't see ANY logs for these txs... |
Still trying to monitor, but haven't got any "bubbly" transactions in the last 24h |
GRPC (bchd.fountainhead.cash) replied with TXID, accepting it, but TX never appeared anywhere after this.
http://136.243.250.139:8111/ Not found (strange, this is the node that replied with TXID) |
Ok, thanks for the detailed report. It is VERY strange that the node that replied with the TXID doesn't see it in its own mempool! That might give us a hint as to how this is broken. I want to see if there are any code paths that will return the TXID even if we decided not to accept it! |
@cpacia any ideas how that can happen? Are there cases we would return the txid but not add it to the mempool? |
One more idea is that it was removed from the mempool later for some reason. But the only reason I can think if is double-spend, which is hard for me to imagine how it happened, since we get UTXOs before each send. |
A few more (happened ~10 min ago):
|
We don't have any code to generate the TXID, so it's 100% that we got it from GRPC |
More:
|
Got dozens more today. Latest example:
|
Tons more. People constantly complain. We need to figure this out.
Note: $0 is when getUtxo fails for some reason
|
Another example:
http://136.243.250.139:8111/mainnet/tx/2a4bfab6d9de41b6f834638447171e0392860cdba4d75a967d3ba30445fcafed (in mempool!) Went to https://rest.bitcoin.com/#/rawtransactions/sendRawTransactionBulk
So TX is in the mempool, but not propagated Parent bfa45cb62cce1797fc4eed0e25d8977d3a11c69f6de5fa34e5e1791f08a5d9ba:
The problem here is that https://explorer.bitcoin.com/bch/tx/5e8eec97569f8308a340b5532b8a8252fc317ad882b6d580bc4b7cf493e0357b :101 is seemingly already spent by 006afe07a5ba6a2a89f5625c1d681fd23d4fcb3e6cdb0af0e2ab6e6181bda5f7 5e8eec97569f8308a340b5532b8a8252fc317ad882b6d580bc4b7cf493e0357b was sent at 2020-08-31T00:17:40.084770650Z 006afe07a5ba6a2a89f5625c1d681fd23d4fcb3e6cdb0af0e2ab6e6181bda5f7 was sent at bfa45cb62cce1797fc4eed0e25d8977d3a11c69f6de5fa34e5e1791f08a5d9ba was at and bfa45 has a lot of successful spending transactions... :( I would need to restart the node, since there's now about 50 transactions that spend descendants of this UTXO, which doesn't exist!
|
You can close the issue if you will, read.cash no longer uses BCHD. |
Not going to close it. Going to still try and figure out why you had these issues but other broadcast heavy apps have not... Just curious what are you using to track utxos now? |
Issue occurred with this tx:
1e6442a0d3548bb4f917721184ac1cb163ddf324e2c09f55c46ff0ba521cb89f
This may be related to #382 (comment) and #375
The text was updated successfully, but these errors were encountered: