Creating a transaction at the same exact second as another one

[Tfs]

Newbie question about the speed of the network in 2025.

Suppose I want to monitor with a bot a given long dormant address A, so that if it sends a transactions to some other address B, say tomorrow at 10:09:26,  then my bot will also send a transaction to B at the same exact time,so that in the blockchain it is impossible to say which one is earliest.

Is it possible? Can you expnain the mechanism, including the time it takes for a tx to be accepted. Thank you.

[PrimeNumber7]

Transactions are included in the blockchain in sets. Each block will confirm a set of transactions, and the block will include transactions in the order they choose.

It is also not guaranteed that a transaction you broadcast will be included in the next block found.

So a transaction could be broadcast from address A to address B at a given time, you could broadcast a transaction to address B shortly thereafter, and the order of the two transactions will be up to whoever finds the next block.

You could potentially include a very large transaction fee to your transaction to have an increased probability that your transaction will be included in the very next block, potentially higher in the next block than the transaction from address A.

But realistically, many will see that all transactions confirmed in block x as all being solidified at the same time.

[DubemIfedigbo001]

Suppose I want to monitor with a bot a given long dormant address A, so that if it sends a transactions to some other address B, say tomorrow at 10:09:26,  then my bot will also send a transaction to B at the same exact time,so that in the blockchain it is impossible to say which one is earliest.

No It does not work that way, transactions are included in blocks and if your bot detects the address has already sent the transaction, meaning it has received at least 1 confirmation, then even if you prompt your system to send some bitcoin to the address at the time of notification, the network delay would have its effect and every new block has a delay of approximately 10 minutes before it is mined and it may be longer if there is higher network difficulty in finding the valid hash to confirm the transactions in the new block.

Like the other speaker said, there is still no guarantee your transaction would be included in the next block although you would be at advantage for it to be included if you use higher fees, and there is no specific time frame for your transactions to be confirmed, it depends on the action of the miners and the network difficulty at that point, but sending transactions concurrently with a speed of light to address B after your bot must have been notified of the first transaction from address A being confirmed is not possible in the bitcoin network.

[HeRetiK]

If both transactions make it into the same block you can't really discern which transaction came first, so with the targeted average block interval being 10 minutes you have a bit of leeway with how fast your bot has to react.

You don't really have a guarantuee that both transaction make it into the same block though or that your transaction gets confirmed earlier, however having a higher transaction fees increases the chance of your transaction being prioritized by miners.

No It does not work that way, transactions are included in blocks and if your bot detects the address has already sent the transaction, meaning it has received at least 1 confirmation, then even if you prompt your system to send some bitcoin to the address at the time of notification, the network delay would have its effect and every new block has a delay of approximately 10 minutes before it is mined and it may be longer if there is higher network difficulty in finding the valid hash to confirm the transactions in the new block.

It depends on how the bot detects the transaction. If the bot is checking the blockchain it would be too late, but usually you'd monitor the mempool for a case like this.

[DubemIfedigbo001]

No It does not work that way, transactions are included in blocks and if your bot detects the address has already sent the transaction, meaning it has received at least 1 confirmation, then even if you prompt your system to send some bitcoin to the address at the time of notification, the network delay would have its effect and every new block has a delay of approximately 10 minutes before it is mined and it may be longer if there is higher network difficulty in finding the valid hash to confirm the transactions in the new block.

It depends on how the bot detects the transaction. If the bot is checking the blockchain it would be too late, but usually you'd monitor the mempool for a case like this.

Even if he monitors the mempool, he gets notification when the transaction has received at least one confirmation because before then the transaction has not been confirmed and from his explanation, he wants to send the second transaction as soon as the first one reaches its destination, meaning it must be confirmed first and in the mempool you use the transaction ID to track transactions that has been confirmed and not those that has been included in a block. to do this he would have access to the transaction ID, meaning the transaction have been created earlier and would only be broadcasted at a specified time.

something like this using mempool.space API

Code:

async function checkTxConfirmed(txid) {
  const res = await fetch(`https://mempool.space/api/tx/${txid}`);
  const confirmTX = await res.json();
  return confirmTX.status.confirmed;  // this would be true if transaction has been confirmed
}

[Amphenomenon]

It depends on the discretion of the miners. While both might be in the same block and possibly have same tx fee, the first pick by the miner would be the first here. They have other means of prioritizing a tx like which get to the miners mempool first or their mempool policies... Although the major one is through higher tx fee, when they are broadcast around same time.

[Ambatman]

say tomorrow at 10:09:26,  then my bot will also send a transaction to B at the same exact time

Exact same time is practically impossible.
Because other nodes may timestamp it slightly differently as a result of clock drift or network delays or even miners discretion.

Like PrimeNumber said,  you can aim to have your transaction included in the same block by pushing with an attractive fee( not a sure solution, but it's one of the best you can get Imo) .
This will make it difficult to determine the exact order within that block and they would both appear the same.

[Tfs]

Thank you to all. Same block is what is needed, and indeed a larger fee seems to have worked in some cases I have seen.

[mcdouglasx]

No It does not work that way, transactions are included in blocks and if your bot detects the address has already sent the transaction, meaning it has received at least 1 confirmation, then even if you prompt your system to send some bitcoin to the address at the time of notification, the network delay would have its effect and every new block has a delay of approximately 10 minutes before it is mined and it may be longer if there is higher network difficulty in finding the valid hash to confirm the transactions in the new block.

It depends on how the bot detects the transaction. If the bot is checking the blockchain it would be too late, but usually you'd monitor the mempool for a case like this.

Even if he monitors the mempool, he gets notification when the transaction has received at least one confirmation because before then the transaction has not been confirmed and from his explanation, he wants to send the second transaction as soon as the first one reaches its destination, meaning it must be confirmed first and in the mempool you use the transaction ID to track transactions that has been confirmed and not those that has been included in a block. to do this he would have access to the transaction ID, meaning the transaction have been created earlier and would only be broadcasted at a specified time.

something like this using mempool.space API

Code:

async function checkTxConfirmed(txid) {
  const res = await fetch(`https://mempool.space/api/tx/${txid}`);
  const confirmTX = await res.json();
  return confirmTX.status.confirmed;  // this would be true if transaction has been confirmed
}

He can monitor an address through the meempool, so when there is an unconfirmed transaction it is detected, it does not need any confirmation for this, and to try to make the transaction made by him go to the next block, he only has to include it with higher fees, although this does not guarantee success it will increase the chances of them being included together in the same block, achieving his goal of not knowing which tx was transmitted first because on paper, both will be in the same block.

[Mia Chloe]

then my bot will also send a transaction to B at the same exact time,so that in the blockchain it is impossible to say which one is earliest.
Is it possible? Can you expnain the mechanism, including the time it takes for a tx to be accepted. Thank you.

The both transactions being confirmed the same time is possible though the chances are also thin but it is not as thin as that of both transaction being broadcasted at the same time this is because based on your setup you would need the transaction to have only been broadcasted before the bot would have picked it up. Plus the time gap your bot would need to create another transaction will also prevent both from being confirmed same time.

No It does not work that way, transactions are included in blocks and if your bot detects the address has already sent the transaction, meaning it has received at least 1 confirmation.

Nope if the op is tracking the other wallet especially via public key he will find the transaction immediately it's broadcasted. Similarly if he's tracking the receiving address he will also see the broadcast immediately that's why it's a public ledger.

[hosemary]

he only has to include it with higher fees

Should use equal fee fee rate, if the purpose is both transactions are included in the same block.

The both transactions being confirmed the same time is possible though the chances are also thin

Why do you think the chance is thin?
If the bot broadcasts the second transaction once it sees the first one and the fee rate used for the transactions are equal, there's a very big chance that both transactions will be included in the same block.

[Pablo-wood]

The both transactions being confirmed the same time is possible though the chances are also thin

Why do you think the chance is thin?
If the bot broadcasts the second transaction once it sees the first one and the fee rate used for the transactions are equal, there's a very big chance that both transactions will be included in the same block.

Two transactions can be included in the same block but will never be confirmed at exact same time in such a way it won't be distinguished. Even with both transactions in the same block the ordering will be visible to everyone onchain.

Thank you to all. Same block is what is needed, and indeed a larger fee seems to have worked in some cases I have seen.

Even with higher tx fee ordering will still be defined. There is nothing like exact same time inside a block, there is always a strict order recording for blocks in every Blockchain. The thing about validators is even with same tx fee and identical timestamps nodes will still put one transaction before the other. As far as miners are concerned there is no randomised order

[Mia Chloe]

Should use equal fee fee rate, if the purpose is both transactions are included in the same block.

This is what I was actually trying to emphasize on the op would have to use exactly the same fee rate that will ensure that the second transaction being broadcasted by the bot stays in the same block as the previous transaction and also have almost the same depth so that both of them get confirmed at almost the same time exactly.

Why do you think the chance is thin?
If the bot broadcasts the second transaction once it sees the first one and the fee rate used for the transactions are equal, there's a very big chance that both transactions will be included in the same block.

The entire possibility still depends on if the bot is able to compute it efficiently else if the first transaction has a bigger fee rate it may be confirmed really fast.

[hosemary]

Two transactions can be included in the same block but will never be confirmed at exact same time in such a way it won't be distinguished. Even with both transactions in the same block the ordering will be visible to everyone onchain.

What do you mean by order?

Miners assign an index number to each transaction they include in the block and block explorers sort the transactions according to those index numbers.
A transaction having a smaller/bigger index number than another transaction doesn't mean it has been broadcasted earlier/later.

The entire possibility still depends on if the bot is able to compute it efficiently else if the first transaction has a bigger fee rate it may be confirmed really fast.

That's not a difficult task for the bot.

[Pablo-wood]

What do you mean by order?

Miners assign an index number to each transaction they include in the block and block explorers sort the transactions according to those index numbers.
A transaction having a smaller/bigger index number than another transaction doesn't mean it has been broadcasted earlier/later.

Aren’t the transaction indexes inside a block always ordered sequentially? What I meant by order is the order in which the miner includes and executes the transactions in the block. That should be the same as the index order if I am not mistaken. So once a miner assigns an index to a transaction, that becomes the execution order during validation.

[mcdouglasx]

he only has to include it with higher fees

Should use equal fee fee rate, if the purpose is both transactions are included in the same block.

If he's talking about an addr that's been dormant and he just wants to monitor where the funds are being sent, I don't think it has anything to do with whether they're mined in the same block or not; the blockchain already handles that.

But if he's monitoring the dust transaction for other purposes and wants to include it in the next block together, it's not really a question of setting the same fee being the most effective. Instead, it needs to be a better-developed bot that quickly builds the dust transaction dynamically based on the size of the transaction being monitored. The fee depends on whether the bot assumes you have a fast parameter or if it checks every x seconds.

If it doesn't monitor in real time, setting more fees gives it a better chance of both being included equally.

[hosemary]

Aren’t the transaction indexes inside a block always ordered sequentially?

No.
The only rule we have about orders of the transactions in the block is that the first transaction must be the coinbase transactions. In other words, miners must assign the index number 0 to the coinbase transaction.
Miners can put all other transactios in the block in any order they want.

[stwenhao]

Miners can put all other transactios in the block in any order they want.

Well, almost. If there is Alice->Bob transaction, and Bob->Charlie transaction depends on that, then Alice->Bob should appear in the block before Bob->Charlie. Which means, that the whole block can be validated in a single pass. But yes, in case of independent transactions, they can appear in any order.

However, many nodes use Bitcoin Core, and when they request block template, then things produced by each and every node are pretty much similar, if their mempools are more or less identical. Sometimes, some transactions at the beginning of the block are prioritized, even if they have low fees, or no fees, but in general, if you run a node, and call "getblocktemplate", then you can usually predict, how 90% of the block space would be allocated.

So, to sum up: miners can change the order of transactions, but usually they don't. Much more often, they just increase extra nonce, instead of reordering transactions (also because it is faster, and because it requires only recomputing the coinbase transaction, and only some parts of the merkle tree, where it is connected).

[odolvlobo]

Newbie question about the speed of the network in 2025.

Suppose I want to monitor with a bot a given long dormant address A, so that if it sends a transactions to some other address B, say tomorrow at 10:09:26,  then my bot will also send a transaction to B at the same exact time,so that in the blockchain it is impossible to say which one is earliest.

Is it possible? Can you expnain the mechanism, including the time it takes for a tx to be accepted. Thank you.

All transactions in a block occur at the same time. The time of a transaction is the time of the block it is included in. The time of a transaction is not when it was created or broadcast, though that can influence which block it is included in. One transaction is earlier than another transaction only if it is included in an earlier block. There is no way to guarantee that your transaction is in the same block or an earlier block.

The timestamp of a block is not the time it was added to the block chain, but it is close. It is guaranteed to be within about an hour of the actual time it was added. Furthermore, it is not uncommon for a block to have an earlier time than the block that precedes it.

I'm curious about what you are trying to accomplish. When bitcoins are sent from A to B, why do you also send to B?

[gmaxwell]

I'm curious about what you are trying to accomplish. When bitcoins are sent from A to B, why do you also send to B?

Perhaps to try to exploit some refund mechanism or some drain bramaged assets protocol.

FWIW, within a block as people have noted there is no mandatory order beyond topological consistency (parents come before children), which is why it's best to treat all txn in the block as happening at the same time.  So there is no "first" that matters other than whatever scheme you're trying to hack considers first... which might mean placed earlier in the block.

In practice, miners mostly sort transaction by ancestor feerate, and then if that's the same I think wtxid tiebreaks. So, assuming that the target considers earlier in the block to be first, to be 'first' given common network behavior you'd set your feerate to just slightly higher than the other txn.  It may also be helpful to be *smaller* in terms of weight than the other transaction to make sure that transaction selection doesn't skip over you as the block becomes full because you don't quite fit but include the other txn instead. You can make your spending txn as small as possible by spending a taproot coin and not paying to any other output than the target.

There is no particular difficulty in detecting unconfirmed transactions-- many thieves already do this:  The often refrain from stealing from addresses where they have the key in the hopes that the user will reuse the address and send more funds.  But if they see a transaction they try to take the funds as fast as they can and bet that they have faster txn relaying than the real owner along with a higher fee to make their txn more preferable to miners.


(I'm generally not a fan of helping people with their exploit homework, but OTOH if anyone is running something dumb enough to be vulnerable to txn order then their doom is kind of inevitable, and it's probably protective to discuss why such systems are broken.)