Even John attempted to come up with a noninteractive approach here Split one-sided transactions in pure MW by tromp · Pull Request #64 · mimblewimble/grin-rfcs · GitHub but it turns out lacking unfortunately. From my experience, people are not against NITX itself as a feature, they are against the specific implementations of NITX which add A LOT of complexity. Block size increase isn’t the issue, transaction size increase is. To give a concrete example, imagine we find a way to do 2-2 transactions without kernels, then Increasing the max weight of the block which is filled with 2-2 transactions adds absolutely no footprint, so the block size is not the issue (only the bandwidth increases). The increase of transaction size however can be done in 2 ways, either by adding prunable data which increases bandwidth usage and temporary storage or by adding unprunable data e.g. information on the kernel which adds a footprint on the chain forever. But they don’t add only data, they add rules which is a source of complexity. Similarly, John and many others spent a lot of time thinking about 2-step solutions and I particularly remember John saying it’s a good thing when it was first being researched - if I recall correctly, he even wrote an email to one of the authors of a different signature scheme to ask something. People aren’t discouraging these attempts, they’re trying to solve them themselves, the problem is that these problems aren’t easy to solve in a way that would be a good fit for Grin.
Even though I’m surprised how much we got right with the Slatepacks and it is my favorite improvement, I personally believe we’ve been perhaps too ambitious with the first Slatepack standard version and should have gone with the pure copy/paste version and no Tor for the first version. This would make it simpler to have a working version with exchanges while keeping it simple for extension because adding new layers (e.g. a transport layer or multiple of these) on top of a minimal standard is simpler.
I’ve heard this story a few times now. I’m not buying Ignotus would make things very different and make the complexity tradeoffs that are suggested in some proposals. Here’s why:
First import on github README.md where he makes the first bulletpoint Clean and minimal implementation, aiming to stay as such.. Similarly, in the “Philosophy” section adds this as the first thing Grin likes itself small and easy on the eyes. and finishes with It may have strong opinions to stay in line with its objectives, which doesn't mean disrepect of others' ideas.
Ignotus on complex systems - Overall, I'm not a huge proponent of "more is better". It's too easy to forget that what's sacrificed on the other side of the balance is simplicity. And blockchain implementations are complex systems that can use every bit of simplicity that can be found.
Again - Because MimbleWimble itself relies on a simple yet robust cryptographic construct (Elliptic Curve Cryptography) we aim to keep that simplicity goal in mind. It's also our belief that bitcoin and other cryptocurrencies crumble under the weight of complexity and technical debt. Our goal is to have a clean implementation that many can review, learn from, and build upon.
and again - 17:39 < igno_peverell> I like Cuckoo because the implementation is short and simple and it's easy to grasp as a whole, I'm trying to keep the idea of simplicity that's in MW
Imagine you’re building a new project where you’ve committed tens of thousands of lines of code and you want to let the world know what it is about. What kind of mindset makes the first point about a new project a strong point on simplicity and minimalism of the project? and then adds a variant of “some ideas might not make it, but this isn’t meant as a disrespect”. History wasn’t rewritten by a group of minimalists, Ignotus was very clearly a simplicity enthusiast before starting Grin.
In reality it was just what is usually seen in the houses of people of moderate means who want to appear rich, and therefore succeed only in resembling others like themselves: there are damasks, dark wood, plants, rugs, and dull and polished bronzes—all the things people of a certain class have in order to resemble other people of that class. His house was so like the others that it would never have been noticed, but to him it all seemed to be quite exceptional.
– The Death of Ivan Ilyich
True, but what I would like to see is a commitment of taking at least one potential solution and invest effort on making it secure, and feasible.
The kind of support we give on the Grin++ Telegram Support Group. When a question turns to be repeatable I tend to write and publish something to then point the users to that write-up. Some users record videos to help other users. And to be fair, after implementing the Slatepack RFC, support questions have been reduced, but before that, it was a painful headache; now what we see is Pools and the few exchanges implementing different solutions. We even haven’t improved the current situation, but now we want to push another flow, why? because is better? sure, it might be, but the same argument that is being use to keep exploring and experimenting the current MW implementation in order to discover its full potential, which is reasonable enough, can be used to keep exploring and improving the SRS flow, but again, what do we get? a big: “let’s push the RSR flow because without using tor even if we spent hours and hours, maybe years, trying to educate users on using tor with grin, and even without payment proof… let’s switch and explore that”… for me, and without any intention of attacking anyone, it doesn’t makes sense, it is confusing and it will confuse users.
If we keep hurting users, we won’t have any users, we won’t have miners, pools, or even exchanges and this yellow experiment that we all do love and care about will vanish.
RSR is not better than SRS, they complement each other. The way i see it is that SRS is mostly better when sending from userA to userB (in this case one person needs to do 2 steps and SRS seems like a good choice here). When a service wants to integrate grin then (to receive payment) then RSR seems better since the user only needs to do one step. I’m totally for advancing the SRS (not sure what exactly you mean by that, but since in my view grin needs SRS I applaud such things). Tor is a separate thing, whether exchanges should support it or not is not clear to me. Do you really think it’s hard for the users to understand invoices? I think people just need a quality material to learn from. You’re not attacking anyone (your behaviour is exemplary), we’re just all passionate about this project and are discussing things. Sorry if some of my answers seem like attacks, they’re not meant as such
That there is a shortage of Devs I get, but dwindling user community, I do not think that is the case?
Well, sure Grin was hard to use in the beginning, which might have led to some users giving up because although minimal in desing the user experience was complex. However, that is currently not the case. Basically the “problem” with interactivity is ever decreasing, especially with two mobile phone wallet implementations.
Although I agree that there is e a strong “defensive reaction” from some developers like @tromp, this reaction originates from the equally strong “pushy” attitude to claim that Grin needs to have nitx, which is accompanied with a lot of overly negative statements that Grin is unusable, difficult to use etc. etc. This is simply not the case, Grin has become way more usable in the past few years, and we live an age of continous connection (IoT, 5G etc), which means the need for interactivity is an ever decreasing problem.
I agree however with @david and @davidtavarez, that the discussion, the research into nitx should continue. If anything, this community is always searching for better, smarter, more minimal/elegant solutions. Research into nitx is part of that same quest for better and more elegant solutions which is in line with Grin’s spirit.
Regarding the RSR workflow, how would this work when withdrawing from an exchange, should I as user innitiate a transaction in my wallet and copy that online? If that is the case, I do think this is less inuitive than SRS for users and should not be pushed unless there are some major befits.
In a store, this would be different and RSR would fit since for fiat transactions it also is the store owner who innitiate a transaction, by requesting it (entering amount in the payment terminal).
I would like to remind everyone that SRS and RSR are technical terms we use. The end game should not be such that users use these words. Both SRS and RSR share this:
party A proposes a contract
party B signs
party A signs
so the flow might be the same e.g. propose, sign, sign. You can propose a contract where you receive money or where you send it The only annoying difference I see between the two is that RSR has a more annoying play attack scenario. The play scenario in RSR where the receiver doesn’t broadcast should be obvious when thinking of a transaction as a contract that you have signed. They can sign it at any point and publish it on the chain. I’m using the word “contract” just to make things obvious in this example.
Press a button to Withdraw and copy the shown slatepack (if tor fails) into the wallet
Copy back the slatepack
Press a buton to finish the transaction
Deposit
Press a button to deposit and copy the shown slatepack (if tor fails) into the wallet
Copy back the slatepack
Press a buton to finish the transaction
Therefore, the difference is not important at all for the user, as long as we make the user only perform a single step (SRS for withdrawel and RSR for deposit).
So using both should not be any problem for a user, he or she will most likely not know or care which flow is making the magic work under the hood and will indeed be happy that it only involves a single action to perform. @vegycslol.
I’m not so sure if they won’t need to know, they probably will need to. When creating a new tx they would pick either payment or invoice, so imo it would be best if they understand both flows (no magic since it’s not needed imo)
I think as a fan, what Grin needs is a simple goal, at first, which is a unique private transaction, A sends to B and both of them must be online. From this simple rule, there will be many supporting facilities for transactions either on wallets, or special types of exchangers that can support them and so on, making it even more complex. Grin should be built in this way, and in addition to that Grin ambition is to replace fiat, must interact with fiat not interact with other cryptos, well unless stablecoins.
The play scenario in RSR where the receiver doesn’t broadcast should be obvious when thinking of a transaction as a contract that you have signed.
I think this can largely mitigated either by using a (multiparty?) timelock to the transaction, where the sender is able to reclaim funds after a certain number of blocks (10?). Will write something up on @tromp’s PR to see what they think.
I’m not sure I understand correctly what you mean. The case I mentioned is prior to the tx landing on the chain, which means that the sender can always just spend the input they provided in a new transaction which invalidates the one the receiver did not broadcast - this is the solution in safe-cancel RFC.
If you mean solving this by making 2 transactions instead of just 1, then I believe this may have 2 possible problems:
Uses 2 kernels which doubles the size of the chain
No, you’re right, I was thinking of a situation where the tx was already on-chain.
The safe-cancel RFC would also require the user to:
monitor the chain to ensure the tx posted
use some kind of watchtower to watch the chain for them, automatically notifying the wallet the next time it is online to do a self-spend
I still think I agree with those in this thread that suggest having one standardized tx flow (SRS), and making exchanges/pools build on that.
For example, the exchange could put a form for “please create a transaction for X Grin, and post here”. The exchange’s wallet does its part of the tx, and instructs the user “please import the tx to your wallet, verify everything is correct, and finalize”.
The above flow would work for exchanges / pools / stores that do not want to implement TOR sending for whatever reason.
For those implementing TOR sends, the flow is even simpler “please send X GRN to this Slatepack address.”
Just reposting what i’ve posted on keybase some time ago, so that it doesn’t get lost.
let’s say amazon integrates grin. You have a cart with items in it and then click “checkout”. Now you have 2 different flows:
SRS:
user copies the total amount of his cart and also copies amazon’s grin address to create step1 slatepack
user enters the generated slatepack on the amazon page, amazon generates next slatepack
user copies this new slatepack and finalizes the transaction
Here amazon doesn’t know if the user has signed the tx or if the transaction didn’t reach the chain etc.
User had to copy the amount, amazon’s grin address, create the first slatepack, copy next slatepack and finalize.
RSR:
user enters his grin address (so that exchange can encrypt for him), amazon generates the new slatepack which the user copies
user generates the next slatepack through the “pay” subcommand
user pastes slatepack on the amazon page
Here amazon knows exactly the state of the transaction.
User had to paste his grin address, copy slatepack, pay to create the second slatepack and paste it
From my understand of early payment proofs, memo would need to be created in the first step of SRS (well at least that makes sense to me although it might be possible to push it to step 3 but it makes less sense), which means the user would also need to take care of the memo, instead of letting amazon automate this process - amazon has the digital cart data, so it can either populate the memo with it or generate hash of it and send you the receipt or smth. I might be wrong, but i don’t see real services being happy with the SRS flow integration
Interactivity in building payments, what a brilliant idea. How come this sounds somewhat familiar
Having the input’s and output’s amount blinded makes life much easier for Grin. Only need to adopt the part where both parties contribute inputs and the total amount of outputs equals the number of inputs to obfuscate direction to have our own privacy enhancing, blockchain bloat avoiding special payjoin.
let’s say amazon integrates grin. You have a cart with items in it and then click “checkout”. Now you have 2 different flows:
…
From my understand of early payment proofs, memo would need to be created in the first step of SRS (well at least that makes sense to me although it might be possible to push it to step 3 but it makes less sense), which means the user would also need to take care of the memo, instead of letting amazon automate this process - amazon has the digital cart data, so it can either populate the memo with it or generate hash of it and send you the receipt or smth.
Fair enough. I’m still wrapping my head around how a receiver could block payment in the second round of SRS. At that point the receiver doesn’t have a fully signed tx, do they? How does spamming an unsigned output block anything? Anyway, still reading through the papers and code to figure this out.
To me the two flows are about shifting responsibility for tx finality from one party to another. RSR flow is like handing a signed check over to Amazon, saying “I hope you cash this.” Then having to constantly monitor your bank account until the check clears. If users already struggle getting used to SRS flow, RSR seems much more complex when things go wrong.
On the other hand, when things go right, I agree that RSR is a simpler flow for the sender, and potentially the receiver. Like I said, I still have more research to do.
Thanks for looking into it. Here’s an example of how you could block it. Suppose the sender and the receiver create a transaction T through SRS. Receiver in step 2 added his output O1 so T contains O1. Receiver creates a new self-spend transaction T' which also creates O1. If they are able to push T' to the mempool/chain before T gets there, then T is invalid because it would create the same output O1. Consensus rules say that UTXO set can’t have the same output twice in it.
And this is why custodial wallets currently offer the best user experience on Bitcoin Lightning Network. Obviously that’s not great for a decentralized currency. Admittedly always online wallets are a bigger issue for Lightning because of the whole channel closing fee.
In general the comparisons of MW and Lightning are quite apt, as others here have pointed out already, they struggle with very similar UX issues. But as far as I’m aware those hurdles haven’t been overcome on the Lightning side either and I’d imagine they have a lot more People working on it.
After having some discussions today on discord, I decided to write things up in a document in case anyone wants to read what I was trying to explain. Here’s one of the big tradeoffs that the current NITX proposals make (both David’s and Gary’s).
Trustless node sync. While it’s true that Mimblewimble has a weaker model than Bitcoin, it preserves these two properties. Proof of authentication is preserved because there cannot exist any state transition in the past for which a party that owns any input/output of the state transition did not inject their blinding factor into the kernel. Replay attacks are bad and should be addressed, but they don’t break this property as the owner signed the transition for the original transaction prior to replay.
A good explanation of this problem is also in the Introduction section of MingleJingle which addresses this problem but introduces many more tradeoffs.
