Asset Issuances paying only BTC

[jdogresorg]

Currently in order to issue a Named asset or Subasset, an XCP anti-spam fee is required.

One of the primary complaints I have heard over the years is that "Counterparty requires a shitcoin (XCP) to use the platform". While this is untrue, and XCP is only used as an anti-spam mechanism in asset issuances and a couple other features, it is true that XCP is required to perform some features.

I propose that we come up with a mechanism to automatically purchase the necessary XCP from dispensers before performing the action which requires the XCP (Issuance, Dividend, Sweep).

In this manner, we could have users pay only BTC to use any of the features of Counterparty without the need to obtain XCP (it is automatically obtained for them when needed)

For Instance, to issue a Named asset using only BTC, it could look something like this.

• CP API updated to display what amount of XCP will be needed to perform the issuance
• User/Wallet locates a dispenser with ample XCP supply and reasonable price (can be automated)
• User/Wallet sends request to CP API to generate ISSUANCE transaction and specifies the dispenser to purchase from (tx_hash)
• CP API generates a transaction which :
  • Creates a normal issuance transaction
  • Adds an additional output to pay the XCP dispenser

When the transaction is mined and executed by Counterparty :

• Dispense is processed first
• XCP is purchased from XCP dispenser using BTC and credited to buyers address
• XCP is destroyed from buyers address and used to issue an asset
• Named asset is issued

There are some pitfalls to this method, like :

• XCP Dispenser could run out before tx is mined,
• XCP Dispenser could be way over/under priced

For these reasons, I think the dispenser selection should happen on the API level (user chooses, and is aware of exact BTC amount to pay)... versus trying to have the CP protocol figure out the best dispenser to use and a variable amount of BTC.

[keyuno]

One of the primary complaints I have heard over the years is that "Counterparty requires a shitcoin (XCP) to use the platform". While this is untrue, and XCP is only used as an anti-spam mechanism in asset issuances and a couple other features, it is true that XCP is required to perform some features.

XCP came into existence through the process of burning bitcoin and essentially serves as an extension of bitcoin. It is important to recognize that the complaints are misleading, and Counterparty should not cater to individuals who propagate false narratives.

I propose that we come up with a mechanism to automatically purchase the necessary XCP from dispensers before performing the action which requires the XCP (Issuance, Dividend, Sweep).

The dispensers themselves are fundamentally flawed to the point where suggestions like "trusted dispensers" and KYC-like verification are proposed (via Twitter) as potential solutions. These proposals contradict the core principles of Counterparty, which is built on the idea of providing a decentralized system without relying on third-party trust. Currently, dispensers are at best a necessary evil, but the goal is to move away from them rather than introducing additional dependencies on them in user interactions.

[jotapea]

an extension of bitcoin

100% agree.

[0xblockjack]

In my opinion the "complaint" is due to a communication problem that affects the "perception" of XCP.

At the moment the project with the most interest in continuing to create numeric assets and therefore paying the fee in XCP per issuance for the creation of numeric assets is Bitcoin Stamps (and all mining platforms or individual miners).

However, the reason there is interest in Bitcoin Stamps is because of their on-chain nature in Bitcoin. So anything that is "perceived" as going outside the Bitcoin ecosystem will have a negative impact on the creation of new stamps and therefore the payment of this fee.

For me this is the best solution as it is the quickest to act and aligns with both parties.

The other alternative I see is to spend economic and human resources to change this market perception. From my experience in FMCG, changing the market perception is something that costs a lot of money and time. And unfortunately it is something we have neither counterparty to limit spam nor projects contributing to the development of Stamps.

[stet]

The dispensers themselves are fundamentally flawed

Yes and for this reason alone this idea is not a great idea for CP but of course freewallet etc could attempt to do this on the edge.

[davestaxcp]

"XCP Dispenser could run out before tx is mined"

• If in a perfect world with future fixed dispensers and the XCP you are dispensing is locked and "secured" without any risk of front-running for the payment to process... then this could work well for the user to either "pay with 0.5xcp" or "pay with 0.00xxx btc" as a button while creating the TX

"XCP Dispenser could be way over/under priced"

• This would mean the BTC price for the dispenser along with the fee should be easily "refreshable" for the user to see the difference in the fee's as they come back from the API call. (Refresh probably shouldn't be too spammable I'd assume) Also it might be good here to show EXACTLY which dispensers are being used (or will be) to have a manual second check for the user.

• You would have to warn or limit buying amounts at certain levels. For instance 0.14 XCP at one price in a low (almost out) dispenser and another at 0.36 XCP at maybe a much higher price. Either you would have to limit the amount paid and do it level by level, or add the fee for the second transaction. Might be difficult to "automate" the perfect amount you want to buy at a given time without ramping fee's up high. For instance in some sort of larger XCP buy situation, what would it look like in fee's to clean out 5 dispenser with a bulk buy?

Other thoughts:

• It would make the process have one less step for the user while still keeping the system of using XCP as the "anti-spam" function
• You could even have a direct "buy XCP with BTC" button to just "quick accumulate"
• This could even integrate buying orders that are up for XCP directly with BTC, which could be really useful
  ^^ This could be reeeealy cool :)

[0cam]

I like the idea of the wallet using a xcp/btc order instead of a dispenser like @davestaxcp states, if it's possible. The wallet could search for the best xcp/btc order that has the necessary amount and execute. I think xcp/btc have less attack vectors than dispensers. Is there anything I'm not thinking of?

[adamkrellenstein]

I think this is a great feature for a wallet to implement, simply to improve UX. But IMO it shouldn't be a concern for the protocol reference implementation.

[jotapea]

This makes more sense, at the edge like @stet mentioned. The asset name issuance's XCP burn is itself the connection to the BTC burn.

[adamkrellenstein]

Closing, because dispensers are not trustless.