An open discussion on Non-interactive transactions

You’re proposing to make a controversial change to the consensus model, which will likely lead to a fork of Grin, just as the Bitcoin big blockers forked away due to irreconcilable differences.
This is not in the best interest of Grin.

I can imagine a future where many people don’t download the kernel history, but a zero knowledge proof of its existence [1]. Then the IBD is linear in the UTXO set, and the bloat is not insignificant.

A clean security model is an integral part of Grin’s appeal.
We shouldn’t have to explain to peple why “year old coins can be stolen by a week-deep reorg” is acceptable.

[1] Proof-Carrying Data without Succinct Arguments

No, I’m proposing to work together with those who oppose the current NITX proposals so we can find the cleanest and safest design that meets the usability needs of our users without sacrificing the prunability and privacy that makes Grin great.

This chain split fearmongering is entirely unnecessary. I’m very likely the only Grin dev who could have pulled off a successful fork of Grin, yet I never once entertained the idea, even when many practically begged me to. If forking Grin was an option, I certainly wouldn’t have spent so much time trying to change the minds of those who are hopelessly obsessed with “minimalism” at the extremely high cost of practical usability.

While I agree a 15-20% increase is not insignificant, it’s still quite a small price to pay for the usability advantages of non-interactive transactions. To be fair though, the chain very likely would be a LOT larger right now if we had nitx, because people would be actually using Grin…

Then why were you so adamantly opposed to implementing a clean solution for preventing replay attacks? There is nothing clean about a security model that relies on wallets very carefully choosing inputs & outputs to prevent the possibility of replay attacks. The concerns there are exactly the same as with nitx - somebody could send coins to you and then later take them back. It just so happens that replay attacks are much easier to pull off…

Then auto coinswap, or self-spend by default once we have ZKPs to prove kernel history, or continue to recommend the _still possible_ interactive transactions. Where is this concern for the difficulty of explaining to users how the wallet works when we’re discussing the many complex scenarios around interactive transactions?

Just a few days ago you argued for sometimes using RSR and sometimes using SRS, rather than going with a uniform standard that’s easier to learn. You seemed very unconcerned with users having to learn how it works when I continued to bring up the impracticality of forcing users to understand how the wallet works. The solution is always “it’s up to the UX developers to make this easier.” Well if that’s an acceptable answer, then an acceptable response here is that the UX developers can make recommendations to the user about mixing coins, self-spending, or preferring interactive txs.


I appreciate how selflessly devoted you’ve been to Grin. It’s clear you want Grin to succeed, so we’ve got that in common. But refusing to budge even a little to try to find middle ground has led to a painful stalemate whereby nothing ever gets done. That is not in the best interest of Grin.

It seems likely we’ll never accomplish anything until one side finally gives up and just goes elsewhere :slightly_frowning_face:

2 Likes

I dare to say it may not accomplish it!

To clarify what I am about to say, I am not in favour of implementing nitx right now. Nor is it relevant for this discussion whether I, you or someone else thinks it is right or wrong to implement nitx in Grin.
We owe it to the project and each other to entertain the thought of nitx and have a theoretical discussion of what the current least ugly nitx ‘solution’ would be.

  • What are the main bottlenecks that currently prevent nitx? Which are the problems/bottlenecks that if they could be solved, would allow real consideration of implementing nitx in Grin?
    • Could we put bounties on solving these problems?
  • Is it even theoretically possible to have nitx extension blocks, to move or burn coins in Mimble Wimble (whether this is something desirable yet another discussion altogether).
  • What are the current compatibility issues (not in vision but in consensus and encryption)
  • Can nitx transaction exist outside of Grin’s consensus model in order to make nitx and ‘opt-in’ feature that does not affect the use of ‘pure’ MW Grin? E.g. burning and creation of coins in Grin?
  • Could non-interactive transactions be de-insentivised, e.g. paying a rent for keeping bloat on the chain. Automatically self spending nitx outputs in a normal interactive transaction whenever a user comes online?

I argue to avoid making it a ‘philosophical’ battle of what is right or wrong, since those are subjective, and we are all right and wrong at the same time. Instead of searching for a middle ground, just keep to a theoretical exercise where we can argue for arguments sake without even thinking there is a real project at stake. What in my opinion would be the ideal outcome of this discussion would be to have a well founded overview of existing or possibly new theoretical solutions with all their up and downsides, as well as practical issues that would require solving or could be put in the bounty system.

2 Likes

Grin devs are really talented,as we see above.

A Tier 1 technical discussion, despite everything you managed to come together and move forward since 2017. There s always light.
Grin community watch you guys!

To freshen up this discussion, would it be an option to start having an online relay-wallet?
Something like you have blockchain.com, for those who would like to have a always online wallet service.
Preferably it should be setup in such a way that funds are transfered to the normal wallet as soon as the user comes online. Of course, the problem would be that such a service would require to have access to you privatekey of this online wallet for the siging. If there would be an insentive, e.g. the service profider is allowed to send some transaction fee to him or herself, it might work, although it would only be advisable for small ammounts.
Alternatively, this could be a distributed service, e.g. i will create an account with someone with a Grin wallet who will serve as my always online relay/intermediate wallet at my own risk. Again, once I come online, funds should be transfered automatically. This fits with the address book that @davidtavarez has for Grin++ and is all interactive transactions under de hood.

Sorry, I realise I am getting off-topic.

It’s not really off-topic. I thought about something along the line. It’s not decentralized enough but easier to use. How would an online-wallet work is the real question.

@CCCC Maybe it could be one wallet, that runs multipple TOR instances (slatepack addresses for many accounts simultaniously, sharing the same instance of the blockchain). So it would be a bit a server running and supercharged wallet with multiple accounts loged simultatniously.

Preferably each account would be be compartimentalised, e.g. virtual services. So an alternative would be very small minimal VM’s running in paralel with the full wallet. This would however increase the cost, so prefably they are like a light node sharing the same blockchain (e.g grinnode.live) for checking if transactions are valid, but each with their own privatekey.

Isn’t that similar to a bank? We want to avoid having to trust other people

It would be too centralised for my taste, but it could serve those willing to make such a sacrifice. An alternative would be a Grin buddy system. So basically the same kind of service done through a friend who has two accounts (one wallet) online at the same time. A distributed version would also be possible, but then some kind of reputation system would need to be in place, e.g. super nodes who are showing proof of stake. But that would be way to complex a solution to solve what I personally would call a minor inconvenience.

With slatepacks you can also work around the inconvenience of needing to be online at the time someone innitiates a transaction, the only difference it that the funds are not locked. So personally I am searching for a solution that is not out of proportion complex to what we are trying to solve. E.g. having a plugin to Signal that links your addres book to grin addresses and automatically detects if a slatepack is received, would just as much make a users life easier and would still be completely based on interactive transactions.

While deviating from Mimblewimble and sacrificing Grin’s simplicity,
one of its main assets.

That kind of language does not belong in a civilized discussion.

Bitcoin lightning shows how interactive transactions can be made quite usable.

I am adamantly opposed to needlessly complicating the consensus model.

Because there are advantages to exchanges using RSR for withdrawals. And always being the middle party in both withdrawals and deposits makes for a uniform exchange user experience,

Plenty got done in Grin in its first two years, especially considering the limited manpower. Consensus model changes with significant downsides, which you are pushing for, are exactly the type of change Grin should resist.

Grin should make the UX as easy as possible, but within the confines of staying true to its nature as a clean Mimblewimble implementation.
The extreme simplicity of MW’s transaction model gives it a huge potential for future possibilities beyond just party A sending an on-chain payment to party B. I do not want to diminish that potential by the short-sighted action of making the uncommon act of A paying an offline B slightly more convenient.
I want to optimize Grin for the coming decades, not for the coming years.

You might as well say that the Bitcoin lightning network, which has to operate within the same interactivity confines, will never accomplish anything.

2 Likes

While this is not guaranteed, I think it is the most underrated feature of simplicity. I’m not even sure if I have the same thing in mind as tromp, but we might give away features that are unknown to us today, but can only exist when the computational requirements are extremely simple. It’s important to understand that this “hidden feature” goes away even when we can prove the complexity secure. Even a formally verified code makes these possibilities go away. So giving up simplicity is not only a tradeoff in security as this could be solved with a formal verification, but there are likely features that will be thrown out the window when complexity is added.
I’m fully aware one could say “but this is a hypothetical scenario and we are solving issues that don’t exist”, and unfortunately, the only answer I have is that I have a hunch this and other advantages of simplicity are going to be discovered in some form. It might take years or decades before that happens, but as things continue being discovered, I expect some interesting features to only be possible in the simple version of Grin. I’m not saying people should follow any single individual’s “hunch”, but I think very few in the community understand what I’m trying to convey here, so most have likely not even considered these scenarios.

Another thing I’d like to add is that Grin is only 2 years old and in my opinion, we really don’t want to be adding this much complexity so early on. Even if we did nitx (in the form they are today) in the first decade, it would still be “added complexity through a very large system redesign”. The question that pops in my mind is “what happens in the next decade?”. This is the problem I have with Ethereum. Their approach is “agile” which comes at the expense of nobody really knowing what’s going to happen next year and they keep piling up the complexity. It’s extremely easy to complect a system, but extremely hard to simplify it, so we should be moving towards the complexity side of the spectrum very slowly, very carefully and only when really needed. I think we are extremely lucky that Mimblewimble is an extreme case of a design that seems very hard to simplify further so throwing this out the window would be a missed opportunity in my opinion. I feel like Grin has a much higher chance of success in the long run if it is based on a simple design.

2 Likes

It’s main assets are privacy and scalability. Most people don’t care about minimalism: https://twitter.com/DavidBurkett38/status/1303106005056851971

I can certainly say this is the first time I’ve ever seen lightning network touted as an example of good usability.

So I guess a clean security model is not such an integral part of Grin’s appeal?

How much time have you spent supporting grin users? I’ve personally spent hundreds, maybe even thousands of hours helping people try to use grin. I know a thing or two about how new users think about transacting. To most users, there is nothing “uniform” about this approach.

How are we supposed to explain to users that receiving from another grin user is different than receiving from an exchange? What happens when some exchanges support RSR, but some support SRS? What about stores - should they use RSR and SRS? How are service providers supposed to decide whether they qualify for exchange-style RSR, or normal style SRS?

Also, why have we given up on trying to support sending via tor? I thought the beauty of slatepacks was the ability to support synchronous in most cases, but fall back to asynch if the receiver is unreachable? Why are we no longer recommending that? Why is it that we continue to make recommendations that make things harder for our users?

True. Just look how many API and slate versions we’ve implemented!

There’s limited manpower because we launched with possibly the least usable cryptocurrency ever, so the hype died almost immediately and everyone bailed.

You can support both itx and nitx. We can do everything in our power to discourage people from using nitx unless absolutely necessary, including trying first to contact the receiver via tor to build transactions interactively, limiting the number of nitx per block, charging additional fees, showing big warnings, etc. There are plenty of ways we could compromise to get what we both want. But compromise never appears to be an option.

So do I, by making sure we actually stay relevant enough to survive decades.

I didn’t say we will never accomplish anything because we have interactive transactions. I said we will never accomplish anything when one side refuses to search for reasonable compromises. It’s always minimalism or death, and sadly it’s starting to seem like Grin might end up with the latter.


I’m not going to continue these discussions. This coin was once the pinnacle of innovation, and you could just feel everyone’s enthusiasm when discussing new, cutting-edge ways to push mimblewimble to its limits. We used to discuss using BLS to possibly support aggregating kernels or one-sided txs (a much more complex consensus change), and Igno himself was very interested in it as well. We discussed finding alternative accumulators for a constant-sized replacement of MMRs. We were always on the lookout for ways to improve Grin’s privacy or scalability even further. Not all of the ideas were good, but we were at least trying to push the technology forward so we can remain relevant.

But then we launched, hype died, Igno left, and history was rewritten by a small group of minimalists whose one desire seemed to be creating the most simplistic consensus model out there, regardless of its impact on practical usage. Now, it’s not even worth the effort to propose new ideas, because it would be too exhausting and fruitless to try to fight the inevitable political battle that will result. We’ve become so good at minimalism that even our dev community is minimal, with near-silent dev channels outside of our weekly meetings. The dwindling dev community and shrinking userbase should’ve been enough for most people to stop and consider that maybe, just maybe, we aren’t on the right path.

1 Like

That’s exactly what I want to do.
Mimblewimble is by design limited to interactivity.

I want to respect those limits rather than break them.

Many people feel the same way as An open discussion on Non-interactive transactions - #3 by tromp

That’s certainly true, but at the same time most people didn’t take 1 week to study mw and still vote on such polls, so the result can’t be different than that (privacy and scalability sound cool, maybe you should rename minimalism to security in such poll, i know they’re not synonyms but it would be a much fairer approach based on people’s knowledge)

Most people never tried invoices, it can’t seem uniform if they don’t know invoices even exist or have not tried using them in a scenario where they could be useful

You don’t seem to be worried about the case where some exchanges use tor and some don’t. That’s imo a harder thing to understand than having invoices

RSR imo to automate the process as much as possible (2 steps automated here vs 1 in SRS case)

Who gave up? If we ever implement payment proofs with a memo i would still like to have the communication first try through tor (but with manual confirmation). Payment proofs without memo could keep the autoreceive

I don’t see why you think such solution would be good. To me this basically reads as “we have implemented this but please don’t use it” and i see no reason to implement nitx in such a way (much better to just have both than this imo)

I was happy to read that I misunderstood you. But what I see is that you’re not willing to compromise anything, it feels like Grin is only about the minimalist MW implementation or nothing. I’ve been repeating this over and over again, and I will say it again: I’m sure this minimalist implementation will payoff in the long term. But, it seems you’re completely ignoring reality.

This is reality:

Also this:

I noticed a long time ago that, and I hope I’m wrong, the Council isn’t spending a second giving support to users. There is a clear detachment here, between how users are using Grin (the few that are) and this idea of not putting attention to usability. And this is bad, really bad, and leads me to ask myself whether Grin is meant to be used or not.

Every attempt of NITX or 2 round transactions are being discouraged, the Council seems to be against that for the merely fact of being against. When a proposal, uncompleted or not, is made public there is no: “we think this is good, let’s explore this idea and try to make it possible”. There is always the counter-arguments of being insecure, incomplete and/or my favorite: it increases the block size.

And this is great, my question is: is usability in your list at least? are you thinking about the end users?

Sometimes it looks like users are been treaded as some kind of peons that need to be sacrificed in order to achieve… what? This is hurting Grin; we could, of course, condemn all Exchanges for not having in place the “right implementation”, but how will they? if we can not even agree on usability.

3 Likes

This is a horribly misguided view. The end goal is not to be mimblewimble as described by the spec, or to “respect” its limits. The goal of Grin is to be a privacy-preserving digital currency that can be used by anyone, Anywhere. Of course we use Mimblewimble, but not just because we think Mimblewimble is some kind of divine end goal, but because we want the scalability and privacy benefits that Mimblewimble gives us.

Your argument would be equivalent to saying that bitcoin doesn’t support Schnorr, so we should respect that limit rather than try to include Schnorr support.

It’s great to plan ahead and be thinking about decades from now, but we also need to remain relevant today. The way we’re currently trending, Grin won’t survive its first decade.

1 Like

We should quit wishful thinking; when we see exchanges implementing different solutions, and requests made by exchanges being ignored, it is clear that we’re disconnected from the challenges they’re facing. So, Grin is not only disconnected from users but from Exchanges, why is this so hard to understand?

1 Like

What kind of support do you have in mind here?

That’s not true, i think we have once come to the conclusion that we all want 2 steps instead of 3, even tromp said so. Each 2 step approach is being looked at, there was a new approach from the council member not long ago. There are also problems with 2 step that we don’t know how to solve (eg. spam attack)

All these arguments are valid, especially if you’re hoping that the project lives for decades/centuries

1 Like

It’s easy to understand and i agree with that, my point is that RSR/SRS flow is much easier for the user to go through and for the exchanges to integrate grin