But for potntial kenel aggregation, it needs BLS signatures. Cannot do with Schnorr signatures as it needs interactivity to aggregate Schnorr signatures
And kernel aggregation closes the door to payment channels and atomic swaps
You could aggregate up until a certain time, the NRD window for example.
This might need a consensus change so there is a hurry. One grin dev seems to agree with Kurts preferred solution, so why would you suggest he is calling all of them dumb?
Which Grin dev is favorable to closing the door on kernel aggregation?
Donāt see why a consensus change should be done in a hurry 
Especially when it seems to be rather non consensual at the moment.
1 Like
Yeast suggested preventing replayed kernels at consensus level, which is what Kurt wants. It seems as if the major reasons against it is the performance hit on machines rather than whatever you are suggesting.
Just an average Jo opinion here, with limited technical knowledge, so I know my opinion does not have nor should have much weight in this discussion.
As a user I deffinetely do not want to ever be confronted with manually having to check if a transaction is replayed, it should indeed be:
Since Payment channels and as such NRD kernels are not in the immediate planning (at least as far as I know) and since the sum of all kernels is not that much data to hold
For now it sounds to me that not allowing duplicate kernels is the most pragmatic and simple solution to implement before the comming hard fork. More thought can be put in possible alternative solutions before hard fork 4.
I only partly get the aggregation of kernels, but I do know is that it should not be implemented for now if it would interfere with atomic swap since this is a much desired feature by many.
1 Like
There is no kernel aggregation because we donāt know how to do that - thereās no known way to aggregate Schnorr signatures non-interactively. What I mentioned above with summing the kernel commitments is merely something that would allow an even lighter full node, not something that is actually implemented (when I say kernel commitment here Iām talking about the excess curve points).
I encourage people to participate in the next meeting which will be on Tuesday Jun 23 @ 15:00 UTC in grincoin#dev channel on Keybase (meeting info here https://github.com/mimblewimble/grin-pm/issues/304).
It seems that replay attacks and mitigations are scheduled some time so we can debate about what are good options and why. I would definitely like to see a comparison of pros/cons of approaches. I definitely donāt think we should be sneaking a consensus change to disallow duplicate kernels (regular, not NRD) into hard fork 3, doing consensus changes fast isnāt a good idea imo
1 Like
Do you know about potential side effect consequences of duplicate NRD? Has someone given a serious look to it? Do we want to sneak in NRD fast? Do we think of our technical preferences here or do we think about long term user friendly ness and robustness? Antioch has said that Payment channel is not finalized. How do we know that replays will not have bad consequences on the usability of Payment channels or their robustness and does not even open for more attack vectors due to them being linked to additional complexity which is layer two solutions?
I fail to undersrtand why NRD kernels should be a sacred cow here, and why we go fast with them without any peer reviews from the broader community, and thus going against all grin principles of technological conservatism and robustness. I hope that someone could explain that so that people that still care about the direction of this coin outside of the council can understand
I donāt know about payment channels so I canāt speak about that. NRD kernels are a way to do relative locks which seems to be a prerequisite for a payment channel. Iām not sure itās fair to say āwithout any peer reviews from the broader communityā since the RFC was up for anyone to challenge for quite some time. I agree that probably less people than I would prefer actually read the proposal, but thatās likely a consequence of a relatively small dev community and centralized knowledge on these topics. Do you have any suggestion to improve this situation? Do you think it would make sense to pay some cryptographers (e.g. Poelstra) to review the idea?
Regarding the replay attacks and NRD, I agree that we should explicitly think how NRDs can be affected. I suggest you bring this up at the meeting where replay attacks are scheduled so that we see where we stand here and why they are possible/impossible 
I donāt blame the fact that the proposal was up for review for everyone. It indeed was and still is. But it is not because it was up for review that we can as a consequence just integrate it. Otherwise, your coin can integrate only non-reviewed changes and you forget about the conservatism. I was precisely trying to be fairā¦ to the claimed and revendicated Grin conservatismā¦ nothing elseā¦
Technical conservatism does not come for free.
It in particular requires serious review for any non trivial change. Thats how it is. And now that we have found the replay attacks, definitely more than ever.
1 Like
Payment channels are immune to replays because they use 2-of-2 outputs almost exclusively, and would require both participants cooperating in the replay.
2 Likes
Having two people cooperating or just be alone to do a replay attack is strictly the same threat model.
They have no-one to attack but themselves.
4 Likes
OK, I thought they had to cooperate to do damage to other people. In that case, that is cool then, except for the cases where they dont use 2-2 outputs. could you develop that case and detail how attacks, if any, would look like in that case?
I fail to see how the simple replays of transactions through copying nrd kernels and their signatures would be avoided compared to regular (non nrd) kenels
NRD kernels are designed for use in transactions with 2-of-2 inputs only.
I dont exactly know how modern bitcoin lightning would look or would be possible on top of grin.
But it seems as if it could be a problem for the case of payment routing or other entirely off-chain movement of grin (i.e. any scenario where direct on-chain payment channels arent created)
As far as my knowledge on LN goes , it always involves a on chain smart contract. In case of newer LN, multiple paths can be utilised to combinedly get enough funds for transfers, autopilot can automatically manage channels by opening and closing them, but the channels themselves and the on chain contracts with timelocks are actually the same. So asfar as I can think of there are no additional risk with more advanced uses of LN.
You do not need to open on-chain payment channels with every party you interact with, and also not the routing intermediaries. But I am not sure if these (or anything else people might try to do on layer 2) are susceptible to NRD replay attacks.