Counterparty CIP Proposal: Counterparty Payment URI Scheme

Development
1

I am proposing CIP 2 - Counterparty Payment URI Scheme

Here is the proposed scheme:

counterparty:<address>[?amount=<amount>&asset=<asset>&label=<label>&message=<message>]

Discuss and express your approval or disapproval here please.

2 Likes
2

Thanks for this effort!

Do you think there should be another URI Scheme for other actions (non-payment related), or can we have one that includes actions such as DEX orders and similar?

1 Like
3

The use case here in my mind is a website or mobile web application that is asking the user to pay a certain amount to a specific address. And then when the user clicks that link, their desktop, mobile or web wallet launches to send the payment.

Is there a use case for a website to ask for other specific actions? Like a specific DEX order?

I donā€™t think so. But please lay out a use case if you think there is one here.

1 Like
4

Devonā€™s CIP proposal for a counterparty payment URI scheme is fine with me. I think initially we should only support ā€œsendā€ actionsā€¦ but we can easily tack on extra vars in the future for extended functionality.

Nice work Devon :slight_smile:

5

Yes, DEx orders is one of other options (you could also call them ā€œSellā€ orders, in addition to the proposed ā€œBuyā€).
Maybe also broadcasts (for voting) and bets. I donā€™t know how much more complex itā€™d get that way, but if if this can be added in the same go without going through 2-3 rounds of amendments in coming months, maybe itā€™s worth it. If users can user their wallet more, it creates a self-reinforcing effect.

6

I can see why a wallet would want to support buy and sell orders against the DEx. But why would a website need to generate a specific URL that instructs the userā€™s wallet to place a specific Bid or Ask? I donā€™t see the use case from the websiteā€™s point of view.

Iā€™d like to keep this CIP focused on just the payment URI since that is the immediate problem that Tokenly Pockets, the Indie Square Wallet (and maybe Counterwallet?) want to solve right now.

If someone wants to create another CIP that extends this CIP and defines additional parameters such as bid/ask parameters, I donā€™t think there is anything in this CIP that is preventing that.

Are you ok with saving those other operations for a future proposal and moving forward with the CIP as it is now?

1 Like
7

Sounds reasonable, perhaps itā€™s best to start small and see how itā€™s working out and not complicate things too much.
Thanks!

1 Like
8

Iā€™ve already stated on the Slack channel, but IndieSquare approves this proposal. Thanks for organizing this.

9

Does it make sense to limit this URI scheme to merely send transactions? Why wouldnā€™t we want an action type and support (broadcast/send/bet/cancel/ussuanceā€¦)?

IMO - weā€™d want a counterparty://send/[?amount=&asset=&label=&message=]

and maybe leave the opportunity for counterparty://order/assetname/amount[?optionalparams=here]

10

Here is my thinking on why we want to keep it simple (like BIP 21):

  • I expect the overwhelming majority of the uses for the URI will be when websites display a ā€œclick here to payā€ button/QR code.

  • We want to follow BIP 21 as close as possible for wallet makers to easily incorporate counterparty functionality along with existing bitcoin functionality.

  • This proposal does leave the URI scheme open for future expansion with an action (or equivalent) parameter. If we follow the send convention then the most important parameter of the action can be first. Here are some examples of how we might want to extend the URI scheme in the future:

    • A broadcast might look like this counterparty:I%20am%20awesome?action=broadcast

    • An order might look like this: counterparty:MINERCARD?action=order&get_quantity=1&give_asset=XCP


I see the appeal of the `counterparty:send/1MyAdress1245` style URI. But, for me, consistency with BIP 21 is more important.
1 Like
11

no need for the //

counterparty: not counteryparty://

12

Iā€™d favor for consistency that only sends have that initial parameter where the address is.

Instead, other tx types can begin counterparty:[?parameter=value&....]

13

Any objections to merging this in as a Draft tomorrow as is?

@brighton36 - are you ok with the BIP 21 style URI for this CIP and leave it open to expansion by using an action (or equivalent) parameter in a possible future CIP?

Note that we donā€™t have to decide anything about how the future URIs will look, just that it is feasible.

1 Like
14

I added CIP-2. It has a status of draft. Weā€™ll wait for broad acceptance from the community and then consider it active in, say, a month.

1 Like
15

Here is the official pull request to move this CIP to a status of Accepted: