Duplicate Transactions

[OrmEmbaar]

There are dozens of instances of duplicate transactions in the blockchain. These duplicate transactions all appear to be transfers. Here are some examples:

Transfer: 0x12cd3dc1d5ceb0cf5fb6eceee26c26ec375ad4e7433bc5c139b252a0fafa29ff
Appears in blocks:

• 0x28ec473ee5a96d227abce3df0a363685104af014e991d4da4c01ceb2fae6d61a
• 0x39fbf1ad55452d881500511d0cc78c195d51c4e9bfcfc4f3fe506a51bc358835

Transfer: 0xcc5aa4c2f88f1af66e01aa8807edc572ae7bfdb4539a6822fe8427c1a30186ce
Appears in blocks:

• 0xd48e14d245f6f9fbceb3bd6e3645c24df5e4b943aa5ad202cdf55c2beba2e26e
• 0xe128b53c33ac0a0883892dba48698011981ec032eca3089dcccdc009e74dd0a0
• 0x29e8da36bb5eb84d60abc5d1a5a596c984dac25e47462a87b74f16c3bdc27ac1
• 0x50120cecaeace054ff712beec7e72b2d8e38be151de87dc36e4b79631986531c

Is this expected behaviour? I have been unable to determine whether these duplicate transactions affect account balance.

[gavofyork]

There's nothing inherently stopping the same transaction from being applied twice in a substrate chain. It's up to the runtime logic to ensure that this doesn't happen in a way that is harmful to the userbase of the chain. The SRML Balances module (used by Polkadot) does allow for balance transfers to be replayed in certain conditions: specifically, when an account becomes dead its nonce (which prevents replay attacks) gets reset allowing for a potentially valid replay.

However, transactions can be crafted to ensure that they cannot be replayed by making them valid only for a certain range of blocks. Polkadot-UI doesn't currently support this safety measure (Substrate-UI does by default though), so if a previously depleted account is funded again and if the account's user used Polkadot-UI to transfer some balance in the first place, then it can be replayed, resulting in a "duplicate" transaction hitting the chain.

This hole will be closed as Poilkadot-UI matures and prevents accounts that may yet receive funds or have sent funds using unsafe replayable transactions from becoming depleted.

[gavofyork]

CC @jacogr

[jacogr]

Yes, we have an issue logged to move to (by default) mortal transactions for the polkadot-js api & apps - it is way overdue. (Not for lack of priority)

[ghost]

We are facing this issue in our faucet ( https://faucets.blockxlabs.com ). We see transactions replayed for depleted account. Will be looking forward to Polkadot-UI feature limit transaction validity for certain blocks.

[jacogr]

The apps UI does not yet send mortal by default, however since you mention the faucet, I am assuming you are using the polkadot-JS API. Just specify the era information as part of the signAndSend options when you submit mortal transactions and it will be treated as such.

Sadly, we are behind in docs samples here, however if you look at the linked PRs on the API around this, the samples are provided as tests for the exact functionality.

[emielsebastiaan]

Perhaps related: we have seen for our Polkascan (archive nodes) that the number of transactions in the queue (tx pool) are increasing while the nodes have clearly processed all txs they got from the p2p network. The longer the node has been running, the higher this number gets.

[gavofyork]

Probably not related. Maybe file another issue. @jacogr is there an issue logged for integrating mortal transactions into the UI and sending by default (and ideally also displaying a big fat warning if a user tries to deplete an account that the UI doesn't know sent purely mortal transactions from?)

[gavofyork]

Closing for now in any case as it's well-understood.

[jacogr]

@gavofyork Yes, the UI now send mortal by default. (polkadot-js API as well)