nonce transaction counter is required

[hicaru]

Nonce is required

The main problem absence nonce:

• Cancel one of the batch transactions.
• Speed up one of the batch transactions.
• Priority control, of all transactions.
• Avoid collisions in hashsum (each tx payload is unique)
• Pool queue sorting.

For example:

• A user send 10 transaction to A1muhtTqVkpzDJgwASYGya9XaY1GmVYfNeJwpobdmtDACTRTBpW address with amount 0, if we don't use nonce the hash of payload will be same.

• If a user send 20 transaction at same time and want to cancel 6th, he shall cancel all 20 transactions.

• If a user send 20 transaction at same time and want to speed up first transaction, he cannot do it.

Nonce attack:

If a user sends me 10 coins, I as the hacker can send the same transaction 10000 times, it will confirmed because a transaction already signed.

[damip]

I agree with the following benefits:

• being able to send many times the same transaction at the same time: this can currently be done by varying the expiration period slightly which is not ideal
• cancelling transactions: but it would not be 100% reliable, and not very usable given that your transaction is applied after 8 seconds on average in Massa

However, it would also imply that transactions are larger by at least 1 byte, which reduces throughput.

Also note that the attack mentioned in this issue is currently impossible in Massa:

• re-inclusions of already executed operations are ignored (not executed)
• operation payload contains an "expiration period" after which the operation cannot be executed anymore

What do you think ? I'm hesitating

[hicaru]

i think to ignore transactions is bad way, one byte can one transaction, but users are not send only one transaction, they send batch transactions, and one byte can be faster for batch transactions.

We cannot use period field, because we cannot know when tx will be confirmed, or node just reject batch.

For example: A user send one tx pear 8 second, or a user send 10 transaction pear 9 second, so we have more transactions pear block.

[damip]

i think to ignore transactions is bad way, one byte can one transaction, but users are not send only one transaction, they send batch transactions, and one byte can be faster for batch transactions.

We cannot use period field, because we cannot know when tx will be confirmed, or node just reject batch.

For example: A user send one tx pear 8 second, or a user send 10 transaction pear 9 second, so we have more transactions pear block.

Sorry I didn't understand your comment. Can you reformulate ?

[hicaru]

i think to ignore transactions is bad way, one byte can one transaction, but users are not send only one transaction, they send batch transactions, and one byte can be faster for batch transactions. We cannot use period field, because we cannot know when tx will be confirmed, or node just reject batch. For example: A user send one tx pear 8 second, or a user send 10 transaction pear 9 second, so we have more transactions pear block.

Sorry I didn't understand your comment. Can you reformulate ?

i mean, users will send more then 1 transaction pear a block, also they shall able to cancel and speed up transactions

[damip]

i mean, users will send more then 1 transaction pear a block,

They already can. It's only fully identical transactions that can only be included once (more than 1 op where the same person is sending the same amount of coins to the same recipient with the same fee and the same expiration period). This is a marginal use case.

also they shall able to cancel and speed up transactions

We can discuss this