4.0.0 Beta Testing Steps

[yeastplume]

General Notes

• The send and invoice should output/send V3 Slates by default before the hardfork, and V4 Slates / Slatepack Messages afterwards. To force the sending of V4/Slatepack, use the --v4 switch, e.g grin-wallet send --v4 etc
• Ensure your 4.0.0 wallet is connected to a 4.0.0 Node
• If running a 3.0.0 wallet, ensure it's connected to a 3.0.0 Node

3.0.0 Compatibility

• [x] Run the 4.0.0 on an untouched wallet data directory created with 3.0.0 or earlier, ensure all commands work info, txs, send, etc
• [x] Send via HTTP from a 4.0.0 wallet to a 3.0.0 wallet listening on HTTP
• [ ] Send via TOR from a 4.0.0 wallet to a 3.0.0 wallet listening on tor (you may have to fudge a bit here and run the grin-wallet address on the 3.0.0 wallet data to get its Slatepack Address)
• [x] Send via HTTP from a 3.0.0 wallet to a 4.0.0 wallet listening on HTTP
• [x] Send via TOR from a 3.1.2 wallet (earlier 3.1.x TOR sends are broken) to a 4.0.0 wallet listening on TOR
• [x] Send from a 4.0 wallet to a 3.0 wallet via file output. grin-wallet send -d <addr> will attempt to send to the 3.0 via TOR, then should output a V3 slate to a file if it can't be found. recieve into the 3.0 wallet then finalize in the 4.0 wallet, etc
• [x] Send from a 3.0 wallet to a 4.0 wallet via file, workflow should be identical to 3.0.0 send/receives etc
• [x] Test invoice workflow from a 4.0 wallet to a 3.0 wallet
• [x] Test invoice workflow from a 3.0 wallet to a 4.0 wallet
• Ensure wallet outputs V3 slates by default before floonet HF and V4 slates/slatepack afterwards
• [ ] All of the above sends with payment proofs

Slatepack workflow (all 4.0 to 4.0 wallets)

• USE --v4 to output Slatepack Messages pre-hardfork
• [x] Send from a 4.0 wallet to another 4.0 wallet via TOR
• [x] Send from a 4.0 wallet to another 4.0 wallet via HTTP
• [x] Send from one wallet to another without specifying an address (should be identical to the previous ile workflow, except you can cut/paste slates)
• [x] Invoice from one wallet to another without specifying address
• [x] Send from a 4.0 wallet to another via file (with or without address) start the sending wallet's TOR listener, then manually receive in the receiving wallet, ensure response is automatically posted back to sender.
• [x] Send an invoice to a wallet and start listener, other wallet should automatically post filled-in invoice if creator is listening
• [x] Test sends with or without payment proofs (destination address must be specified)
• When sending Slatepack Messages manually, permute beween reading from file -i or pasting them into the terminal
• [x] Mainnet testing of the above with small amounts
• Send a small amount to the exchange of your choice on a 4.0 wallet.
• [x] Test delayed finalizing (e.g finalize with the --nopost flag, then grin-wallet post)

New Owner API Functions (Should all be tested)

• [ ] get_slatepack_address
• [ ] get_slatepack_secret_key
• [ ] create_slatepack_message
• [ ] slate_from_slatepack_message
• [ ] decode_slatepack_message

Other

• Check help commands make sense for new Slatepack workflows
• [x] Use new grin-wallet unpack (beta.2) only command to view the contents of Slatepack Message (should also decrypt the payload if the message is intended for the wallet).

[lehnberg]

Some initial progress, with more to follow...

ID	Environment	Desc	Method	Proof?	Result
TW1	Linux Debian	send from 3.0.0 → 4.0.0	http	no	✅ PASS
TW2	Linux Debian	send from 3.0.0 → 4.0.0	Tor	no	✅ PASS
TW3	Linux Debian	send from 3.0.0 → 4.0.0	File	no	✅ PASS

[lehnberg]

Some further progress, with more to follow...

ID	Environment	Desc	Method	Proof?	Result
TW4	Linux Debian	invoice from 4.0.0 → 3.0.0	file	no	✅ PASS
TW5	Linux Debian	invoice from 3.0.0 → 4.0.0	file	no	✅ PASS
TW6	Linux Debian	send from 4.0.0 → 3.0.0	slatepack -d, output as file	no	✅ PASS

[lehnberg]

Additional progress...

ID	Environment	Desc	Method	Proof?	Result
TW7	Linux Debian	send from 4.0.0 → 3.1.2	Tor	no	❌ FAIL - not supported
TW8	Linux Debian	send from 4.0.0 → 3.0.0	http	no	✅ PASS
TW9	Linux Debian	send from 4.0.0 → 4.0.0	http	no	✅ PASS
TW10	Linux Debian	send from 4.0.0 → 4.0.0	Tor	no	✅ PASS
TW11	Linux Debian	send from 4.0.0 → 4.0.0	Tor	yes	✅ PASS
TW12	Linux Debian	send from 4.0.0 → 4.0.0	Slatepack no address	no	✅ PASS
TW13	Linux Debian	send from 4.0.0 → 4.0.0	Invoice	no	✅ PASS
TW14	Linux Debian	send from 4.0.0 → 4.0.0	Slatepack Tor	no	✅ PASS
TW15	Linux Debian	send from 4.0.0 → 4.0.0	Slatepack Tor	yes	✅ PASS
TW16	Linux Debian	Unpack command, unencrypted	-	-	✅ PASS
TW17	Linux Debian	Unpack command, encrypted	-	-	✅ PASS
TW18	Linux Debian	Unpack command, attempt to decrypt by unauthorized	-	-	✅ PASS
TW19	Linux Debian	Upgrade from 3.0.0 wallet → 4.0.0	-	-	✅ PASS
TW20	Linux Debian	v4.0 no address receive, with automatic response via Tor	slatepack	no	✅ PASS
TW21	Linux Debian	v4.0 invoice, with automatic response via Tor	slatepack	no	✅ PASS

[quentinlesceller]

Tested all new Owner API endpoints. Everything works!

Method	Chain	Environment	Method	Proof?	Result
get_slatepack_address	Floonet	macOS 10.15.5	-	-	✅ PASS
get_slatepack_address	Mainnet	macOS 10.15.5	-	-	✅ PASS
get_slatepack_secret_key	Floonet	macOS 10.15.5	-	-	✅ PASS
get_slatepack_secret_key	Mainnet	macOS 10.15.5	-	-	✅ PASS
create_slatepack_message	Floonet	macOS 10.15.5	-	-	✅ PASS
create_slatepack_message	Mainnet	macOS 10.15.5	-	-	✅ PASS
slate_from_slatepack_message	Floonet	macOS 10.15.5	-	-	✅ PASS
slate_from_slatepack_message	Mainnet	macOS 10.15.5	-	-	✅ PASS
decode_slatepack_message	Floonet	macOS 10.15.5	-	-	✅ PASS
decode_slatepack_message	Mainnet	macOS 10.15.5	-	-	✅ PASS

Comment on create_slatepack_messagemethod: The call will fail if:

• sender_index is null or non present. Considering the field is `Option' I find it strange.
• recipients is null or non present. That I can see the point but not sure if it is possible to add more flexibility here.