Time-Locked Buyer Payouts

[HenrikJannsen]

Protection Against Bank Charge-Back Using Time-Locked Buyer Payouts

Overview

This proposal introduces a time-locked payout output for the buyer as a protective mechanism against bank charge-back fraud.
The idea: if the buyer initiates a fiat payment that later gets reversed (charge-back), the seller gains the ability to slash the buyer’s locked funds.
The mechanism is strictly optional and dynamically adjusted per-trade based on buyer profile, payment method, reputation, account age, and risk category.

If risk is low, the time-lock delay can be 0, resulting in no change from current behavior.

---

1. Time-Locked Buyer Output

Purpose

• Prevent the buyer from immediately spending their Bitcoin payout.
• Give the seller a time window to respond in case a charge-back occurs.
• Provide a cryptographic enforcement tool (Slash Transaction) that the seller can use when fraud is detected.

Mechanism

The buyer payout UTXO includes two script paths:

1. Key Spend Path (timelocked, CSV)

   • Controlled solely by the buyer.
   • Buyer may spend only after the relative time-lock elapses.
   • Represents the normal/legitimate settlement path.

2. Multisig Spend Path (shared control)

   • Used only when the seller initiates a slash.
   • Allows the seller to activate a Slash Transaction, spending both:
     • the buyer's payout UTXO
     • and the seller’s security deposit (or newly added funds)
   • Funds are sent to the Burningmen as in the standard Redirect Tx.
   • Requires ANYONECANPAY|ALL sighash to allow the seller to attach their deposit flexibly.

---

2. Protocol Adjustments

2.1 Buyer Output Script

The buyer payout output becomes a Taproot output with:

• Internal key: the joint MuSig2 aggregated key of both peers
• Key-spend branch: CSV-timelocked spend by the buyer alone
• Script-path branch: a MuSig2 multisig spend enabling seller-initiated slashing

2.2 Additional Aggregated Key

A third MuSig2 aggregation context is added:

• Two aggregated keys become fully owned by each peer at trade completion (current model).
• The third aggregated key remains jointly controlled.

---

3. Slash Transaction

Definition

A prepared Slash Transaction is created during trade setup (or before buyer fiat payment begins).
It:

• Uses the multisig script-path of the buyer's payout UTXO.
• Is signed with SIGHASH_ANYONECANPAY | SIGHASH_ALL.
• Underfunds the Burningmen output by the amount of the seller’s deposit.
• Requires the seller to attach:
  • either their locked security deposit output
  • or fresh additional inputs if that output has already been spent

As the seller requires the exact input amount they need to make a preparation tx with one output suited for that.

Purpose

• Seller can only broadcast the Slash Transaction when fraud occurs.
• Misuse is deterred because the seller must commit their own deposit.
• Prevents abuse: a seller cannot grief a buyer because slashing costs the seller as well.

Behavior

• If the seller claims the buyer used a stolen bank account (charge-back):
  • Seller broadcasts the Slash Tx with added deposit.
  • Burningmen receive both amounts.
  • Arbitration investigates the case.

---

4. Summary of Key Advantages

✔ Protection Against Charge-Back Fraud

Seller gains a cryptographic mechanism to respond when fiat is reversed.

✔ Adjustable per-trade

Time-lock delay can be:

• small for trusted buyers or safer payment methods
• 0 for negligible-risk methods
• high for new or unverified buyers

✔ Economic Deterrence

Slash Tx requires seller to lock their own deposit.
This prevents misuse while ensuring the mechanism can be activated if real fraud occurs.

✔ Minimal Protocol Changes

Only:

• add locktime
• an extra MuSig2 aggregated key context
• adjusted payout script
• one additional prepared transaction (Slash Tx)

Cryptographic scheme stays within MuSig2 + Taproot conventions.

✔ Retains Non-Custodial Architecture

• No intermediaries
• No centralized dispute resolution
• Burningmen remain as neutral cryptographic sinks

5. Considerations

• Adds complexity to the protocol and with complexity potential risks
• Delaying the effective payout might be not welcomed by users
• It might be that very few users will actually use that option and most will resort to other options (higher security deposit, dual account payment,...). In that case we made the trade protocol more complex and added potential risks for little gain.

---

6. Conclusion

Time-locking the buyer payout combined with a slash-enabled script path creates a powerful, decentralized mechanism for mitigating bank charge-back scams. It introduces no custodial role, adds minimal complexity, and offers configurable granular protection based on fiat payment risk and buyer trust level.

6. References

Here is a summary from @stejbac from a Matrix discussion:

Perhaps a special Redirect Tx could be created and signed (say, at the trade start) with just the buyer payout UTXO as input, but signed with ANYONECANPAY|ALL sighash type, and underfunding the BM outputs with an amount roughly equal to the seller's security deposit. Then the seller could be free to use it at any time. even possibly before the trade ends, but would have to fund it with an additional security deposit, to deter abuse. I think it would be better to exclude it and stick with ordinary keyspend-only payout outputs for trades which carry zero or negligible chargeback risk, which would presumably be the majority of the trade volume.

I can't see any issues that would be created by having an additional timelocked script path for the buyer output, which the buyer gains unilateral control of at the end of the trade, with the keyspend path used only for the Warning Txs (and any cooperatively signed mediated payout txs). It shouldn't create any issue with the Swap Tx. It just means that there would be three aggregated pubkeys (with associated MuSig2 KeyAggContexts) instead of the two at present. Two of them would become fully owned (that is, learning the aggregated private key) by the respective peers at the end of the trade, as they are at present. The third would retain joint ownership, with neither party ever learning the aggregated private key. The third aggregated pubkey would then serve as the internal key of buyer payout address, in place of one of the other two as at present, which would instead serve as the pubkey in the new script path. So the cryptography wouldn't need to change much (really just adding a third KeyAggContext) -- only the creation and signing of the txs would need to change a bit, plus adding the new prepared tx with the ANYONECANPAY|ALL sighash type.

I don't think it would be possible to reuse the Warning Tx by making one of its inputs ANYONECANPAY, as it's not meant to be used past the end of the trade, and attempting to do so would allow the peer's Penalty Tx to be used. So it would probably be easier just to add a new prepared tx to redirect to the BM to the trade setup. (Possibly the completion of its signing could be delayed until the buyer starts the fiat payment, as it wouldn't be needed before then.)

Note: This is an AI generated summary