Pep Talk for one sided transactions

Earlier today i followed a discussion between @lehnberg and @david on telegram (t.me/grincoin) regarding one-sided-transactions.
lehnberg wrote:

Thanks David.
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.

Davids Response:

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.

11 Likes

Would you like to paste the relevant portion of the Telegram chat here, for those who don’t have that app?

2 Likes

i added the discussion to my post.

Good idea to create a thread here @Grundkurs.

The conversation started here:

And ended here:

The idea of interactive transactions might be good in terms of privacy but in practice isn’t working pretty well. From the Developer perspective, I can tell people faces the same issue over and over again: “making their wallet reachable”; I ended up hosting a Service just for that and integrating this to Grin++ GUI. This is adding more and more unnecessary complexity making harder to bring all Grin features to a Wallet. Also, just thinking about a Mobile Wallet is a huge headache, the only feasible approach is to connect the wallet to a remote Node, making Grin less private, anonymous and, more important, less secure, which is not an option.

I’m not saying that non-interactive transactions are something easy to achieve, for sure it’s hard; I agree there is no a final proposal, but for God’s sake, this is something that will make life easier to everyone, users, developers and Exchanges. I’m trying really hard to not sounds biased on this topic, but it’s a headache, a bad one. The gains of non-interactive transactions are so much that is it really hard to argument against it.

I can’t understand why this is not a #1 priority.

5 Likes

but for God’s sake, this is something that will make life easier to everyone, users, developers and Exchanges.

This is another good point here.

I entirely agree. I think one-sided txs is critical, ASAP.

Building in support for soft forks seems to be fading away as well, but that seems to be really important for whenever the last planned hard fork will be (currently a little over 6 months away).

1 Like

I love MW for its conceptual simplicity and elegance.

Its outputs are Pedersen commitments r*G+v*H which combine value and blinding factor into a single curve point. The blinding factor serves both to hide the value and to control ownership. Correspondingly, a single (multi-)signature serves both to prove value balance (non-inflation) and to authorize transfer of ownership. That’s kind of magic.

This allows MW to completely do away with bitcoin script, which is a language for specifying the conditions under which individual outputs can be spent, usually signatures with public keys that hash to a given value.
It’s also a huge source of complexity within Bitcoin.

MW instead requires interaction between sender and receiver to construct the signature. This incidentally removes the possibility of certain errors where funds are sent to the wrong place. (and makes it very ransom unfriendly). Note that such interaction is also required in 2nd layer networks like Bitcoin Lightning that is seeing growing adoption, and is bound to be the common form of transacting if Bitcoin is ever to see mainstream adoption. Having a similar experience between on-chain and off-chain tx building will ease the transition for Grin users.

In the one-sided tx proposal there would be two very different kinds of output. The simple MW ones that we have now, and complex ones that have several (at least four) additional fields of data attached to it.
For these complex outputs, the blinding factor no longer suffices to control ownership, as it will be known by both sender and receiver.
Rather, as in bitcoin, the spender must also prove knowledge of a specific public key. The full extent of additional data and rules is not clear, as the proposal is incomplete. It’s also not clear how transactions should deal with a mix of simple and complex inputs/outputs.

I find these complications to be detrimental to the simplicity of MW. Grin in particular aims to be a minimal and lightweight implementation of MW and this is neither.

The security problem may not be relevant in practice due to absence of week-long reorgs, but is still an ugly wart.

The main reason for the current usability problems is that exchanges don’t offer a backup mechanism for wallet connection failures, something that the deprecation of http and compact slates should improve.

7 Likes

Requiring interaction will always create usability problems. Beam is entirely SBBS and the main issue they get is requiring the wallet to be online. I appreciate the beauty and simplicity, but I also acknowledge the usability issues that interaction will always have. I think the best case scenario for refusal to support non-interactive transactions will drastically promote the use of custodial wallets or sharing seeds with always-on solutions, both of which seem less ideal to me than supporting non-interactive transactions.

2 Likes

If its technically possible to achieve non interactive transactions without sacrificing security, you guys should give it a try! :slight_smile:

Just my 2 Grin

When people ask me for my Grin address, I give them my gate.io address. I would never be so reckless with any other coin, but for Grin, it’s just not worth the hassle of coordinating a time when sender and receiver are both online. I’ve been in crypto long enough to “know better”, so if Grin is too difficult for me to use without a third party service, it’s never going to be useful for the masses.

Self spend the UTXO and you have no risk. Or the fact that a 7 day reorg would wreck the project if it was ever pulled off so whatever one-sided (non-interactive) transactions were exploited is kind of irrelevant

I try to keep my nodes running but they find a way to break themselves. So either way you cut it there isnt a great solution. For whatever reason, the leeching nodes I have are more stable, but I would always check if they are up and fine before trying to get a transaction. None of this seems very usable to me.

@tromp said it nicely. I too think that Grin should not sacrifice its unique traits, for the sake of being more like other coins. Lightning Network also has to deal with interactivity and liveness, even more so than Grin. And it seems to be progressing towards better usability with every new wallet regardless.

1 Like

It isnt to be like other coins, it is so people can use it. Lightning is significantly easier to use than grin, WAY easier.

I don’t have much to add on the technical side.

Just that as a user, miner and investor I REALLY want to see one sided transactions on grin.

Even if it adds some technical complexity it would eliminate almost all the use ability issues we run into.

1 Like

Sounds like Grin should take suggestions from Lightning on how to improve usability despite being interactive…

Grin has been in development since before lightning was launched so there has been all the time in the lightning world to take the suggestions. Some of the solutions include lots of non-custodial (and custodial) services, watchtowers and other p2p layers to facilitate message deliveries (even in asynchronous manner). They also support pre-signed redemption txs for receivers, similar to Ignos idea for grin. Grin core has made decisions to not develop the solutions that lightning has used to improve usability. There were always good reasons for not supporting them, but I feel they arent as good as the reasons for supporting them.

Let’s be clear here: there is nothing like one sided transactions in Lightning Network. The requirement that sender and receiver are both online at the moment of payment is absolutely essential and unavoidable in LN. Anything else involves some kind of custody.

What makes LN more usable than Grin is just the user experience. No longer do I need to care about port forwarding madness etc like in the beginning with first generation of LN wallets. With the latest wallets (like Phoenix or Muun) there is also no need to handle channels by user, it just happens on the background, so user experience is becoming pretty smooth.

I see no technical reason why Grin couldn’t get to the same level of Ux with its current blockchain-tx format as is. It’s just a matter of engineering and manpower on the application layer I guess. At this point in time, there is more Lightning wallet teams than there is Grin developers.

I quite liked the experience of using grin with grinbox. I hoped the grin ecosystem would continue more that way, federation of grinboxes or something like that seemed most user friendly to me at the time.
Transactions over Tor will also move things forward I hope… so I am optimistic that in time, usability will improve. In my opinion it’s not worth sacrificing grin’s unique strengths (like scalability and txs uniformity) in the process.

There is 1000 other altcoins that can do one sided transactions and nobody is using them anyway.

:pray:

6 Likes

I think you have raised some good points, and despite I have never used lightening i have not much to add :slight_smile:

We must keep big maximum 2 methods of transactions available to users in wallets. OGs may still be able to tweak wallet to do their favorite slate exchanges independently, but it is horrible for a user to have 1. many methods 2. none of them is standardized 3. none of them as you said had enough manpower to make the ux irreprochable.
And it may take years and years before we have LN usabibility. But at the same time we need a community.

I hope that it will resolve. We just need people to happily use the coin. For now it has been a nightmare (more difficult coin to use in the industry) or too repulsive and most people just use other coins.

If you keep repulse people, people ends up hating you or just forgetting about you.

I hope we are in a good path

2 Likes