# Efficient solution to verify kernel uniqueness + better absolute timelocks
**URL:** https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526
**Category:** Development and Technical Discussion
**Created:** [July 9, 2020, 8:44pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526 "2020-07-09T20:44:08Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@david](https://forum.grin.mw/u/david)
#### Post date: [July 16, 2020, 8:58pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/41 "2020-07-16T20:58:43Z")
I don’t think anyone is advocating indexing all kernels. Only a week or so.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 16, 2020, 9:05pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/42 "2020-07-16T21:05:36Z")
> [@Anynomous](#):
>
> please give some more concrete examples so we can understand better the weight given to monoticity
See my (edited) reply in [Replay Attacks and possible mitigations - #115 by tromp](https://forum.grin.mw/t/replay-attacks-and-possible-mitigations/7415/115)
---
### Author:  [@Kurt](https://forum.grin.mw/u/Kurt)
#### Post date: [July 17, 2020, 5:38am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/43 "2020-07-17T05:38:15Z")
Fake news lol. security and reorgs don’t have any issue with this solution. It is trivial to verify the security as I did above.
It is trivial also to _keep_ transaction monoticity for the lovers of it.
1. Look for which `relative_height` bitcoin blockchain has less than x% (for example x = 0.000001) of its transactions making it to the blockchain _after_ that time. Call it `relative_cap`.
2. _Don’t_ enforce `relative_max` in the grin protocol rules, but do the same algorithm as described in OP for uniqueness of all kernel with `relative_height` lesser than `relative_cap`.
3. When you see a kernel with `relative_height` which is greater than `relative_cap`, treat it differently and keep it with you in a list. And check kernel uniqueness of this kernel against the kernels in that list and the ones that are in blocks between its `signature_block_height` and `signature_block_height + relative_cap`.
This list will contain about `x/100 * total_number_of_kernels` kernels.
Choose your `x` small enough according to your needs and the list will be very small with nice `relative_cap`.
This theoretically requires to keep all the kernels though. It may be an issue for nodes that want to prune kernels from their device. But uniqueness check is still very efficient.
I have personally not seen any problem with tx non-monoticity
---
### Author:  [@mably](https://forum.grin.mw/u/mably)
#### Post date: [July 17, 2020, 10:09am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/44 "2020-07-17T10:09:33Z")
I guess it’s time to produce a complete RFC of your solution, it’s rather painful to read all those forum posts.
---
### Author:  [@Kurt](https://forum.grin.mw/u/Kurt)
#### Post date: [July 17, 2020, 10:17am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/45 "2020-07-17T10:17:15Z")
What a cry baby you are.
---
### Author:  [@mably](https://forum.grin.mw/u/mably)
#### Post date: [July 17, 2020, 10:20am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/46 "2020-07-17T10:20:08Z")
As you want, you just won’t get anywhere with such behavior. But you don’t seem to understand it.
---
### Author:  [@Anynomous](https://forum.grin.mw/u/Anynomous)
#### Post date: [July 17, 2020, 10:39am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/47 "2020-07-17T10:39:11Z")
In an attempt to cut through the fog of all arguments and clear my own mind I tried to make an overview with the different Pro’s and Con’s of the curren system and the proposal by Kurt. Also I listed Fears and Solutions that I could find. I know the overview is subjective and might very well contain mistakes on my part. Feel free to provide feedback so we can make the overiew as objective as possible. In yellow I hightlighted what I think are the two main perceived bottlenecks.
The way I see it, both the current system which does not enforce kernel uniqueness and Kurt’s proposal have their own merits. It would not suprise me if in the end a compromise would be the best solutions. e.g. a) Including max\_block height in the slate for normal transactions since this is behaviour the user would expect, but allowing transactions without fiex max\_block height to allow for example one side closure of LN channels or other special use cases b) Adding a setting to wallets running a full node to enfore unique kernels or warne the user of duplicate transactions 3) using BIP44 of BIP88 for one seed for multiple wallets and optional key sweeping is a good idear in general.
---
### Author:  [@Kurt](https://forum.grin.mw/u/Kurt)
#### Post date: [July 17, 2020, 10:42am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/48 "2020-07-17T10:42:33Z")
Yes, why not do a mix of the two if we choose this solution and not enforcing uniqueness can be proven secure for kernels that are used for payment channels.
I don’t see yet why having a window could not help make LN more secure as Andrew Poelstra is explaining in the video
---
### Author:  [@Anynomous](https://forum.grin.mw/u/Anynomous)
#### Post date: [July 17, 2020, 10:45am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/49 "2020-07-17T10:45:10Z")
Exactly, a normal user wants transactions that can expire and does not want to think about replay etc.
Special usecases might exist and should be allow. Take the best of both worlds, this is also what Bitcoin does, e.g OP\_RETURN and not checking of P2SH to allow all kind of scripts, even invalid ones and special use cases like storing fingerprints, certificates etc on the blockchain. I think Grin should be similar in spirit, keep thinks simple, but that does not mean only one transaction type can exist.
---
### Author:  [@Kurt](https://forum.grin.mw/u/Kurt)
#### Post date: [July 17, 2020, 10:46am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/50 "2020-07-17T10:46:16Z")
I indeed think having expiration is a nice usecase for users, as @david also pointed out in his post above.
---
### Author:  [@oryhp](https://forum.grin.mw/u/oryhp)
#### Post date: [July 17, 2020, 10:56am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/51 "2020-07-17T10:56:18Z")
I’m also up for having the possible solutions/mitigations listed with pros and cons. I personally find it very hard to understand when there is too much information all around. An overview of each with honest pros and cons would make everything easier for everyone. I’m up for writing these for payjoin solution and can later contribute my views to others as well. We can start adding this to the google doc that @johndavies24 created and shared on keybase
> **[Grin Replay Document](https://docs.google.com/document/d/1BbXhgFd3byP_gfvnteRq4BmfXjtv5PJtJwI13CJsZT8/edit?usp=sharing)**
>
> Security Issue: Grin allows for kernels to be replayed, which allows for the possibility that, under certain circumstances, a given wallet has UTXO(s) that could be spent by a third party. Simple Circumstance: If Alice pays Bob X grin and Bob pays...
---
### Author:  [@johndavies24](https://forum.grin.mw/u/johndavies24)
#### Post date: [July 17, 2020, 11:18am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/52 "2020-07-17T11:18:36Z")
Nice, I would just note that allowing users to save available data isnt a meaningful privacy concern because adversaries can and will create custom solutions to save all of that data. You end up with a data disparity with those who have access to a wealth of data and everyone else who doesnt. Not only is your privacy compromised but if you need to use this data to protect yourself, for one reason or another, you cant. Meanwhile, your adversaries can use the data against you.
However, all solutions that change transaction graphs should be thought about thoroughly, because these could harm privacy in a manner that provides the adversary with data that they otherwise would not have, creating new privacy leaks and/or new ways to attack users to gain knowledge or force behavior that allows them to gain knowledge.
---
### Author:  [@quentinlesceller](https://forum.grin.mw/u/quentinlesceller)
#### Post date: [July 17, 2020, 12:42pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/53 "2020-07-17T12:42:52Z")
Thanks @johndavies24 @oryhp @Kurt @Anynomous I also find it very hard to follow and such document would be awesome!
---
### Author:  [@bluimes](https://forum.grin.mw/u/bluimes)
#### Post date: [July 17, 2020, 3:48pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/54 "2020-07-17T15:48:13Z")
Don’t judge a person without full understanding of the situation. Just because you don’t agree, doesn’t mean that you’re right.
---
### Author:  [@mably](https://forum.grin.mw/u/mably)
#### Post date: [July 17, 2020, 4:00pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/55 "2020-07-17T16:00:44Z")
I wouldn’t say it better 😉
---
### Author:  [@oryhp](https://forum.grin.mw/u/oryhp)
#### Post date: [July 17, 2020, 4:44pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/56 "2020-07-17T16:44:08Z")
I’ve described the PayJoin Replay Protection (it’s at the end). Feel free to give feedback on pros and cons.
> **[Grin Replay Document](https://docs.google.com/document/d/1BbXhgFd3byP_gfvnteRq4BmfXjtv5PJtJwI13CJsZT8/edit#)**
>
> Security Issue: Grin allows for kernels to be replayed, which allows for the possibility that, under certain circumstances, a given wallet has UTXO(s) that could be spent by a third party. Simple Circumstance: If Alice pays Bob X grin and Bob pays...
---
### Author:  [@Kurt](https://forum.grin.mw/u/Kurt)
#### Post date: [July 17, 2020, 7:49pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/57 "2020-07-17T19:49:30Z")
Thanks for the suggestion @quentinlesceller @johndavies24 @phyro, I’ve done a pdf doc on unique kernels but can’t import it here (support disabled).
It seems the support of pdf upload can be enabled in the site settings, in which case, I could upload it.
Edit: Thanks @johndavies24 who has uploaded it in Google doc and also the pdf version on keybase. Rocket Launchers are welcomed to modify pros and cons at will
---
### Author:  [@johndavies24](https://forum.grin.mw/u/johndavies24)
#### Post date: [July 17, 2020, 8:27pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/58 "2020-07-17T20:27:58Z")
I think this thread is a nice thing for people to refresh their memory about some of our prior conversations on payjoins
> [@PayJoin (P2EP) in Grin](https://forum.grin.mw/t/payjoin-p2ep-in-grin/7265):
>
> Say Alice wants to send 2 Grin to Bob. A simple transaction looks like the following. Alice spends a 5 Grin output, Bob receives 2 Grin and Alice receives 3 Grin in change. 5 Grin -\> 2 Grin 3 Grin Even with hidden values the structure leaks “direction” with one output presumably a “change” output. Alice has ownership of the spent output and the new change output and further analysis may reveal this shared ownership. If the change output is identified then the direction of flow o…
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 18, 2020, 10:28pm UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/59 "2020-07-18T22:28:57Z")
> [@Kurt](#):
>
> Andrew Poelstra is saying in this video below that things like my scheme of unique kernel verification can make LN more secure.
No, he doesn’t.
Here’s the exchange that just transpired on grincoin#general:
johndavies24
11:40 PM
He says that prior transactions will become invalid and only 1 valid transaction will exist, no?
tromp
11:41 PM
that is something quite different from expiry
all previous channel closes are always valid
so they add revocation mechanisms
this really has nothing to do with monotonicity
Andrew is the biggest proponent of monotonicity that I know of
---
### Author:  [@Kurt](https://forum.grin.mw/u/Kurt)
#### Post date: [July 19, 2020, 1:53am UTC](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526/60 "2020-07-19T01:53:35Z")
> [@tromp](#):
>
> Andrew is the biggest proponent of monotonicity that I know of
Would you have precise quotation(s) and source(s) of Andrew Poelstra talking about this?
I’ve googled the term (with Andrew’s name) and the only occurrence google returned to me in the first page of the results is a paper of him and Maxwell from 2014 called “Towards Unlinkable Bitcoin’s transactions”. Note the optimism in the title of the paper. I guess everyone can make mistakes, we are all humans, including Andrew.
In this paper ”monotone” or ”monotonicity” qualify a set of signers with some specific properties.
[Previous page](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526.md?page=2)
[Next page](https://forum.grin.mw/t/efficient-solution-to-verify-kernel-uniqueness-better-absolute-timelocks/7526.md?page=4)