So many wrongs here…
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.
Implementing multiple things increases complexity which makes it
- Harder to reason about
- More likely to create new security issues
@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.
Thanks for asking!
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.
I think @tromp states the reasons clearly around the desire for “tx monotonicity” here -
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…
Why is this important? Vast majority of users dont “think about tx processing” and I dont see why thinking about it matters more than practical aspects and the UX.
This is a good point, but could be fixed by having a rule for the min length of time tx would be valid.
Why cant these be renegotiated?
Ok, I’ll admit that Tromp and Antioch have seemed to cover the bases with wallet rules, from what I can tell. I think making the UX much worse is a really bad decision, one that will not affect Tromp & Antioch and is easier for them to make. I think this decision will hurt grin immensely and that it is imperative that the UX is improved rather than harmed. I think passing the buck on security to wallet devs and end users is a cop out and also a horrible mistake that will harm the adoption of the coin even more than the current obstacles. I hope you all sincerely consider the average user (which has no hope of using grin today) when you make such important decisions. Every user running the same seed on mobile as desktop will be forever annoyed by these horrible decisions. It is not simple to treat UTXOs your wallet has control of as anything other than yours, it is not simple that some might not be solely in your control and it is not simple to mark txs the user willfully and legitimately made as “in limbo” because of choosing a poor UX instead of hardened security
Like @johndavies24 I find the arguments given for enforcing a list of all kernels to be kept a bit abstract. I understand it from a ‘philisophical’ point of vieuw but I would like to hear more about concrete usecases to warent the burden of keeping all kernels stored forever. Payment channel renegotiation only for online wallets sounds like an acceptable price to pay.
Question: What would be the cost exactly in Gb’s for nodes to keep a record of all kernels?
However, I do find that migrating of funds would be a usefull feature to add to wallets, even if this might put a burden on wallet developers.
I’ll share an idea that I found interesting to think about. If creation of initial set
S is possible, it might prevent all replay attacks. I’m not saying this is a good idea to go with if it is indeed possible, but it is an interesting approach at least.
if ”A gives B” is the tx you want to replay, where A was a output that you owned, you can always and easily do ”Aprime gives B” for your replay, where Aprime is different from A, and you adjust your kernel offset.
The root cause of a replay is not the values of the outputs and if they are different or not but it is people being able to copy and paste a kernel.
So the only serious and non broken solution is to prevent people from copy paste them.
Wouldn’t this require the knowledge of blinding factor of
A (for which we assume in MW only the owners know)? meaning that only the real owner would be able to do that
yes it is true it would require knowledge of the blinding factor of A to do the replay with Aprime different from A
It’s not. What made you think that?
At the time of writing I thought this was the case since nodes keep a full record of all kernels, but I realise now this is for other reasons.