Completely agree with that. However I have always thought we want to reduce the number of steps and that we are willing to sacrifice some simplicity for better UX 
We do want better UX which can be done by reducing the number of steps for standard txs. But maintaining a whole separate flow for functionality that isn’t currently used by anyone just leads to a bunch of unnecessary code and complexity. You should try digging into the slate building logic in grin-wallet sometime just to see how much confusion invoice flows really add - all for a feature I’ve never once seen used.
Agree - it might make sense to reduce to only a single flow for this, esp as it’s not clear whether anyone is even using the invoice flow.
Shame we didn’t think of doing this prior when we still had hard forks, but I suppose it’s not hard fork dependent. We would need to see if we could gracefully handle the transition somehow without borking older version wallets in the process… 
1 Like
Both flows, SRS, and RSR have their place. The crucial difference is which party ends up completing and publishing the transaction, which gives them the advantage of knowing that any inputs they add will actually be spent, and knowing approximately when the transaction will be confirmed.
5 Likes
For both flows i was thinking about having 3 cmd max and avoid confusion.
Standard Transaction :
Send an amount
Request an amount
Finalize a transaction
invoice Transaction :
Request an amount
Send an amount
Finalize a transaction
Reallife example :
- when i send money, i need to know the receiver (address) and the amount to send. i can’t just send money without knowing the receiver.
- as a receiver i need to request that amount (slatepack) to accept it
Standard Transaction flow :
grin-wallet send -d grin1dhvv9mvarqwl6fderuxp3qgl6qpphvc9p4u24347ec0mvvg6342q4w6x5r 180grin-wallet requestgrin-wallet finalize
if send takes an address AND an amount → standard transaction
if request takes no args → standard transaction
Reallife example :
- when i’am selling something, i need to know the buyer (sender) and request him an amount.
- as a sender i need to send that amount (slatepack)
invoice Transaction flow :
grin-wallet request -d grin1dhvv9mvarqwl6fderuxp3qgl6qpphvc9p4u24347ec0mvvg6342q4w6x5r 180grin-wallet sendgrin-wallet finalize
if request takes an address AND an amount → invoice transaction
if send takes no args → invoice transaction
PS : this flow can be applied to exchanges @vegycslol
3 Likes
The word publish is very descriptive here for whoever is actually broadcasting the transaction.