Duplicate transaction error

[pavybez]

When I attempt to do the following twice it throws up a duplicate transaction error:

./eosc --wallet-port 7777 transfer inita currency 10000

If I run the same command with a different amount it works fine but only once.

./eosc --wallet-port 7777 transfer inita currency 10001

The error output is as below:

2274982ms thread-0 main.cpp:768 main ] Failed with error: 10 assert_exception: Assert Exception
status_code == 200: Error
: 3030011 tx_duplicate: duplicate transaction
Transaction is not unique
{}
thread-0 chain_controller.cpp:828 validate_uniqueness

[pavybez]

You have to enter the commands quickly to reproduce error.

[learnforpractice]

Approve, that’s weird.

>> eosapi.transfer('inita','eos',100,'abc',0)

b'{"transaction_id":"eae5e2659fbdf3a5d410b3f94b5e1aca189c8c320eff710bb9de58b683a9d88f","processed":{"refBlockNum":0,"refBlockPrefix":0,"expiration":"2017-09-08T13:03:04","scope":["eos","inita"],"signatures":[],"messages":[{"code":"eos","type":"transfer","authorization":[{"account":"inita","permission":"active"}],"data":{"from":"inita","to":"eos","amount":100,"memo":"abc"},"hex_data":"000000008040934b000000000000e62b640000000000000003616263"}],"output":[{"notify":[{"name":"inita","output":{"notify":[],"sync_transactions":[],"async_transactions":[]}}],"sync_transactions":[],"async_transactions":[]}]}}'

>> eosapi.transfer('inita','eos',100,'abc',0)

84733ms thread-1 eosapi.cpp:333 transfer_ ] 3030011 tx_duplicate: duplicate transaction Transaction is not unique {} thread-1 chain_controller.cpp:830 validate_uniqueness {"trx":{"refBlockNum":0,"refBlockPrefix":0,"expiration":"2017-09-08T13:03:04","scope":["eos","inita"],"readscope":[],"messages":[{"code":"eos","type":"transfer","authorization":[{"account":"inita","permission":"active"}],"data":"000000008040934b000000000000e62b640000000000000003616263"}],"signatures":[]}} thread-1 chain_controller.hpp:319 validate_transaction {"trx":{"refBlockNum":0,"refBlockPrefix":0,"expiration":"2017-09-08T13:03:04","scope":["eos","inita"],"readscope":[],"messages":[{"code":"eos","type":"transfer","authorization":[{"account":"inita","permission":"active"}],"data":"000000008040934b000000000000e62b640000000000000003616263"}],"signatures":[]}} thread-1 chain_controller.cpp:959 apply_transaction {"trx":{"refBlockNum":0,"refBlockPrefix":0,"expiration":"2017-09-08T13:03:04","scope":["eos","inita"],"readscope":[],"messages":[{"code":"eos","type":"transfer","authorization":[{"account":"inita","permission":"active"}],"data":"000000008040934b000000000000e62b640000000000000003616263"}],"signatures":[]}} thread-1 chain_controller.cpp:265 push_transaction

[pavybez]

I debugged code and found that we generate a digest using transaction details. Hence if we have two similar transactions in the same block the message digest turns out to be the same and the hash function produces the same ID for both transactions. I think we should have a unique identifier for transaction besides just the block reference number.

[bytemaster]

This isn't a bug per-say, you can resend the transaction after the expiration of the original.

You can update the TAPOS every 3 seconds (or use older tapos)
You can update the expiration if you really need to
You can add a dummy message to the transaction as well.

[bytemaster]

Alternatively, you can put multiple transfers in a single transaction.
The wallet could implement the "naggle" algorithm if this double-sending occurs frequently

[bytemaster]

This issue should be resolved in the following way:

• add a print message explaining why a duplicate was created and indicating ways to fix it
• implement a flag on CLI wallet to specify a longer expiration window
• implement a flag on CLI wallet to add a "random" no-op message to force uniqueness, documentation of flag should warn user that it will consume extra bandwidth

[wanderingbort]

@bytemaster Instead of a "noop" message which would need to be recognized by the producer code so that it doesn't try to load some wasm code account and execute it, how do you feel about pushing 1-4 extraneous bytes to the end of a single messages data? Currently we are not enforcing that every byte of a message is read and this would ultimately save the overhead of an additional message header.