Likes - Activity - hungpq - Algorand
Overflow/underflow of []byte integer operations
A 128-byte string can be stored in scratchpad or in the global/local storage with key "", the empty key (since you have 128 bytes for both the key and the value together). You can also hash it, extract part of it, … or do more complex algorithms.
Inputs of the b+, b*, … operations are limited to 64 bytes. But outputs are not. So b* output may be 128 bytes. There is never an overflow. However, then you cannot use the 128-byte output in any of the b+, b*, … operations. See The Algorand Virtual Machine (AVM) and TEAL.
You can use the sandbox in dev mode: Also, if you are considering setting up a CI for your repo, maybe running unit-tests on each push or PR you could consider this sandbox DockerHub image in GitHub Actions, like in this example.
If its 64 bytes in hex, its 32 bytes raw. That’d be the pub key which you can just encode_address on. See the docs here: Encoding and Decoding - Algorand Developer Portal.
You can:
- use any of the standard dApp wallet (AlgoSigner, MyAlgoConnect, or WalletConnect).
- use kmd API which essentially allows you to do all the goal account ... commands and goal clerk sign related commands.
Yes I don’t think there is any way. The byte integer operations b+ and b* do not overflow. The result will just be larger than 64 bytes. b- fails on underflow. See Transaction Execution Approval Language (TEAL) for details.
The balance opcode includes pending rewards. The only place that matters where pending rewards are not included is for compounding.
The decimal value is purely for display. At the blockchain level, the only thing that matters is the number of base units without the decimal point.
Summary of important notes
- Rekeying is a way to change who is allowed to sign/authorize transactions from that account.
- The limits for log are detailed here: Up to 32 times, up to 1024 bytes.
- It is important to note differences between exp and expw.