# Use of NRD kernels in Grin payment channels **URL:** \ **Category:** Development and Technical Discussion\ **Created:** [May 4, 2020, 12:00pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298 "2020-05-04T12:00:16Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [May 4, 2020, 12:00pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/1 "2020-05-04T12:00:16Z")
[https://lists.launchpad.net/mimblewimble/msg00636.html](https://lists.launchpad.net/mimblewimble/msg00636.html) ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [June 24, 2020, 11:11am UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/2 "2020-06-24T11:11:57Z")
My question is not directly related to the link above posted by Tromp, but more related to the rfc that @antioch did on NRD themselves, which is at: [https://github.com/mimblewimble/grin-rfcs/blob/master/text/0013-nrd-kernels.md](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0013-nrd-kernels.md) At some point in time, Antioch specifies that the message of the signature of NRD kernels should be of the form: `Hash(feature | fee | relative_height)`. (\*) It is specified that users should reuse kernels (duplicate) for new transactions for some mechanism specific to payment channels, and that this duplicate kernel will only be valid after `relative_height` blocks have been mined since the first occurrence. Discussion have occurred about enforcing unique kernels for grin, in order to fully avoid replay attacks and as a consequence make grin robust for the long term, as well as resistant to theft. What about adding a single bit to the message ? Instead of signing NRD with messages having the form of (\*) , we would sign with messages of the form: `Hash(feature | fee | relative_height | switch)`, where `switch` takes the value `0` at the first occurrence of the kernel, and `1` at the second occurrence of the kernel. That would allow to enforce kernel uniqueness for all kernels and avoid all problems due to replay attacks, including the ones that we may have not figured out. The scalability cost is negligible since normal kernels take around `100` bytes of data. If several instances of the NRD kernels need to be produced, switch would take the value `i-1` at the `i`-th instance, and also fixes the problem in that case, so that different kernels would be enforceable including for nrd kernels. Is there anything that would make preventing us from doing this? ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [June 25, 2020, 9:31am UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/3 "2020-06-25T09:31:34Z")
> [@Kurt](#): > > where `switch` takes the value `0` at the first occurrence of the kernel, and `1` at the second occurrence of the kernel. > [@Kurt](#): > > Is there anything that would make preventing us from doing this? The complication here is we do not necessarily know (in the general case) at _transaction creation time_ if this is the first or second instance of a given kernel on-chain. This also puts a requirement on all nodes to maintain a full index over all historical kernels to determine the `switch` value for each kernel to verify the signature. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [June 25, 2020, 9:59am UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/4 "2020-06-25T09:59:02Z")
I dont understand exactly the problem(s). 1. You are saying in the RFC: ”Each node should maintain 2 weeks of kernel history in the local NRD kernel index. This will cover the pathological case of a 1 week rewind and the validation of a 1 week long relative lock beyond that. The primary use case is for revocable payment channel close operations. We believe a 7 day period is more than sufficient for this.” So, what is the issue with including `switch` in the indexation for those two weeks. I understand that `relative_height` has a maximum of 2 weeks, correct? Pardon my ignorance if it is not the case 🙂 2. The value of `switch` is with each NRD kernel, on-chain. it takes 1 bit. I am quite keen to think and reflect on how exactly we could do a slight modification to ensure that NRD kernels work while not needing to have the same occurrences onchain. The advantage is pretty big. it would allow to provide the guarantee that GRIN is resistant to theft, instead of hoping and praying god that no harm happens through the replays attacks (which will definitely not happen if GRIN starts to have some success). ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [June 25, 2020, 10:29am UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/5 "2020-06-25T10:29:13Z")
> [@Kurt](#): > > If several instances of the NRD kernels need to be produced, switch would take the value `i-1` at the `i` -th instance, and also fixes the problem in that case, so that different kernels would be enforceable including for nrd kernels. How do you store the value for `i-1` in 1-bit? ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [June 25, 2020, 10:36am UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/6 "2020-06-25T10:36:27Z")
As I said in my original message: ”$$If$$ several instances of the NRD kernels need to be produced, switch would take the value `i-1` at the `i` -th instance, and also fixes the problem in that case, so that different kernels would be enforceable including for nrd kernels.” The If meaning that I do not know. I do not have the knowledge on how payment channels work. Alright then, it will take more than one bit. You can explain me how many times we allow to have those occurences? can we put a cap? If it is an infinite number of times that we need to allow, then 4 bytes allow you to count all the kernels for the next 100 years at full transaction capacity. 4 bytes is less than 5% of the size of regular kernels ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 9, 2020, 7:36pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/7 "2020-07-09T19:36:19Z")
@antioch , I’ll pass the previous trolling. “The secret associated with the adaptor signature is swapped to allow funds to be claimed while the relative lock locks funds prior to a refund being claimed. We note that NRD kernels and adaptor signatures are not directly compatible as a prior instance of an NRD kernel would have revealed the secret associated with the adaptor signature. That said we can produce transactions with multiple kernels and we can use this to isolate the adaptor signature on a separate kernel alongside an NRD kernel. It is an unresolved question if there is a way to modify the SAS protocol and avoid the need for these additional kernels in Grin/MW.” What is the problem here that is occurring exactly? Can’t the two same excesses have different signatures? Your proposal doesn’t seem to refer to replays in its description. Two kernels with same excesses and different signatures _do_ refer to each other. However, two identical kernels actually _don’t_ refer to each others, due to the possibility of replay. To be clear, kernels are identical if and only if they share same excesses and signatures. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 10, 2020, 1:25pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/8 "2020-07-10T13:25:28Z")
> [@Kurt](#): > > @antioch , I’ll pass the previous trolling. I’m not sure what this is in reference to? > [@Kurt](#): > > What is the problem here that is occurring exactly? Can’t the two same excesses have different signatures? Your proposal doesn’t seem to refer to replays in its description. Two kernels with the same excess can be exchanged for one another, even if the signatures differ. An adaptor signature would be trivially defeated. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 10, 2020, 1:54pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/9 "2020-07-10T13:54:28Z")
Do you mean here that we don’t commit to kernel’s signature? (I have no idea) Committing to them would come at no cost basically. Unlike adding more kernels as it seems you currently propose, which bloats the blockchain. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 10, 2020, 2:09pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/10 "2020-07-10T14:09:41Z")
> [@Kurt](#): > > Do you mean here that we don’t commit to kernel’s signature? (I have no idea) > > Committing to them would come at no cost basically. We commit to theses in the kernel MMR yes. Once a block is on-chain the kernels cannot be modified. But that does not prevent one kernel from being exchanged for another in a transaction. A transaction is simply a container of inputs/outputs/kernels (plus an offset). ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 10, 2020, 2:13pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/11 "2020-07-10T14:13:08Z")
I dont get what you mean by being “exchanged”. Once a signature is done, its done, and it cannot be re-done unless the _two_ parties agree to redo it. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 10, 2020, 2:23pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/12 "2020-07-10T14:23:26Z")
Both parties agree to build both NRD kernel instances ahead of time. They cannot use an adaptor signature on _both_ as one needs to be added on-chain (and requires a full signature). They cannot use an adaptor signature on only\_one\_ of these instances for reasons described above. Hence the need for an additional kernel - one for NRD, one for adaptor signature. ---
**Author:** ![Kurt](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/kurt/32/3361_2.png) [@Kurt](https://forum.grin.mw/u/Kurt)\ **Post date:** [July 10, 2020, 2:36pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/13 "2020-07-10T14:36:05Z")
Not so clear to me for now. Does one of the adaptor signatures should not be added on chain? Is “full signature” a normal signature (by opposition to an adptor signature)? Which reasons “described above”? I have not understand the “exchange” situation. If you’re OK we can discuss this more on keybase. I am interested to review more your proposal, but I need a bit of help since I have not worked on this topic during several months like you did. On top of that my proposal to verify kernel uniqueness has the side effect to allow to broadcast transactions ahead of time (arbitrarily) , which might be useful. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [July 10, 2020, 3:09pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/14 "2020-07-10T15:09:41Z")
Does the problem have to do with this: “We can think of settlement as being done in two equal halves, with 2 equal half-kernels, which is where the NRD kernels come in. In order to allow for revoking an attempted old settlement, there is a required delay between 2 instances of the same NRD kernel.” “say by Alice, she is free to change her blinding factor to any other while also changing the transaction’s kernel offset by the same amount, and redoing the rangeproof on her output (she’ll have to keep Bob’s default output as is)” [https://lists.launchpad.net/mimblewimble/msg00636.html](https://lists.launchpad.net/mimblewimble/msg00636.html) So is the problem that the kernel is not one one but existing in two parts? Anyhow, hard to grasp for me what exactly the problem is at least I would like to undertand the problem. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 10, 2020, 3:18pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/15 "2020-07-10T15:18:30Z")
> [@Kurt](#): > > Does one of the adaptor signatures should not be added on chain? Think of an adaptor signature as a full signature with a “piece” missing. This missing piece is the thing that must be revealed to complete the signature. It is not a full signature and cannot be accepted on-chain. A good overview of adaptor signatures - [scriptless-scripts](http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/) Also - [https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/](https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/) > [@Kurt](#): > > Is “full signature” a normal signature (by opposition to an adptor signature)? Yes exactly. Full signature - can be accepted on-chain as part of a kernel. Adaptor signature - missing a piece, not a valid signature. So if you have two kernels, one with a full valid signature and one with an adaptor signature then instead of revealing the missing piece, simply use the other signature. Which means you cannot do this safely. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [July 10, 2020, 3:22pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/16 "2020-07-10T15:22:09Z")
> [@antioch](#): > > So if you have two kernels, one with a full valid signature and one with an adaptor signature then instead of revealing the missing piece, simply use the other signature. Which means you cannot do this safel And this would not be safe because of this: "say by Alice, she is free to change her blinding factor to any other while also changing the transaction’s kernel offset by the same amount, and redoing the rangeproof on her output (she’ll have to keep Bob’s default output as is)”, So she can change the amoun, or is this not relevant to the issue at hand? ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [July 10, 2020, 3:33pm UTC](https://forum.grin.mw/t/use-of-nrd-kernels-in-grin-payment-channels/7298/17 "2020-07-10T15:33:14Z")
> [@Anynomous](#): > > So she can change the amoun, or is this not relevant to the issue at hand? Not directly related. The adaptor signature here allows a use case of “reveal the secret (the missing piece) in exchange for the funds in the tx”. If the adaptor signature can be trivially bypassed then the secret is worthless.