Mimblewimble-cheque: Scalable blockchain with 2-step transactions
It’s a slightly different approach than the existing proposals. It uses a provably secure signature algorithm based on a 2022 paper about half-aggregation of signatures. A notable drawback is that the kernel size is 160 bytes instead of 96 bytes with vanilla Mimblewimble, but someone might still find it interesting.
When I’ve been thinking about 2 step i came to the conclusion that we would require a “hello” message to enable slatepack step1 spam filtering. So for example if person A wants to send coins to person B then both should first introduce themselves (exchange some data which is specific for this person, eg. B sends his grin address which is constructed specifically for person A, so that when he gets slatepack step 1 from A he knows it’s from A - note that A might have leaked this address to C and C starts spamming, so you know who leaked (A) and therefore know who to block).
MWC - sounds like Grin fork 
Thank you, it’s very educative, especially SASchnorr part.
Thank you for writing this up, @tevador. This is the most exciting research I’ve read all year.
I’m curious, why is timestamp included independently from the transaction description? Is the timestamp significant to the protocol in some way I don’t understand?
The timestamp and payment description are not strictly needed for security, they are just auxiliary fields to ensure the uniqueness of s. However, the public key P, the amount v and the nonce n are strictly needed for security as they prevent certain attacks.
In my opinion, it doesn’t make sense to make adjustments to the formula.
I think all the characteristics of Grin are positive, especially in terms of monetary policy and technology. However, what we lack at Grin is an industry to support it. Without industries built around Grin, the coin itself holds little value.
e-commerce is big industry, just use QR codes to send/receive slatepacks, all we need is proper SDK/plugin 
其实跨境电商也是可行的，但是缺少技术的宣传，和推广，希望grin蒸蒸日上,感谢无私的奉献者
Any industry that can amass 1,000,000 to 10,000,000 citizens.
I really don’t want e-commerce
I really want ( Identification system )
Imagine an identification system that operates on grin, much like how a car relies on gasoline. This concept envisions a unique approach where grin, a cryptocurrency, plays a central role in powering the system’s functionality.
Grin approach is internet-money, digital cash, Identification system you can get at your bank with CBDC, good luck with this 
As motIvation of the new protocol you mention that MW imposes a usability hurdle:
it either forces both Alice and Bob to be online at the same time or possibly face long delays caused by either party to complete the transaction.
But the MWC protocol still has a lesser usability hurdle: a long delay can be caused by the recipient to complete the transaction.
While MW might have two such delays, it’s only the latter that introduces uncertainty as to whether the transaction will complete.
For the sake of argument, that is much less of a user-experience penalty than the 3-step model. In the 2-step model, Alice can sign her cheque, send it to Bob, and forget about it. Even if Bob takes a long time to cash his cheque, that only hurts Bob. Alice has no UX penalty for Bob’s delay.
In the 3-step model, however, if Bob takes a long time, it penalizes Alice too, by requiring her to come back online according to Bob’s schedule. Or if Alice is no longer available, the TX may never complete and Bob is penalized for Alice being unavailable.
Sure, both models have usability tradeoffs, but the 2-step model makes it so neither party is dependent on the other’s schedule, which leads to a clearly better UX. Is it worth the extra kernel size? Is it worth introducing addresses, instead of remaining ‘address-less’? Maybe not. But its certainly a UX improvement.
The benefits of a 2-step protocol were discussed at length here: Eliminating finalize step
From my understanding, it has been considered to be an improvement.
My goal was to provide a 2-step protocol that does not compromise on security. Whether the costs are worth the benefits is not something I can answer.
Jast as in the 3-step model, e.g. RSR initiated by Bob, Alice can sign her cheque in round 2, send it to Bob, and forget about it. This is not a difference between the two models.
The difference is that in MW, Bob has to send key material to Alice in round 1 when requesting payment.
IMO it’s more accurate to say it eliminates the first step rather than the final one.
It is an improvement, but your write-up would be more accurate saying that it lessens the usability hurdle, rather than suggest it eliminates it.
That is not always the case. Alice might already know Bob’s long-term address, in which case MWC does not need the first step. In the 3-step protocol, Bob can’t have a long-term key that is sufficient for Alice to construct her half of the signature.
That’s not true for invoices though since receiver still has to wait for the sender to get the coins. Also when doing standard payment (SR) you will have to lock your utxos as the sender, which makes ux worse imo.
You misunderstood me. I’m saying that the difference is that MWC doesn’t need to send key material before the first signing step, while MW does.
OK, noted. The previous discussions are referring to the 2-step protocol as “eliminating the finalize step”, so I kept the terminology.
“Bob verifies that he has never received a payment with this sending key before.”
What if he reinstalled the wallet (does he need to check that timestamp is after his last transaction)? If yes, should we expect people to carefully check each timestamp?