Solutions to "rugspenser" problem

Development
1

Attack vector:

Scammer detects incoming buy and immediately sends another buy transaction with a higher fee. The scammer’s tx gets priority and the legit buyer loses his bitcoins.

Possible solutions:

1. Pre-payment before full payment
This requires a protocol change. The logic is simple. If less than a full dispense is detected, allow up to 12 blocks for the second tx. Perfectly safe as the protocol keeps the token on escrow. The buyer, if not trusting the seller, can thus make a tiny pre-payment first, wait for it to confirm, and then make the full payment. If trust is not an issue, pre-payment is not necessary. The buyer can always make the full payment at once.

2. Trusted middleman
This will not require a protocol change. Someone trustworthy publishes a list of new addresses. Anyone can set up their dispenser on one of these addresses. After a successful dispense, the middleman forwards BTC to the seller. In case of an unsuccessful dispense, the buyer is reimbursed. A small fee can be charged, so this is even a potential business model. A multisig address can be used, where the middleman can exist of several parties.

3. Verified dispensers
This will not require a protocol change. Someone publishes a list of dispensers with good track records, or dispensers announced by, for example, twitter accounts. The problem with this solution is that for new users it will take time to build reputation, and that you can never be absolutely certain that someone “trustworthy” won’t pull an exit scam.

Thoughts? Other solutions?

2

I think the only viable option is no1 partial payment as the other two options are not trust-less and that is problematic

3

I agree with B0B in that only a version of #1 would make sense, #2 and #3 are too centralized or complicated for verification (Twitter’s get hacked).

I’m not too fond of “partial payment” from a buyers perspective, would likely cause confusion or manual mistakes in my opinion.

Though I think some sort of restriction is very needed for the ability to close the dispenser when an unconfirmed dispense is waiting to confirm.

Some sort of “auto lock” on the ability to close the dispenser when an unconfirmed tx is seen could work.

Though, many people have brought up the idea a “troll” user could send very low fee tx’s to “block” the closing of the dispenser for a prolonged period.

There would have to be a high incentive to get the tx confirmed within “X” amount of blocks (and quicker than low spam tx’s if there are some in unconfirmed), which would fall on the buyers responsibility. You would have to put a disclaimer that said “if your tx does not confirm in X blocks” you MAY not receive your token and explain why or how. You are recommended to use ULTRA high fee setting (or something like that).

People brought up an idea of “first in queue” but this idea allows for the “trolls.” But with an auto-lock function on close dispenser enabled it would still be “highest tx fee of buyer first.”

This could end the need for “trusted” dispenser owners assuming the buyer confirmed in X blocks easily. Yet it would still cause buyer induced mayhem if a heavily sought after token got “bought out” and some users paid high fee’s and received the token even though their tx was “later.” But when the dispenser ran out of tokens to dispense, some unconfirmed tx’s at “previous reasonable prices” would be front run.

Again though, this could be at the users risk if they are trying to “beat” low fee tx’s that are unconfirmed. Which I think has been fended off somewhat xchain showing unconfirmed tx’s as “tokens already being dispensed.”

It could solve at least a part of the problem and reduce scammers.

Still pondering some sort of idea to solve this from someone who knows much less about the coding side. ¯_(ツ)_/¯

Edit: I’m glad I pondered this but the ultimate flaw is still that the “scammer” could just “buy back” the token with a huge fee with unconfirmed tx’s still in queue. So it might not work. :frowning:

4

This could be possible on the WALLET level but not on the PROTOCOL level. Scammers almost certainly run custom scripts, therefore such a wallet policy won’t solve the problem.

Moreover, a scammer can always BUY from an unknown address (instead of CLOSE) and it is impossible to determine legit vs scammer address.

Solutions that rely on “first in mempool” are also impossible on the protocol level. A fundamental property of Counterparty is that all nodes (today, as well as years from now) see the same blockchain. There is no way to tell what entered mempool first. Only the ordering inside the blocks is known, and it is independent from mempool (in fact, ordering is usually sorted by sat/vB which is what rugspenser scammers exploit).

I believe the only possible protocol solution is prepayment.

1 Like
5

I see.

I do see your theory on prepayment, but when it is brought it up amongst the community it is usually referenced alongside the theory of BTCpay and how that process works.

Coming from a user (non technical understanding), what would the difference be between what BTCpay is and what “prepaid” Dispensers would be. How would they differ in user experience as well as the technical side of things?

Before the community tries to tackle the community feeling of “trust” with dispensers, would it be better to instead then focus Users to lean to learning about BTCpay functionality? As many older Devs and Users here point to that feature as the “solution” to this issue of trust.

Though at the moment there seems to be a protocol issue with btc_order_minimum and btc_order_minimum_adjustment_1

In the event BTCpay is polished and possibly widely used in the near future, do you think it would be better to point new users to that feature that find a lack of trust in dispensers?

And if prepaid ideas to dispensers were added as a function what would the advantage or disadvantages be as a buyer/seller?

1 Like
6

BTCpay is a special transaction where bitcoin is safely transferred after a DEX order match. Within a twenty block window the BTC must be sent along a CNTRPRTY message containing the hashes of the two matching orders.

A dispenser prepayment would function similarly but technically be different. If a partial dispense is detected, reserve the dispenser and give a 12 block window to make the full payment. No CNTRPRTY message needed here.

Pointing users to DEX/BTCpay would help – but for SELLERS it is often more convenient to use a dispenser.

  • Never expires (unlike DEX orders that expire).
  • Dispenser can guarantee sale of whole units (unlike DEX where you risk selling 0.00001 of divisible token).

BUYERS are left in a bad position. When they discover an attractive offer on a dispenser, they have no choice but risk getting rugged or pass on the offer. (Until prepayment is implemented).

2 Likes
7

Thank you, this is a very informative reply and would be open to the experimentation you mentioned with Dispensers.

Definitely if implemented would need some in depth explanation to users that are used to the “old way” of things.

Would it be possible to have this feature “optional” if this is opposed to at a protocol level?
Or would the whole point be to “replace” the protocol with something more robust?

8

Optional. The buyer does not need to make a prepayment. Can still make the full payment at once if they trust the seller / accept the risk.

It will be an upgrade to dispensers, not a new transaction type.

1 Like