A call for "op_return" query param support in BCH Wallet Software

2019-05-01T10:01:30.000Z Honest Cash

A call for "op_return" query param support in BCH Wallet Software

The "op_return" and "op_return_raw" query parameters are simply small tags that are appended to bitcoincash: style URI's that allow a small piece of data (max 220 bytes) to be attached to a transaction. At their simplest, their use may look like this:

// op_return is useful for plaintext messages
 bitcoincash:qzgauu2gy4aj744xe0xhxam4j5pxrgmqrqlx8gk6zu?op_return=Rent%20from%Jim
 // op_return_raw is useful for binary encoded data (we pass the op_return_raw as hex)
 bitcoincash:qzgauu2gy4aj744xe0xhxam4j5pxrgmqrqlx8gk6zu?op_return_raw=ABACADAF

I would like to point out some of the use-cases that "opreturn" and "opreturn_raw" (hex version) query parameters would allow as I think this should be a relatively simple addition for most wallets. And it would be a good step towards native Dapp-like support in Wallet Software.

  1. Tracking transactions without having to act as a custodian

    What I am referring to here is the possibility for a service to allow Alice to pay Bob directly - without having to act as a custodian of funds at any point. Currently, some services, in order to confirm that Alice has indeed paid Bob, will generate a temporary address and act as a "proxy" (or forwarder) of sorts to deliver the funds to Bob. Thus, the flow looks something like this: Alice -> Service -> Bob. This puts the service at technical risk - and, as a custodian (albeit very short-term), possibly legal risk too. It is also more expensive from a fee perspective as it requires two transactions.

    The other commonly utilized technique is to have a web-wallet for the service. From a user experience point of view, this can be a bit of a nuisance. Users forget which services they have funds in. The initial transfer of funds to the web-wallet can also be discouraging.

    If op_return (and op_return_raw) was supported, this would allow Bob to use the service with an address generated by his own Wallet Software. The service, who needs to track when successful transactions to Bob take place (and who they came from), can then generate a bitcoincash: URI, in principal, like the following:

    bitcoincash:qpq63av7ufz9j4npkhumfkk6lynnsg2vvc83y43dqa?op_return=SRVC_ALICESID_SHORTHASH
    WHERE:
    SRVC = Service Identifier (4 Bytes)
    ALICESID = Alice's ID on the service
    SHORTHASH = A signature hash that verifies the op_return statement was generated by the service
    (This is just an example, services could structure their OP_RETURN statement however they like.
    In cases such as the above, it is also far more likely that op_return_raw would be used.)
    

    In this respect, with only a few extra bytes of data, the service is able to "track" that a payment has indeed taken place between Alice and Bob.

  2. CashAccount Registration/Updates

    Currently, registration for https://www.cashaccount.info/ is generously paid for by the service itself (thank you Jonathon). If op_return_raw was supported, registration could take place by plugging some values into text inputs (username, address, etc) and having the service generate a QR code that the user's preferred wallet could then scan and pay.

  3. Memo.Cash Posting

    This is similar to the above. Instead of relying on a web-wallet, a user could simply be presented a text-input and a QR code could be generated which would allow the user to make a Memo.Cash post. There is still the problem of maintaining identity between posts as wallet addresses would likely change. I would be keen to hear other's thoughts on a possible solution to this. In any case, it would allow users to post anonymously with ease and I could see the general concept being expanded for use in a global URL commenting system. E.g:

    ?op_return=SHA256(URL_OF_SITE)_USERS-COMMENT WHERE SHA256(URL_OF_SITE) = A SHA256 hash of the URL the user is currently on USERS_COMMENT = The user's comment on that particular URL

These are just examples - ultimately there's a lot of Dapp-like functionality that op_return query paramater support could allow.

Currently, the only wallets that I'm aware of that support op_return (and op_return_raw) query parameters are Electron Cash and Badger Wallet. The Bitcoin.com Wallet requires a change on the server-side Bitcore Wallet Service in order to enable this functionality (more details here: https://bounty.cash/#/categories/1/apps-features/bounty/1/support-for-op-return-query-parameter).

If more wallets supported op_return and op_return_raw, it would make development of some services far easier by:

  1. Eliminating the need for a "forwarder" (proxy) service.
  2. Mitigating legal risk by removing the need for the service to act as a custodian.
  3. Allow for Dapps to be developed without needing to implement a web-wallet specific to their service's needs.

The benefit to the user is that, in many cases, they will be able to keep their funds in their preferred wallet instead of having them speckled amongst dozens of web-wallets.

Down the line, perhaps placeholders (and functions?) in the "op_return" and "op_return_raw" parameters could open up support for even more interesting Dapps.

Responses


RE: A call for "op_return" query param support in BCH Wallet Software

by @christroutner

What are the relevant standards for this feature? Is it BIP70 that covers query parameters in Bitcoin payments? I know there is also the Lokad ID standard that helps to standardize OP_RETURN values so that wallets and dapps can properly classify them. 


It would be great to layout the landscape of standards that apply to this feature and figure out exactly which ones impact it. I'm also unclear as to how to get new standards accepted into BCH or what the process is.