Blockchains with non-interactive transactions allow a attacking specific targets by injecting outputs in the target's wallet - a "cheap" variant that sends small values is known as a dusting attack. This is possible because the users only have control over the outgoing traffic from their wallet and have almost no control over the incoming traffic.
User sells something, confirms it wants to receive N coins. User waits to see it appears on the chain and in their wallet.
Pros:
- Solves the problem
- Simple solution
- Easy to reason about
- Easy to prove it's impossible to own outputs you didn't agree to
- Cross-wallet compatible
- Restore wallet compatible
Cons:
- Not a good experience - User needs to manually confirm. This can be annoying for some users and users are not used to doing this.
I personally see manual confirmation as a benefit and a natural way of doing things. When you pay in a store, if you pay with cash, then both the buyer and the seller manually confirm the trade by taking the money and agreeing. Similarly if you pay with a credit card, both parties confirm the amount and do the work to make it go through - it doesn't automatically happen to make your life easier. Both in this manual confirmation case and in the store case, you know what you buy/receive and you make your own fate consciously.
User sells something. User waits to see it appears on the chain and in their wallet.
Two solutions were proposed:
- Setting a threshold option that ignores amounts that are less than N coins - this is not a solution at all. If this were a solution, then adding some hashrate to ETC network would also "solve 51% attacks", but we all know it does not, it only makes them more expensive.
- If the wallet sees a new output, the user needs to decide to accept or ignore the output - this is an actual solution.
Below is my view of the solution mentioned in the 2nd point.
Pros:
- Solves the problem
Cons:
- Very messy - It's messy because it requires multiple actions for the same output (multiple wallets/restore) and because it doesn't happen when we naturally would expect it to. If you login to your wallet after 1 week or 6 months and see an output that you need to mark, will you actually remember what it was about if it has some generic value e.g. 10 coins? Probably not. Not just that, you can have multiple such outputs infront of you and you're now confused because maybe you accepted them in the other wallet you have (or had and your phone that died 2 months ago).
- Harder to reason about due to the messiness - this follows from 1.
- Cross-wallet problems because you need to mark the outputs on every wallet - it comes from the fact that a mobile and desktop wallet don't communicate.
- Wallet restore requires you to mark all the outputs again and it is impossible to distinguish an injected output with 10 coins from an output you expected - we probably agree on this
- Not a good experience - Seeing the outputs after checking your wallet after half a year and having to make a choice for months ago isn't really a good solution and I'd say it might be creating more problems than it attempts to solve in some cases.
If we go to a chain that has addresses e.g. Bitcoin, I can't imagine this conversation when going over your outputs due to some regulations:
Q: "What about this one sir? it's your address and you didn't tell us you own these coins!"
A: "Oh yes, but I marked these as 'ignore' in my wallet"
Own your outputs is the simplest model that can be made to solve output injections and it works with a single click on the phone at the time you expect to make a trade. It's also impossible to say "it appeared in my wallet".
- Interactive txs introduce the ability for the receiver to check the value they're about to receive so I'm not sure why we're not taking advantage of this
- The slatepack could still be exchanged over Tor
- The user would get slatepack summary which they would confirm
- I think it might enable a stronger payment proof with a hash reference that can be checked against some document that was agreed on
- Easier to explain "signed" transactions when you have a 'sign/confirm' step and not auto-signing in the background. This is important for understanding the cancel option of any signed transactions that are pending - this is safe-cancel which seems like a necessary RFC when we have interactivity
- Bitcoin, Ethereum and others only control the outgoing traffic from the wallet, they have absolutely no control over incoming funds. We have an opportunity to control also the incoming traffic and take advantage of yet another unique property
- Consistent with RSR flow since this one can't be automated