Shielded transaction rejected: the proof for the encrypted transfer doesn't validate
matsuro-hadouken opened this issue · 11 comments
Recently all shielded transactions got rejected.
Transactio been send with following sintax:
spawn concordium-client --grpc-ip 127.0.0.01 --grpc-port 10000 transaction send-gtu-encrypted --receiver "$receiver" --amount "$amount" --sender "$sender" --no-confirm
Complete output:
Enter password for decrypting the secret encryption key:
Transferring 0.100000 GTU from encrypted balance of account '4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q' (PoSFreak) to '2xBEKSeitEmHXX6xQ7DikMcqacx1zGCWnPRzZyts75pZReqt1r'.
Allowing up to 30070 NRG to be spent as transaction fee.
Transaction expires at Fri, 29 Jan 2021 03:51:29 UTC.
Warning: There is a pending transaction with nonce 274, but last committed one has 273.
This transaction will have nonce 275 and might hang if the pending transaction fails.
Enter password for signing key:
Transaction 'd7a8e12782c27cd34733f0e3c1aa941ecd0dab5ca1cecae7ead1a349a0786411' sent to the baker.
Waiting for the transaction to be committed and finalized.
You may skip this step by interrupting the command using Ctrl-C (pass flag '--no-wait' to do this by default).
The transaction will still get processed and may be queried using
'transaction status d7a8e12782c27cd34733f0e3c1aa941ecd0dab5ca1cecae7ead1a349a0786411'.
[03:42:54] Waiting for the transaction to be committed..................
Transaction is finalized into block 48102256af91684433df0b111f87b78f9b63a02b8bffb9667c4af8ee464fd093 with status "rejected" and cost 3.007000 GTU (30070 NRG).
Transaction rejected: the proof for the encrypted transfer doesn't validate.
[03:43:29] Waiting for the transaction to be finalized...
[03:43:29] Transaction finalized.```
Hi Matsuro,
We see that your transfers are successful now. The issue was probably that the first transfer was still pending, when the next one came in. In that case you get that error message. A solution is to wait until transaction is finalized before you proceed with the next one transaction.
Kind regards,
Emil, Concordium Support
@eb-concordium but the status of the transaction is "rejected", how could transfers of rejected transaction be successful?
concordium-client transaction status d7a8e12782c27cd34733f0e3c1aa941ecd0dab5ca1cecae7ead1a349a0786411Transaction is finalized into block 48102256af91684433df0b111f87b78f9b63a02b8bffb9667c4af8ee464fd093 with status "rejected" and cost 3.007000 GTU (30070 NRG).
Transaction rejected: the proof for the encrypted transfer doesn't validate.
Hi Matsuro,
We see that your transfers are successful now. The issue was probably that the first transfer was still pending, when the next one came in. In that case you get that error message. A solution is to wait until transaction is finalized before you proceed with the next one transaction.
Kind regards,
Emil, Concordium Support
It should be enough delay for previous transactions to be processed ( success/rejected ), I'm trying to push now with 5 minutes interval. Same issue now with unshield transactions, they mostly rejected. Push interval 5 minutes, same.
The trace you posted in the original message has
...
Warning: There is a pending transaction with nonce 274, but last committed one has 273.
This transaction will have nonce 275 and might hang if the pending transaction fails.
...
which indicates you were sending transactions too quickly. Unshielding has the same considerations as shielded transfers and they are not independent.
Can you describe in more detail what exactly you are doing? 5min should in almost all cases be plenty of time between transactions since average block times are 10s (unless your node has trouble keeping up with the chain). But if you are running a number of scripts in parallel (e.g., one that does shielded transfers, another that does unshielding) that could be a problem.
No user response; issue closed.
The trace you posted in the original message has
... Warning: There is a pending transaction with nonce 274, but last committed one has 273. This transaction will have nonce 275 and might hang if the pending transaction fails. ...which indicates you were sending transactions too quickly. Unshielding has the same considerations as shielded transfers and they are not independent.
Can you describe in more detail what exactly you are doing? 5min should in almost all cases be plenty of time between transactions since average block times are 10s (unless your node has trouble keeping up with the chain). But if you are running a number of scripts in parallel (e.g., one that does shielded transfers, another that does unshielding) that could be a problem.
And this is the problem, yes, is not one script is all in parallel. I believe even with this situation transactions should pass trough, Is really not to many of them even with my parallel deploys script. Personally consider this as issue, but you guys decide, maybe is a feature. Currently pushing in this frequency:
*/2 * * * * cd /home/concordium/T/ && bash simple.sh
*/2 * * * * cd /home/concordium/T/ && bash shielded.sh
*/2 * * * * cd /home/concordium/T/ && bash unshield.sh
*/2 * * * * cd /home/concordium/T/ && bash amount.sh
With that setup it is very unlikely that you would be reliably successful. Encrypted transfers and unshielding are unfortunately mutually dependent due to the nature of the cryptographic protocols that are used. Trying to do both in parallel without synchronization is just not going to work reliably.
I would recommend that you combine the shield, unshield, and amount scripts into a single one where you first shield, then do encrypted transfers, and then unshield the amount. The way the challenges are structured there should be plenty of time for the script to complete.
encrypted transfers
will try again your suggestion, but it was my previous was of pushing mix where it wuns functions in a sequence:
start_time && simple_tx
start_time && shield
start_time && shielded_amount
start_time && unshield
They was failing any way, first attment was to run evey 5 minutes where I get enough failed transaction which lead to failure in a challenge rules. Then I decide to run them faster like 2 minutes in hope all of them made it in to 5 minutes window. Still to many fails. Will do again now see if it helps. Thank you !
Update. Here is log of the full sequence where time of each even been calculated in seconds.
FULL SEQUENCE EXECUTION TIME: 1336.11 seconds which is 22 minutes. The longes halt happen on shielded transaction, took 613.52 seconds and unshield.
=====> SENDING SIMPLE TRANSACTION
spawn concordium-client --grpc-ip 127.0.0.01 --grpc-port 10000 transaction send-gtu --amount 0.1 --receiver 2xBEKSeitEmHXX6xQ7DikMcqacx1zGCWnPRzZyts75pZReqt1r --sender 4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q --no-confirm --no-wait
Using default energy amount of 59 NRG.
Sending 0.100000 GTU from '4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q' (PoSFreak) to '2xBEKSeitEmHXX6xQ7DikMcqacx1zGCWnPRzZyts75pZReqt1r'.
Allowing up to 59 NRG to be spent as transaction fee.
Transaction expires at Mon, 8 Feb 2021 16:20:02 UTC.
Warning: There is a pending transaction with nonce 17526, but. last committed one has 13402.
This transaction will have nonce 17527 and might hang if the pending transaction fails.
Enter password for signing key:
.Transaction '45d7fae5a9c3e8a6dd30add61ed9e3c2cba867374d76b035af59ff2e9f0a9414' sent to the baker.
---------------------------------------------------
0.98 seconds
---------------------------------------------------
=====> SENDING SHIELDED TRANSACTION ...
spawn concordium-client --grpc-ip 127.0.0.01 --grpc-port 10000 transaction send-gtu-encrypted --receiver 2xBEKSeitEmHXX6xQ7DikMcqacx1zGCWnPRzZyts75pZReqt1r --amount 0.1 --sender 4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q --no-confirm
Using default energy amount of 30070 NRG.
Enter password for decrypting the secret encryption key:
.....Transferring 0.100000 GTU from encrypted balance of account '4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q' (PoSFreak) to '2xBEKSeitEmHXX6xQ7DikMcqacx1zGCWnPRzZyts75pZReqt1r'.
Allowing up to 30070 NRG to be spent as transaction fee.
Transaction expires at Mon, 8 Feb 2021 16:20:03 UTC.
Warning: There is a pending transaction with nonce 17527, but last committed one has 13402.
This transaction will have nonce 17528 and might hang if the pending transaction fails.
Enter password for signing key:
Transaction '7c40bef6125f2d483eef4dc5eb6c7a89ddf510ea8b9a6f40fc88404edd72dac8' sent to the baker.
Waiting for the transaction to be committed and finalized.
You may skip this step by interrupting the command using Ctrl-C (pass flag '--no-wait' to do this by default).
The transaction will still get processed and may be queried using
'transaction status 7c40bef6125f2d483eef4dc5eb6c7a89ddf510ea8b9a6f40fc88404edd72dac8'.
[16:10:06] Waiting for the transaction to be committed...
Error: Transaction failed before it got committed. Most likely because it was invalid.
---------------------------------------------------
613.52 seconds
---------------------------------------------------
=====> FILLING UP SHIELDED VAULT BALANCE ...
spawn concordium-client --grpc-ip 127.0.0.01 --grpc-port 10000 account encrypt --amount 1 --sender 4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q --no-confirm --no-wait
Using default energy amount of 159 NRG.
Transferring 1.000000 GTU from public to encrypted balance of account '4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q' (PoSFreak).
Allowing up to 159 NRG to be spent as transaction fee.
Transaction expires at Mon, 8 Feb 2021 16:20:16 UTC.
Warning: There is a pending transaction with nonce 17528, but last committed one has 13402.
This transaction will have nonce 17529 and might hang if the pending transaction fails.
Enter password for signing key:
Transaction 'a38c7c8cc15af7405f034aaa59f8e43d99749fd1113ed81b974ab19a571a48e6' sent to the baker.
---------------------------------------------------
0.20 seconds
---------------------------------------------------
=====> UNSHILDING FROM VAULT ...
spawn concordium-client --grpc-ip 127.0.0.01 --grpc-port 10000 account decrypt --amount 1 --sender 4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q --no-confirm
Using default energy amount of 16065 NRG.
Enter password for decrypting the secret encryption key:
.......Transferring 1.000000 GTU from encrypted to public balance of account '4aY7Fbwmfswis7rdVLBrsk3VZFa8suRUcCPTBPfJ2gJacmNF9q' (PoSFreak).
Allowing up to 16065 NRG to be spent as transaction fee.
Transaction expires at Mon, 8 Feb 2021 16:20:17 UTC.
Warning: There is a pending transaction with nonce 17529, but last committed one has 13402.
This transaction will have nonce 17530 and might hang if the pending transaction fails.
Enter password for signing key:
Transaction '56b32e0f0f0484d2c9d74e95144a5f97fb87107decd25e266bdc03a110270329' sent to the baker.
Waiting for the transaction to be committed and finalized.
You may skip this step by interrupting the command using Ctrl-C (pass flag '--no-wait' to do this by default).
The transaction will still get processed and may be queried using
'transaction status 56b32e0f0f0484d2c9d74e95144a5f97fb87107decd25e266bdc03a110270329'.
[16:10:19] Waiting for the transaction to be committed...
Error: Transaction failed before it got committed. Most likely because it was invalid.
FULL SEQUENCE EXECUTION TIME: 1336.11 seconds
Update: Restarted baker, freed system from pending transactions. Now looks like they all pass trough in the right sequence. So it looks like everything clear more or less. Maybe it should be system which offload pending deploys periodically.
The node does regularly delete pending transactions although it does take some time to do that, and this depends on expiry time of transactions, among other things.