protocol: Spam deterrence #675

binarybaron · 2025-11-04T19:12:31Z

This PR introduces a change in the atomic swap protocol to discourage spam. It does so by attaching a fee to refunds. This fee will be burnt.

Current situation

The exchange rate of each swap is set at the start and can't be changed.
A swap either completes within 12 hours (this requires cooperation by both parties), or be cancelled.
A swap might still be cancelled after both parties lock their respective currency.

In that case the taker ("Bob") can issue a refund within a 24 hours window. He will get his Bitcoin back and the maker ("Alice") will get her Monero back.

The problem

This can be abused by malicious takers in two ways:

A maker with significantly higher reserves than other makes might use part of it to block other maker's reserves.
This is possible by initiating a swap and waiting for the maker to lock the Monero.
Then not continue the swap and wait for a refund.
This will only cost the malicious actor transaction fees for 3 Bitcoin transactions, while preventing the "small maker" from competing in the market for trading volume.
A malicous actor might start a swap and decide only to complete it when the exchange rates change in their favor enough.
If that doesn't happen they can refund for the low cost of 3 Bitcoin transactions.
This allows the malicious actor to treat the swap like a (bascially) free Monero call option.

The solution

The root problem causing both these issues is that refunds are free (for the taker).
By attaching a cost to refunds (only refunding a part of the Bitcoin) this is no longer the case.
Thus both tactics are no longer profitable.

Makers will be able to set the extend of the refund fee. Takers will know the refund fee prior to starting a swap and decide whether to trade or not.

The refund fee does not go to the maker. That would create skewed incentives. The refund fee will be "burnt". The only way to retrieve it is for the maker to sign a transaction giving it back to the taker.

However, the maker will be able to voluntarily give the taker a full refund. This is what we call "amnesty" for now. This is intended such that makers can help out clueless takers who accidentally refunded.
This path is, however, purely voluntary and takers can't 100% rely on it.

Implementation

binarybaron · 2025-11-04T19:16:09Z

This issue has been assigned a bounty (💰)

Current bounty:

0 XMR contributed by @binarybaron and @Einliterflasche
0.60433 XMR contributed by the eigenwallet community

Exceptions for this specific bounties

Due to the nature of this issue (cryptographic/protocol complexity rather than implementation complexity) the bounty will also be used to fund audits.

Bounty donation address

If you want to incentivize work on this issue, you can help increase the bounty by donating to the address below.

87UHJU9GA3qHn4sX4ZZndEERmqEXx94kuS3QFZ1XGVNg28YcWX2H9AqBh5G6Uc4cfmKRbTDQ3HgsoVKW1RuPHtzLSUEHrmN

Fine print

We use bounties to incentivize development and reward contributors. All issues available for a bounty have the Bounty 💰 label.

To receive the bounty of this issue, you agree to these conditions:

Bounties will be set and awarded at discretion of @binarybaron
An issue is considered resolved when the patch(es) proposed by the contributor is/are merged in the appropriate repository according to terms of the issue.
The first person who resolves an issue in its entirety will receive the entire amount of the bounty.
If the issue is resolved collaboratively by more than one person, the reward will be distributed among the contributors
Donating to the bounty does not guarantee that this issue will be completed and refunds are generally not issued. If they are then they are granted at the discretion of @binarybaron

pokefan77 · 2025-11-07T11:51:14Z

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.
Why 10% of Bobs money is at risk in case Alice doesnt coorporate, which happened before with some makers!

Einliterflasche · 2025-11-07T12:00:58Z

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:

a decentralized reputation system. Takers who didn't get the refund can publish a proof, thereby discouraging other takers from swapping with this maker
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
the maker does not gain anything from withholding the refund, thereby he is not incentivized to do so

Everyone would be better off if this wasn't necessary, but it is. That's the sad truth.

pokefan77 · 2025-11-07T12:21:44Z

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"
your phrasing is totally misleading, confirming your narrative. My question was why Bobs 10% are at risk, and neutrally said the truth is: "the maker does not gain anything from releasing the refund, thereby he is not incentivized to do so"
Its the same situation as btc punished. the truth is that there is even ongoing discussion on matrix because somebody lost his big amount of money because the maker did not help him, because he has 0 incentive to do so.

Can you elaborate when partial refund will be done instead of full refund and punish?

jstark2a · 2025-11-07T18:57:23Z

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

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.

somebody lost his big amount of money because the maker did not help him, because he has 0 incentive to do so.

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."

pokefan77 · 2025-11-07T22:05:29Z

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%?

jstark2a · 2025-11-07T23:38:32Z

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.

pokefan77 · 2025-11-08T06:07:32Z

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%

Franz-Hermann-GT · 2025-11-08T08:48:49Z

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.
In most cases, takers cancel the swap when the XMR price drops during that period. As mentioned earlier, this effectively works like a free call option.

binarybaron · 2025-11-08T15:37:57Z

It is not a flat 10%. The 10% is purely for demonstrational purposes. The percentage can be dynamically configured by the maker.

binarybaron · 2025-11-08T19:49:58Z

This issue has been assigned a bounty (💰)

Current bounty:

0 XMR contributed by @binarybaron and @Einliterflasche

0.60433 XMR contributed by the eigenwallet community

Exceptions for this specific bounties

Due to the nature of this issue (cryptographic/protocol complexity rather than implementation complexity) the bounty will also be used to fund audits.

Bounty donation address

If you want to incentivize work on this issue, you can help increase the bounty by donating to the address below.
87UHJU9GA3qHn4sX4ZZndEERmqEXx94kuS3QFZ1XGVNg28YcWX2H9AqBh5G6Uc4cfmKRbTDQ3HgsoVKW1RuPHtzLSUEHrmN
Fine print

We use bounties to incentivize development and reward contributors. All issues available for a bounty have the Bounty 💰 label.

To receive the bounty of this issue, you agree to these conditions:

Bounties will be set and awarded at discretion of @binarybaron

An issue is considered resolved when the patch(es) proposed by the contributor is/are merged in the appropriate repository according to terms of the issue.

The first person who resolves an issue in its entirety will receive the entire amount of the bounty.

If the issue is resolved collaboratively by more than one person, the reward will be distributed among the contributors

Donating to the bounty does not guarantee that this issue will be completed and refunds are generally not issued. If they are then they are granted at the discretion of @binarybaron

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.

pokefan77 · 2025-11-08T20:09:06Z

Shouldnt a protocol change be fully audited?

binarybaron · 2025-11-08T20:14:37Z

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.

src-gui/src/renderer/components/alert/SwapStatusAlert/SwapStatusAlert.tsx

…fund.rs and add backwards compatible BobRefundType for abstracting over refund signatures

Einliterflasche · 2025-12-17T17:12:56Z

I'm trying to understand this. Does it basically mean the taker by default will get a 100% refund, unless the maker chooses to intervene during the 2-block window to deny them, say 2%, of the refund?

That is correct. The actual amount/percentage that is "burnable" is negotiated before the swap starts.Makers will be able to configure it on their end. Takers can choose whether to start a swap with the given maker's conditions or not.

The reasoning behind this is that makers are always online, and as such can handle a short timeframe.

There will also be a system in the controller for makers to say that a specific swap's refund should be burnt, if it gets refunded.

…y_amount == 0

:

pokefan77 · 2025-12-18T11:42:37Z

what reputation system are you refering to?

…FinalAmnesty when the amnsty output is greater than zero

binarybaron · 2025-12-19T13:03:05Z

src-gui/src/renderer/components/alert/SwapStatusAlert/SwapStatusAlert.tsx

    case BobStateName.CancelTimelockExpired:
    case BobStateName.BtcCancelled:
    case BobStateName.BtcRefundPublished: // Even if the transactions have been published, it cannot be
+    case BobStateName.BtcPartialRefundPublished: // Even if the transactions have been published, it cannot be


incomplete comment

binarybaron · 2025-12-19T13:03:47Z

src-gui/src/renderer/components/pages/swap/swap/done/BitcoinRefundedPage.tsx

+
+export function BitcoinPartialRefundPublished() {
+  return (
+    <>TxPartialRefund published</>


Too little information for the user to understand what is going on

binarybaron · 2025-12-19T13:06:20Z

swap-env/src/config.rs

-    // By default, we do not tip
-    Decimal::ZERO
+#[derive(Clone, Debug, Deserialize, PartialEq, Eq, Serialize)]
+pub struct RefundPolicy {


Make this an enum?

binarybaron · 2025-12-19T13:08:02Z

swap-machine/src/alice/mod.rs

+        // When the amnesty output is zero, we can't construct the tx partial refund transaction
+        // due to an integer underflow.
+        // We only send the cancel and full refund signatures.
+        if self.btc_amnesty_amount.unwrap_or(bitcoin::Amount::ZERO) == bitcoin::Amount::ZERO {


this is also true when btc_amnesty_amount < fee required to spend it

also btc_amnesty_amount as a name for this is a bit ambigious

maybe something like btc_refund_potential_burn, not sure though

binarybaron · 2025-12-19T13:09:35Z

swap-machine/src/alice/mod.rs

+        // We sent Bob the encsig for the full refund path already, so we don't
+        // care about the partial refund path signatures of Bob anyway.
+        // We just save `None`.
+        if self.btc_amnesty_amount.unwrap_or(bitcoin::Amount::ZERO) == bitcoin::Amount::ZERO {


same here as above, also perhaps extract this into some trait that allows checking if the amount is high enough to construct a transaction for it?

Einliterflasche · 2025-12-19T13:10:19Z

what reputation system are you refering to?

Currently there is no reputation system. But now that makers can, in theory, burn some of the refund of the takers we still want to incentivize not doing that.

The taker could proof that the maker burnt the funds by sharing TxRefundBurn. This means takers can avoid makers who are shown to haven often burnt refunds in the past.

swap-machine/src/lib.rs

binarybaron · 2025-12-19T13:11:13Z

swap-orchestrator/src/lib.rs

 pub mod containers;
 pub mod images;
+
+use anyhow as _;


why is this necessary? maybe we should hide some of these crates behind a flag if there only used for the binary?

binarybaron · 2025-12-19T13:12:13Z

swap-p2p/src/out_event/alice.rs

+        // should go into the amnesty output
+        send_wallet_snapshot: bmrng::RequestReceiver<
+            bitcoin::Amount,
+            (swap_setup::alice::WalletSnapshot, bitcoin::Amount),


extract this into a named tuple or add an explicit comment above this line (// (snapshot, amnesty_amount)

binarybaron · 2025-12-19T13:15:48Z

swap-p2p/src/protocols/quote.rs

 #[typeshare]
 pub struct BidQuote {
    /// The price at which the maker is willing to buy at.
-    #[serde(with = "::bitcoin::amount::serde::as_sat")]


I think its good to keep these for completeness snake. We want the network protocols serialization to be defined as explicitly as possible.

binarybaron · 2025-12-19T13:16:02Z

swap-p2p/src/protocols/swap_setup.rs

 pub enum SpotPriceError {
    NoSwapsAccepted,
    AmountBelowMinimum {
-        #[serde(with = "::bitcoin::amount::serde::as_sat")]


same here, I think we should keep them

binarybaron · 2025-12-19T13:19:07Z

swap/tests/partial_refund_bob_claims_amnesty.rs

+/// Bob locks Btc and Alice locks Xmr. Alice does not act so Bob does a partial
+/// refund, waits for the remaining refund timelock, and then claims the amnesty.
+#[tokio::test]
+async fn given_partial_refund_bob_claims_amnesty_after_timelock() {


We need another integration tests for the other paths

pokefan77 · 2025-12-19T18:49:19Z

what reputation system are you refering to?

Currently there is no reputation system. But now that makers can, in theory, burn some of the refund of the takers we still want to incentivize not doing that.

The taker could proof that the maker burnt the funds by sharing TxRefundBurn. This means takers can avoid makers who are shown to haven often burnt refunds in the past.

while the idea is great its easily avoided: just swipe setup and get new maker identity if labeled as described above
as there is currently no benefit of maintaining a "Identity"

Franz-Hermann-GT · 2025-12-19T20:00:25Z

what reputation system are you refering to?

Currently there is no reputation system. But now that makers can, in theory, burn some of the refund of the takers we still want to incentivize not doing that.
The taker could proof that the maker burnt the funds by sharing TxRefundBurn. This means takers can avoid makers who are shown to haven often burnt refunds in the past.

while the idea is great its easily avoided: just swipe setup and get new maker identity if labeled as described above as there is currently no benefit of maintaining a "Identity"

I think there is an important asymmetry here: maker identities are much more costly to rotate than taker identities. A taker can reset their identity with a simple reinstall, while a maker typically runs long-lived infrastructure with stable liquidity and uptime.
This also means that a simple “burn count”–based reputation could unfairly penalize makers who are actively targeted by spammers. That would make a maker's identity look “bad” purely because he's being attacked, not because he misuses burns.
Additionally, due to the recent improvements, the number of swaps failing for purely technical reasons is converging towards zero. This means that most remaining aborts are behavioral rather than technical, which makes contextual interpretation of burns even more important.

Franz-Hermann-GT · 2025-12-19T20:26:22Z

As a side note, the previously used “went online X days ago” metric (or similar) could also be a useful additional signal for makers, as it naturally reflects identity persistence and operational stability.

jstark2a · 2025-12-19T21:21:01Z

cancels leave fingerprints on the blockchain that are very easy to spot (deposit, cancel 72+ blocks later, refund < 144 blocks later)
I may write a script to blacklist swaps from takers that are linked to cancels for large amounts

Franz-Hermann-GT · 2025-12-19T21:41:05Z

Maintaining a simple taker peer ID–based blacklist can be quite effective, too

jstark2a · 2025-12-19T21:49:05Z

Maintaining a simple taker peer ID–based blacklist can be quite effective, too

I noticed the spammer (linked to the same btc), usually rotates peer ids now

binarybaron marked this pull request as draft November 4, 2025 19:12

binarybaron changed the title ~~protocol: Partial refund~~ protocol: Spam deterrence Nov 8, 2025

binarybaron mentioned this pull request Nov 12, 2025

Use bech32m taproot instead of outdated bech32 segwit #660

Open

binarybaron added the protocol label Nov 12, 2025

nabijaczleweli reviewed Nov 19, 2025

View reviewed changes

src-gui/src/renderer/components/alert/SwapStatusAlert/SwapStatusAlert.tsx Show resolved Hide resolved

Einliterflasche force-pushed the protocol/partial-refund branch 2 times, most recently from 266e3a1 to c5e0871 Compare December 1, 2025 15:32

binarybaron added 2 commits December 1, 2025 17:01

fix react bug nullish check

dbc4949

add tx_refund_amnesty

f46f4ee

Einliterflasche force-pushed the protocol/partial-refund branch from c5e0871 to f46f4ee Compare December 1, 2025 16:01

Einliterflasche added 7 commits December 1, 2025 18:28

move TxPartialRefund to partial_refund.rs and TxFullRefund to full_re…

95b9e32

…fund.rs and add backwards compatible BobRefundType for abstracting over refund signatures

remove unnecessary functions on BobRefundType

2d8f843

move run_swap_setup of alice into seperate function

6cdf507

change tx_refund_encsig to tx_partial_refund_encsig in Message3

208f485

add amnesty_amount and tx_partial_refund_fee to swap_setup

9e4cfff

add tx_partial_refund_fee to NewSwap

1842cac

fix compilation errors in bitcoin wallet tests

f5b7984

Einliterflasche added 8 commits December 17, 2025 18:36

Merge branch 'hardfork/v4' into protocol/partial-refund

31a6267

alice: sent encsig for TxFullRefund during swap setup when btc_amnest…

06478eb

…y_amount == 0

bob: make fee fiels in state puiblic

6cfe009

tests: add integration test for partial refund + amnesty

0276e8c

:

alice: don't try to publish TxRefundAmnesty

92c7ee3

add new integration test to ci

840d029

fmt

a91ac5f

controller: output table when running get-swaps

15ed690

Einliterflasche added 2 commits December 18, 2025 16:47

controller: display more information about swaps

8a4ac95

swap-setup(alice+bob): only construct TxRefundAmnesty/TxRefundBurn/Tx…

db2343f

…FinalAmnesty when the amnsty output is greater than zero

binarybaron commented Dec 19, 2025

View reviewed changes

swap-machine/src/lib.rs Show resolved Hide resolved

binarybaron commented Dec 19, 2025

View reviewed changes

protocol: Spam deterrence #675

Are you sure you want to change the base?

protocol: Spam deterrence #675

Uh oh!

Conversation

binarybaron commented Nov 4, 2025 • edited by Einliterflasche Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Current situation

The problem

The solution

Implementation

Uh oh!

binarybaron commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This issue has been assigned a bounty (💰)

Current bounty:

Exceptions for this specific bounties

Bounty donation address

Fine print

Uh oh!

pokefan77 commented Nov 7, 2025

Uh oh!

Einliterflasche commented Nov 7, 2025

Uh oh!

pokefan77 commented Nov 7, 2025

Uh oh!

jstark2a commented Nov 7, 2025

Uh oh!

pokefan77 commented Nov 7, 2025

Uh oh!

jstark2a commented Nov 7, 2025

Uh oh!

pokefan77 commented Nov 8, 2025

Uh oh!

Franz-Hermann-GT commented Nov 8, 2025

Uh oh!

binarybaron commented Nov 8, 2025

Uh oh!

binarybaron commented Nov 8, 2025

This issue has been assigned a bounty (💰)

Current bounty:

Exceptions for this specific bounties

Bounty donation address

Fine print

Uh oh!

pokefan77 commented Nov 8, 2025

Uh oh!

binarybaron commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Einliterflasche commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pokefan77 commented Dec 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Einliterflasche commented Dec 19, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

binarybaron commented Nov 4, 2025 •

edited by Einliterflasche

Loading

binarybaron commented Nov 4, 2025 •

edited

Loading

binarybaron commented Nov 8, 2025 •

edited

Loading

Einliterflasche commented Dec 17, 2025 •

edited

Loading