See my (edited) reply in Replay Attacks and possible mitigations
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.
Look for which
relative_heightbitcoin blockchain has less than x% (for example x = 0.000001) of its transactions making it to the blockchain after that time. Call it
relative_maxin the grin protocol rules, but do the same algorithm as described in OP for uniqueness of all kernel with
When you see a kernel with
relative_heightwhich 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 + relative_cap.
This list will contain about
x/100 * total_number_of_kernels kernels.
x small enough according to your needs and the list will be very small with nice
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
I guess it’s time to produce a complete RFC of your solution, it’s rather painful to read all those forum posts.
What a cry baby you are.
As you want, you just won’t get anywhere with such behavior. But you don’t seem to understand it.
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.
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
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.
I indeed think having expiration is a nice usecase for users, as @david also pointed out in his post above.
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
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.
Don’t judge a person without full understanding of the situation. Just because you don’t agree, doesn’t mean that you’re right.
I wouldn’t say it better
I’ve described the PayJoin Replay Protection (it’s at the end). Feel free to give feedback on pros and cons.
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
I think this thread is a nice thing for people to refresh their memory about some of our prior conversations on payjoins
No, he doesn’t.
Here’s the exchange that just transpired on grincoin#general:
He says that prior transactions will become invalid and only 1 valid transaction will exist, no?
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
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.
Following DM discussions with someone and @david, I want to speak about potential DOS vectors introduced by the kernel uniqueness scheme and the tx expiry it requires if we put a cap at consensus level on the maximum relative_height accepted.
As it was mentioned by @Tromp and @david, a first fix to DOS would be that one would need to make validating nodes refuse all txs that are broadcasted and that are about to expire (it can happen if the two signers set signature_block_height equal to a block height of the past, typicall close to current_block_height - relative_max) so that those txs don’t make it to the mempool and don’t make node crash because mempool has too much tx. This is very important as nodes crashing could result in particualar in some miners being unable to mine and could hence diminish network security quite a lot, which is really bad.
This fix fully fixes DOS vector introduced by txs expiring when blocks are not full.
However there might be DOS vector introduced by tx expiring more difficult to fix if blocks are full and that the blockchain is heavily used.
The reason for that is that an attacker could broadcast many txs with low fees (but just sufficiently high to be accepted to the mempool) such that he fills up something like 90% of the mempool. Honest people doing honest txs will set their tx with normal fees and those txs could occupy the top 10% of the mempool.
With a bit of luck, the cost of the DOS attack when blocks are full will be very low for the attacker as most of his txs will end up being refused due to top 10% being accepted and attacker’s transactions expiring after the two weeks.
This is not guaranteed to be cheap, since if the blockchain sees less usage in the coming two weeks, then all the DOS txs will end up on the blockchain and the DOS cost would be basically the same as a blockchain which doesn’t use expiring txs, but if usage continues to be massive, then the attacker might be able to have most of his txs not making it to the blockchain resulting in a very low cost DOS attack, which is not good.
The fix for this might be a slightly more complex mempool management, but I dont know yet how to exactly do that. @david thinks it is possible, but my naive intuition says that I don’t know if it can be done really clean and cover all cases such that DOS threat model becomes essentially the same to that one of a blockchain without tx expiry.
Otherwise, there is a full fix, as specified in an earlier post, where one could still use my scheme to check kernel uniqueness quite efficiently without having expiring txs (for this, as I mentioned, you need to get rid of the max relative_height allowed and accept all relative heights, and treat onchain kernels that have a large relative_height due to having waited a long time before making it to the blockchain in a separate list, likely very small, while applying the same uniqueness algorithm allowed by the scheme for kernels with relative_height smaller than the given fixed threshold (set by wallet))