Planning: Post 5.0.0 wish list

Question

Planning: Post 5.0.0 wish list

lehnberg opened this issue 4 years ago · 15 comments

lehnberg commented 4 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

Answer 1 · 2021-01-12T16:00:37.000Z

atomic swaps
also multisig is on the list twice

Answer 2 · 2021-01-13T07:37:42.000Z

my letter to Santa:

improve compatibility with OSX mimblewimble/grin-wallet#554 and mimblewimble/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

Answer 3 · 2021-01-26T15:32:30.000Z

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

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

Answer 4 · 2021-01-26T15:57:45.000Z

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.

Answer 5 · 2021-01-26T16:35:19.000Z

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

Answer 6 · 2021-01-29T16:27:47.000Z

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

improvement of late locking

Answer 7 · 2021-01-30T04:52:39.000Z

investigate two step transaction(Eliminating finalize step)

Answer 8 · 2021-02-02T14:34:06.000Z

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

Answer 9 · 2021-04-13T15:50:05.000Z

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.

Answer 10 · 2021-05-18T01:55:36.000Z

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.

Answer 11 · 2021-05-26T16:47:44.000Z

Hello. When release?

Answer 12 · 2021-06-23T09:48:52.000Z

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?

Answer 13 · 2021-06-23T18:04:25.000Z

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

Answer 14 · 2021-08-12T16:03:47.000Z

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/

Answer 15 · 2021-11-17T08:41:16.000Z

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.