https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018364.html
so that they could gain privacy benefits from increased use of payjoin.
6 Likes
Interactive txs also allow the possibility to make the output injection attacks (dust attacks) impossible which also improves the privacy.
3 Likes
This has been disproven over and over.
There are 2 ways interactive txs can combat dust attacks:
- Wallets are configured to not accept transactions with outputs below a certain amount.
- Users can be manually involved with each transaction and are responsible for not accepting transactions they deem “dust”
In a non-interactive scheme, the equivalent is:
- Exactly the same. Ignore all outputs below a certain dust amount (some bitcoin wallets already do this).
- Require users to manually mark transactions as safe ex-post facto.
The end result is the same. I know we’ve discussed this a number of times, yet that same claim continues to be made.
3 Likes
It’s definitely not the same end result. Putting a threshold isn’t really a solution, it’s an ugly hotfix to the problem that still persists. A threshold only makes the output injection attack more expensive, it doesn’t make it impossible. The only real solution to this problem is 2. Whether Bob confirming his signature is good or bad is another debate, but this is really the only solution because it’s the only one that actually solves the problem.
But I just explained the equivalent of (2) in non-interactive schemes.
1 Like
- is not a good solution because marks are not on chain which means that if i have 1k utxos i need to remark them all when i reinstall the wallet (on each device) and it’s also impossible to remark them correctly since you can have multiple utxos with the same amount, some of which you’ve marked as safe and some not, but you can’t really know which
1 Like
It’s not equivalent. One is the user deciding what outputs will be in his wallet, the other is others deciding what they will be, but having the user filter them out. You also need to redo all the filtering on a wallet restore. The difference is whether you fully control the existence of your outputs state (wallet) or not
Whether you think it’s a good solution or not is beside the point. I don’t think it’s a good solution to have to manually accept all payments, but that’s not the point of this dicussion.
@oryhp claimed, as he often does, that interactivity txs allow the possibility to make dust attacks impossible. But my claim is if you’re willing to inconvenience yourself to make that the case for interactive txs, you can also inconvenience yourself to make that the case for non-interactive txs as well. If restores are that big of a problem, just self-spend all approved outputs with some additional on-chain metadata.
Yes, each approach has different tradeoffs, but the point is that if you are claiming dusting attacks can be made impossible on interactive txs, then I’m claiming that they can also be made impossible on non-interactive txs.
This is nothing more than a disingenuous argument over semantics. If your wallet won’t let you spend an output unless manually approved, then for all practical purposes those unapproved coins are not part of your wallet.
1 Like
It is really is the same though. Only difference is when a user restores his wallet, such that the new wallet doesn’t know which outputs to ignored. But this too can be fixed easily, and the solution isn’t ugly; It’s quite elegant actually.
There are several things to like about interactive txs, but I’m convinced that dust attacks isn’t one of them.
2 Likes
I’m interested in hearing what would this look like. For example, say we have the case that vegycslol mentioned. How do you distinguish easily between your output that owns 10 coins and the output injection that owns 10 coins?
All I’m saying is that there cannot exist an output on the chain which you own and did not agree to. This is only possible to achieve with interactivity when the receiver fully confirms each output. We can make all kinds of wallet hacks to make the user not notice these outputs or whatever, but I simply don’t know how you’d get this property in a noninteractive setting.
I’ll stop my input on this topic here because we have derailed from the topic. I suggest we instead get on a new thread if we want to discuss this further.
It doesn’t matter if an output exists on chain. That’s not what’s important about preventing dust attacks. All that matters is that dust coins are not spent with non-dust outputs, which could reveal information about you or your tx history. By not spending them at all, we get the same privacy as your interactive solution.
The UX can be as simple as listing “pending” transactions, and them not showing up in your available balance until you accept or reject them. That’s no more of a hack than any other solution.
1 Like
That’s the part where we disagree imo. I claim that dusting attacks are not possible with interactivity and it’s impossible to prevent them in nitx (ignore the word dust which suggests a small amount because it can also be 1k grin, the point is that someone can inject something against your will and trace your txs)
I agree that a malicious actor can potentially harm a user’s privacy IF that user restored his wallet on a new environment AND IF the malicious actor is willing to send a material amount of coins.
But then it becomes not a dust attack but a highly targeted attack, which is contradictory to whole premise of a dust attack.
Once we go into targeted attack territory, there are many types of attacks which are as effective or more so, that a motivated actor can use.
By the way, you assume that users would decline 1,000 grins if sent their way out of the blue for no apparent reason. Only the most privacy-prudent users would deny that - and those users most likely already selectively spend their outputs.
1 Like
Have you used the previous http listener or the tor listener on your interactive wallet? You cant prevent dust in this setting. In fact, if you turn the listener off until you want to interact with someone you still couldnt stop it if someone sent you the dust while you were live. Are you asking for a file/text slatepack exclusive world?
I would most defenitely accept and then selectively use that output to make a donation to the Grin fund 
1 Like
Assuming the use of stealth addresses, change outputs could be sent to special change address that is never published. This way dust-change outputs can be easily distinguished from dust-attack outputs even after a wallet restore.
That’s an interesting idea. So this solves the change outputs. The receiving outputs are not solved with this technique, right?
The only way to permanently mark received dust outputs as safe for spending is to sweep them to
an address that is known not to contain unsafe outputs.
The same applies to interactive transactions in most cases unless you want to manually
confirm all incoming payments, which is simply not feasible if you are running a business.
1 Like