Manual confirmation of an incoming transaction

[davidtavarez]

Rendered text.

This is a proposal to add a new feature to give users the ability to decline an incoming transaction.

Unresolved questions

• Could it be true the default value of the manual_confirmation configuration property?
• Will this could work for more than 2 participants?
• Can we replace the finalize command by the sign command?

[DavidBurkett]

This takes Grin in a direction most of us have been vocal against. Concept NACK.

[GeneFerneau]

While I get the motivation, and agree an option to enable this might be useful for some people, those people could also just turn off synchronous transactions (essentially what this RFC does anyway).

I agree with @DavidBurkett, concept NACK

The added comlpexity doesn't seem worth the payoff.

[phyro]

a direction most of us have been vocal against

I wouldn't say "most" were against. There were definitely less people for this a year ago when I first suggested this, but we've learned more about the tradeoffs it brings since then. This thread shows mostly positive feedback which is the latest discussion around this feature https://forum.grin.mw/t/lets-create-the-ultimate-grin-wallet-experience-grin-ux-ui/9092/

The added complexity

I see this concept as simplifying the current state rather than making it more complex. At the moment, we are mixing transaction logic with transport by doing If Tor -> auto-sign. The transport protocol/logic should have nothing to do with the signing of the transactions, it shouldn't even know what data it's transfering.

I'd also argue that the current flow is "inbetween" of noninteractive and interactive, and it takes advantage of neither of the two. It's not noninteractive because that seems impossible to do so you don't really get the main benefits noninteractivity would bring. At the same time, it tries to inhibit interactivity by forcing it to look like noninteractive transactions which also takes away the advantages interactivity could bring, specifically:

• memo commitment on a payment proof - this can be a hash of an actual real world invoice/contract
• control of incoming outputs - impossible on any other chain because the prerequisite for this is that noninteractive transactions must be impossible, which afaik is only true in MW
• output selection for payjoin transactions - receiver could pick inputs to contribute at step2 of SRS
• intuitive safe-cancel transaction - knowing you added a signature is a prerequisite to knowing when to cancel a tx
• ability for each party to contribute custom fees - sender and the receiver can each decide to bump the fees if they want

It's true that people could just use the non-Tor flow, but why not make this plain slatepack exchange use Tor as well? Tor is about transporting data from A to B which in our cases are Slatepacks. IMO, it would be nicer if we didn't assume transaction building logic based on the transport protocol.

I'll be brutally honest now. What bothers me most is that we don't use advantages of either noninteractivity or interactivity. On top of that, the current flow comes as very damaging to understanding safe-cancel of a transaction (it's fair to mention that this was impossible to know when it was implemented because Play attacks were not known back then). It sometimes feels that we're trying to be too much "just like Bitcoin". Grin has a completely different transacting model than Bitcoin, so trying to make it be like Bitcoin (which is what the current auto-sign tries to do) is going against the very interactive nature of Grin transactions which are a big part of what Grin is.

[davidtavarez]

The added comlpexity doesn't seem worth the payoff.

I believe I'm proposing the simplest and cleaner way to achieve manual transaction acceptance, and still this is a optional feature, disabled by default, therefore implementing this RFC won't hurt any users.

IMO, it would be nicer if we didn't assume transaction building logic based on the transport protocol.

I agree with that, matter in fact, assuming the transaction building logic and the transport protocol as an indivisible thing confuses the users more.

Benefits are clear. I the short term, we gain more control over our wallets, in the long term, we unleash very interesting possibilities that worth trying. I don't understand why we are not taking advantage of this.

This takes Grin in a direction most of us have been vocal against.

I fully support all efforts to make Grin easy to use, and at the same time I'm against of trying to fit Grin into the Bitcoin box. In my honest opinion, by shaping Grin to look and feel, and to mimic Bitcoin, we are undermining Grin's development, and I don't think we want to do that.

[pkariz]

While I get the motivation, and agree an option to enable this might be useful for some people, those people could also just turn off synchronous transactions (essentially what this RFC does anyway).

While it's true that you can manually accept/reject transactions this way, it's imo a very bad UX and it disincentivizes its usage

The added complexity doesn't seem worth the payoff.

RFC's suggestions can be split in 2 parts:

• manual confirmation setting, new api endpoints and a new decision based on the new api's responses
• restructuring of commands (possibly replace some commands with sign command, maybe all step2 and step3 commands, so pay, receive and finalize)

Only the first part is needed to support manual confirmations and my guess is that the required changes can reuse the existing parts so they probably shouldn't be that complex. The second part is just to make it more intuitive for new users - I believe it's confusing to users what finalize does, for example to me pay and receive suggests the transaction is done. The SRS step now looks like this:

1. grin-wallet send <args> (sender)
2. grin-wallet receive <args> (receiver)
3. grin-wallet finalize <args> (sender)

An improvement would imo be:

1. grin-wallet create send <args> (sender)
2. grin-wallet sign <args> (receiver)
3. grin-wallet sign <args> (sender) --> sign and post the transaction on the chain, same as the current finalize

To me the latter variant seems way easier to understand for new users and at the same time it teaches them when the signings occur. Although RSR is not globally accepted transaction flow it makes sense to note that the command flow is symmetrical, just different order of who runs which.
An even better way would imo be to structure them like this (to later move repost under tx subcommand etc):

1. grin-wallet tx create receive <args> (sender)
2. grin-wallet tx sign <args> (receiver)
3. grin-wallet tx sign <args> (sender) --> sign and post the transaction on the chain

I agree with @phyro that users will not understand safe cancel unless they understand when the signing happens. I also believe commitment to transaction contract can be very important - committing to a memo is one example, but users could also just write the content there if it's small.

[Anynomouss]

If manual confirmation is an opt-in, I am fully in favour of it.
Manual confirmation is not an important most users, nor should it, or will it be pushed upon normal user to use it. However, there are many future situations and use cases where manual confirmation will become important.
Below a few examples example, for one-time use addresses.

1. Once one-time use addresses are implemented, users might want to use these one-time use addresses in combination with manual confirmation. E.g. an exchange might manually, or via software, want to check if outputs in the transaction are in a taint database before accepting them.
2. A store might want to protect itself from a dust attack, hence manually confirm incoming transactions. One-time use addresses will alleviate the risk of (tainted-)dust attacks since an address will be only shared with one customer and a tor listener will be only temporarily. Still a store might want to use this option to have full control of what outputs are coming in.
3. A heavily privacy-oriented use might want this future. I already spoken to few. We should not make manual transaction signing default at the cost of average users, but there no reason to deny this option to user who want it.

• Regarding Safe cancel, I think there is a very pragmatic solution. Safe cancel should be default so a user does not even need to worry or understand why unless they want to.
The user can be shown a popup explaining that Safe cancel will send the coins to his own wallet and therefore incur a transaction fee. A link can be provided in the pop to a page with further explanation. In general, I think pop ups with explanation can be shown to users when hovering over a function, or possibly a link near each option to a page with further description of a parameter such as enabling manual confirmation.
• I agree that it is important that users understand when they sign a transaction. However, also here I think we should no force a user to become knowledgeable, I mean who know the inner workings of a bank transfer… you just trust it to work, I want grin to be the same. We can however trick user into intuitively understanding signing process by using a double check-mark system (see forum post). This is identical to Signal, Telegram, WhatsApp and matches the signing steps in grin perfectly.
• Regarding the naming, as I stated before I think it is important to use the word sign, I fully agree here with @phyro and @pkariz. I do however want to propose to also be explicit in using either ‘broadcast’ or ‘publish’ in the last transaction step, so:

1. grin-wallet tx create receive (sender)
2. grin-wallet tx sign (receiver)
3. grin-wallet tx sign-broadcast (sender) --> sign and post the transaction on the chain

It is important to change step 3 into sign-broadcast since this makes it clear when transaction is finished. This flow also works with Multisig much better since the user will automatically be shown 'sign-broadcast' if he is the last needed signature.
Anyhow, I think making a distinction in the last step is important, especially since I hear so many people saying that it is important to educate the user about what each step in the transaction process entails.

I also really look forward to the memo function, I think it can be used in many ways that we cannot fully predict yet, but it opens up a lot of use-cases.

[pkariz]

If manual confirmation is an opt-in, I am fully in favour of it.

If manual confirmation is an opt-in the average user will understand the signing exactly the same as he does now - he doesn't :)

Manual confirmation is not an important most users, nor should it, or will it be pushed upon normal user to use it.

I expect utxo blacklist to be a thing sooner or later and auto-receive would mean that the owner of a blacklisted utxo can screw up anyone he wants as long as he has his tor address (or knows victim's evil "friend" to share a slatepack with an unexpected content). Not having to manually confirm every transaction you get in such a system seems wrong to me if the system supports it easily and especially if the system supports invoices - so that the service provider (or seller) doesn't need to do anything manually. The only exception i see are donations since there can be many transactions in a short amount of time

• Safe cancel should be default so a user does not even need to worry or understand why unless they want to.

The problem is that the user needs to know when to click cancel and he won't know that if he doesn't understand the signing steps

• I agree that it is important that users understand when they sign a transaction. However, also here I think we should no force a user to become knowledgeable, I mean who know the inner workings of a bank transfer… you just trust it to work, I want grin to be the same.

Banks can revert some transactions or cover some losses, grin can't do that, so the users need to know how to safely use grin. I think the only thing the user must know is when he signed the transaction and what that means (he can still cancel it if he cancels it in time). That's basically the same as the contracts work in real world, so it should not be hard to teach them that

It is important to change step 3 into sign-broadcast since this makes it clear when transaction is finished.

I would not create a separate command or button for the last signature but rather notify the user what happened through the output. If the signature is the last one you get information that the transaction has been broadcasted, otherwise you get some other information

[Anynomouss]

If manual confirmation is an opt-in the average user will understand the signing exactly the same as he does now - he doesn't :)

Yes, and I think that is fine. we just have to make all default behavior and settings safe

The problem is that the user needs to know when to click cancel and he won't know that if he doesn't understand the signing steps

I agree with the problem, but not with the solution. The way I see it, all these things can be handled by the wallet itself. /Smart default behavior can protect a user from having to understanding anything. E.g. the wallet could show a popup to a user for all transactions that are pending and older than 1 month, warning the user that leaving them halve signed allows the receiver to still claim the coins (again thinking from a GUI wallet perspective). If you use the command line wallet I think the chance of a user being aware of the inner workings of Grin is much higher, but again I am in favor of not demanding technical knowledge or understanding at all from users. We can invite them to understand, and make it easy to find information, e.g. using information buttons near all settings, but it should also 'just work' like other coins, otherwise new-users will have little reason to adopt using grin.

I would not create a separate command or button for the last signature but rather notify the user what happened through the output. If the signature is the last one you get information that the transaction has been broadcasted, otherwise you get some other information

I am thinking from a GUI wallet perspective, in which case it would be best to automatically modify the wallet to show 'sign-broadcast' if it is the last signature. For grin-wallet I can imagine that using 'sign' for both steps might be better/simpler combined with maybe the wallet asking for verification the user wants to broadcast (Y/n).
-> Solution 1: I do think it is ok to make manual confirmation default, if committing to memo-field/document hash is in the transaction.
I mean you do not want users to 'sign' a contract without knowing they signed it. So yes, in that case it would be ok to default to manual confirmation. An added bonus of defaulting to manual-confirmation if a memo-is present, is that basically each party has the power to request the other party to manual confirm by including a memo in the transaction.
E.g. a store owner using RSR flow can simply add a memo field in which case the Sender will have to manually confirm.
-> Solution 2: Additionally, we could make this an parameter within the transaction, allowing the creator of the transaction as well as the other party to toggle manual confirmation for the other party. This would work for both SRS and RSR without the need of adding a memo field. The reason why I think this option might be best is because some users might find it undesirable to have to use the memo-field to toggle manual confirmation since it leaves a trace on the blockchain.

[pkariz]

I agree with the problem, but not with the solution. The way I see it, all these things can be handled by the wallet itself. /Smart default behavior can protect a user from having to understanding anything. E.g. the wallet could show a popup to a user for all transactions that are pending and older than 1 month, warning the user that leaving them halve signed allows the receiver to still claim the coins (again thinking from a GUI wallet perspective).

You can attack a person in 5 minutes, so you can't automatically prevent it. While it's true that for SRS the wallet could detect it (receiver's output is duplicated in another tx so it's blocking this one), you can't do that for RSR (the best you can do is explain that invoices can't fail if the receiver is not a bad actor)

-> Solution 1: I do think it is ok to make manual confirmation default, if committing to memo-field/document hash is in the transaction.

Manual confirmation must be required when you commit to a memo because otherwise if i know that you autoreceive transactions then i can create a memo where it says that I'm buying your house for 1 grin

-> Solution 2: Additionally, we could make this an parameter within the transaction, allowing the creator of the transaction as well as the other party to toggle manual confirmation for the other party. This would work for both SRS and RSR without the need of adding a memo field.

I think it's receiver's own choice whether he wants to manually confirm or not and the sender should have no say in it. If the sender creates a memo and receiver's wallet (or maybe even better an address) is set to autoreceive then it should reject it somehow. RSR must have manual confirmation otherwise the receiver could steal all of the sender's money

[marekyggdrasil]

I like the idea of not accepting transactions by default. This feature protects the receiver from potential trouble. Consider the following:

MW transactions are private and it would be hard (if not impossible) to find the sender. What if receiver wallet is a company and sender is an attacker who wants to cause trouble by anonymously sending some small amount of money. How the accounting would register and declare this payment? It is impossible to tell where it comes from and what is it for. I can imagine users might want to control who can send funds.

Another thing is, this is not possible with chains that have non-interactive transaction. It would be a thing other coins cannot do. Point for ツ!

[Anynomouss]

I think it's receiver's own choice whether he wants to manually confirm or not and the sender should have no say in it. If the sender creates a memo and receiver's wallet (or maybe even better an address) is set to auto-receive then it should reject it somehow. RSR must have manual confirmation otherwise the receiver could steal all of the sender's money

In my opinion it is better to present a transaction to a user when it requires manual confirmation than letting a transaction fail or be rejected.
I fully agree that manual confirmation is needed for RSR and for SRS+memo. As long as SRS without memo is automatically received I think we do not obstruct the average user from using Grin.

[tromp]

I support this option, allowing the user to embrace the interactivity inherent in MW. They can already do this by disallowing synchronous communication, but combining it with synchronous communication can make it nicer by removing the need to copy and paste slatepacks.

Please add a link the the payment proof RFC at the bottom.