Planning: Post 5.0.0 wish list

[lehnberg]

About

Non committing, list of ideas for things to work on in 2021.

Definitions

P1 - Critical / Must haves
P2 - Important
P3 - Fix if time

Wish list

P1

PIBD*
multi-sig*
Wallet backend improvements (SQL)
libsecp fork update
preventing chain corruption*
safe cancel*

P2

tor support for nodes*
light node*
testnet exchange / making it easier for exchange integrations
payjoins*
binaries for older systems, older GLIBC or build on low RAM machine < 300MB
invoice payment proofs*
hardware wallets*

P3

wallet view key*
one-time use slatepack addresses for wallet*
flyclient*
atomic swaps*
aggregators*
block archive node support*
improve compatibility with OSX
anchors*
bulletproofs+*
NRD activation*

*) requires RFC to be accepted

[jaspervdm]

atomic swaps
also multisig is on the list twice

[marekyggdrasil]

my letter to Santa:

• improve compatibility with OSX The Trust Settings Record was corrupted grin-wallet#554 and The invoice payment flow breaks with LibTx Error and LibWallet Error on OSX grin-wallet#560
• prepare binaries for older systems with older GLIBC or make it possible to build the wallet from source on low RAM machine < 300MB

[tromp]

testnet exchange (this could fall under "making it easier for exchange integrations")

https://forum.grin.mw/t/testnet-exchange

[tromp]

try avoid corrupting the chain DB when killing server. or allow for DB repair.
Having to resync from scratch is very painful and bad for the network.

[phyro]

light node (pruning node) is roughly described in this gist. It seems possible to prune everything but the MMR peaks for every MMR we have if we assume that output lookups are done through inclusion proofs. Has some open questions. The forum thread with discussion is in this thread

[MCM-Mike]

#388 (comment) if we dont discuss this on the #388

improvement of late locking

[xiaojay]

investigate two step transaction(Eliminating finalize step)

[phyro]

I would like to add that we probably want to get late locking and have a working RSR flow with a payment proof sooner rather than later. We have a single exchange (tradeogre) supporting slatepacks, so we could take this to our advantage and prioritize these. Let's get the simplest flow for the exchanges working asap.

This includes:

• No Tor (code/flow branching based on availability is an unnecessary complexity we add to them)
• RSR deposits (they should finalize to avoid any network hops and potential issues there)
• SRS withdrawals (same here)
• Think of all the possible cases that can happen (grin is different. Interactivity needs to be thought out well, but luckily, we only need to do that once)

RSR and SRS require late locking if we want it to be smooth for the exchange and RSR flow needs invoice payment proofs

[tromp]

we can add the formal prover / integrity checker discussed in

https://forum.grin.mw/t/investigation-formal-proofs-alternate-verifier-implementation/8712/10

to the list.

[marekyggdrasil]

A simple feature idea: add a wallet command that provides a plaintext slatepack secret key, it would be a CLI equivalent of get_slatepack_secret_key method from the owner API.

Motivation: If user wants to sign a message with ed25519 key matching the wallet address (and thus, prove ownership of the address) has to run owner API and go through the difficult process of initiating secure communication with it just to extract this key.

[ghost]

Hello. When release?

[cekickafa]

I would like to add that we probably want to get late locking and have a working RSR flow with a payment proof sooner rather than later. We have a single exchange (tradeogre) supporting slatepacks, so we could take this to our advantage and prioritize these. Let's get the simplest flow for the exchanges working asap.

This includes:

* No Tor (code/flow branching based on availability is an unnecessary complexity we add to them)

* RSR deposits (they should finalize to avoid any network hops and potential issues there)

* SRS withdrawals (same here)

* Think of all the possible cases that can happen (grin is different. Interactivity needs to be thought out well, but luckily, we only need to do that once)

RSR and SRS require late locking if we want it to be smooth for the exchange and RSR flow needs invoice payment proofs

is that off the table?

[phyro]

Not off the table, but we need people to think about this I guess

[marekyggdrasil]

It would be handy to be able to display slatepacks as QR codes in CLI

https://github.com/timvisee/qr2term-rs
https://docs.rs/qr2term/0.2.2/qr2term/

[ghost]

I would like to request that the recovery phrase when doing init -r can be passed by a command-line argument either directly or as a file, the same goes for slate packs when sending and receiving. the reason i would like this is that it will allow us to script wallet workflow, as currently everybody is using expect or pexpect which is a hack and requires a graphical terminal to be present else it doesn't work, leaving no way to interact with the main implementation if you are running code that has no access to a graphical terminal. https://forum.grin.mw/t/help-how-do-i-recover-a-wallet-programmatically-5-reward/9343/17

edit: this is also a really simple fix if there is somebody who wants to cherry-pick this one. Like I say I would do it myself but rust is alien to me.