With the current release of the app we had decided that the watermark shouldn't be read if it was never written in the first place.
This isn't an issue to say that this behavior is incorrect, but the tezos client when doing setup baker does a read of the watermark first, which in this case results in an error.
As the app aims to be compatible with current tool and ecosystem, we need to patch this, at least for the legacy API, so we allow this behavior
Initial report
Testing the baking app (with locally modified version of the client to display these packets)
```
./tezos-client -E https://granadanet.api.tez.ie setup ledger to bake for ledger://ironclad-labradoodle-shabby-zebu/bip25519/0h/0h --main-chain-id NetXz969SFaFn8k --main-hwm 643302
Warning:
This is NOT the Tezos Mainnet.
Do NOT use your fundraiser keys on this network.
Nov 2 22:11:40.338 - client.signer.socket: Found 1 Ledger(s) "(2c97, 1011)"
Nov 2 22:11:40.338 - client.signer.socket: Processing Ledger at path [3-3.4:1.0]
-> REQ 80 09 00 00 00
<- RAW PKT 01 01 05 00 00 00 0b 39 31 34 39 33 66 35 34 00
90 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
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<- RESP [Ok] 39 31 34 39 33 66 35 34 00
Nov 2 22:11:40.353 - client.signer.socket: Found a "Tezos Baking 3.0.0" application at [3-3.4:1.0] (git-description:
Nov 2 22:11:40.353 - client.signer.socket: "91493f54\000")
-> REQ 80 02 00 00 09 02 80 00 00 2c 80 00 06 c1
<- RAW PKT 01 01 05 00 00 00 24 21 02 88 48 68 b5 0b cc 7f
5b f6 2d 93 3c 74 8b 5e e4 18 8b e0 c3 0a 44 a3
f9 97 6e 95 2a b9 42 3a c2 90 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<- RESP [Ok] 21 02 88 48 68 b5 0b cc 7f 5b f6 2d 93 3c 74 8b
5e e4 18 8b e0 c3 0a 44 a3 f9 97 6e 95 2a b9 42
3a c2
-> REQ 80 0b 00 00 00
<- RAW PKT 01 01 05 00 00 00 02 64 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 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
<- RESP [Unknown status code 0x6400]
```
That error is because it wouldn't be valid reading a watermark from memory if a watermark was never written there in the first place. Allowing so would actually be unsound.
From the packets we can see the entire communication flow:
first the version is requested `-> REQ 80 09 00 00 00` , to which a good answer is returned,
then the public key is requested `-> REQ 80 02 00 00 09 02 80 00 00 2c 80 00 06 c1` (the details of the request are not important) and is checked with the URI provided
the next request is the problematic one: `-> REQ 80 0b 00 00 00` , which is a `Query_all_high_watermarks` , which is reading from our memory before any memory is written on it, which is what leads to the error
With the current release of the app we had decided that the watermark shouldn't be read if it was never written in the first place.
This isn't an issue to say that this behavior is incorrect, but the tezos client when doing setup baker does a read of the watermark first, which in this case results in an error.
As the app aims to be compatible with current tool and ecosystem, we need to patch this, at least for the legacy API, so we allow this behavior
Initial report
Testing the baking app (with locally modified version of the client to display these packets) ``` ./tezos-client -E https://granadanet.api.tez.ie setup ledger to bake for ledger://ironclad-labradoodle-shabby-zebu/bip25519/0h/0h --main-chain-id NetXz969SFaFn8k --main-hwm 643302 Warning: This is NOT the Tezos Mainnet. Do NOT use your fundraiser keys on this network. Nov 2 22:11:40.338 - client.signer.socket: Found 1 Ledger(s) "(2c97, 1011)" Nov 2 22:11:40.338 - client.signer.socket: Processing Ledger at path [3-3.4:1.0] -> REQ 80 09 00 00 00 <- RAW PKT 01 01 05 00 00 00 0b 39 31 34 39 33 66 35 34 00 90 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <- RESP [Ok] 39 31 34 39 33 66 35 34 00 Nov 2 22:11:40.353 - client.signer.socket: Found a "Tezos Baking 3.0.0" application at [3-3.4:1.0] (git-description: Nov 2 22:11:40.353 - client.signer.socket: "91493f54\000") -> REQ 80 02 00 00 09 02 80 00 00 2c 80 00 06 c1 <- RAW PKT 01 01 05 00 00 00 24 21 02 88 48 68 b5 0b cc 7f 5b f6 2d 93 3c 74 8b 5e e4 18 8b e0 c3 0a 44 a3 f9 97 6e 95 2a b9 42 3a c2 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <- RESP [Ok] 21 02 88 48 68 b5 0b cc 7f 5b f6 2d 93 3c 74 8b 5e e4 18 8b e0 c3 0a 44 a3 f9 97 6e 95 2a b9 42 3a c2 -> REQ 80 0b 00 00 00 <- RAW PKT 01 01 05 00 00 00 02 64 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 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 <- RESP [Unknown status code 0x6400] ``` That error is because it wouldn't be valid reading a watermark from memory if a watermark was never written there in the first place. Allowing so would actually be unsound. From the packets we can see the entire communication flow: first the version is requested `-> REQ 80 09 00 00 00` , to which a good answer is returned, then the public key is requested `-> REQ 80 02 00 00 09 02 80 00 00 2c 80 00 06 c1` (the details of the request are not important) and is checked with the URI provided the next request is the problematic one: `-> REQ 80 0b 00 00 00` , which is a `Query_all_high_watermarks` , which is reading from our memory before any memory is written on it, which is what leads to the error