I see. It’s still not clear to me how the user would understand anything from RSR (i assume he would have a choice to pick RSR or SRS when creating a tx). I think invoce-flow feels way more natural for most people. To me payment-flow and invoce-flow seem understandable, or start-invoce and start-payment (or change start with create) might be the buttons on my gui. That mid-X is less informative, we would understand it, non-technical people wouldn’t know what it’s about imo
To avoid regression, we could initially just add these as command aliases to grin-wallet. So we would have aliases
request-bill -> send
offer-bill -> receive
accept-bill -> finalize
for SRS/regular flow, and
request-payment -> invoice
offer-payment -> pay
accept-payment -> finalize
for RSR/invoice flow. Everything will keep working as is, but users have the option to start using a more consistent system of step names.
6 Likes
In the Tuesday meeting, some people wondered how users could relate to concepts like request, offer, accept in the two flows.
For Receiver initiated RSR flow, the typical scenario is an online order.
When you’re done filling up your shopping cart, you’re presented with payment options (request-payment), which you proceed to fill out (offer-payment), and the merchant confirms your order (accept-payment).
For Sender initiated SRS flow, the typical scenario is a dine-in restaurant.
As the meal concludes, you typically ask for the bill (request-bill)
The waiter prepares and brings you the bill (offer-bill) and after making sense of the amount, you pay the bill with cash or a card swipe (accept-bill).
While you may think of payments as just consisting of a send and receive, the send is nearly always preceded by the receiver expressing the amount they expect (donations/tips being one exception). By making this request explicit, we obtain a reasonable mapping to our 3 step protocol. It’s far from perfect, but it’s uniform across the flows and steps and should be easier to memorize with a little practice, with less risk of forgetting the 3rd step.
1 Like
Regarding Tromp’s naming proposal, I like that all 3 steps have identical names regardless whether it’s about SRS or RSR flow => request, offer, accept. The second part of the name suggest the direction of the money from the user perspective. What’s nice about this naming is that the offer step suggests that the transaction is not done (unlike our current 2nd step names). This is helpful to the user understanding that the flow is ongoing.
As I mentioned above, I like that it reuses step names across the flows and hints whether a next step exists.
I find it interesting that SRS and RSR flows are really similar, they’re just flipped around in some way. I’ll ignore the broadcasting of a transaction because it’s easier to focus only the transaction construction. Both SRS and RSR can be thought as:
- prepare a state transition description
- party A signs the state transition
- party B signs the state transition
After these 3 steps you have a valid state transition (transaction). So what is happening behind the scenes is that both parties need to sign off on some state transition (regardless of the flow). I do understand that people don’t think in terms of state transitions.
There’s another way to reuse names but in a different order depending on the flow (using the state transition steps above):
prepare-send -> send
sign-receive -> receive
sign-send -> finalize
prepare-receive -> invoice
sign-send -> pay
sign-receive -> finalize
I’m assuming here that the wallet would be able to identify which sign-send it is based on the transaction information.
The bad side of this is that it doesn’t hint to the user that there needs to be a signing order e.g. you can’t do a sign-send before sign-receive in SRS flow. I’m not arguing for this, I’m merely sharing another way to think about transaction building.
1 Like
Whatever you decide, I think the naming of the stages that follow the finalization step should be considered as part of the decision.
E.g.
offer -> agree -> broadcast -> confirm/reject
and
request -> agree -> broadcast -> confirm/reject
If you want to name the stage where the tx is finalized and awaiting broadcasting, then you have:
offer -> agree -> finalize (for broadcast) -> broadcast -> confirm/reject
and
request -> agree -> finalize (for broadcast) -> broadcast -> confirm/reject
I would argue that “receiving” grin is a process that only ends successfully after the transaction has been broadcast to the network and confirmed by the network. Therefore my personal taste would be to not use the word “receive” for a single step of a multi-step receiving process.
Imagine the confusion when someone says they haven’t received Grin, and it’s unclear whether that’s referring to an unfinalized transaction or to an earlier “receive” step not having happened.
If you’re “sending” funds to someone, it doesn’t make sense for “sending” to consist of a list of stages where one of those stages is called “send”. Otherwise I could have a transaction that has not finished being sent, yet has completed the “send” stage.
1 Like
I wonder how far we can push this?
The difference in the two flows is simply who initiates and what direction funds flow. And I suspect these become even more similar once payjoin is considered.
Once a partial slate is created then it simply becomes a matter of both parties signing in the correct order.
Does the wallet (and user) even need to care about naming of these three steps?
Is this potentially just -
* send (0/2)
* sign (1/2)
* sign (2/2)
* invoice (0/2)
* sign (1/2)
* sign (2/2)
I’m just thinking about how bitcoin multisig is implemented in electrum etc.
You have an unsigned tx (0/2), then partially signed (1/2), then fully signed (2/2) and it can be broadcast (in the case of 2-of-3 multisig for example).
Our wallet knows what state the tx slate is in and knows what needs to be performed (2nd signing step etc.) Maybe these don’t even need names? And the wallet command(s) are more generic?
3 Likes
I like this approach, best one so far.
Numbering the steps is about as straightforward as we can get with 3 step transactions.
I actually had twice sign step at first, but then I decided to change it to make it obvious whether it is a receive or send. But I suspect that we could indeed have a single sign command for both cases because as you mentioned, it can be derived from the “metadata”. This would however need to make sure that the user doesn’t do any unexpected “reverse signing” where they would expect a receive but really sign a send or something. I’m not good on the details here, but a single sign command if possible would also be an interesting choice imo.
The problem of unintuitive signing order is still around, but you have solved the confusion whether there is another step needed with the 1/2 and 2/2. If the reverse signing isn’t an issue, then I really like this. I think it is quite intuitive because it’s like a party proposing a contract of state transition and then both (or many) parties signing off on it. Perhaps even having the first one the same might be possible e.g.
transition subtract 5 // == send
sign
sign
Similarly, for receive you use
transition add 5
And then
alias send = transition subtract
alias receive = transition add
You wouldn’t really need the “add/subtract” subcommand but I described it this way because it’s easy to miss the difference between transition 5 and transition -5. Transition is probably not the best word though, maybe contract/offer would have been better e.g.
offer -d <grin_addr> +5 // send
// or similarly
offer -d <grin_addr> -5 // receive
But it would need to be clear that you offer the counter party to reduce their holdings for 5 in the receive case.
Edit: and yes, a bonus here is that a single sign command scales for multisigs with more participants as well (well, maybe the order becomes a bigger problem, not sure)
1 Like
I would also like to add that transaction cancel can then be thought as an unsign operation which comes at a cost. You can unsign the transaction right now (unspend in cancel rfc) or at the next transaction signing time (respend in cancel rfc)
Using a single “sign” command would be fine for working from the command line. However, for GUI wallet I think the RSR, SRS naming from @tromp would work best.
I appreciate the simplicity of @antioch signed steps, but I am not sure if non programmers would find the first step send (0/2) to be confusing, in which case using step numbers would be better. In all cases I think it will be important to clearly show to the user at which step number 1),2),3), or signing step
(0/2), (1/2), (2/2) the transaction is.
Hey Doc!
If it is not two late, my two cents! Lets make this easy…
- You PAY
- You get a RECEIPT (Print)
- You SIGN (Receipt)
Just like a credit/debit card transaction that most all of literate humanity is accustomed to doing. If there is a presentation by seller then it should be four steps.
- BILL (Offered/Presented)
- PAY
- RECEIPT
- SIGN
: )
4 Likes
i think offer → sign → sign is the simplest one where offer is either send/invoice (like @antioch mentioned) or some other words, the numbers (representing tx’s stage) help.4-step receiver-initiated steps confuse me quite a lot (we don’t have 4 steps so it’s hard for me to imagine how this would work in practice). The receipt signing is also confusing to me because in my country we never sign receipts 
1 Like
I’ve always thought it was simpler to just have 4 steps for invoices. Just have an invoice step that specifies amount and address, then perform the standard send.
And from a technical perspective, it’s so much simpler. There aren’t 2 different flows to worry about. It’s much more minimalistic 
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.