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.