Planning: Post 5.0.0 wish list

lehnberg commented 3 years ago

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 commented 3 years ago

atomic swaps also multisig is on the list twice

marekyggdrasil commented 3 years ago

my letter to Santa:

improve compatibility with OSX https://github.com/mimblewimble/grin-wallet/issues/554 and https://github.com/mimblewimble/grin-wallet/issues/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 commented 3 years ago

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

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

tromp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

https://github.com/mimblewimble/grin-pm/issues/388#issuecomment-769903682 if we dont discuss this on the https://github.com/mimblewimble/grin-pm/issues/388

improvement of late locking

xiaojay commented 3 years ago

investigate two step transaction(Eliminating finalize step)

phyro commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Hello. When release?

cekickafa commented 3 years ago

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 commented 3 years ago

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

marekyggdrasil commented 2 years ago

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 commented 2 years ago

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.

mimblewimble / grin-pm