Create Pay2PublicScript.md

[Steve132]

I'm proposing a CashAddr extension to create an address format to serialize arbitrary (short) scriptPubKey scripts. This allows one simple codepath to allow all wallets who implement this format to automatically support sending short non-standard scriptPubKey transactions. It has benefits for OP_GROUP proposal, and OP_RETURN data proposals, and many others, without creating or allocating a bunch of transaction address formats in the spec.

[Steve132]

There's a bug in the logic of this regarding the length bits. Specifically, most scriptPubKeys aren't exactly a multiple of 4 bytes long. There are a bunch of good possible ways to address this problem, however.

[Steve132]

So, one really really really important aspect of development that this solves is that it decouples smart contract development services from the security and custodial issues of maintaining a compatible wallet.

Right now, the easiest most user friendly way to post to the blockchain using the memo.cash protocol is to make an account with memo.cash, send some coins there (to a private wallet), on a centralized service, all so that their custom wallet software can create the properly formatted output transaction for the smart contract.

The only way to do it without centralization is to use a different client side wallet unique to that protocol, which I'm not sure exists yet (although I guess it could).

However, with this standard, a memo.cash implementation could simply be an entirely client-side insecure piece of javascript with a form that lets you enter the text and it creates the address according to this standard. For example, I could enter "Hello, Bitcoin Cash!!" into a javascript form, (or even an offline tool) and then the page could generate the address/uri

bitcoincash:z94x6qjgv4kxcmevyppxjarrda5kugzrv9eksgfpqzsu8aym?amount=1

Which I could then pay 1 satoshi to with ANY bitcoincash wallet and correctly implement a payment to the memo protocol. This is much much much simpler and easier and more secure than exposing my privacy and security by using a custom wallet just to provide custom smart contract outputs.

Thus, the 'service' of enabling smart contracts for customers to use is decoupled from the custodial service of wallets.

For UX and decentralization we should not encourage or require every smart contract protocol or colored coin application to develop, secure and maintain a (possibly centralized) custom wallet. We should not encourage or require every user to do that.

[Steve132]

Another example: Suppose I want to accept colored coins

then I can actually create a valid OP_GROUP recieve address for a colored token with the from that address using a similar simple non-custodial utility.

For example, suppose the group ID of the token is qzfk77qqyfaw8xzgt2we98jwh3x62665qcss4zw220 , and a bch address is bitcoincash:qr6m7j9njldwwzlg9v7v53unlr4jkmx6eylep8ekg2,

then bitcoincash:zkfk77qqyfaw8xzgt2we98jwh3x62665q6c82a4f7kl53vuhmtnsh6pt8n9y0ylcav4kekkf3zktnwgglhp6clq is a valid address for the token.

Interestingly, there's some cool UX stuff created by this. For example, similarly, again, 'minting' your own token for any asset from BCH you control can now be done with a simple non-custodial tool off the blockchain instead of a custom wallet service. If you have coins in an address bitcoincash:qzfk77qqyfaw8xzgt2we98jwh3x62665qcss4zw220, you can mint those coins into an asset by sending (with your existing wallet!) to bitcoincash:zkfk77qqyfaw8xzgt2we98jwh3x62665q6c82a4fjdhhsqpz0t3esjz6nkffun4ufkjkk4qx3zktnwgggjxcux2

One important thing to note for colored coins under this proposal:

token source: bitcoincash:qzfk77qqyfaw8xzgt2we98jwh3x62665qcss4zw220
mint address: bitcoincash:zkfk77qqyfaw8xzgt2we98jwh3x62665q6c82a4fjdhhsqpz0t3esjz6nkffun4ufkjkk4qx3zktnwgggjxcux2
token reciev:bitcoincash:zkfk77qqyfaw8xzgt2we98jwh3x62665q6c82a4f7kl53vuhmtnsh6pt8n9y0ylcav4kekkf3zktnwgglhp6clq

Notice how they now all share a prefix because the token is the same? That's good for UX.

It's a little long, and we could create a more-short standard address 'type' format for tokens if we wanted to that has all of these same features, but the advantage of being able to use one standard and a generic wallet to do all these things seems cool.