Stuck transaction with descendants - help!

[erikmollink]

I am hosting a BTCPay server for my company, using a full node.

Yesterday I made a stupid mistake. I wanted to get rid of a received dust transaction of 547 sat and tried to send it to a another address with a very low fee of only 336 sat.

Now, there have been two sending transactions after this event (with normal mining fees) that are descendants of this first low-fee transaction.
All three transactions are after 20 hours still unconfirmed in the local mempool and have not been broadcasted. None of the three TxIds can be found in a block explorer.

Is it true that these two descendant transactions will only be broadcasted and picked up by the miners when the ancestor is confirmed?

I tried to bump the fee for the first low-fee transaction by using bumpfee "tx-id", but that does not work as the transaction has descendants.

I do not have the luxury to just wait until they are removed from the mempool because the other two transactions should already have gone through yesterday.

How to fix this? Is it still possible that I ask a miner or - as what was suggested in the "Stuck transaction topic" - to ask someone who has access to F2Pool's transaction selector?
I am willing to pay for the fees of course.

Below is the output of the mempool entries of the three involved transactions

Code:

root@btcpay:~/btcpayserver-docker# ./bitcoin-cli.sh getmempoolentry "de188ec7d50032773a43af8703b2f17d6bde2ae701b64934bce3e8850cd6a904"
{
  "fees": {
    "base": 0.00000336,
    "modified": 0.00000336,
    "ancestor": 0.00000336,
    "descendant": 0.00243679
  },
  "vsize": 168,
  "weight": 669,
  "fee": 0.00000336,
  "modifiedfee": 0.00000336,
  "time": 1614980377,
  "height": 673314,
  "descendantcount": 3,
  "descendantsize": 2471,
  "descendantfees": 243679,
  "ancestorcount": 1,
  "ancestorsize": 168,
  "ancestorfees": 336,
  "wtxid": "e447f30957e1c02dab97d17b99722e9d96c46efdb7f30ff61301f06cbd955377",
  "depends": [
  ],
  "spentby": [
    "e7d87aff1e35fda17d730e2a9c0f881de3d53969ea267d48c5845b11c0b54220"
  ],
  "bip125-replaceable": false
}


root@btcpay:~/btcpayserver-docker# ./bitcoin-cli.sh getmempoolentry "e7d87aff1e35fda17d730e2a9c0f881de3d53969ea267d48c5845b11c0b54220"
{
  "fees": {
    "base": 0.00209658,
    "modified": 0.00209658,
    "ancestor": 0.00209994,
    "descendant": 0.00243343
  },
  "vsize": 1985,
  "weight": 7940,
  "fee": 0.00209658,
  "modifiedfee": 0.00209658,
  "time": 1614980377,
  "height": 673314,
  "descendantcount": 2,
  "descendantsize": 2303,
  "descendantfees": 243343,
  "ancestorcount": 2,
  "ancestorsize": 2153,
  "ancestorfees": 209994,
  "wtxid": "591b6276720347fe1ccbc113c782102326c6bc054b278482d8899cfe446ecc7d",
  "depends": [
    "de188ec7d50032773a43af8703b2f17d6bde2ae701b64934bce3e8850cd6a904"
  ],
  "spentby": [
    "4504fe03e55a51fba376be24e7467240370aaa0a7d2ce92befecd05e3490e916"
  ],
  "bip125-replaceable": false
}


root@btcpay:~/btcpayserver-docker# ./bitcoin-cli.sh getmempoolentry "4504fe03e55a51fba376be24e7467240370aaa0a7d2ce92befecd05e3490e916"
{
  "fees": {
    "base": 0.00033685,
    "modified": 0.00033685,
    "ancestor": 0.00243679,
    "descendant": 0.00033685
  },
  "vsize": 318,
  "weight": 1269,
  "fee": 0.00033685,
  "modifiedfee": 0.00033685,
  "time": 1614980377,
  "height": 673314,
  "descendantcount": 1,
  "descendantsize": 318,
  "descendantfees": 33685,
  "ancestorcount": 3,
  "ancestorsize": 2471,
  "ancestorfees": 243679,
  "wtxid": "417954e54d2ab38461083b099f2374ea2aa57040fcca7312ca5f6e83beacb5c1",
  "depends": [
    "e7d87aff1e35fda17d730e2a9c0f881de3d53969ea267d48c5845b11c0b54220"
  ],
  "spentby": [
  ],
  "bip125-replaceable": true
}

 

[ranochigo]

Is it true that these two descendant transactions will only be broadcasted and picked up by the miners when the ancestor is confirmed?

They will only be confirmed when the parent transaction is confirmed, either in the same block or in a preceding block. As the parent transaction isn't relayed, your subsequent orphan transactions can't be confirmed as well.

I tried to bump the fee for the first low-fee transaction by using bumpfee "tx-id", but that does not work as the transaction has descendants.

I do not have the luxury to just wait until they are removed from the mempool because the other two transactions should already have gone through yesterday.

None of your transactions are replaceable so bumpfee will not work regardless. It is not in the mempool in the first place, or at least it is very poorly propagated. You can try scripting a raw transaction instead with the inputs used in that transaction. It'll go through just fine.

How to fix this? Is it still possible that I ask a miner or - as what was suggested in the "Stuck transaction topic" - to ask someone who has access to F2Pool's transaction selector?
I am willing to pay for the fees of course.

Below are is the output of the mempool entries of the three involved transactions

Possible. I'm not aware of anyone who has access to that though. Be wary of anyone claiming they do and attempting to collect payment upfront.

You might want to use https://coinb.in/ to script your raw transaction. If you were to include any of the inputs from the first transaction (de188ec7...) in your new transaction, then that transaction and its descendants will also be invalidated when it gets confirmed and you should be able to make the other transactions as well.

[erikmollink]

You might want to use https://coinb.in/ to script your raw transaction. If you were to include any of the inputs from the first transaction (de188ec7...) in your new transaction, then that transaction and its descendants will also be invalidated when it gets confirmed and you should be able to make the other transactions as well.

That sounds promising. I have never scripted a raw transaction before and am a bit puzzled what exactly to put into the the fields at https://coinb.in/.
Would you (or anyone) be able to assist me with this as I do not want to make any errors. Feeling bad enough already that I created this mess in the first place.

[LoyceV]

Yesterday I made a stupid mistake. I wanted to get rid of a received dust transaction of 547 sat and tried to send it to a another address with a very low fee of only 336 sat.

This isn't helping you now, but for next time:

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

The transaction sends the 547 sats to a miner. The benefit of the OP_RETURN is that it doesn't create a UTXO that will never be spent. It works with hardware wallets, too.

[o_e_l_e_o]

You might want to use https://coinb.in/ to script your raw transaction.

Given that OP says that none of the transaction have been broadcast, and I can certainly not find any of them in a handful of mempools I have just checked, would it not be easier for him to just use abandontransaction on the first one, which will abandon all three transactions and allow the inputs to respent directly from Core. He can then just create and broadcast new transactions the usual way without having to manually script anything.

OP, see here for more information: https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/abandontransaction/

[ranochigo]

That sounds promising. I have never scripted a raw transaction before and am a bit puzzled what exactly to put into the the fields at https://coinb.in/.
Would you (or anyone) be able to assist me with this as I do not want to make any errors. Feeling bad enough already that I created this mess in the first place.

Before that, you can try abandontransaction to see if it'll remove the transactions as well as the descendant transactions to see if it'll remove them and mark them as spendable.

Code:

bitcoin-cli abandontransaction de188ec7d50032773a43af8703b2f17d6bde2ae701b64934bce3e8850cd6a904 

If you're running anything older than 0.21.0, can you try restarting your full node and running it with -zapwallettxes as a flag at startup?


If neither of them works, then you'll have to try to create a raw transaction manually and it can be slightly tedious. I was trying it out for myself and their own server doesn't seem to be working so you'll have to select a different source at  https://coinb.in/#settings. Select Blockchair (Bitcoin Mainnet) under Unspent Outputs. At https://coinb.in/#newTransaction, you can enter the address that contains the inputs from (de188ec7...). After which, you should see that the inputs tab is populated with the unspent inputs associated with that address like so:


After which, you have to paste the desired address in the Address column as well as the output amount. Take note that any Bitcoins that is not spent will be used as a transaction fees so you have to spend all of it less the transaction fee or just add another output to use as a change address. If you're unsure as to how much transaction fees to include, here's a nifty website that gives you the fees to include (https://bitcoindata.science/plot-your-transaction-in-mempool.html).

After which, you can click on submit and there should be a box with a long string. Copy that down.

Code:

bitcoin-cli decoderawtransaction "COPIED STRING"

Check if the transaction details are correct. You should be able to see the virtual size as well. Divide your fees in satoshi by that to get your fee rate which should be what you have entered in the site above. If it is, you can sign it/

Code:

bitcoin-cli signrawtransactionwithwallet "COPIED STRING"

You should be given a signed raw transaction. Decode it at https://coinb.in/#verify to check it again and you can broadcast it using https://coinb.in/#Broadcast.

Given that OP says that none of the transaction have been broadcast, and I can certainly not find any of them in a handful of mempools I have just checked, would it not be easier for him to just use abandontransaction on the first one, which will abandon all three transactions and allow the inputs to respent directly from Core. He can then just create and broadcast new transactions the usual way without having to manually script anything.

OP, see here for more information: https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/abandontransaction/

I forgot about that at first. Should work if it's not in the local mempool.

[erikmollink]

Given that OP says that none of the transaction have been broadcast, and I can certainly not find any of them in a handful of mempools I have just checked, would it not be easier for him to just use abandontransaction on the first one, which will abandon all three transactions and allow the inputs to respent directly from Core. He can then just create and broadcast new transactions the usual way without having to manually script anything.

OP, see here for more information: https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/abandontransaction/

Tried that also, but the transaction is already in the local mempool of the node, so the transaction cannot be abandoned unless I would clear the local mempool. I have no clue to do that without bringing the whole BTCPay server offline and somehow delete the mempool from memory and/or disk. Sounds like a risky operation and I don't feel confident enough to do such.

[erikmollink]

Before that, you can try abandontransaction to see if it'll remove the transactions as well as the descendant transactions to see if it'll remove them and mark them as spendable.

Code:

bitcoin-cli abandontransaction de188ec7d50032773a43af8703b2f17d6bde2ae701b64934bce3e8850cd6a904 

If you're running anything older than 0.21.0, can you try restarting your full node and running it with -zapwallettxes as a flag at startup?

  "version": 200100,
  "subversion": "/Satoshi:0.20.1/",
  "protocolversion": 70015,
 
Why is older than 0.21.0 relevant?

[ranochigo]

Why is older than 0.21.0 relevant?

-zapwallettxes was removed in 0.21.0.

[o_e_l_e_o]

Sounds like a risky operation and I don't feel confident enough to do such.

Fair enough. I would follow ranochigo's advice above about using coinb.in instead then. Alternatively, if you are familiar with a light wallet such as Electrum, you could export the private key(s) of the address(es) you spent coins from in the first transaction, import that/those private key(s) to the light wallet, and use it to create, sign, and broadcast a new transaction.

You would need to use the command dumpprivkey "address"

See here for more info: https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/dumpprivkey/

[erikmollink]

Yesterday I made a stupid mistake. I wanted to get rid of a received dust transaction of 547 sat and tried to send it to a another address with a very low fee of only 336 sat.

This isn't helping you now, but for next time:

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

The transaction sends the 547 sats to a miner. The benefit of the OP_RETURN is that it doesn't create a UTXO that will never be spent. It works with hardware wallets, too.

But, wouldn't that not also stuck any other transactions being done after the dump of the dust, as they would be a child of this dust dump transaction?
I would have to wait first for this transaction to get confirmed before I can do any other transactions?

[LoyceV]

But, wouldn't that not also stuck any other transactions being done after the dump of the dust, as they would be a child of this dust dump transaction?

No. Burning the dust means it won't have any outputs you can use anymore, so it ends there.

I would have to wait first for this transaction to get confirmed before I can do any other transactions?

No.

[ranochigo]

I would have to wait first for this transaction to get confirmed before I can do any other transactions?

You made a small mistake in here. Burning dust entails that the transaction should only contain the dust as the inputs and nothing else. The purpose of certain dust attack is to de-anonymize users by making them spend the dust inputs together with their other inputs and thus resulting in a link between those addresses in the same transaction. By spending the dust with your other UTXOs (inputs), you are doing exactly as they intended. In some cases, the inclusion of that dust input would actually increase your transaction fees disproportionately, making it more expensive to spend the dust.

As long as you take care not to include any of your own inputs in a transaction intended to burn the dust, none of your other transactions will be dependent on that transaction as none of them will be spending the output from the burning transaction.

You can lock specific UTXOs to avoid spending them at all and save the hassle.

See the documentation: https://chainquery.com/bitcoin-cli/lockunspent

[odolvlobo]

Yesterday I made a stupid mistake. I wanted to get rid of a received dust transaction of 547 sat and tried to send it to a another address with a very low fee of only 336 sat.

For future reference, here is a guide showing how to dump the 547 satoshis if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c