protocol: Spam deterrence #675
Conversation
This issue has been assigned a bounty (💰)Current bounty:
Exceptions for this specific bountiesDue to the nature of this issue (cryptographic/protocol complexity rather than implementation complexity) the bounty will also be used to fund audits. Bounty donation addressIf you want to incentivize work on this issue, you can help increase the bounty by donating to the address below. Fine printWe use bounties to incentivize development and reward contributors. All issues available for a bounty have the To receive the bounty of this issue, you agree to these conditions:
|
|
Can you elaborate when partial refund will be done instead of full refund and punish? It seems like Bob needs Alice to get 10% of his money back in case of partial refund. |
|
Yes. This update will essentially move some trust requirement from the maker (that the taker is not a spammer) to the taker (that the maker will refund). However, this can be addressed as follows:
Everyone would be better off if this wasn't necessary, but it is. That's the sad truth. |
|
I am not sure if i and others understand your words "takers might choose to only start swaps for which the maker has already provided the full refund address. Thus not requiring the maker to fully refund" can you rephrase it please? sorry "the maker does not gain anything from withholding the refund, thereby he is not incentivized to do so" Can you elaborate when partial refund will be done instead of full refund and punish? |
I am also trying to understand but here is how I interpreted it: Makers will have the choice to offer full refunds or partial refunds. The taker will know the maker's refund policy before they begin a swap. The full refund policy is straightforward: If the taker cancels, they get the full refund. For the partial refund policy, if the taker cancels, they are not guaranteed to receive 100% of their money back. The purpose of this is to disincentivize malicious takers from abandoning swaps because they know there is no penalty for doing so. If you as a taker do not like the idea of a partial refund, you as a free market participant, can refuse to do business with that maker. Because partial refunds mean less risk to the maker, this will allow them to offer lower rates.
He lost his money due to negligence (or at least failure to understand the refund process). As the docs state "With most makers, you can still redeem the Monero even after being punished. This is, however, purely voluntary and we advise against relying on this." |
|
That would mean either makers are ok with full refund = they automatically give it, or they are not ok with full refund, meaning they will also not help giving it. Its just 10% scam. Its not even remotely justified as fees of all makers are currently around 2%, why should a taker loose 10%? |
It's not a scam if you know what you are agreeing to. The taker also doesn't lose anything if they simply complete the swap like they agreed to. Makers are not obligated to hand out free 12 hour XMR call options. Adding a partial refund support will actually help honest takers. If there is not penalty, a maker can lock up the liquidity of other makers that offer lower rates than them. Then they can jack up their rate because their competition is gone. This is effectively a Denial of Service attack against makers. |
|
If thats the worry the penality fee should at maximum be the fee that they ask from the user for a completed trade, not a flat 10% |
The XMR price movement also needs to be taken into account here — it can easily move 5–8% during those 12 hours. |
|
It is not a flat 10%. The 10% is purely for demonstrational purposes. The percentage can be dynamically configured by the maker. |
I wanted to specify this in a bit more in detail as they seems to be some confusion around the bounty on this issue. In general donations to specific issues will NEVER go directly to neither me nor @Einliterflasche. Issue specific bounties are for funding work of outside contributors. Donations to this issue will not necessarily result in me implementing this in a faster manner. Donations will be used to potentially fund an outside contributor to give this a review to assess the security of this on the protocol level. As the funds collected here are unlikely to be enough to fund a full audit (something like TrailOfBits would do) this is going to be "light review" most likely with no attribution to the reviewer. We are in talks with someone who is well trusted in the Monero community and is more than enough qualified. If we don't find a reviewer, the funds will be used for other bounties. |
|
Shouldnt a protocol change be fully audited? |
No, not at all protocol changes necessarily require an audit. We are not introducing any new novel cryptography here. I understand the concern here though. This will obviously be well tested. |
Note
Introduces partial refund by splitting cancel spend into refund + amnesty outputs with a new amnesty-spend transaction, and updates the UI alert to handle null swaps safely.
TxCancel::build_refund_with_amnesty_transactioncreates a refund to user plus an amnesty output (shared descriptorA,B).TxRefund::new(...)updated to takeA,Bandamnesty_amount, store amnesty descriptor, and compute sighash; adds helpersamnesty_amount(),amnesty_outpoint(),build_amnesty_spend_transaction().TxRefundAmnestytype to spend the amnesty output: constructs tx, computes digest, adds signatures, exposes weight and watch script.TxRefundAmnesty; addsrefund_amnestymodule.SwapStatusAlertacceptsswap: GetSwapInfoResponseExt | null, derivesswapIdsafely, and short-circuits on null;StateAlertalso guards null.swapId).Written by Cursor Bugbot for commit 266e3a1. This will update automatically on new commits. Configure here.