You’re probably already in communication with the other party then. If you want to initiate the slate sending, then you’d use bill-flow by doing request-bill.
If the other party initiates, they do request-payment.
Normally, it’s the receiver that specifies the amount , but (in the near future I expect) it will also be possible for the sender to specify them in their offer-payment step.
I disagree. IMO request-offer-accept is not only simpler, but more importantly, can be applied consistently across both flows.
@oryhp Great to know that under the hood they are the same, just a different procedure to build them.
Regarding 2 step transfers, I though @Kurt was having a sort of preliminary schema based on the many proposals from before. Of-course it needs a lot more screening so impossible to implement any time soon which is fine by me since I never had issues with interactive transfers.
My hope is that the mobile wallets resolve part of the complains about interactive transfer since they are always online.
Alternatively, we can end all confusion by calling them
receiver-sender-receiver (RSR) flow and
sender-receiver-sender (SRS) flow.
I’m not sure this ends the confusing since the steps 1. and 3. sound like the same step
I think this makes a lot of sense.
This suggests there may be an opportunity to make a clearer distinction between the tx building flow from the funds flow.
I prefer payment-flow and invoice-flow.
Edit, I like the RSR en SRS flow naming as well, very unambiguous. This naming is ideal for the naming of the procedure as a whole, for the steps themselves we still need the descriptive names such as *request-offer–accept
I think RSR and SRS don’t give enough info to what’s going on in each step (not technically but what’s the step for). Also when people will say “we are still on step sender” it’s ambiguous since there are 2 with the same name. I prefer request-payment over request-pay (sounds more clear to what’s going on). The request-bill is seems reasonable to me, i do agree that it can be a bit confusing though (since bill is related to invoice and that’s not the invoice flow).
That leaves a lot of confusion because request-payment,offer-payment,accept-payment is what we called invoice flow.
These are not names for the steps, but for the flows. The suggested step names are request-payment,offer-payment,accept-payment for RSR flow and request-bill,offer-bill,accept-bill for SRS flow.
One more naming convention I thought of.
Have a receive flow (aka RSR) consist of
start-receive
mid-receive
end-receive
and have a send flow (aka SRS) consist of
start-send
mid-send
end-send
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.
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.
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:
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.
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.
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?
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)
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.