CIP21 - Dispensers

CIP21

3 Likes

Address 17XGUUpJpd5FPrHuUcuhMeXjzm5VVPc3uG has been created, assigned to CIP21, and fully funded.

3 Likes

Nice work!

When will it be live?

Can I help test it on the testnet or irl?

1 Like

It’s being tested rn, however the current implementation goes along with cip6, cip20 and cip21, and there’s an error popping up which i can’t nail quite yet (something about scriptverify flags being enforced, but that was working before… huh)

2 Likes

awesome, I’m really looking forward for this one

2 Likes

Milestone #1 payout (0.125 BTC)
https://xchain.io/tx/14181bd6e735512fed2a8805779c1ec6004ad894727424269945fda27a0c5161

Milestone #2 payout (0.125 BTC)
https://xchain.io/tx/87d0d458bd181f932c7dceb9aecb86eb64078b662dcfd5afa8c1b8c23f9e1f90

1 Like

CAN SOMEONE EXPLAIN HOW THIS WORKS ?

Amount to dispense ???>> What do I put here ? Just one token ?
Enter the amount of the asset to be dispensed for each main chain amount received.

Amount to escrow - This is how much I want you to excrow for the top amount to dispense before escrow runs out , RIGHT?

“The total quantity to escrow, it’s suggested to be a multiple of the dispenser give amount”<<< this is confusing, shouldn’t it read the amount you want to be dispensed total ?

Main chain rate ? Is this the bitcoin rate per coin or per the total escrowed ? Jaut says “The amount of bitcoin to be received” But for WHAT ? One coin or the total escrowed coins ?

Use freewallet.io desktop wallet… every field has a questionmark next to it which you can hover your mouse over to get a detailed description of what the field is expecting… it answers your questions above

Some thoughts on dispenser upgrades…

  • Delayed closing
    Rather than closing the dispenser immediately, all dispenser closing are delayed by 5-10 blocks to prevent a dispenser operator from closing a dispenser with a high fee after buyer sends funds.

  • Close to creation address option
    One pain point with dispensers is after they’re closed you need to send BTC to the dispenser address to be able to send the asset back to yourself. Adding a flag to send the dispenser escrow back to the creation address would alleviate this issue.

  • Allowable address option
    Dispenser will only dispense to a pre-determined address when using this option. This would be the equivalent of leveraging Counterparty as the escrow for an OTC deal in BTC.

  • Expiration option
    Similar to DEX orders, an expiration option would be specified as a number of blocks from creation. This could be used in conjunction with the “close to creation address” option to give users an Opensea-style experience.

1 Like

Thanks for writing up your thoughts on these great features… All of them sound good to me. Some additional thoughts below.

  • Delayed closing
    Rather than closing the dispenser immediately, all dispenser closing are delayed by 5-10 blocks to prevent a dispenser operator from closing a dispenser with a high fee after buyer sends funds.

I support this idea, but I propose a tweak to this, which is that we only delay closing the dispenser if there is a pending dispense. This would solve the problem of dispenser operators closing dispensers with a pending dispense, but also allow dispenser operators to close their dispenser immediately if there is no pending txs (BTC incoming) to the dispenser address. Thoughts?

I too have been thinking about various features that we could add to the dispensers to make them more usable in various cases. Here are some of my thoughts on additional dispenser upgrades…

  • Use/Reuse any bitcoin address as a dispenser
    Currently Counterparty only allows opening of new dispensers on a different address if that address is a fresh/empty addresses with no transaction history.

    We could update Counterparty to allow opening up of a dispenser on any address, once that address ownership has been verified via a signed message. Perhaps we standardize the message that is to be signed to be the current date in YYYY-MM-DD format like ‘2023-01-23’, then update Counterparty API with a open_address_signature field, which users can provide the message signature. The API would simply verify if the message signature was valid (proving ownership of the open_address), and then would allow opening of the dispenser on the open_address.

  • Allow dispensers to sell ‘packs’ of cards
    Currently Counterparty dispensers only sell one card at a time, and to sell multiple cards at the same time, you need to setup multiple dispensers on the same address.

    We could update counterparty to allow users to specify a list of what assets/tokens/quantity get dispensed when a dispense is triggered. We could have the wallet allow users to provide a simple list of assets to dispense similar to MPMA sends:

    BACON, 1.00000000
    RAREPEPE, 1
    PEPECASH, 1000000.00000000
    XCP, 1.23456789
    

    In the API we would have the following changes :

    • asset field would change to support array of assets [‘BACON’,‘RAREPEPE’,‘PEPEPCASH’,‘XCP’]
    • give_quantity field would change to support array of quantities [100000000,1,100000000000000,123456789]
    • escrow_quantity field would change to support array of quantities [1000000000,10,1000000000000000,1234567890] (10x dispenses)

The problem here is you can’t do this at a protocol level because the mempool is not the same across nodes. So there’s really no way for counterparty-lib to detect pending dispenses. You could probably be closer to 5 block delay rather than 10 and still get the benefit of preventing scam dispensers. That should be a short enough amount of time that people aren’t inconvenienced too much.

Thanks for the clarification. I tend to disagree about the inconvenience… having to wait 1-2 hours to close a dispenser is a long time, especially in cases where the dispenser operator is just trying to change the dispenser price. Or where they opened a dispenser at a bad price by mistake, Now they are supposed to close the dispenser, wait an hour, come back and then re-open the dispenser?.. seems inconvenient.

I support trying to prevent fraud on dispensers, but not sure preventing users from being able to perform actions in a timely manner is the correct path forward… do we have any stats on how often this “close while dispense is pending” is actually happening?

It’s just a trade off to prevent a low cost attack. Personally I think it’s probably worth the minor inconvenience of dispenser closers waiting a few blocks once the cancel tx is confirmed.

At the end of the day, due to the nature of dispensers, we can’t prevent all attacks. A bad actor could always snipe by paying dispenser price with a very high fee and this wouldn’t prevent that.

Lots of interesting suggestions. Some thoughts:

Delayed closing
I’m against it. It’s sort of possible already to delay closing by using a low btc fee. Conversely, if you want to close immediately, use a high fee. I think this simplicity/flexibility is good.

And as you mentioned, a bad actor could front-run dispensers anyway.

Close to creation address option
This would be a great feature! My only concern is the length of the message data. Dispensers already use 84 bytes when oracle feed is added. Would be great if this option can fit an 80 byte op_return somehow.

Allowable address option
Great suggestion! Maybe this should be a new message type tho? Unlike dispenser, which require 100% trust (and is currently being used VERY IRRESPONSIBLY), the allowable address option will require no trust.
It should be easy to build infrastructure around such a contract too. I will write a separate post about this. IMO potentially a very useful upgrade to Counterparty.

Expiration option
This is something I want and certainly would use. Again, my only concern is the message data. Maybe bundle several such upgrades to a new tx ID, and make the op_return message more efficient to fit 80 bytes?

Use/Reuse any bitcoin address as a dispenser
Does your suggestion open up for scripts/wallet not using API to put dispensers on any address? A solution on the protocol level could be to let an address send a broadcast to open it up for dispensers. I believe something similar exists, require memo, where an address broadcasts that it only accepts transfers with a memo.

Allow dispensers to sell ‘packs’ of cards
Isn’t this already possible by setting up multiple dispensers on one address? If anything, I’d actually like to allow several dispensers of the same asset on the same address. It opens up for 3 for 2 offers etc. (Would be possible if one dispenser has price 0.1 and the other 0.2).

Two more topics I’d like to discuss:

Reservation
If partial dispense is detected, reserve token for 12 blocks. If a second tx is made within the deadline, and the amounts sum up, then make the dispense.
This will remove the need to trust the seller. IMO a very high priority should be to add either this feature to dispensers or a new OTC contract.

Random dispense
Send BTC, have a 1/X chance of getting the token. The block hash is a perfect random number. This should probably be a new transaction type under a different name.

1 Like