Unless I’m mistaken, Mallory and Carol have to replay some transactions to steal Bob’s funds. Kernel uniqueness prevents it.
1 Like
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.
2 Likes
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:
- Successful execution of the attack also requires that the two groups of outputs that can be exchanged by the attacker have equal amounts.
- 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.
4 Likes
Feel free to credit its discoverer:-)
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?
Added.
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.
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?
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.
1 Like
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.