CIP - Dispenser Reservation

[Jpja]

CIP 32

Abstract

Reserve a dispenser for 10 blocks by sending a tiny amount of BTC dust to it.

• This is optional. Dispensers can be used without reservation as before.
• Backwards compatible. No changes to how dispensers are set up.

Motivation

When a buyer sends bitcoin to a dispenser, there is no guarantee that the dispense gets executed. Several factors can lead to a dispense failing, including random and malicious ones. Currently, one should only buy from a dispenser if the amount is trivial or the seller is trusted to reverse a failed transaction.

Dispensers have increasingly been used beyond the designed scope. Whether this is due to convenience or ignorance, significant losses have occurred. Moreover, hackers have set up so-called "rugspensers" that automatically steal the buyers' bitcoins.

Allowing for the reservation of a dispenser will make dispensers safe for any amount of value.

Details

The new rules added to the dispenser consensus code:

• If a an incoming BTC transaction is smaller than one dispenser lot but at least 5,000 sats (₿0.00005, currently ~$1.35), then the protocol reserves this one lot for 10 blocks. (Previously this transaction would have been ignored.)

• If the buyer pays the full amount within the 10 block deadline, the tokens get dispensed.

• If the buyer does not pay within the deadline, the reserved block is released back to the dispenser and available to anyone again.

Examples

A) A dispenser for TOKENA is listed for ₿0.01. Alice buys this token directly without reservation. The hassle of dealing with a reservation is not worth it since the amount is so small.

B) A dispenser for TOKENB is listed for ₿0.1. Bob wants to buy this token but is not confident that the seller will refund him in case something goes wrong. He therefore firsts sends a dust amount of 5,000 sats. Once it confirms, he waits 3 blocks to be absolutely sure and proceeds with paying the remaining ₿0.09995.

C) An XCP dispenser is listed at ₿0.0002 per XCP. Charlie suspects this might be a rugspenser. But since he can only reserve one lot (ie one XCP) it is not worth it. He rather looks for a dispenser where XCP is bundled in larger lots, like ₿0.02 for 100 XCP, where it makes sense to make a reservation.

D) Dave messed up the decimals. Instead of paying ₿0.12345678, his wallet rounded down by one satoshi. A reservation was automatically made, so all Dave had to do was send a dust amount to trigger the dispense.

Read the full CIP.

Discussions

I wanted to minimize the complexity of this proposal. Some tradeoffs I considered:

Parameters
I chose absolute simplicity. No reservation parameters. This means no changes are necessary for the CNTRPRTY message. It also keeps dispensers logic easy to understand. However, one existing parameter can become useful; lot size. When you set up a dispenser with 1000 XCP you can choose sell in batches (lots) of one XCP each for ₿0.0001, in lots of 100 XCP each for ₿0.01 or only sell all 1000 for ₿0.1. Market dynamics should decide which lot size that becomes preferable.

Dust limit
I chose no explicit amount. Bitcoin's 546 sats (~$0.15) limit is the implied limit. This means you can hold up a dispensers (one lot of it) for about 50 cents (dust + btc fee) every 10 blocks (~100 minutes). I think this is an unlikely attack though. No one would lose directly from this – except the attacker. The seller will earn a lot of dust, and 546 sat utxos can economically be consolidated. Moreover, if such a dispenser blocking attack did take place, a competing buyer could after 10 block compete for a reservation by paying a higher fee.
EDIT: Due to concerns that it's 546 sats makes it too cheap to hold up a dispenser, I introduced a minimum dust amount of 5000 sats (₿0.00005, currently ~$1.35). Keep in mind that this is the cost of blocking one lot for 10 blocks. Most dispensers have one token = one lot, so the attack quickly becomes very expensive.

10 block deadline
BTC_PAY, the equivalent on the DEX, uses 20 blocks. But that was chosen in 2014. Back then it was expected to wait for 6 confirmations. Now 3 should suffice. There was also a threat of some mining pools (Eligius) blocking Counterparty. No other mining pool to date has had a similar policy. Most importantly, RBF didn't exist in 2014. You can always up your fee to get included in the next block if mempool clogs up. Anything less than 10 blocks I'd consider too risky. After all, blocks come at random intervals. You don't want a situation where you failed to make the payment on time because blocks were mined abnormally fast.

Argument against: Use DEX
It is true that risk-free BTC/token trading can happen on the DEX. But the reality is that liquidity moves to dispensers because they are more convenient. Buyers are (until this CIP is implemented) faced with the dilemma of risk losing their BTC on a dispenser or not buying at all. I believe this is unreasonable and can easily be fixed with this CIP.

Argument against: Delay closing with 5 blocks
It solves nothing. In a separate thread I have explained why scammers will frontrun by buying from another address instead. Such a script would take ~20 lines of python code and use bitcoin api's only (no counterparty api's). In telegram another argument was that the scammer would need liquidity (which is not the case with closing). Like to frontrun a ₿0.1 dispenser, the scammer needs to send ₿0.1 between his own addresses. While technically true, I don't see this as a noteworthy deterrent.

[Jpja]

Let me elaborate on the "use the DEX instead" argument.

The dispenser has several advantages over the DEX for BTC trading.

• With the DEX you risk selling part of a divisible token. E.g. list one FDCARD for sale and someone might pick up just 0.01. Dispensers have all-or-nothing logic, so you can specify that only one full token can be sold.
• With the DEX you cannot bundle several tokens. On the contrary, you can include an entire collection under one dispenser. Again, you can be certain that you sell all or nothing.
• DEX orders expire. In many cases annoying. Dispensers remain open until sold or seller decides to close.
• With the DEX, the buyer might fill several sellers (and there's no way to avoid this, lowest ask orders get filled). This will lead to several BTC_PAY orders that may not be worth the fees. With dispensers, the buyer can choose the most suitable seller, not necessarily the cheapest one.
• With the DEX, the seller should always place a limit order. If he goes for a market order, chances are that the buyer is not online and won't fulfill the BTC_PAY payment. With the OTC nature of dispensers, the seller effectively and intuitively places a limit order.
• With the DEX, the opposite applies to buyers. Always place market orders that match a current sales offer.
• Order books on the DEX, for the above reasons and perhaps some hard coded additional conditions, sometimes overlap. This was the case long ago at least. I don't think this has been solved.
• Creating a good interface for the DEX is very difficult if not impossible.
• Making a BTC_PAY requires full trust in Counterparty infrastructure (special CNTRPRTY opreturn message with hashes of matching orders). With dispensers (even reservation) you can verify the existence of the dispenser on both xchain and xcp.dev, then rely solely on bitcoin explorers (no incoming or outgoing tx from dispenser address guarantees the dispenser is still open). I can envision trading the most valuable counterparty token through a reserve dispenser ;)

Note that this applies to trading BTC on the DEX. For token-token trading, the DEX is very good.

The dispenser, on the other hand is, tailored for exchanging tokens for BTC (OTC style). It is the ideal solution for selling low-value tokens and a good solution for high value tokens when the seller is trustworthy.

The green area is the special case where dispensers are the best solution.

If we add reservation as an option, dispensers become a general solution to BTC-token trading. Simply use a reservation in the area that previously was orange or red.

[keyuno]

Dust limit
I chose no explicit amount. Bitcoin's 546 sats (~$0.15) limit is the implied limit. This means you can hold up a dispensers (one lot of it) for about 50 cents (dust + btc fee) every 10 blocks (~100 minutes). I think this is an unlikely attack though. No one would lose directly from this – except the attacker. The seller will earn a lot of dust, and 546 sat utxos can economically be consolidated. Moreover, if such a dispenser blocking attack did take place, a competing buyer could after 10 block compete for a reservation by paying a higher fee.

Participants from rival protocols may seek to exploit vulnerabilities in Counterparty, leading to the possibility of a continued dust attack on dispensers.

[Jpja]

Aren't there cheaper, more cost effective attack vectors - from a pure DB bloat perspective?

If holding up trades for a certain token is the goal, the attacker cannot hold up the dispenser for more than 10 blocks. Once the reservation expires, anyone interested can compete to make the next reservation. The one who pays the highest fee ratio gets it.

[jdogresorg]

There are def more cost effective attack vectors in CP... tho wont be listing them here for attackers to utilize 😛️️️️️️

It would be trivial to create a script to spam dust transactions automatically whenever a dispenser reservation expires.... IMO any reservation system needs to collect a certain percentage (%) of the total amount of BTC, not just dust.

If you collect too little in the reservation, too easy to spam dust attack and tie up dispenser.

If you collect too much in the reservation, scammers still able to run off with funds from reservation.

I am supportive of the overall idea of a reservation system, but, there is no perfect solution here that makes dispensers 100% unscammable, and this reservation system only adds additional complexity to dispensers, without much additional benefit.... Scammers still able to scam funds AND/OR attackers can spam dust attacks to prevent normal dispenses.

Longer-term, a reservation system could work, but think we need some more discussion and data on what reservation system should look like, what amount should be collected, how long should reservations persist, how the reservation queue should work, how normal dispenses should work when there are dispenser reservations, etc.

IMO, dispensers should remain a "single BTC payment only" system until a reservation system is refined enough that the general consensus from the community at large is that this is an overall improvement.

[keyuno]

Aren't there cheaper, more cost effective attack vectors - from a pure DB bloat perspective?

I'm not a security expert, but as I consider various scenarios, it becomes apparent that the outcome largely depends on the objectives the attackers aim to achieve. Nevertheless, our primary objective should be to minimize the number of potential attack vectors.

[Jpja]

IMO any reservation system needs to collect a certain percentage (%) of the total amount of BTC, not just dust.

What if the price is ₿1 and the reservation cost is set at 1% – I would not feel comfortable risking a ₿0.01 reservation deposit. I think we should set a fixed amount for all dispensers. The exact value should make the tradeoff you mentioned. Someone posted a good estimate in Telegram. Good if it can be copied here for future reference.

this reservation system only adds additional complexity to dispensers, without much additional benefit

Disagree here. Buyers are currently at the mercy of the seller. The current risk profile is not much better than sending Bitcoin to a stranger and expect them to send you tokens in return. Adding an option to reserve and remove all risk (except one tx fee and some dust). What can be more beneficial than this?

how the reservation queue should work, how normal dispenses should work when there are dispenser reservations

First included in a block gets processed first. This is the same as for everything in Counterparty. Changing the ordering would be a deep change. Not worth the complexity imo.

Example 1: A dispenser has one token for sale. An incoming dispense and a reservation makes it to the same block. The reservation comes first, so the dispense is ignored. The buyer who lost must ask seller for refund.

Example 2: As before but dispenser has two lots. Both get filled.

Example 3: A dispenser with two lots has one active reservation. An incoming dispense triggers the remaining available lot.

Example 4: A dispenser with two lots has one active reservation. The seller closes the dispenser. The open lot gets closed immediately. The reserved lot gets paid within the deadline and the buyer gets his token.

Example 5: Same a #4 except this time the reservation expires. The reserved lot goes back to the seller and the dispenser is fully closed.