I looked at the contract and there are two ways to transfer grin, SRS and RSR. The interaction method is still A->B->A, or B->A->B, so I don’t understand what’s special about it compared with the original one.
In short, transaction contracts are an attempt to conceptually unify different transaction flows that we do not want regular users to be bothered with. Users just need to understand that a transaction requires each party to sign the “transaction contract”, that’s all anyone needs to understand unless they want to know more.
Conceptually, any transaction can be seen as a transaction contract that requires those who send and those who receive coins to sign the transaction contract. It is combined with unified payment proofs (works for both SRS and RSR the same). Furthermore contract transaction flow is kind of a preparation for the future when perhaps multiparty transactions contracts (e.g. MultiSig) will become possible (currently not possible due to some complications when more than two parties are involved and payment proofs).
For further reading:
2 Likes
A contract is just a unification of SRS and RSR with the same commands and the idea that you want to manually confirm the transaction will be signed. While this is possible in the old flow, it’s often automated for the receiver. I believe some of this desire to automate this part comes from the fact that people are used to Bitcoin-like transactions which don’t require the receiver to do anything to process a payment. Obviously, I can’t speak for others, but my view is that requiring interactive action is a bonus for a very simple reason: both parties see the changes that are about to happen before they sign off on them. This eliminates all kind of output injection attack (e.g. dust attacks, taint attacks,…) which are impossible to prevent on other networks because actions are not signed by all the parties involved. Moreover, both parties checking what gets signed can also catch a mistake before it’s published on the network. As this post explains, there’s some other small details that are changed in this flow like txs defaulting to payjoins, kernel cost is split equally, each party pays for their own input and output fees, late-locking by default etc.
Whether people end up calling these contracts, multisigs, or something else is less important than showing the sign step. Rather than trying to hide the sign step, let’s accept that it’s inherent to Mimblewimble and try to take the advantages it can offer.
5 Likes
I understand a lot of the meaning of grin contract, thank you very much.
Like you said this prevents many types of attacks and is more secure.
Thank you for your explanation. The contract unifies the transaction process and will indeed play a great role in future development.