Replace Dispensers

[adamkrellenstein]

...architecturally, there are three alternatives to dispensers I can think of:

1. a standalone CLI app you run alongside a bitcoind instance
2. a counterwallet-style web app (user holds the keys, but someone else hosts the app)
3. OSS website that does everything for you, including holding the keys

for (1) and (2), if the seller turns off the app, the recipient has to wait for the seller to turn it back on to get their tokens

more fundamental issue is that a dispenser can only hold one single type of asset

[Jpja]

Enable the possibility to reserve a dispenser for N blocks. See CIP32: https://github.com/CounterpartyXCP/cips/blob/master/cip-0032.md

[adamkrellenstein]

Okay sure, but how is that not just recreating BTCPay? A dispenser is just an unsafe DEX transaction that's faster and more convenient because of the lack of safety features.

[adamkrellenstein]

Okay so a dispenser is a blockchain-hosted centralized service. It's trivial for the seller to front-run the buyer and get free BTC.

[adamkrellenstein]

[Jpja]

Enable the possibility to reserve a dispenser for N blocks.

Okay sure, but how is that not just recreating BTCPay?

Reservation is like adding an optional BTCpay to dispensers. I think this is necessary because, as it is now, buyers are put in a very weak position.

If dispenser reservation gets implemented, we might consider removing BTC from the DEX.

[keyuno]

Okay so a dispenser is a blockchain-hosted centralized service. It's trivial for the seller to front-run the buyer and get free BTC.

We need to remove dispensers as they are incompatible with a decentralized environment that aims to minimize reliance on third-party trust.

[jotapea]

From the UX perspective, dispensers are assets available at addresses. With all its flaws, the abstraction is as usable as it gets. I was onboarded thanks to dispensers.

Bridging the gap with a single normal bitcoin transaction. See my first XCP in the wallet after confirmation.

DEX is advanced in comparison.

[jotapea]

@adamkrellenstein Thinking how a standalone app should work:

• Installed as part of the fednode.
• Setup your wallet (or import keys).
• Have some assets to sell.
• <1. What happens here?...>
• Interested user sends BTC to the address.
• <2. What happens here??>
• User receives the units that was paid for.

Practically, the protocol could simply see a SEND in the last step, correct? Or would the protocol be involved in any of the previous steps?

Dispensers, as they exist today, don't need number 2 at all (with risks we all are clear about).

I believe the protocol should have a way to determine what is been sold at addresses. And can't ignore that, even with its flaws, dispensers are very (most?) popular in the Counterparty market.

[adamkrellenstein]

The UX would be the same as it is today, with the only difference being dependent on the choice of architecture specified in the OP. We can add an optional dispenser registry for analytics, if that's important.