Efficient solution to verify kernel uniqueness + better absolute timelocks

Development and Technical Discussion
41

I don’t think anyone is advocating indexing all kernels. Only a week or so.

1 Like
42

See my (edited) reply in Replay Attacks and possible mitigations - #115 by tromp

43

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

1 Like
44

I guess it’s time to produce a complete RFC of your solution, it’s rather painful to read all those forum posts.

45

What a cry baby you are.

46

As you want, you just won’t get anywhere with such behavior. But you don’t seem to understand it.

47

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.

Transaction_expiration_or_noty
Transaction_expiration_or_noty4000×2250 398 KB

1 Like
48

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

2 Likes
49

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.

2 Likes
50

I indeed think having expiration is a nice usecase for users, as @david also pointed out in his post above.

51

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

3 Likes
52

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.

53

Thanks @johndavies24 @oryhp @Kurt @Anynomous I also find it very hard to follow and such document would be awesome!

54

Don’t judge a person without full understanding of the situation. Just because you don’t agree, doesn’t mean that you’re right.

5e1eaae57c6df538f9e2ef5762c2f7f4
5e1eaae57c6df538f9e2ef5762c2f7f4447×534 418 KB

1 Like
55

I wouldn’t say it better :wink:

56

I’ve described the PayJoin Replay Protection (it’s at the end). Feel free to give feedback on pros and cons.

57

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

58

I think this thread is a nice thing for people to refresh their memory about some of our prior conversations on payjoins

1 Like
59

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

1 Like
60

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.