Looks like @antioch and @tromp are definitely not convinced by your proposal.
May be it’s time to move on or start coding.
I personally think we are not in a hurry of anything and we should take all the time needed to reach a global consensus on that particular subject.
Mably, it is fine to not agree to my proposal, I don’t do it for me. There is UX and security. Plus scalability.
If a better solution is found, believe or not I will be more than happy.
But spending weeks and months in keybase and on the forum to defend poor security and UX is something different than providing a solution. it is an attack on grin.
We absolutely are in a hurry to fix an attack that could allow theft of funds, especially considering that the last fork is approaching quickly, so if consensus changes are necessary, now is the time to do that.
Completely agree 
I guess you said it better than me
We don’t share the same vision of Grin.
In my point of view Grin is a very experimental projet that could definitely fail.
If Grin loses what makes it different from other bloated projects, it’s definitely doomed.
So I don’t want anything implemented without reaching a global consensus among developers before.
If you are in only for the quick bucks you better switch to Beam or the like, no need to corrupt Grin.
By the way, anyone is free to fork Grin, that could be a solution for those who think that Grin is being attacked.
Grin is pretty worthless at the moment, so we don’t risk much.
And you can still sweep your funds if you feel suspicious.
So definitely no need to hurry in my point of view.
I corrupt Grin by trying to help fixing the recently found vulnerabilities. Super logic!
bouhhhh (corrupting grin)
Nothing wrong with trying to help. I just don’t like enforcing things on others without consensus.
Let’s all try to acknowledge that we are on the same boat and we all want the best for Grin. Ideas what “best” is clearly differ, but attacking each other is not productive
I am not sure how security of ownership isnt of the upmost priorities. If this is what makes grin different then grin will die. People against a consensus change are not proposing definitive solutions, they are not proposing solutions that maintain security, privacy and UX. They launched a testnet coin to mainnet and gave themselves 4 opportunities to have the coin be reborn and both fix protocol mistakes as well as introduce new features. I dont believe that failing to secure ownership of funds is a rational way to engineer a blockchain and I do not believe that this major security flaw would exist if grin was wiser to delay launch or wise enough to take advantage of the fact that the preplanned hardforks are for the very reason to fix issues that should not exist in any rational blockchain design.
When you live in a glass house, dont throw stones. “Core gets veto rights” and “cool” sound familiar to you? You epiptomize what many have complained about the core. Your attitude is horrible and you have no interest in “team”, “community” or fairness.
You are right, may be Grin will die or never be successful.
If Grin is not ten times better than existing anonymous coins, Grin will not have a chance as it will lack the network effect Monero and the like already have.
Grin is extremly fragile at the moment, any wrong decision could definitely kill it.
We definitely need to reach a strong consensus before making any important changes.
EDIT: Do you guys realize that you have a pretty aggressive tone? I feel that it won’t help anything here.
You have been lurking and not participating to these important and so many discussions. which is totally fine.
But!
If me, and sometimes John were not here, the decision would have already be taken, a wallet fix.
I had to call out Antioch multiple times who ignored technical discussions and relayed at least two times fake information in council meeting.
Would a consil decision be a consensus decision, to take your term?
The truth is that it was a pain in the ass to maintain a debate on these security problems. All opinions are subjective but at some point ignoring ux at that point is super weird and very few people moved their asses to defend UX/ security those last few months
Just to clarify - I apologized to you directly on keybase regarding my “core gets veto rights” comment, which was in bad taste. You then accepted my apology in keybase. And then you come over into the forum and bring it up again, implying I am still at fault over this?
An apology is meaningless if it wasnt sincere. Your behavior makes the sincerity clear. You continue the poor behavior by another comment that adds nothing to the conversation (your smug “cool” comment directed at David) and continue the authoritative attitude that undermines team, community and fairness. You cherry picked the clear opinion comment of “non-starter” and refute productive and factual critiques with nothing more than “no” rather than provide substance, which is another example of your authoritative attitude.
The way I see it, swiping funds is not a bad solution. But what I do find an issue is that the arguments against kernels having an experation time, the monoticity, are not further discussed.
@antioch You mentioned Andrew Poelstra
was a strong supporter of monoticity, meaning transactions that pass the mempool check stay valid forever. And @antioch or @tromp mentioned there are some interesting use cases for kernels staying valid forever. Please tell us more so we can better understand your perspective since the cost of keeping a record of all kernels is in conflict with one of the main advantages of Grin, which is a blockchain that grows in size by UTX0’s and not by the amount of transactions that happened in the past, making Grin massively scalable. Since this is a major advantage of Grin, I think the community needs to hear more about why monoticity is given more weight. Not understanding behind this reasoning is what leads to some frustrations.
To me the lack of strong examples of why monoticity is so important for the councel makes me even wonder if enforcing unique kernels has another reason, e.g. covering up a fundamental flaw in Grin or something…
So again, please give some more concrete examples so we can understand better the weight given to monoticity by you and others in this discussion and why it trumps giving scalability priority?
I don’t believe tx monotonicity and scalability are mutually exclusive. I’m definitely not trying to prioritize anything over scalability here.
I would like to retain our current behavior in terms of storing kernels - i.e. not to add any additional requirements around storing kernels or indexing kernels. All nodes must validate all kernels during IBD but beyond that, some nodes could in theory discard historical kernels. Nodes only keep historical kernels to provide them to other nodes during IBD.
It sounds like maybe you think I am pushing for additional requirements around kernels? It’s the opposite - I don’t want to store or index them beyond what is absolutely necessary.
Tx monotonicity is around simplifying the mempool logic and avoiding spam, specifically transactions that may never actually be accepted on-chain. We can achieve this with the current kernel requirements.
I don’t think we need to verify kernel uniqueness. I think there are alternative approaches that we can take. And if we do not need to verify uniqueness we can avoid needing to index them.
Would mempool logic be too difficult to ensure the kernel was created within a particular time window? That seems simple.
Would spam be avoided if some time period was required to remain on the expiring kernel?
And for good reason!
In the future, we may augment (not replace) a long history of kernels with a concise zero knowledge proof of their validity, which would make Grin even more scalable for people who trust that technology.
I understand there are risks around consensus changes, but mempool complexity shouldn’t really be a deciding factor. Every mempool issue mentioned is trivially solvable.