Can I slowdown someone's transaction?

[shield132]

Maybe sounds a little bit foolish from me but is it possible to slowdown someone's transaction?
We can manually accelerate any transaction if we own pools or at least pay for including specific tx in list of other pools (antpool, viabtc and etc). But isn't there any way to slow down it? Something like this: Choose target transaction and include in your list but stuck it.

[HCP]

In a word, No.

Unless you can convince ALL the nodes not to propagate said transaction... or unless you can convince ALL the miners not to include a specific transaction, there is a chance that a miner will "see" the transaction and include it in a block. Your chances of getting ALL the nodes and miners to do this is practically zero.

Why on earth would you want to slow down a transaction? Are you considering some sort of DoS attack on a specific user/address?

[nc50lc]

Are you trying to find any possible explanations to those "stuck transactions" last December? Or a conspiracy theory?

Theoretically, someone can if he's a miner or a pool operator that has the majority of the total hashrate (more than 51%) which could continuously mine about 6-10 blocks successively (100minutes approx) by not including that tx.
Any blocks mined by others has the chance to not include that transaction, thus, another set of blocks that excluded it (from that "someone") might follow up ~another hours of delay/waiting.

This is statistically impossible unless the total number of competing miners (not pool miners, but the pools and solo miners) fell to one-digit.
And apparently, if someone have that power, he wouldn't use it just for that.

TL;DR, it's a no.

[LoyceV]

I'm going against the consensus here by saying a theoretical yes, but it'll slow down many other transactions too: a spam attack on the blockchain. Just make enough new transactions with a higher fee per byte than the transaction you want to slow down, and your transactions will be included first.
It'll lead to fee spiraling up, and while a RBF will cost the transaction in question a few dollars at  most, you'll be paying up to millions of dollars per day.

So yes, it's possible in theory, but quite unlikely to do.

[bob123]

Well i'd like to add another point of view.
If you do know the date of a transaction in advance and the physical place (or IP address) you might be able to disrupt the transaction from being broadcasted.

Note that this effectively does not slow down a transaction, but completely 'cancels' it.
But you theoretically still would be able to broadcast it at a later date if those inputs hasn't been spent yet.

This requires physical access.


The theoretical plan to perform such an attack would be something like:

1) Either infect your target with malware or use whatever method to gain access
2) Connect the targets node to 8 nodes under your control (8 outgoing connections are standard)
3) When a transaction you want to intercept is broadcasted, don't relay it.
4) Replay the transaction at a later date (if UTXO's hasn't been used yet).

This attack is pretty expensive in terms of time and dedication and not too trivial to perform. It is definetely possible, but very unlikely.

[HeRetiK]

I'm going against the consensus here by saying a theoretical yes, but it'll slow down many other transactions too: a spam attack on the blockchain. Just make enough new transactions with a higher fee per byte than the transaction you want to slow down, and your transactions will be included first.
It'll lead to fee spiraling up, and while a RBF will cost the transaction in question a few dollars at  most, you'll be paying up to millions of dollars per day.

So yes, it's possible in theory, but quite unlikely to do.

Even ignoring RBF and CPFP spamming the network wouldn't guarantee your success though. Sure, you could slow down the whole network, but the specific transaction you are trying to target could by some happy circumstance still slip through the cracks and end up in one of the next blocks.

It is also worth noting that OPs scenario assumes that the transaction is already published. Assuming a reasonable transaction fee this gives a would-be adversary less than 10 minutes (ie. a block interval) to have their spam transactions propagated and validated all over the network. And even then there's a chance that a miner includes transactions that arrived before the spam attack first -- including the targetted transaction.

[aleksej996]

I guess transaction malleability is still possible as non-standard transactions, I am not sure about this though and I would assume it only works with legacy transactions.

As far as I remember, there were pools out there that confirm non-standard valid transactions. So you could send them a malformed transaction and in case it confirms first, I think victim's client would be confused and would need a rescan of the blockchain to check it's balance.

[bob123]

1. As miners, you could don't include transaction & you don't need 51%+ hashrate if there are many unconfirmed transaction.

This would mean he has to convince every miner to not confirm his transaction.
If one single miner decides to include his transaction into a block once he finds it, this is ruled out.
I think this does not fall under the 'Can I..' category.

2. As their ISP (or simply connect to your network), you could block bitcoin's wallet website or default wallet/nodes port.

This wouldn't work because transactions can be created locally and then broadcasted via several different methods. Either via core (directly to the network), via electrum server, via online-services, etc... It wouldn't be possible to block every possible way of broadcasting a transaction.


I agree with your other points. But these two don't seem realistic to me.

[LoyceV]

This attack is pretty expensive in terms of time and dedication and not too trivial to perform. It is definetely possible, but very unlikely.

Let's face it: Bitcoin is designed to be unstoppable, and it works very well.

@shield132: any reason in particular why you're asking this?

[jackg]

I think there's a way to delay the broadcast of a transaction but, once it's on the network (and in the mempool), there's risk the transaction will go through.

As previously mentioned, you can double spend your transaction's inputs with a higher fee but this will cost you a bit more, also, your transactions will sometimes be spent from the outputs of your other transaction so you might just be paying the network for nothing (while taking up space in a block). And there's still the chance the first transaction will get confirmed anyway.

A network attack can also be done, but it would need fees higher than your transaction and quite a bit higher to ensure your transaction is unlikely to fall through the net, and even with this addition, there's still a chance it will fall through and get confirmed.

[shield132]

In a word, No.

Unless you can convince ALL the nodes not to propagate said transaction... or unless you can convince ALL the miners not to include a specific transaction, there is a chance that a miner will "see" the transaction and include it in a block. Your chances of getting ALL the nodes and miners to do this is practically zero.

Why on earth would you want to slow down a transaction? Are you considering some sort of DoS attack on a specific user/address?

No, that's not my intention, I just got an interesting question (at least interesting for me) and wanted to hear opinions about it's possibility.
Just imagine someone receives transaction for very bad job ans you discovered this transaction, want to slowdown it or reject, what can you do?
On another hand if you have stuck transaction, you can speed up so why can't you to slowdown it?
Thanks everyone for answers...

[jackg]

No, that's not my intention, I just got an interesting question (at least interesting for me) and wanted to hear opinions about it's possibility.
Just imagine someone receives transaction for very bad job ans you discovered this transaction, want to slowdown it or reject, what can you do?

You can't really do anything as the network is designed against this.
You would have to purchase Antpool, Viabtc, F2Pool and a load of other major pools (or in fact every other piece of mining hardware) - which would just be impossible.
Although, if you knew someone was going to get paid for it in say 2030, you could start saving now, make loads more miners that stop everyone else from trying to mine Bitcoin by rendering their miners useless and being the only one able to produce the chips - though someeone else might just start to make a chip anyway.

On another hand if you have stuck transaction, you can speed up so why can't you to slowdown it?

If you own the sending private key then you can stop it completely, however, of not then you can't.
If a pool accelerates your transaction, they just add your txid to the list, the coins can still be mined by another miner at that point it doesn't exclusively get mined by that pool. For example, I tried to accelerate a transaction on viabtc and BitFury confirmed it before them.

[HCP]

On another hand if you have stuck transaction, you can speed up so why can't you to slowdown it?

"Speed up" is not really the correct terminology... all you're really doing is asking a particular miner to put the transaction into the next block that they mine. (Note that there is NO guarantee that they will actually find the next, or any, block before the transaction is included by someone else, as per jackg's example with ViaBTC and BitFury). The reason "acceleration" worked with AntPool and ViaBTC was that they had relatively large hashrates... and a fairly decent probability of finding a block within a couple of hours. As opposed to say an accelerator run by some guy with one AntMiner S9

However, to STOP a transaction from being included... you'd need to ask ALL the miners NOT to include that transaction. Obviously, it is technically possible to attempt... but highly improbable to succeed.