1

Suppose I have an application that receives funds from users and instantly moves them into an associated cold storage account.

If one of our nodes detects a transaction broadcast to one of our addresses, can I then generate and broadcast a signed txn sending the funds from the detected transaction to an associated cold storage, without waiting for the block to be mined or any confirmations?

Will the signed txn I generate succeed (assuming the initial transaction itself succeeds and wasn't an invalid broadcast)?


Example:

Block #998 is mined

A broadcasts txn to send 5 ETH to B

B broadcasts txn to send 5 ETH to C

Block #999 is mined

Notes:

  • B, and C were both new wallets which had 0 balance.

  • A's broadcast was valid, just not yet confirmed nor mined.

  • Example ignores fees for sake of simplicity

1

Yes, this is possible. It depends on the order of the transactions within the block itself. If you look at the Position tag of this transaction, you will see that it was the 144th transaction in that block.

In your case, you would want the A->B transaction to be ordered before the B->C transaction.


With that said, you cannot determine the order of the transactions within a block—that responsibility relies solely on the miner who mined the block. Miners can choose to order the transactions however they want, and it is not necessarily consistent between miners.

Because of this, what you proposed is possible, but not guaranteed to work 100% of the time.

6
  • 1
    So in the event it fails, will the failed transaction (e.g. B->C) get sent back to mempool and simply be validated later? Or is it permanently rejected? – Albert Renshaw May 5 '20 at 22:22
  • 1
    If the miner chose to accept it, I believe it will go on-chain but the transaction will fail. This also depends on how the miner's clients are configured. I want to say that some miner's clients will be "smart" enough to know that the tx will fail and will simply not include it in the block at all. – Shane Fontaine May 5 '20 at 22:24
  • 1
    In case A, B are external owned accounts a requirement for a transfer B->C is that B has to have enough balance to pay fees + transfer amount, it will remain in the pending pool otherwise. In the proposed case necessarily A->B will be mined first, since B has no balance. – Ismael May 5 '20 at 23:23
  • @Ismael if a transaction is made B->C where B does not have enough balance to pay the fee it will stay in the mempool until such a time that B has enough balance to pay the fee? Could someone theoretically clog the mempool by spamming unfulfillable transactions or is there some other mechanism that will cause them to become rejected? Also could a miner simply mine the invalid transaction regardless of fee, if they were only interested in the block fee itself, for example? In which case B->C could be invalidated again even with a 0 fee? – Albert Renshaw May 5 '20 at 23:50
  • 2
    @AlbertRenshaw A miner cannot mine invalid transactions, a block with invalid transactions will be reject by other nodes. There are some policies a node can apply to discourage spamming like blacklisting nodes generating them, drop old transactions. – Ismael May 6 '20 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.