Play attack are due to valid transactions not making it to the blockchain while they should.
For a good coin, play attacks is always a problem to solve. it has to do with tx uncensorability, which also turns out to provide security (absence of play attacks).
The security model is that each valid tx should make it to the blockchain through good wallet implementation, good network propagation and good mempool management. solving play attacks by other methods that deals with the fact that a tx has been censored (not made it to the blockchain) is a big flaw.
The core of the issue is to make all valid tx make it to the blockchain. Sweeping outputs is not acceptable ux, it is not robust against wallet restore, and “limbo” state cannot even be insured if wallet is turned offline too soon and other edge cases. This is way too many problems and this can be solved cleanly and correctly by making a few simple rules.
Having the sender not checking its balance before doing a tx creates a problem and the rise of the possibility of a play attack (discussed on keybase), having the reciever knowing the partial offset of the sender creates its own set of problems too (play attack as well). So the question is simple: Do we want to stop having these wallet rules and instead do everything as fix using the limbo method? this is nonsense to me. We can fix everything that we have seen so far with simple and nice rules that provide robustness in security and good user experience as opposed to all the anxiety and such of sweeping coins, and the consequent issues with wallet restore. Grin is a coin, not an experiment in a private laboratory. And we should give the highest attention to users.
Finally replay attacks on the other hand can be all fixed by kernel uniqueness, with a simple and minimalist method which is scalable (see my proposal).
Wrong; they would be swept individually, separated in time.
One should design for simplicity, not for profit from situations that are unlikely to ever happen. The burning helps makes to make it even more unlikely.
No; not since last restore. Since the last time the wallet reported clean status (no outputs in limbo).
It does take those into account. Outputs created by e.g. child wallets appear in limbo, until the user declares them safe.
It still allows play attacks in a limited time window.
Watch towers don’t have the necessary keys, so this would be slightly awkward.
Sure; if you disqualify valid solutions for having worse UX, and ignore limited window attacks on expiring txs.
Prolonging available time to attack, but probably better.
I believe your work arounds are orders of magnitude less simple than unique kernels. Simplicity is ensuring only those with reasonable expectation to control UTXOs are with control, and no one else.
I disagree. I believe the inevitability of this happening is proportionate to adoption and value on chain. If grin is successful and this attack vector is left open, it will happen.
Having two wallets on two devices with the same seed is like a child wallet, I guess similar outcome maybe? The UX of marking UTXOs as safe by the end user does not seem reasonable if you hope for general adoption. “Just works” is simple and end-user friendly. Your suggestions will almost ensure adoption to general public will not occur imo.
Play attacks and replay attacks are almost entirely unrelated and are on separate threads. Play attacks arent attacks and you already proposed a solution that solves much of them, expiring slates solves the rest of them.
Maybe we need to support renegotiation keys or payment channels will require users to have their wallets online, the latter of which is already highly recommended…
None of them protect from future replay attacks that all wallets are vulnerable to because of previously spent outputs. No solution allows for all previously spent outputs to be accounted for upon restore or when multiple wallets exist simultaneously. All solutions only address current UTXOs and that doesnt solve the problem.
I am pretty sure bitcoin had prescribed behavior for RBF and both BRD and Ledger messed that up. I imagine I could find MANY more examples of wallets messing things up, but rather let’s just agree that you cannot protect users with wishful thinking that all 3rd party devs will do everything correctly.
If I had the same seed on my mobile wallet as desktop wallet and used one to spend, that is not in “limbo state” and treating it as such is incredibly annoying and a poor UX. There should be no “limbo state”, what is the most simple (and in agreement for industry) is for wallet balances to simply be accurate and that the wallet is in sole control of the balance.
No it doesnt, it accounts for current UTXOs under control of the wallet. Some time later, when the wallet thinks it has resolved everything, a new tx could come in in the form of a replay for an output spent long before the restore, and the wallet thinks everything is fine and wont detect that this is a replayed tx.
Just like some bitcoin wallets put users in danger, so will some 3rd party Grin wallets. But we can expect people to prefer wallets that follow the prescribed safety requirements, which will include all those listed on the recommended wallets page.
No, it will recognize it as an output it has not generated since its last restore and therefore put it in limbo, excluded from its balance.
The danger in grin is being allowed for reasons I’ve yet to see as logical. It seems as if part of the purpose for the planned hard forks is to leave room for new consensus change proposals and to rectify poor decisions. This is one of them. I dont see how you tout simplicity and want to make a horrible UX even worse and far less simple than the reasonable expectations that transcend the industry.
Also, ledger would certainly be a recommended wallet. In theory, no one knew they didnt follow RBF guidelines until someone checked.
Oh true, so then yes, my main complaints are what you said a few messages ago, about the poor UX, and that i feel like it’s inevitable that the vulnerability will be exploited, else grin wont become relevant. And I feel like it is unfortunate that something could be done about it in a way that is very simple and improves UX but some core members seem to prefer a much more complex solution that doesnt ensure security and makes the worst UX even worse.
You are going to literally make users pay (with fees) to solve a problem you choose not to solve in a much more robust and simple way and you are passing the buck of security onto the user, which is a horrible idea. Users dont update their OS or run antivirus or use different passwords across accounts and you want to pass off security of their funds onto them when a very simple solution exists.
This discussion sounds like there should only be one security implementation. Why not have some redundancy and implent both?
I heard many times before that we cannot think of all possible attacks right now, so having redundancy in security implementations is not a bad thing in my opinion.
Below my opinion roughly based on the arguments in this discussion. For both unique kernels and wallet sweeping there are very good arguments.
Offering the user to migrate UTXO’s for a secure wallet reset is defenitely feasible and if not enforced does not make for bad UX. In fact most wallets provide the option for key sweeping. Migrating funds over multiple blocks with random UTXO amounts will improved obfuscation and privacy while being low costs in transfer fees. Running the same wallet on multiple devices is not a problem. Child keys are always under control of the parent key and migration of UTXO’s on one device will simply be seen as new transactions on the other device. In other words, there is no reason not to implement it.
Implementing kernel uniqueness in the mempool for a certain time horizen as well as setting a max block time for transactions to be signed by both parties is very sensible but might take more time to implement than the wallet solution. Still, on the long it sounds to me like kernel uniqueness in the mempool is the way to go forward since it improves security with minimal costs and without any blockchain bloat. Again, the questiin should be, why not implement this?
In other words, if multiple implementations can be used to reduce known as well as unknown attack vectors while not having any negative effect on UX if implemented correctly, why not implement both? The questuin should not be which solution to pick, but which solution to prioritize so it can be implemented before the comming Hard Fork and which one to implement in the months after. In this case I think being pragmatic and taking into account the amount if work to implement each solution is key. Leaving the user in limbo on play and replay attacks is the worst scenario and should be avoided at all cost.
My suggestion is to shift the narrative of this discussion, start comparing implementation costs and discuss which ‘security measure’ to implement first.
@oryp What you say in general is true, however in this specific case I think there is little added complexity. Implementing the wallet solution is added security and is optional. Key swiping is offered in manny wallets so I think it is doubtfull this will open new attack vectors. Also implementing it is not that hard, so little added complecity.
Inplementing kernel uniqueness is a bit more complex, true, but it is leightweight and very sensible.
My opinion stays the sams, better to discuss priorities than keep this discussion and following inplementation in limbo. So far no one discusses practical matters like implementation costs and time.
This is not what is being proposed. We enforce kernel uniqueness in the mempool today.
The proposal is to enforce kernel uniqueness on-chain for a limited relative block height, 1 week for example. The big disadvantage of this is the introduction of “transaction expiry” where a once-valid transaction becomes invalid after a certain period of time.
Edit: To clarify - we enforce kernel uniqueness across the mempool currently, regardless of time window.
Bitcoin experts like Andrew Poelstra stress the importance of “tx monotonicity”, which is the property that once a tx passes initial mempool entry checks, it remains valid while its inputs are unspent.
I agree this is a nice property that simplifies thinking about tx processing. It makes it easier to manage the mempool.
It also prevents having to deal with certain unwanted complexities. Currently the tx fees protect against spamming of the network. For a tx to be broadcast worldwide, it cannot escape paying tx fees. But if you could publish txs that are about to expire, then the spammer reduces the odds of having to pay any fees (to nearly zero if they are a miner that just found a new block). This problem would be magnified once blocks fill up.
It’s also not clear what impact expiry height has on tx aggregation. Could a tx with a distant expiry get aggregated with another that has an imminent expiry and then get rejected, negating the issuers expectation? Or will we have to limit aggregation, harming privacy?
When in the distant future blocks fill up, tx expiry would be increasingly common, and it’s less clear how broadcasting resources will be covered by fees.
Then there’s the issue of what bitcoiners call “reorg-safety”.
In case of a medium size reorg, expiry risks losing transactions that just barely made it in the old branch. Particularly if the reorg mined empty blocks. Losing already confirmed transactions due an accidental reorg and not being able to replay them without having to reconstruct them from scratch could be a serious problem.
There are also interesting use cases that are incompatible with expiring txs, such as a one directional payment channel. This sets up of 2-of-2 output funded by one side, and then allows arbitrarily many offline payments to the other side, over an arbitrarily long time, which the other party can settle on-chain whenever they like.
And there may be others we haven’t thought of yet. Mandating tx expiry limits one’s design space.
Great to learn more about Grin. I did not know kernel uniqueness was already enforced! Regarding the Lightning nodes, I think the need for channel owners to be online is acceptable. But yes, this requires some more thought.
Personally I see the expiration as a feature, better have transactions with unreasonavle low transfer fees expired and funds made available again than leaving them in limbo. Basically if a transaction has not been prosessed in the time a user can remember the transaction (e.g. 2 weeks), having the transaction being auto cancelled makes for good UX. Just give the user a warning in the wallet his transaction expired because it exceeding the maximum transfer time.
Just thinking, it is also ok to keep enforcing kernel uniqueness without horizen as it is now, as long as users are warned after e.g. two weeks that their transaction has passed the two week transaction period, asking them if they want to sweep the funds, move the UTX0 to a new child key. In this way having funds in limbo is discouraged which already would greatly reduce the chance of replay attacks. I think that in 99% of the cases the user would not put his funds on purpose in limbo and would reclaim his funds when a warning is shown. Maybe replay does not need to be avoided completely, just reduced enough to protect unknowledgable users.
It has not been made clear to me why this is a disadvantage other than we would have to make a consensus change, which I agree that consensus changes should be taken very seriously. Could you elaborate on more reasons why this is a disadvantage? I think most of the wallet solutions have quite clear negative aspects.
You wouldnt say that to your bank who allowed for a possibility that someone steals your money. Plus my other examples are when devs were essentially forced to side with UX over security. Here we have the opportunity for hardened security AND better UX…