There has been “some honest technical discussion” though. The reduced security model issue was identified by antiochp / jaspervdm / tromp after a review on keybase. The rogue key attack, a critical exploit that would allow funds to be stolen, was discovered by tromp and another researcher independently. These were two previously unidentified issues that were picked up by other people reviewing your proposal.
If there ought to be more review, it would be encouraging to keep an accurate, up to date version of the proposal somewhere. Leaving a critical exploit unpatched more than a month is discouraging, and makes it look like the entire effort was abandoned, even if the fix is trivial as you say. Having a place where grin-specific reviewer feedback can be shared helps to bring everyone on the same page, where a comment from one reviewer might inspire another. Doesn’t need to be an RFC, even if that seems like an obvious option.
Comparing this with the armored slates / slatepack proposal does not do your idea justice. Slatepack has a much smaller impact and is also less complex, so was much easier for me to engage with. It obviously helps that it doesn’t raise any contentious, over arching questions of the project like “Should Grin be less secure than Bitcoin?”, or come with any other comparable trade-off. It’s an approach that feels simple and contained in comparison, with fewer “unknown unknowns” and risks for potentially catastrophic protocol failures.
It may well be that the worsened security model only leads to an attack that’s impractical, I would guess that depends on the motivation and resources of the attacker. Introducing the risk for such an attack weakens Grin’s security model nevertheless, and makes it strictly worse than that of Bitcoin, I don’t think this can be disputed. To “simply self-spend coins when you receive large amounts”, as you write in the LIP, seems like something that might be a bigger issue than having interactive transactions.
The changes to the security model were fleshed out on day 1, and the attack was even mentioned by tromp as having no practical difference than any 1-week reorg of the blockchain. The rogue key attacks were identified after I had to go dark with my proposal, since discussion of it was no longer permitted on keybase, which shows more honest technical discussion is needed. Just as relative kernels changed in form numerous times due to various technical challenges, so too has the one-sided proposal, but unfortunately all of these changes had to occur outside of keybase discussions.
I kept an up to date version of the proposal for quite some time, but as discussion of it was discouraged on grin channels, I stopped maintaining it. Litecoin won’t be ready for one-sided transactions for quite some time, so I have not prioritized maintaining their version.
And yes, it is impractical. It requires a one-week reorg. If that occurs to any PoW chain, that coin is already dead, and the opportunity for an attacker to steal coins would’ve already been enormous. I can’t tell if you don’t understand the attack, or you’re just intentionally trying to oversell the risks.
Anyhow, those are my last words on the subject. You may continue to suggest that it’s an insecure scheme, or that it’s my own fault that the technical discussion never took place. I’m done playing these political games.
If the receiver is concerned that the sender could reorg the blockchain an entire week some point in the future, then yes, a self-spend would prevent that, and therefore give you the same security as bitcoin.
@david has always been concerned about making Grin as easy to use as possible. At the end of the day, this is what this project is about: Usable Electronic transactions for all without censorship or restrictions (grin.mw). His Grin+±Wallet is just that: It makes Grin easy to use for folks who happens to not be computer scientists surfing on a CLI on Gentoo Linux.
Being usable is were Grin needs to go (where else should it head to?).
@lehnberg has always been concerned about making sure the Grin Fundamentals are as robust and secure as possible. This is crucial. Without robust systems that are resiliant towards attacks you can not have usable Electronic transactions for all without censorship or restrictions (grin.mw).
So i really don’t get what the aforementioned discussion on telegram was all about. You have the same goals. Grin needs to be more usable (which it is currently not) and it needs to be robust at the same time.
Usually electronic payment is for participiants a no-brainer or as you would say “fire and forget”: You click on “ok/send/confirm” and it is done - the recepient gets the payment delivered by the underlying payment system. Grin is unintuitive to this. You need the recipient to do stuff, send something back or have his wallet online at the same time (what if his deskop-pc is offline because he is at sleep?). One-Sided Transactions need to happen and this is why @david stresses this so much for very good reasons.
Obviously it is not trivial to get there with MW.
Back in the day Bjarne Stroustrup was super unhappy with C. So he created C with Classes (C++). There was one problem: The first C with Classes Implementation was a little slower than C. It was 3 % slower in direct comparison. But who cares, it got classes, right? The speed penalty coming with the concept of classes could have be seen as an acceptable trade-off for the new feature. Turned out Stroustup deemed the speed penalty totally unacceptable and so they started working on it and were able to remove the overhead (https://www.youtube.com/watch?v=69edOm889V4 26:10). In fact they got the classes and the speed.
I really hope for Grin and its mission that the devs think about how get Grin usable and resiliant towards attacks at the same time. It will not be enough to just point out to the security-flaws one suggestion towards a better usability might bring (Status of Litecoin Improvement Proposal LIP-0004 for one-sided transactions).
When nobody uses Grin it does not matter that it is robust under the hood.