# An open discussion on Non-interactive transactions **URL:** \ **Category:** Development and Technical Discussion\ **Created:** [March 3, 2021, 5:16am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510 "2021-03-03T05:16:51Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [March 15, 2021, 9:03pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/41 "2021-03-15T21:03:59Z")
> [@david](#): > > We can spend a year or two iterating on the design and hiring auditors. 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. > [@david](#): > > There is no permanent chain bloat with the LTC proposal. Outputs grow by 15-20%, but are pruned when spent. 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. > [@david](#): > > As you’ve admitted before, it’s only an “ugly wart” of theoretical interest. It has no practical effect on security. 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](https://eprint.iacr.org/2020/1618) ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [March 16, 2021, 1:43am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/42 "2021-03-16T01:43:40Z")
> [@tromp](#): > > 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. 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. > [@tromp](#): > > Then the IBD is linear in the UTXO set, and the bloat is not insignificant. 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… > [@tromp](#): > > A clean security model is an integral part of Grin’s appeal. 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… > [@tromp](#): > > We shouldn’t have to explain to peple why “year old coins can be stolen by a week-deep reorg” is acceptable. 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 🙁 ---
**Author:** ![Gorfo](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/gorfo/32/3536_2.png) [@Gorfo](https://forum.grin.mw/u/Gorfo)\ **Post date:** [March 16, 2021, 2:30am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/43 "2021-03-16T02:30:17Z")
> [@tromp](#): > > If bitcoin lightning can be made easy-to-use, then so can Grin. I dare to say it may not accomplish it! ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [March 16, 2021, 9:56am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/44 "2021-03-16T09:56:41Z")
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. ---
**Author:** ![Cobragrin](https://avatars.discourse-cdn.com/v4/letter/c/aca169/32.png) [@Cobragrin](https://forum.grin.mw/u/Cobragrin)\ **Post date:** [March 16, 2021, 10:59am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/45 "2021-03-16T10:59:28Z")
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! ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [March 16, 2021, 4:51pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/46 "2021-03-16T16:51:41Z")
To freshen up this discussion, would it be an option to start having an online relay-wallet? Something like you have [blockchain.com](http://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. ---
**Author:** ![CCCC](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/cccc/32/3831_2.png) [@CCCC](https://forum.grin.mw/u/CCCC)\ **Post date:** [March 16, 2021, 5:22pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/47 "2021-03-16T17:22:35Z")
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. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [March 16, 2021, 6:32pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/48 "2021-03-16T18:32:13Z")
@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. ---
**Author:** ![vegycslol](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/vegycslol/32/3340_2.png) [@vegycslol](https://forum.grin.mw/u/vegycslol)\ **Post date:** [March 16, 2021, 6:37pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/49 "2021-03-16T18:37:15Z")
> [@Anynomous](#): > > 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. Isn’t that similar to a bank? We want to avoid having to trust other people ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [March 16, 2021, 7:23pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/50 "2021-03-16T19:23:02Z")
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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [March 16, 2021, 10:11pm UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/51 "2021-03-16T22:11:07Z")
> [@david](#): > > 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. While deviating from Mimblewimble and sacrificing Grin’s simplicity, one of its main assets. > [@](#): > > those who are hopelessly obsessed That kind of language does not belong in a civilized discussion. > [@david](#): > > at the _extremely high cost_ of practical usability. Bitcoin lightning shows how interactive transactions can be made quite usable. > [@david](#): > > Then why were you so adamantly opposed to implementing a clean solution for preventing replay attacks? I am adamantly opposed to needlessly complicating the consensus model. > [@david](#): > > sometimes using SRS, rather than going with a uniform standard that’s easier to learn. 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, > [@david](#): > > But refusing to budge even a little to try to find middle ground has led to a painful stalemate whereby nothing ever gets done. 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. > [@david](#): > > It seems likely we’ll never accomplish anything You might as well say that the Bitcoin lightning network, which has to operate within the same interactivity confines, will never accomplish anything. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [March 17, 2021, 12:58am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/52 "2021-03-17T00:58:46Z")
> [@tromp](#): > > 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. 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. ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [March 17, 2021, 8:20am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/53 "2021-03-17T08:20:17Z")
> [@tromp](#): > > While deviating from Mimblewimble and sacrificing Grin’s simplicity, > one of its main assets. It’s main assets are privacy and scalability. Most people don’t care about minimalism: [https://twitter.com/DavidBurkett38/status/1303106005056851971](https://twitter.com/DavidBurkett38/status/1303106005056851971) > [@tromp](#): > > Bitcoin lightning shows how interactive transactions can be made quite usable. I can certainly say this is the first time I’ve ever seen lightning network touted as an example of good usability. > [@tromp](#): > > I am adamantly opposed to needlessly complicating the consensus model. So I guess a clean security model is not such an integral part of Grin’s appeal? > [@tromp](#): > > And always being the middle party in both withdrawals and deposits makes for a uniform exchange user experience, 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? > [@tromp](#): > > Plenty got done in Grin in its first two years True. Just look how many API and slate versions we’ve implemented! > [@tromp](#): > > especially considering the limited manpower. There’s limited manpower because we launched with possibly the least usable cryptocurrency ever, so the hype died almost immediately and everyone bailed. > [@tromp](#): > > 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. 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. > [@tromp](#): > > I want to optimize Grin for the coming decades, not for the coming years. So do I, by making sure we actually stay relevant enough to survive decades. > [@tromp](#): > > You might as well say that the Bitcoin lightning network, which has to operate within the same interactivity confines, will never accomplish anything. 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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [March 17, 2021, 8:58am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/54 "2021-03-17T08:58:32Z")
> [@david](#): > > ways to push mimblewimble to its limits 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](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/3) ---
**Author:** ![vegycslol](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/vegycslol/32/3340_2.png) [@vegycslol](https://forum.grin.mw/u/vegycslol)\ **Post date:** [March 17, 2021, 9:38am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/55 "2021-03-17T09:38:57Z")
> [@david](#): > > Most people don’t care about minimalism 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) > [@david](#): > > To most users, there is nothing “uniform” about this approach. 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 > [@david](#): > > What happens when some exchanges support RSR, but some support SRS? 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 > [@david](#): > > What about stores - should they use RSR and SRS RSR imo to automate the process as much as possible (2 steps automated here vs 1 in SRS case) > [@david](#): > > Also, why have we given up on trying to support sending via tor? 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 > [@david](#): > > We can do everything in our power to discourage people from using nitx unless absolutely necessary 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) ---
**Author:** ![davidtavarez](https://avatars.discourse-cdn.com/v4/letter/d/3ab097/32.png) [@davidtavarez](https://forum.grin.mw/u/davidtavarez)\ **Post date:** [March 17, 2021, 9:43am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/56 "2021-03-17T09:43:52Z")
> [@tromp](#): > > You seem to have misunderstood me, David. 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: > [@david](#): > > 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. Also this: > [@david](#): > > There’s limited manpower because we launched with possibly the least usable cryptocurrency ever, so the hype died almost immediately and everyone bailed 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. > [@tromp](#): > > I want to respect those limits rather than break them. 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. ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [March 17, 2021, 9:54am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/57 "2021-03-17T09:54:11Z")
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. ---
**Author:** ![davidtavarez](https://avatars.discourse-cdn.com/v4/letter/d/3ab097/32.png) [@davidtavarez](https://forum.grin.mw/u/davidtavarez)\ **Post date:** [March 17, 2021, 9:57am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/58 "2021-03-17T09:57:56Z")
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? ---
**Author:** ![vegycslol](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/vegycslol/32/3340_2.png) [@vegycslol](https://forum.grin.mw/u/vegycslol)\ **Post date:** [March 17, 2021, 9:59am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/59 "2021-03-17T09:59:54Z")
> [@davidtavarez](#): > > I noticed a long time ago that, and I hope I’m wrong, the Council isn’t spending a second giving support to users. What kind of support do you have in mind here? > [@davidtavarez](#): > > 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 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) > [@davidtavarez](#): > > There is always the counter-arguments of being insecure, incomplete and/or my favorite: it increases the block size. All these arguments are valid, especially if you’re hoping that the project lives for decades/centuries ---
**Author:** ![vegycslol](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/vegycslol/32/3340_2.png) [@vegycslol](https://forum.grin.mw/u/vegycslol)\ **Post date:** [March 17, 2021, 10:02am UTC](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510/60 "2021-03-17T10:02:57Z")
> [@davidtavarez](#): > > So, Grin is not only disconnected from users but from Exchanges, why is this so hard to understand? 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 [Previous page](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510.md?page=2) [Next page](https://forum.grin.mw/t/an-open-discussion-on-non-interactive-transactions/8510.md?page=4)