I’m not sure payment channels are really necessary for normal commerce like checking out at a convenience store. How long does it take for 0 confirmation or 1 confirmation?
Needless to say, slower transactions are fine for venmo type transactions. As long as the user doesn’t have to keep their screen open the whole time it’s doing its thing.
Grin has the lowest risk of loss of funds from all crypto I know because it is interactive. If you safely store your backup seed and use a properly secure password, there is less chance to lose funds compared to Venmo or any banking App. Banks can fall, Grin can only fall if some major mistake is made, like with the inflation bug. The chance of that ever happening again is very small.
Only downside is the need for grin to unlock your wallet to receive. Using a hardware wallet makes grin much more safe. I wish we had an oficially suported HW wallet
MimbleWimble is one single transaction, we can exchange outputs, like mwixnet did for fast txs maybe, privacy is must have for Grin, at usual blockchain POW is in the last place..
Then channels should be perfect solution for fast txs while we have no DAG or Blockchain with 1sec blocks, seems like cause memory is not fast enough yet.
Lightning is a bit riskier. Transaction channels work like a 2/2 multisig with both users having a revokation key. Quite similar to Grin on chain transaction, but in grin when both parties have signed and the transaction is broadcasted and appears online, its final. The difference with Grin is that the transaction directly appears on chain, making it final. In lightening, only when a channel is closed, all transactions are truly finalized and all parties receve their share on-chain. In the mean time, disputes can occur. Attacks are possible and your wallet (or watch towers) need to stay vigilant and setle any disputes within the dispute setlement time (normally 24 hours). Lets say someone does a DOS attack on your lightning node bringing it offline, funds in your channel can be stolen by the other party broadcasting an old state.
Also, if you lose your lightning node, regaining access to opened channels is hard. If you restore your wallet from seed, you do not automatically see opened channels. Lightning is therefore much more complex than Grin on chain transaction because your wallet has to mitigate all the potential attacks. Also there are privacy concerns with lightening, options to block or sensor transactions, centralization concerns etc. Hopefully all these challenges will be solved over time.
In this case, Grin is honestly just slightly better than Venmo because it offers privacy.
The slower speed is negligible when just sending money to friends because it can happen asynch.
There’s a slight UX annoyance compared to Venmo because of the round robin stuff that needs to happen to finalize transactions, but that can be turned into a benefit with a good UI (swipe to finalize / accept with a fun animation)
Combining something like this with grin slatepacks would give us static messaging addresses to send slatepacks too. Basically something equivalent to venmo / cash app addresses.
I love the idea of a Grin wallet being able to interact with what is essentially a decentralised username. People could use NIP-05 to create user-friendly aliases like myname@mydomain.com. Using Nostr also means that messages can be buffered for offline users, storing events until polled. We should focus hard on this.
Nostr is a generic protocol (not only for grin) that is super easy to spin up servers for
Addresses (pubkeys) remain separate from servers
Two aspects to this.
Combine nostr pubkey MDK messaging with Grin slatepack wallet. The messaging would really just be used for slatepacks and transaction history only. Maybe with little notes similar to Venmo / Cash app. Users can pay pubkeys in their address book.
Spin up nostr relay and let people pay your relay’s pubkey to get access to use the relay server. Self sustaining ecosystem.
Slatepack addresses ar an ed25519 public keys from the wallet that is bech32 encoded with grin added in front for human readability.
Nostrs npub key’s are bench32 encoded ed25519 public keys. So essentially you can already use your slate-pack address for Nostr (just remove grin from the front of the address to get you npub).
So what would actually be needed to create a Venmo App like experience:
Have a Nostr App that recognizes slates by them looking like BEGINSLATEPACK ... ENDSLATEPACK, clicking on them will open a certain App, e.g. Grim wallet?
Or should a NostR chat App be integrated in Grim wallet, like an extra tab?
Something else, if so, tell us?
I am still wondering about the downsides of carelessly sharing your slatepack address pub-key. E.g. if you use your npub address that uses the same pub-key as your slatepack address. Does this not make it easier for people, especially relays, to collect pubkeys from which they can derive grin slatepack addresses? Can this be used to attack or track Grin users, e.g. spamming them either on NostR or on Tor?
An alternative is to either generate a separate npub key and not use the same key as in a slate-pack address.
At the least I think we should only allow the use Nostr on Tor in such a case to avoid making it to easy to link slate-pack addresses to people’s IP.
Yeah I think this is the move for multiple reasons. Another reason is that you can generate a really readable short name from your npub (and that should definitely be separate from your grin slatepack address).
in terms of what to do, there’s a lot of routes to go. Lots of experimenting that we can do. If we literally just want Cash App though, we would primarily create a Grin wallet app then use MDK (MLS on Nostr) for ferrying slatepack transactions back and forth (and nothing else). So the “messaging” would only be slatepacks and some short message about what the transaction is for, not for arbitrary “hey what’s up?” messaging.
Yeah i think the slatepack address needs to be shared inside of an MLS encrypted message then.
The spam can be buffered in this Nostr layer. New messages to you get put in the “spam folder” by default. These spam messages might be sending you their slatepack address, but your address would only get shared after you also initiate contact. (This whole processes can be automated and wouldn’t need to be “real” messages like “hi hello”)
Probably it should go something like a) us drafting a product description and requirements for such a bounty, b) discussing this draft Bounty proposal, with the whole community, c) then putting an amount on it.
It sounds like something that we explicitly want to link to a wallet, e.g. Grim wallet. In such a case we should also specifically discuss it with the relevant developer, see if it meets their vision for the wallet.
