TX stuck with 79 recipients and 860 Sat each blocking my funds

So I've got a transaction that's stuck, and it looks like the issue is an incoming transaction to my wallet that I didn't even know about. I ended up spending an output that's linked to this unknown input. My transaction's fee is 18 vByte/Sat which is fine, but this strange 860 Sat transaction is pretty big and has a fee of 6 Sat/vByte, yet it's still unconfirmed. No clue where it came from, but here's the link: https://blockchair.com/bitcoin/transaction/95e315f00b48201655877d8d86817748fe32b1d7d339c5a334dac28328a4c939 This transaction has 79 recipients, each getting 860 Sat, and it’s been stuck for 3 days now. It's effectively blocking 79 addresses with a total expenditure of 0.00068022 BTC (17.62 USD) and a transaction fee of 0.00018345 BTC (4.75 USD). Funny thing is, I tried using the free tx accelerator from this site https://www.viabtc.com/tools/txaccelerator/ , but it didn't work since the TX is too large. The paid option quoted me a whopping 0.09 BTC, which is around $2100, just to speed it up! Does anyone have any idea what's going on? Is this some weird dust mapping attack from a couple of years back, or maybe someone's trying to block as many wallets as possible? Anyone else caught in this situation? Feels pretty shady... My transaction and pretty much all the funds in my wallet seem to be frozen now. If this isn't the right spot for this, point me in the right direction. I looked around but couldn't find anything related.

This seems to be a dust attack. I don't know the kind of wallet you are using but for wallets like Electrum. You could uncheck the option of spending unconfirmed coins. Sparrow wallet has an option of you selecting the UTXO's you want to spend. This can effectively enable you to spend coins without including the dust sats into your transaction inputs. AFAIK, right now there is nothing you can do, you just have to wait it out until the unconfirmed transaction finally get confirmed if the fee rate drops so which is likely hard to achieve or until the unconfirmed transactions get dropped out of the mempool.

Not sure if it's a dust attack or not because the sender could have sent less sats than 800 (546 if am not wrong). Anyway, what makes things worse is that even the parent transaction of the one you received is still unconfirmed. So, if you are going to perform rbf you'll have to pay for both of them. I haven't done an accurate calculation but I believe if you are going to use rbf to accelerate the transaction you'll need to add 80-90k sats to the paid fees to get a reasonable effective fee rate (~18 sat/vb) Next time, make sure to use the coin control feature to select which UTXOs you want to spend.

You probably meant CPFP, right? At this point, OP can not perform RBF because the unconfirmed ancestor transactions are in a wallet address he probably does not control. Secondly, the ancestor transactions are not RBF enabled.

OP can perform rbf as long as the transaction he made is flagged as rbf even if he doesn't have access to wallets which made the parent transactions (someone corrects me if I'm wrong!). When replacing a transaction by fee, you are telling the node to remove it and replace it with a new one which consumes the same (or a single) inputs and pays higher fees. Technically, this doesn't affect or introduce any change to the parent transaction(s).

He can't perform RBF. I saw his transaction and the RBF was not enabled as well, but I didn't want to share it here since he didn't post the TX ID initially.

Thanks for the comments - we will see how it plays out. viabtc offers to 'rectify' the situation for just ~0.09 BTC and I am not quite willing to pay for that. I am using a coin-specific multiwallet that does not have much fee control- but this would have happened with any wallet I guess, because the culprit is the incoming TX. I guess electrum or bitcoin core would have displayed the pending dust TX, but that also can be overlooked. What weird behaviour, I seem to remember that the dust attacks from 2 or 3 years ago were allegedly done as some kind of marketing gimmick.  I just hope it gets dropped from the mempool sooner or later... Yes, this is the parent TX to the 79-output-TX and is is also still unconfirmed: https://blockchair.com/bitcoin/transaction/ba3c96897174501fec909952ae590176b9211f2a3ae4d3b844fcc26a474756bc This parent TX has 60 senders, all of them 3xyz.. multsig addresses, and the TX going to the subsequent address that sent the dust seems to be a change address- could this be some kind of mixer?

Using coin control would have prevented it: If your wallet doesn't allow manual coin control or manual fees: stop using that wallet and switch to a decent one. Take your seed or private key and import it. For now, all you can do is wait until your transaction is dropped. If your current wallet keeps broadcasting it, that may take a very long time. Bitcoin Core doesn't use unconfirmed inputs from third parties.

In comparison to CPFP, it'll only need an extra 0.00178900BTC to bump to 20sat/vB. (total vSize is 8945 vB) Since there's still 0.00850354 change, you can still use some of it to CPFP whether the wallet supports CPFP so or not. If you do not have any other available UTXO, you can perform CPFP by simply sending another child transaction with enough absolute fee (fee rate multiplied by virtual size). Your transaction and its parents have an overall transaction fee rate of 7.89sat/vB as bundle. It's nearing the bottom of mempools with default size setting. The question is, if your wallet keeps its own mempool and wallet transactions, rebroadcasts dropped txns or need user intervention to remove dropped transactions. It's impossible to give a suggestion without knowing the wallet's name.

I've rewritten your transaction OP to remove the dust input, keep the payment output the same, and very slightly adjusted the fee so you can replace your currently unconfirmed transaction: If you can sign this and broadcast it to a node which accepts full RBF replacements, then it should replace your other transaction and be confirmed fairly quickly. You can do this easily with Electrum if you are able to import your wallet to Electrum using either your seed phrase or a private key for that address. You should do this on an airgapped device for security reasons. Otherwise, at the effective fee rate of ~7.5 sats/vbyte, you are going to be waiting weeks for a confirmation. The parent transaction with a fee rate of 6 sats/vbyte will already have been dropped by default nodes, meaning OP's transaction will have been dropped as well. There are however an increasing number of nodes using non-default mempool settings, which is why we can still see OP's transaction on most block explorers and he can still see it in his wallet.

l8orre, I just created a watch-only wallet with your address in electrum and tried several servers. Some of them still had your transaction (and its parent) in their mempool and some of them had dropped your transaction from their mempool. As mentioned by o_e_l_e_o above, you should be able to broadcast a new transaction using electrum. If you imported your wallet and you saw your transaction, try different servers until you find a one that doesn't have your transaction in its mempool. If your transaction status changed to local, right click on it and select "Remove". In the case you connect to a server that doesn't have your transaction, you can broadcast your transaction even if the server's node hasn't enabled full RBF. Due to security reasons, it's better to create a watch-only wallet with your address for finding a server which doesn't have your transaction in its mempool and broadcasting your transaction. As suggested by o_e_l_e_o, import your private key and sign your transaction on an air-gapped device.

Thank You so much Sir, this worked!!! I created a view only electrum wallet on another device, found the spurious dust TX, went through the servers, found one that listed this TX as 'local', deleted it from there, and was able to send (from another, secure rig) a small-ish TX with a beefy fee from another address to that my original address. Now my original child TX has disappeared, while the spurious dust TX is still pending, but I can send funds again! Hard to follow how this could work, but it did! Thank You! These two precursor TXs look interesting, they do seem to be some kind of consolidation protocol. The latter one that blocked my TX was someone spreading out a change TX over 79 other addresses (seemingly random), and the precursor to that one received 60 inputs with almost the same amounts, all from 3xy addresses - looks like some consolidation or intermingling going on .. Also, why would someone disperse  0.00086367 BTC - 22.38 USD of change, seemingly just to get rid of it? This is the precursor TX to the offending change dispersal: https://blockchair.com/bitcoin/transaction/ba3c96897174501fec909952ae590176b9211f2a3ae4d3b844fcc26a474756bc I am not that much of a blockchain sleuth, but it sure looks weird... So if the sender does not up the fee a bit it will bounce sooner or later, and to what purpose was it sent then? Was this done specifically to bounce eventually? Or a SPAM attack on BTC with underfunded TXs that are meant to bloat the mempool?

The motivation for all these "mempool attacks" don't make any sense to me. You just temporarily hold up the mempool from processing other transactions for shits and giggles. Eventually the mempool clears because you cannot keep creating spam at this rate forever, and all of the transactions get processed, making the whole attack useless.