I’m not calling anybody arrogant. I’m saying a particular belief is an arrogant view.
I think lightning devs are trying to work towards a more bitcoin-like experience as much as the tech will permit. Most LN devs will tell you it’s not yet ready for everyday use. They’re still trying to find ways to minimize interactivity. We OTOH make arguments for why interactivity is good, and it’s just users who are wrong.
Another difference is bitcoin already has much more adoption. LN is somewhat like when credit card companies started switching to the new, annoying chips for enhanced security.
We’re also trying to find ways to minimize interactivity. But not by compromising the original goal of the project to provide a minimal MW implementation.
We argue that interactivity is great for robustness, and not as bad as you make it out to be for usability. It’s an extra cut-and-paste.
Could’ve fooled me. I’ve seen vegycsol and phyro say interactivity is the distinguishing feature of Grin.
Anyhow, the point remains that users are unlikely to change how they transact just to use Grin. Similarly, LN will struggle to achieve adoption unless they are able to adapt to existing processes.
I still hold that opinion tbh - the user should have the option not to accept the funds imo. I’ve only seen vegycslol agree with the manual user interactivity, nobody else said it’s a good idea apart from him - at least I can’t recall anyone supporting it. I understood tromp’s point as talking about minimization of the steps needed
yes i’ve said that and i still think it is since if you don’t have interactivity you can’t reject an incoming utxo. I do think that the constant emission seems like another unique thing, probably even bigger than the interactivity
Although to be frank, we have already established after lengthy discussions in Keybase, that the ability to selectively approve incoming UTXOs can also be achieved solely by wallet requirements, which Grin is in the best position to enforce, since interaction is already the standard.
This effectively creates 2-step transactions if done through an RFC with sufficient consensus. It could also just be a ‘switch’ which the user flicks on or off, choosing whether he wants grin-style or bitcoin-style transaction flow (the first providing some benefits and could be the default).
Which leaves us with only one real argument against Non-interactive transactions; The theoretical and practical complexity it brings. On this, I can hardly be the judge.
@Paouky Something like this? It should be no problem to research this information. The filled in YES/NO fields have not been researched yet and just placeholders.
I agree. Interaction is a feature in this sense. Many payment methods that we use today are interactive in one way or the other. For me it is the third step that seems unnecessary and bureaucratic from a user’s point of view. The protocol requires it at the moment for technical reasons, but for the transaction partners after invocation (1) and confirmation (2) everything is already said that needs to be said about their intentions.
@Grundkurs Yes exactly.
Perhaps also a field that says whether withdrawals are active at the moment (although this may be hard to check sometimes, so we could rely on everybody’s input).
The second step is one party signing for the tx, and the third step is the other party (counter) signing.
Neither one can be omitted. Both parties need to confirm. The second and third steps are both confirmations.
Only the first step (what you call invocation) can possibly be omitted.
My point is that when two parties have confirmed the transaction, it is hard to explain why a third step would be needed, maybe that’s why I have a hard time to understand it after hours of trying.
@grn You can think of it this way: Both parties need to sign (confirm) the transaction, which makes sense.
But, the first step (called “send”) only gives the receiver what he needs to know in order to sign the transaction. This is required for a Schnorr signature between two parties; They both have to build their signature on a common value, and so the receiver has to know its value before he can sign.
The second step (named “receive”) is the receiver doing this signing I mentioned. This is in effect a partial signature, because the full transaction signature needs to be product of both sides. The receiver sends this over to the sender.
The third step (named “finalize”) is the sender signing (aka confirming) it himself. Only now does he do it, not in the first step. Then he can post it to the chain since the Schnorr signature is complete.
I also want to know why the 5.0 upgrade is so troublesome that most exchanges are unable to recharge and withdraw cash? Is there any technical problem with the exchange? Or is there something wrong with this upgrade of GRIN?
