# Eliminating finalize step revisited
**URL:** https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627
**Category:** Research
**Created:** [July 10, 2023, 9:49pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627 "2023-07-10T21:49:42Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 10, 2023, 9:49pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/1 "2023-07-10T21:49:42Z")
[Mimblewimble-cheque: Scalable blockchain with 2-step transactions](https://gist.github.com/tevador/96af9c8ea6e297e3db8969eaaf4aefcf)
It’s a slightly different approach than the existing proposals. It uses a provably secure signature algorithm based on a [2022 paper](https://eprint.iacr.org/2022/222) 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.
---
### Author:  [@vegycslol](https://forum.grin.mw/u/vegycslol)
#### Post date: [July 10, 2023, 10:05pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/2 "2023-07-10T22:05:35Z")
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).
---
### Author:  [@ardocrat](https://forum.grin.mw/u/ardocrat)
#### Post date: [July 10, 2023, 10:26pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/3 "2023-07-10T22:26:47Z")
MWC - sounds like Grin fork 😂
Thank you, it’s very educative, especially SASchnorr part.
---
### Author:  [@AceKaplin](https://forum.grin.mw/u/AceKaplin)
#### Post date: [July 11, 2023, 2:30am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/4 "2023-07-11T02:30:40Z")
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?
---
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 11, 2023, 6:11am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/5 "2023-07-11T06:11:04Z")
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.
---
### Author:  [@Goonyer](https://forum.grin.mw/u/Goonyer)
#### Post date: [July 11, 2023, 8:09am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/6 "2023-07-11T08:09:36Z")
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.
---
### Author:  [@ardocrat](https://forum.grin.mw/u/ardocrat)
#### Post date: [July 11, 2023, 8:39am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/7 "2023-07-11T08:39:39Z")
> [@Goonyer](#):
>
> 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 🙂
---
### Author:  [@pengliangfui](https://forum.grin.mw/u/pengliangfui)
#### Post date: [July 11, 2023, 10:00am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/8 "2023-07-11T10:00:59Z")
其实跨境电商也是可行的，但是缺少技术的宣传，和推广，希望grin蒸蒸日上,感谢无私的奉献者
---
### Author:  [@Goonyer](https://forum.grin.mw/u/Goonyer)
#### Post date: [July 11, 2023, 10:31am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/9 "2023-07-11T10:31:05Z")
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.
---
### Author:  [@ardocrat](https://forum.grin.mw/u/ardocrat)
#### Post date: [July 11, 2023, 10:37am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/10 "2023-07-11T10:37:24Z")
> [@Goonyer](#):
>
> I really don’t want e-commerce
>
> I really want ( Identification system )
Grin approach is internet-money, digital cash, Identification system you can get at your bank with CBDC, good luck with this 😃
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 11, 2023, 3:10pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/13 "2023-07-11T15:10:13Z")
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.
---
### Author:  [@AceKaplin](https://forum.grin.mw/u/AceKaplin)
#### Post date: [July 11, 2023, 3:39pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/14 "2023-07-11T15:39:19Z")
> [@tromp](#):
>
> But the MWC protocol still has a similar usability hurdle: a long delay can be caused by the recipient to complete the transaction.
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.
---
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 11, 2023, 4:24pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/15 "2023-07-11T16:24:11Z")
> [@tromp](#):
>
> But the MWC protocol still has a similar 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.
The benefits of a 2-step protocol were discussed at length here: [Eliminating finalize step](https://forum.grin.mw/t/eliminating-finalize-step/7621)
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.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 11, 2023, 4:25pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/16 "2023-07-11T16:25:44Z")
> [@AceKaplin](#):
>
> 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.
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.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 11, 2023, 4:29pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/17 "2023-07-11T16:29:18Z")
> [@tevador](#):
>
> The benefits of a 2-step protocol were discussed at length here: [Eliminating finalize step](https://forum.grin.mw/t/eliminating-finalize-step/7621)
IMO it’s more accurate to say it eliminates the first step rather than the final one.
> [@](#):
>
> From my understanding, it has been considered to be an improvement.
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.
---
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 11, 2023, 4:33pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/18 "2023-07-11T16:33:02Z")
> [@tromp](#):
>
> The difference is that Bob has to send key material to Alice in round 1 when requesting payment.
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.
---
### Author:  [@vegycslol](https://forum.grin.mw/u/vegycslol)
#### Post date: [July 11, 2023, 4:42pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/19 "2023-07-11T16:42:40Z")
> [@AceKaplin](#):
>
> but the 2-step model makes it so neither party is dependent on the other’s schedule, which leads to a clearly better UX
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.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 11, 2023, 4:45pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/20 "2023-07-11T16:45:54Z")
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.
---
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 11, 2023, 5:01pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/21 "2023-07-11T17:01:45Z")
OK, noted. The previous discussions are referring to the 2-step protocol as “eliminating the finalize step”, so I kept the terminology.
---
### Author:  [@vegycslol](https://forum.grin.mw/u/vegycslol)
#### Post date: [July 13, 2023, 2:39pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/22 "2023-07-13T14:39:17Z")
“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?
[Next page](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627.md?page=2)