# 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:** 8
**Page:** 3
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 19, 2023, 6:21pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/43 "2023-07-19T18:21:48Z")
Unless I’m mistaken, Mallory and Carol have to replay some transactions to steal Bob’s funds. Kernel uniqueness prevents it.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 19, 2023, 6:54pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/45 "2023-07-19T18:54:48Z")
> [@tevador](#):
>
> Kernel uniqueness prevents it.
Oh, right. That would indeed.
In Grin we don’t want to pay the price (indexable kernels) to enforce kernel uniqueness. In fact, we have NRD (No Recent Duplicate) kernels that can be duplicated after some time, which can be used to implement relative time locks.
---
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 19, 2023, 7:32pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/46 "2023-07-19T19:32:45Z")
I’m suspecting that the Wagner attack cannot be prevented with reusable addresses because the sender always learns some linear relation between the recipient’s keys.
Revision 4 of the 2-step protocol acknowledges the existence of the attack and tries to mitigate it in the following ways:
1. Successful execution of the attack also requires that the two groups of outputs that can be exchanged by the attacker have equal amounts.
2. Transactions can’t be replayed to steal recreated outputs that were previously spent.
The fact that the protocol requires a relatively expensive consensus rule (kernel uniqueness) is not ideal, but I don’t have a better solution at the moment. The takeway is that doing 2-step transactions securely is harder than it seems.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [July 19, 2023, 9:30pm UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/47 "2023-07-19T21:30:29Z")
> [@tevador](#):
>
> Revision 4 of the 2-step protocol acknowledges the existence of the attack
Feel free to credit its discoverer:-)
> [@tevador](#):
>
> 1. Transactions can’t be replayed to steal recreated outputs that were previously spent.
When you say “The first public key in every transaction kernel must be unique”, is that intended to apply to both the SASchnorr signatures as well as the regular Schnorr signatures?
---
### Author:  [@tevador](https://forum.grin.mw/u/tevador)
#### Post date: [July 20, 2023, 9:56am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/48 "2023-07-20T09:56:21Z")
> [@tromp](#):
>
> Feel free to credit its discoverer:-)
Added.
> [@tromp](#):
>
> When you say “The first public key in every transaction kernel must be unique”, is that intended to apply to both the SASchnorr signatures as well as the regular Schnorr signatures?
My assumption was that SASchnorr would be used in all cases to hide single-party transactions. Similarly, Monero requires all transactions to have at least 2 outputs. It’s a tradeoff between privacy and efficiency.
In any case, this protocol cannot tolerate replays, so kernel uniqueness would have to be applied to 3-step transactions as well if they were allowed.
---
### Author:  [@noobvie](https://forum.grin.mw/u/noobvie)
#### Post date: [July 25, 2023, 2:06am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/49 "2023-07-25T02:06:39Z")
Can Grin be built something like gift card? i write a code/qr code in the paper, user just input that code into the grin wallet then his balance will decrease/increase accordingly?
---
### Author:  [@Trinitron](https://forum.grin.mw/u/Trinitron)
#### Post date: [July 25, 2023, 4:17am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/50 "2023-07-25T04:17:17Z")
We have thought about “grin vouchers” before where you would basically provide someone the private key to a wallet as a one step gift card.
It has the obvious bug or feature that the gifter retains access to the funds until the recipient redeems it, but that would be acceptable in many contexts.
With some client side code the generation and redemption of these “vouchers” via a QR could be automated and easy. TX fees would be paid twice, on generation and again on redemption.
---
### Author:  [@vegycslol](https://forum.grin.mw/u/vegycslol)
#### Post date: [July 25, 2023, 11:44am UTC](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627/51 "2023-07-25T11:44:57Z")
> [@Trinitron](#):
>
> It has the obvious bug or feature that the gifter retains access to the funds until the recipient redeems it
To be fair, all vouchers we use today have this property. The only way for that to not be the case would be if the voucher was made with some data of the receiver, but that would make voucher creation flow a bit more annoying.
[Previous page](https://forum.grin.mw/t/eliminating-finalize-step-revisited/10627.md?page=2)