No, very clearly I would like this security risk to be nullified by a consensus change that ensures reasonable and rational expectations (that transcend the entire industry) are maintained.
But if this is not accomplished then yes, I would prefer if the wallet “attempted” to identify replay risks and give me full access to all funds available to my wallet and if I dont solve the security risk (which I find to be an unreasonable risk) then the balance should decrease if I am subjected to a replay attack.
You try to pay Bob, by signing for some outputs to be spent, but the tx fails to get broadcasted, and Bob is unresponsive. So you cancel the tx. And the amount re-appears in your balance.
Then some years later, after you had to restore your wallet, you suddenly see your balance decrease. You have no memory of the canceled tx to Bob. But Bob did remember…
Is that acceptable wallet behaviour?
Note this has nothing to do with re-plays, and can happen with kernel uniqueness.
I was under the impression that file slates, possibly all stale txs, expire after some time period. If that is not accurate that reflects the ignorance in my reply to this scenario. However, even if they never expire, this is no different than writing a check and the recipient choosing to deposit at a later date. It is entirely acceptable that your balance changes in this case. Everyone would love for an electronic wallet to be infallible but this is user error in my opinion, same case with checks, and nothing of concern.
Without having even looked at what exactly a kernel is it is hard to say what is best. But here goes. Roughly I agree with @tromp on the “sweeping” part, combined with rather pragmatic wallet implementation.
I would propose upon restoring of a wallet to offer the user the option (not enforce) to swipe all UTX0’s.
E.g. Message to show in the wallet:
"
Option 1) Restore Without sweeping funds
Option 2) Reset, sweep existing funds for safety to protect against replay attacks. If you were forced to reset you wallet under suspicious circumstances, we advice this option. Note this will automatically cancel any non-confirmed transactions and move your funds to a new single address in your wallet ".
In case of a BIP44 multi account wallet, the funds can be moved to the first following account (sweep funds from account 1 to account 2) for which the first child key has no funds associate to it. In case there are funds associate, move on to account 3 etc.
In this case the user has the option to play it safe, but lose a bit of privacy. At the same time, sweeping adresses is common for many wallets and therefore not that new or scarry to users.
I think it is enough to allow the user to protect against replay attacks without enforcing it using this or a similar pragmatic, non-consensus changing implementation. The prosed change I think agrees with most arguments given here and can be quickly implemented. More discussion might result in better solutions later on, but for now I think having a solution that works and is simple is better than going for consensus change such as enforcing tracking and uniqueness of kernels.
It is different. When you tell your wallet to cancel the tx, it has the ability to invalidate the tx by sweeping one of its inputs. Which would make its balance safe.
No way to ensure any future wallet implementations will protect users. We just say two of the most used and arguably reputable bitcoin wallets subjected to an implementation failure.
This is a huge privacy concern that links all of your UTXOs together. It also incentivizes an attacker to send replay txs to ensure that users link their UTXOs. This is a bad plan
Not to mention that it only protects your current UTXOs from replay, it doenst protect YOU from future replay attacks from all previously spent outputs. Again, a bad plan.
True, it can be solved at some additional costs, e.g. spreading the funds:
Option 1) Restore Without sweeping funds
Option 2) Reset, sweep existing funds for safety to protect ahains replay attacks. If you were forced to reset you wallet under suspicious circumstances, we advice this option. Note this will automatically cancel any non-confirmed transactions and move your funds to a new single address in your wallet
3) Sweep funds and transfer to a specified number of new addresses, enter number of new adresses the funds will be randomly distributed over them"
The only propblem is that it would add more complexity for both the user and the implementation. Further I do not know if emptying all funds at once, so in the same block, can be used to identify/cluster them.
The solution of sweeping funds can also be used in combination with giving slates an expiration date, e.g. 24-48 hours. To me this sounds as practical and sensible part of the solution but in the end it is all about finding the best balance between: security, privacy, user-experience and simplicity to implement.
Parent wallet will always have control and replay would still be valid, right? Maybe not, but yeah you could also create a new wallet and spend there but again a major privacy hit with consolidation and/or unacceptable UX
Yes, all children keys are provibly owned by the parrent, so you can auto accept any transaction between any children since it is all happening inside the wallet. Also no need for a new mnemonic seed since all children keys can be regenerated easily, so funds never leave the wallet, just migrating between children keys.
Thinking about it, it is also realy easy to implement, it is just using the full functionality on an BIP44 HD wallet. The derivation of children keys is standardized, a few lines of codes and takes only 1 or a few seconds on a PC. Also always good to follow BIP standards, BIP44 is a cross crypto currency standart:
m / purpose’ / coin_type’ / account’ / change / address_index which gives say a value of m/44’/60’/0’/0
60 should be replaced with the coin number of Grin. Only the random distribution part for the coins to be sweeped would be unique for Grin.
In theory this could be used for money laundering e.g. I have a business with many customers for high prices, I recreate their outputs and mine the blocks to pick up the fee rewards (I’ve heard something like this happened on some chains).
We also have to be careful with burning things as wallet implementations could have a ‘history bug’ or similar and we wouldn’t want to burn all the outputs in this case.
Perhaps the most straightforward and non-aggressive option would be to tell the user when the output was spent along with showing the payment proof (if possible) and give them a choice to burn/sweep or ask again later or something.
Edit: actually I think the money laundering would be too hard to pull off. A wallet implementation mistake is still dangerous though
Since this topic has gone kind of stale, I would like to summarize what I think are two of the issues. All of the proposed solutions would require that all future wallet implementations take the recommended precautions, they dont ensure security.
Current UTXOs are possibly susceptible to replay attack
This can be addressed with a full wallet history.
** One solution is to sweep (or self spend) at risk UTXOs. This is a privacy concern by linking your UTXOs and opens the door for an attack that encourages users to link their UTXOs
** Another solution is to ignore these at risk UTXOs. This is effectively burning coins and preventing users from access to value that they otherwise have the potential to control
** A third solution is to spend as fees, which seems to discourage the attack, but still has users lose access to value they would otherwise have the potential to control.
One issue is how to identify these upon wallet restore or in the situation of multiple wallet instances running on the same seed
** Tromp suggested sweeping all outputs created since last restore. Again, bad UX, but also requires trust that the user knows when the last restore was. It also doesnt take into account that some users will have multiple instances running simultaneously, so D.O.A.
** Antioch suggested requesting the payment proof from the sender, which they may or may not provide. Poor UX and not trustless in that you cannot get the necessary information without someone else.
** Antioch suggested identifying at risk outputs by determining the block the UTXO originated and check all the kernels in the block for duplications. This will identify a lot of false positives but should not identify false negatives. Mediation solutions after positive identification above (none of which are satisfactory to me). The issue is that he suggests this index of kernels be discarded after restore, which would only protect the user from replay attacks on current UTXOs, but not prevent them from all previously spent outputs. That is a deal breaker.
All previously spent outputs are susceptible to replay attacks
This can be addressed with full wallet history, therefore cannot be addressed during restore or multiple wallet instances running concurrently.
No wallet-based solution has been provided for this fact. Makes all wallet-based solutions D.O.A.
Antiochs index solution could work if the index is never discarded, but it was suggested by himself that this would be too resource intensive.
There have been at least two consensus solutions provided. One by Kurt and one that is live on the beam blockchain that solve all of the issues trivially with minimal impact on resources or usability of other features in blockchain. Today, Tromp suggested in the Mimblewimble Community telegram room that this would be a restriction on payment channels (which wont be needed for years), but beam’s solution for this is renegotiation of the payment channel. Renegotiation is an entirely reasonable solution as payment channels require constant monitoring anyway, so your wallet would have to be online to protect you from funds being stolen. If necessary, some kind of renegotiation powers could be provided to watch towers.
What is certainly not necessary is allowing the possibility that a wallet is not the sole entity in control of the UTXOs in its possession (referring to standard wallets, not multisig or other fancy wallets).
To date, there has been no solution provided that successfully provides security against replay attacks besides a consensus change as no solution addresses all previously spent outputs.
I’d just like to add a point of clarification here. This does not need to be trustless. Somebody claims they sent you funds (and they hope you cannot verify otherwise). You would be advised not to ship a widget out in return for those funds if they refuse to provide a payment proof.
a. They are not really your funds.
b. They are planning to “replay attack” and pull the funds back out of your wallet.
c. They are hoping you ship the widget out.
This I think brings up a key point here -
During a “replay attack” these are not your funds. There is nothing to be stolen.
At some point in the past you send me 1,000,000 grin.
I then subsequently send those 1,000,000 grin to Charlie.
You then initiate a “replay attack” -
By actually sending me another 1,000,000 grin.
And hoping I ship an expensive widget out in return.
And then replaying the send to Charlie.
This second instance of 1,000,000 grin are not mine. They cannot be stolen from me. The only thing that can occur during a “replay attack” is you convince me that they are mine and that I owe you something in return.
Grin values simplicity… Very simply, any UTXO your wallet has control of are your funds. Don’t complicate things by pretending otherwise
They may not be planning anything, it could be a result of a third party wallet implementation with no malicious intent. It is not fair to assume that all users understand the intricacies of what the wallet is doing or that all wallet implementations will behave as you hope.
Two more references to this false premise that I addressed above. It’s not reasonable to err on the side of simplicity until it’s not convenient to you, nor is it appropriate to change an expectation that is uniform across the industry: UTXOs your wallet has access to are yours.
In fact, replayable UTXOs are demonstrably and provably in the possession of the at risk wallet.
Play attacks are hardly attacks and are unrelated to replay attacks that can be mitigated by unique kernels. I believe that’s why Tromp created a new thread for them. Play “attacks” are akin to a check that wasn’t deposited and is not only easy to solve at the wallet level but a concept that it familiar in finance.
Replay attacks happen on chain and on chain is what matters. Play attacks do not happen on chain and are trivial to solve, Tromp already proposed a great solution
I do think it is valuable to consider both “play” and “replay” as variations on a similar theme though. If we can find a solution that solves these in a generic way then that might be preferable to attempting to solve for for specific instances.
There are 2 solutions, that I know of that solve outputs in limbo because the tx wasn’t broadcasted. One Tromp proposed in the play attack post. The other is @david one sided (non-interactive) transaction, so yet another compelling reason to support these. Otherwise, there is no way to prevent outputs in limbo because of unbroadcasted txs, it’s another negative side effect intrinsic to interaction.
There is no generic solution to solve both as they’re fundamentally different situations.