Custom operations + custom permissions == integration with other services

[GwenNelson]

Perhaps we should allow custom operation types for SMTs that can be defined as metadata from the control account.

Each operation type should specify the requirements for the operation to succeed in terms of which permissions are required on sending user and various other parameters in other places, then once validate the operation specifies multiple primitive operations to carry out. The total operation should be atomic, if the primitive operations can not be carried out, the overall operation must fail and none should be carried out.

For example, a standard "pay" operation would require the operation to be signed by the sending user's private key for the "pay" operation.

Custom permissions could enable features such as limited payments (think of an analogy to credit/debit card payment authorisations or direct debit). Under the "pay" permissions, the user's metadata provides a list of public keys or accounts authorised to make payments from their account specifying the token type they can charge from, and for each token type a limit on overall amount and frequency.

Permissions may also be "single-shot", being removed as soon as the operation is carried out.

As a practical scenario, a user may generate a permission for another user to perform the pay or post operations once and only once. Applications for this are obvious but include things such as providing a merchant a one-shot permission to take payment only once they ship a product, limiting the amount to the amount of the order.

The definitions of custom operations should be specified at token creation time so that a token creator can not redefine an operation to require less permissions.

A payment in STEEM or SBD should not be possible to authorise inside an SMT operation - operations that require STEEM/SBD payments will have the implied requirements for a "pay" permission on STEEM+SBD in addition to whatever other requirements they impose for their own token.

To simplify things for end users, the actual permissions required for each operation can be requested via a service like SteemConnect, with the user being prompted to authorise each permission along with the token type and limits on the permission being requested.

For example, upon checkout at an online store for an order worth 20SBD the merchant may request a payment in SBD once the order is shipped - it would request a one-shot permission limited to 20SBD with an optional expiry time. The user would be directed to SteemConnect to authorise the payment.

Another example is a user authorising a repeated payment using a custom "subscribe" operation that adds an authorisation for repeated payments of a set amount at a set frequency. A "cancel subscription" and "take subscription payment" operation would be defined to allow online services to manage their user's subscriptions. A simple repeated payment could be used, or the service may instead have to use "take subscription payment" manually, allowing for the option of things such as discounts etc (by not taking the full subscription amount).

The actual semantics of these operations would be up to token creators, though I would suggest some basic operations would improve STEEM and SBD directly.

With SMTs, the custom operations may also be authorised via SteemConnect, with the operation definition containing metadata that specifies a human-readable description of what they do.

For example, I can imagine an online MMO representing ingame HP and money having a healing service that makes use of a custom "heal" operation which requests permission to transfer GIL (money) from the user in exchange for increasing the user's HP metadata. Such metadata could be set with permissions inside the original SMT definition so that the user themselves can not arbitrarily increase it (cheating, in terms of online gaming). Alternatively, the HP amount could be setup as a token (though this brings with it added complexity as things such as HP are not zero-sum or transferrable normally).

For integration with other services, a token creator may specify trusted sources of information (similar to how witnesses manage SBD price feed) for things such as pulling whether or not a transaction was carried out in BTC and other cryptocurrencies (witnesses could help here in a very simple way). Operations may have a requirement that an event has taken place elsewhere that could be managed by having the user submit an operation named (for example) "request verify bitcoin payment" which would then need to be signed by a minimal number of witnesses or other trusted sources (who is trusted depends upon the requirements set by token creator). The trusted sources would then respond with "verify bitcoin payment", an operation which optionally pays them a fee from the initial user.

In the online gaming example, a trusted source could be the game server: simply create an account representing the game server and have it verify "request verify game kill" operations in order to enable users to be rewarded on the blockchain for ingame actions.

[realnedscott]

Is this not Turing complete programming?

Sent from my iPhone

On Aug 21, 2017, at 12:07 PM, Gareth Nelson notifications@github.com wrote:

Perhaps we should allow custom operation types for SMTs that can be defined as metadata from the control account.

Each operation type should specify the requirements for the operation to succeed in terms of which permissions are required on sending user and various other parameters in other places, then once validate the operation specifies multiple primitive operations to carry out. The total operation should be atomic, if the primitive operations can not be carried out, the overall operation must fail and none should be carried out.

For example, a standard "pay" operation would require the operation to be signed by the sending user's private key for the "pay" operation.

Custom permissions could enable features such as limited payments (think of an analogy to credit/debit card payment authorisations or direct debit). Under the "pay" permissions, the user's metadata provides a list of public keys or accounts authorised to make payments from their account specifying the token type they can charge from, and for each token type a limit on overall amount and frequency.

Permissions may also be "single-shot", being removed as soon as the operation is carried out.

As a practical scenario, a user may generate a permission for another user to perform the pay or post operations once and only once. Applications for this are obvious but include things such as providing a merchant a one-shot permission to take payment only once they ship a product, limiting the amount to the amount of the order.

The definitions of custom operations should be specified at token creation time so that a token creator can not redefine an operation to require less permissions.

A payment in STEEM or SBD should not be possible to authorise inside an SMT operation - operations that require STEEM/SBD payments will have the implied requirements for a "pay" permission on STEEM+SBD in addition to whatever other requirements they impose for their own token.

To simplify things for end users, the actual permissions required for each operation can be requested via a service like SteemConnect, with the user being prompted to authorise each permission along with the token type and limits on the permission being requested.

For example, upon checkout at an online store for an order worth 20SBD the merchant may request a payment in SBD once the order is shipped - it would request a one-shot permission limited to 20SBD with an optional expiry time. The user would be directed to SteemConnect to authorise the payment.

Another example is a user authorising a repeated payment using a custom "subscribe" operation that adds an authorisation for repeated payments of a set amount at a set frequency. A "cancel subscription" and "take subscription payment" operation would be defined to allow online services to manage their user's subscriptions. A simple repeated payment could be used, or the service may instead have to use "take subscription payment" manually, allowing for the option of things such as discounts etc (by not taking the full subscription amount).

The actual semantics of these operations would be up to token creators, though I would suggest some basic operations would improve STEEM and SBD directly.

With SMTs, the custom operations may also be authorised via SteemConnect, with the operation definition containing metadata that specifies a human-readable description of what they do.

For example, I can imagine an online MMO representing ingame HP and money having a healing service that makes use of a custom "heal" operation which requests permission to transfer GIL (money) from the user in exchange for increasing the user's HP metadata. Such metadata could be set with permissions inside the original SMT definition so that the user themselves can not arbitrarily increase it (cheating, in terms of online gaming). Alternatively, the HP amount could be setup as a token (though this brings with it added complexity as things such as HP are not zero-sum or transferrable normally).

For integration with other services, a token creator may specify trusted sources of information (similar to how witnesses manage SBD price feed) for things such as pulling whether or not a transaction was carried out in BTC and other cryptocurrencies (witnesses could help here in a very simple way). Operations may have a requirement that an event has taken place elsewhere that could be managed by having the user submit an operation named (for example) "request verify bitcoin payment" which would then need to be signed by a minimal number of witnesses or other trusted sources (who is trusted depends upon the requirements set by token creator). The trusted sources would then respond with "verify bitcoin payment", an operation which optionally pays them a fee from the initial user.

In the online gaming example, a trusted source could be the game server: simply create an account representing the game server and have it verify "request verify game kill" operations in order to enable users to be rewarded on the blockchain for ingame actions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[GwenNelson]

It doesn't need to be turing complete, but if it is turing complete that's a plus, not a negative.

We would want custom operations to not take too long to verify, so although they could in theory be used to implement arbitrary algorithms that should be discouraged.

[theoreticalbts]

So I think part of what you're proposing is that, instead of having relatively coarse-grained roles -- owner, active, and posting -- you instead have more fine-grained roles, so perhaps you have a permission that only grants access to a single operation (e.g. transfer).

Redefining the permission system of STEEM is something we've talked about for a while. But it's simply out of scope for this project.

For example, upon checkout at an online store for an order worth 20SBD the merchant may request a payment in SBD once the order is shipped - it would request a one-shot permission limited to 20SBD with an optional expiry time

What you're describing here is proposed transaction. Proposed transactions were a feature designed by me, included in BitShares 2.0. However, proposed transactions require a lot of UI work in order to be usable -- the UI frontend must be able to display arbitrary transactions and show the user a view which completely describes what the proposed operations will do. This UI development work was never done.

For STEEM we deliberately decided not to include proposed transaction functionality. Because ultimately, the proposed transaction functionality can be done completely from blockchain amount.

I think the rest of what you're slowly finding your way toward is either a full-fledged smart contract system, or a fabric-of-blockchains idea where state is exported between blockchains. The backend team has had extensive technical discussions about these topics.

While interesting, we've decided not to prioritize these efforts, and focus our limited engineering resources on functionality that is more limited in scope than what you're beginning to envision here.

[GwenNelson]

I would not propose we use this for the main steem blockchain - instead the idea is to enable this kind of arbitrary definition to take place for SMTs only. The examples I gave are just that - examples.