I’m trying to be as honest as I can. I’m not sure the 2 points you enumerated are enough to capture everything because it is possible the receiver makes the original tx invalid in some cases I think.
I do agree that unique kernels (on chain) seem easier to reason about but, at least I, still can’t say I know the full implications of this. I’m having a hard time identifying what exactly even is a transaction on Grin (is it a kernel? Kernel + payment proof? Or maybe it includes also inputs and outputs? Etc.). The best we can do is try to challenge each other’s ideas and see where this leads us as we learn about some potential new cases along the way. I think we all agree it is very important to challenge all ideas
I did not mean you were dishonest. Sincere excuses. I just thought it was important to make it clear that they are separate issues, especially for people that are not familiar with the subjects.
I am pretty convinced that 1. and 2. (and 3., but this one is relative with malleability: verifying that a tx made it to a block has to be done without checking against the recipient’s outputs) are sufficient to allow that a tx will make it to a block, as expected, and that the sender will be able to take notice of it.
I am retiring of the debate. It’s been too long, and too much arguments for what I can handle. The situation kind of becomes absurd to my eyes, where some persons literally wipe away any blow in the UX without any problem, and sometimes at the cost of security as well.
Moreover, despite 3 months of passionate debates with technical arguments, and large rooms to participate, it seems that “authority” arguments without any technical foundation still make the most effect within certain members of the Counsil (see last meeting).
I am saying without animosity, just as facts that I observed, and I hope that Grin will find the best solution for its users, their experience, and their security.
Good point. So an output that you signed for to be spent should also be considered in limbo. Post adjusted to reflect this.
The clean status report is based on identified UTXOs, it will never know all the already spent outputs that pose a risk, it will never flag them during future attacks.
I appreciate unknowns of expiring kernels and unknowns of consensus changes, but I am much more concerned with knowns. To me, it seems as if replay attacks are inevitable if there is any adoption and value on chain. Nothing proposed yet besides a consensus change will fix this inevitable security risk.
I have wondered if mandatory payment proofs would solve this issue, I am not sure. I also dont understand reasons why payment proofs are not mandatory, but maybe reasons exist.
My bad, I read it with the wrong tone in mind! I hope you continue to challenge the solutions that are discussed, your input is invaluable 
if it feels too much, what helps me is to take a few days off and then come back.
I think both sides - pro consensus change, pro wallet change - are very passionate about the project and have different views. Don’t let that discourage you though, we might converge at the end, who knows 
The wallet already handles these, awaiting finalization. There is no concern about txs that are not on chain, they dont matter and they expire naturally or need to be cancelled. If you cancel early and they end up on chain, the wallet solves this as well.
There’s also a case where the sender sends all the input value to someone and hence have no outputs.
Edit: sorry misread your comment. My guess is you’re right.
Notice that this state of outputs is very similar to outputs that you previously spent. Or to outputs that you do not realize you may have previously spent, due to a wallet restore. That’s why I like to consider all of these in limbo. And it makes sense to treat them all uniformly.
They cannot be treated uniformly because they are inherently different, a UTXO awaiting finalization is not at all similar to a spent output that is already on chain. The former case would result in a wallet balance issue, but no risk of replay because no one’s wallet would ever reflect that tx as completed, the sender (or recipient in the case of invoice txs) are responsible for broadcasting and both parties are responsible for awaiting on chain confirmation. If the sender restores their wallet and tries to spend the UTXOs awaiting broadcast, then the recipient loses out, again no replay risk. If the sender restores and tries to spent the UTXOs while the broadcasted tx is in mempool then their new tx will get rejected, again no replay risk. The threat that non-broadcasted txs pose is negligible in comparison to the permanent risk of replay for previously spent outputs that are on chain, the threat they pose is already understood & expected, which is not the case for replay attacks.
It is quite similar. In both cases the wallet recognizes a utxo as its own, but without any further action from the wallet, this utxo can become spent on-chain.
The only distinction is that one is a play, and the other a re-play.
In neither case can the output be included in the wallet balance.
In both cases, the wallet may need to sweep the output to get it back into its balance.
1 Like
Feel free to replace burning by sweeping…
In one case the balance is considered “awaiting to be finalized” and in grin-wallet is not reflected in the bottom line (total balance) and cannot be used or spent in any way. The wallet simply marks as spent (or awaiting finalization on receiver end) to make sure it doesnt accidentally try to use them in a subsequent transaction. In the other case, it is on chain and can be used and spent.
This distinction is basically everything, the distinction reflects the entire purpose of the blockchain component.
On chain UTXOs that the wallet controls MUST be reflected in the wallet balance. The fact that it may have risk of being replayed does not change the reality that it is a real on-chain UTXO that the wallet currently could spend.
There is nothing to sweep and self spend for a UTXO that is in limbo because the tx was never broadcasted. The tx process will either expire naturally or you cancel it in your wallet so it knows it can spend it again (your restored wallet or wallet instance on another machine would have no issue spending it and not even know that it is in a tx that is awaiting broadcast. In the case of recipient the other wallet instance/restored wallet would never pretend this new UTXO exists so there is nothing to spend).
In the case of an on-chain UTXO that is at risk of replay, you dont “need” to self-spend, it is just a security solution at the expense of privacy and UX.
That is in complete agreement with what I said above.
The other case being a re-created utxo that the wallet spent in the past. Which cannot be safely used, as it is subject to replay of the former spend.
Now you’re just contradicting yourself.
The wallet should only include in its balance those outputs which it knows it has never signed for to be spent (for Grin as-is, without kernel uniqueness).
It can be safely used, not safely held
It must be swept in order to be under the wallet’s sole control.
So you would be happy to have the wallet include outputs that are not safely held in its balance? And then simply show a reduced balance the next time the user opens their wallet?
It isnt contradicting, the non-broadcasted tx essentially doesnt exist. The wallet just temporarily marks the UTXOs as spent to create a better UX.
The following statement must be true in a rational design:
All on-chain UTXOs that a wallet has access to must be reflected in the wallet balance.
The solution for this is to burn grin that a user would otherwise be able to use and increase their balance and value. I dont think a burn solution is a good solution. It also requires 100% accuracy of identifying all replayable UTXOs, both those that currently exist in the wallet and all future risks from all past spent outputs. There has yet to be any suggestions that would ensure that all past spent outputs will be identified 100% of the time as replayed, all of the suggested solutions have only addressed currently “controlled” UTXOs.