Double spending in an UTXO based system is relative simple. Each transaction output can be considered as a "coin" that can be spent only as a whole and only by one transaction. It practically means that applying two transactions in a round for an unspent transaction means a kind of a double spending. The situation gets a little bit complicated if we consider an account / balance based system. One implementation of such a system is that there is a nonce both at the account and at the transactions as well: if the transaction nonce is by one bigger than the account nonce, implies that the transaction can be applied to the account. Otherwise we might as well have a replay attack. Despite of the logic it remains questionable how such a logic can be implemented. The versions are the following:
- After each transaction, the nonce is incremented by right away one. The problem is there are two transactions to the same account, than one must be considered as double spending and on the one hand must not be added to the block and it must be deleted from the transaction pool as well (as the nonce of the account already increased, there is no way that the transaction with the original nonce can be valid). As this is pretty much compatible with the classical UTXO based systes, it might not be the most performant solution and it might cause problems at use-cases where the only use-case is not just money spending, and there might be several actors working with the same account.
- Even with a simple money based blockchain system, it might be the use-case that I create to transactions in the same time for the same account in a way that they spend less money than the total amount of the account, and I certainly expect that both transactions are executed. If they are executed in the same block, the situation is actually solvable, as the miner can check and validate the transactions, and increase the nonce accordingly. However it might be a little bit tricky if the two transactions are executed in separate rounds, because the miner gets them in separate rounds from the transaction pool.
- From a conceptual point of view however, the simplest consideration is to assume one account one transaction. In such situation a standard use would send one transaction at a time. If she wants to send several transaction as a batch of transactions, the wallet would simply create a set of transactions with an always increasing nonce. If coincidentally one nonce gets refused for some reason, the wallet can again create and sign the transaction with a bigger nonce.
- From a conceptual point of view however, the simplest consideration is to assume one account one transaction. In such situation a standard use would send one transaction at a time. If she wants to send several transaction as a batch of transactions, the wallet would simply create a set of transactions with an always increasing nonce. If coincidentally one nonce gets refused for some reason, the wallet can again create and sign the transaction with a bigger nonce.
