anoma / namada

Rust implementation of Namada, a Proof-of-Stake L1 for interchain asset-agnostic privacy
https://namada.net
GNU General Public License v3.0
2.39k stars 948 forks source link

Forced transfers exceeding balance are regarded as successful #2893

Closed Rigorously closed 1 month ago

Rigorously commented 6 months ago

A forced transfer with an amount exceeding balance and/or using a non-token address as token such as your implicit address will be rejected, however the transaction is deemed successful.

namadac transfer --source rigorous --target rigorous --token rigorous --amount 99999999 --force
Submitting a tx to reveal the public key for address tnam1qrqgs5e67esl3yjdq3dccls0470ctcm6m5kx4cal...
Enter your decryption password: 
Transaction added to mempool.
Wrapper transaction hash: FEFDA1B79C8C324CC8FEF94663B1F12BA8A478A061ADBAE04BFD8BFD6C38F262
Inner transaction hash: BD93013E23E86E0E0B1478747A1F95FCDA8F70770F51D7B5F067F1423FE86DEA
Wrapper transaction accepted at height 116693. Used 20 gas.
Waiting for inner transaction result...
Transaction was rejected by VPs: [
  "tnam1qrqgs5e67esl3yjdq3dccls0470ctcm6m5kx4cal"
].
Changed keys: [
  "#tnam1qrqgs5e67esl3yjdq3dccls0470ctcm6m5kx4cal/public_keys/data/00"
]
No balance found for the source tnam1qrqgs5e67esl3yjdq3dccls0470ctcm6m5kx4cal of token tnam1qrqgs5e67esl3yjdq3dccls0470ctcm6m5kx4cal
Transaction added to mempool.
Wrapper transaction hash: 8C47AB297BF5F2F3F4D0F76B34F60918A0D53A9ED91E4523E4F0351464F56733
Inner transaction hash: 8682B469E837603CFB3BD11D9D6EDF62D1261920FCC359DE11F7BA2C47396B86
Wrapper transaction accepted at height 116695. Used 24 gas.
Waiting for inner transaction result...
Transaction was successfully applied at height 116696. Used 3397 gas.

https://namascan.com/tx/8682B469E837603CFB3BD11D9D6EDF62D1261920FCC359DE11F7BA2C47396B86

image

image

quangtuyen88 commented 6 months ago

The weird is it's transfer txt but log print :

Submitting a tx to reveal the public key for address 
Fraccaman commented 6 months ago

isn't the transaction hash BD93013E23E86E0E0B1478747A1F95FCDA8F70770F51D7B5F067F1423FE86DEA ? but the namadascan urls points to a different hash (the reveal public key transaction, which was succesful indeed)

Rigorously commented 6 months ago

I did not explicitly execute reveal public key. It was done automatically by the transfer command with the inner transaction hash 8682B469E837603CFB3BD11D9D6EDF62D1261920FCC359DE11F7BA2C47396B86.

The Extended NEBB by Kintsugi shows that Reveal Pk failed, while the Transfer was successful.

image

Here is the transaction log of the automatic reveal public key on Namascan:

https://namascan.com/tx/BD93013E23E86E0E0B1478747A1F95FCDA8F70770F51D7B5F067F1423FE86DEA

image

And finally, on a tool I am working on, it shows a quite big sum of Naan sent and received with my account, after trying out how far I could push the transfer command (256-bit with a couple decimals).

image

Fraccaman commented 6 months ago

got it, we can look into this, thanks for opening an issue

opsecx commented 6 months ago

I wonder if this in reality is a Namadexer issue. The tools above draw their data from indexer afaik. (at least mine does - the tool Rigorous is working on)

Rigorously commented 6 months ago

I wonder if this in reality is a Namadexer issue. The tools above draw their data from indexer afaik. (at least mine does - the tool Rigorous is working on)

In the first post you can see that namadac also says that the automatic Submitting a tx to reveal the public key transaction was rejected, while the transfer transaction that comes after that was added to the mempool and successfully applied.

Rigorously commented 6 months ago

Opened a separate issue for the automatic Submitting a tx to reveal the public key when using --force. https://github.com/anoma/namada/issues/2919

cwgoes commented 1 month ago

Should no longer be an issue.