I noticed this in the last day or two.

I am no longer able to use azteccli [command] i.e. azteccli balance.

following error:

Setting up the SDK... !
Failed to close the connection: TypeError: Cannot read properties of undefined (reading 'destroy')
    Error: Version mismatch with rollup provider. Error: Rollup provider / SDK version mismatch. Hard refresh your browser or update SDK.

However, the following works fine.

./bin/run.cjs [command] i.e. ./bin/run.cjs balance

I'm assuming it's not recognizing the latest sdk version or perhaps there's something messed up with my local config?

azteccli withdraw 0.3 --time instant
Failed to close the connection: TypeError: Cannot read properties of undefined (reading 'destroy')
› Error: Unexpected arguments: --time, instant
› See more help with --help

I am running into an issue when I issue the azteccli conf command stating that conf is not a command. However, I did install the conf-cli and conf is found if I invoke it by itself from the cmd line. 

azteccli conf wallet metamask
› Error: command conf not found

conf from the cmd line results in no error.

Hi! I need help

I can't withdraw my money from Aztec!
My Wallet L1 0xF278AC8e97dd418A3ce13307Fa1b44Ff87a18F7c
My wallet L2 0x0c1669810741bbffd63d0b7e25d6c2a8b8d58ff3d89d683c8227e0984ec90b9619b53d464dd44c86bb4bf443e1c95085cc74d46e5a1fae45546b2622ff8edbea

I have not been able to withdraw my ETH from the Aztec network for more than a month. I repeat the withdrawal attempt at least 50 times every day! I'm very tired!

I tried to solve the problem using 30 different computers and devices, as well as about 15 different ways of accessing the Internet. Nothing helps me!

The whole problem is definitely on the side of Aztec!

I may have found a bug in the Aztec network. There are more than 1000 incoming transactions on my wallet. Perhaps the Aztec network is not capable of servicing such wallets.

I ask the Aztec team to help solve my problem, since I have not been able to collect my ETH for more than a month.

I've been experimenting with making something which requires me to calculate grumpkin addresses from a private key.

In order to check correctness I've been comparing against a key pair as generated using azteccli and could never get it to match. I ended up testing with a private key of 0000000000000000000000000000000000000000000000000000000000000001 using the accountKey flag to narrow down where the issue was (as we'd expect to get the grumpkin curve's generator as the public key) and found that I didn't get this from azteccli.

// expected (produced by my code)
0x00000000000000000000000000000000000000000000000000000000000000010000000000000002CF135E7506A45D632D270D45F1181294833FC48D823F272C
// actual (produced by azteccli)
0x01cb173c186c2980e47465852c42a81f6cad7ba529bf8db1eadc9975419b4922008ce53fd8aee2d3169c720ced4a7f2318835a6a5155aa89257269ca46e95324

It looks like the issues stem from these lines where we take the CLI input and convert it to a buffer:

The problem is that Buffer.from by default takes the input as the utf8 encoding whereas we want the hex encoding. This means that rather than using the actual bytes of the private key, we're using the bytes of the string representation of the private key.

> Buffer.from("0000000000000000000000000000000000000000000000000000000000000001")
<Buffer 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 ... 14 more bytes>
// The bytes in the buffer don't match up with the hex string and the buffer is 64 bytes long so a 256 bit key has suddenly doubled in size. 

> Buffer.from("0000000000000000000000000000000000000000000000000000000000000001", "hex")
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01>
// This now matches the bytes in the hex string.

azteccli doesn't do any validation on the resulting buffer so we don't notice that the Buffer is the wrong length and just take the first 32 bytes and ignore the rest.

This also seems to be an issue when deriving your aztec keys from a metamask signature (but I haven't tested this flow against zk.money to test it).

Suggested fix

To fix this, we should change any instances of Buffer.from(x) to Buffer.from(x, "hex"). We should also trim any 0x prefix from the input as in this case we just get an empty buffer rather than throwing an error (we probably throw an error anyway when reading past the end of the buffer but it's not very user friendly). We can wrap this into a bufferFromHexString function which performs this validation.

To help catch these issues, it would be good if the sdk performed length checks on any buffers it receives to make sure they're of the expected length.

azteccli deposit 2.5 --asset dai --time instant
Setting up the SDK... done
Awaiting user signature... done
Error: Insufficient allowance. Call approve() first.