{"action":"created","issue":{"url":"https://api.github.com/repos/EOSIO/eos/issues/5451","repository_url":"https://api.github.com/repos/EOSIO/eos","labels_url":"https://api.github.com/repos/EOSIO/eos/issues/5451/labels{/name}","comments_url":"https://api.github.com/repos/EOSIO/eos/issues/5451/comments","events_url":"https://api.github.com/repos/EOSIO/eos/issues/5451/events","html_url":"https://github.com/EOSIO/eos/pull/5451","id":354527739,"node_id":"MDExOlB1bGxSZXF1ZXN0MjExMjY5ODYw","number":5451,"title":"Subjectively fail transaction if contract bills RAM to another account within a notification handler","user":{"login":"arhag","id":8333406,"node_id":"MDQ6VXNlcjgzMzM0MDY=","avatar_url":"https://avatars0.githubusercontent.com/u/8333406?v=4","gravatar_id":"","url":"https://api.github.com/users/arhag","html_url":"https://github.com/arhag","followers_url":"https://api.github.com/users/arhag/followers","following_url":"https://api.github.com/users/arhag/following{/other_user}","gists_url":"https://api.github.com/users/arhag/gists{/gist_id}","starred_url":"https://api.github.com/users/arhag/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arhag/subscriptions","organizations_url":"https://api.github.com/users/arhag/orgs","repos_url":"https://api.github.com/users/arhag/repos","events_url":"https://api.github.com/users/arhag/events{/privacy}","received_events_url":"https://api.github.com/users/arhag/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/EOSIO/eos/milestones/23","html_url":"https://github.com/EOSIO/eos/milestone/23","labels_url":"https://api.github.com/repos/EOSIO/eos/milestones/23/labels","id":3604125,"node_id":"MDk6TWlsZXN0b25lMzYwNDEyNQ==","number":23,"title":"Version 1.2.3","description":"","creator":{"login":"heifner","id":3933649,"node_id":"MDQ6VXNlcjM5MzM2NDk=","avatar_url":"https://avatars3.githubusercontent.com/u/3933649?v=4","gravatar_id":"","url":"https://api.github.com/users/heifner","html_url":"https://github.com/heifner","followers_url":"https://api.github.com/users/heifner/followers","following_url":"https://api.github.com/users/heifner/following{/other_user}","gists_url":"https://api.github.com/users/heifner/gists{/gist_id}","starred_url":"https://api.github.com/users/heifner/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/heifner/subscriptions","organizations_url":"https://api.github.com/users/heifner/orgs","repos_url":"https://api.github.com/users/heifner/repos","events_url":"https://api.github.com/users/heifner/events{/privacy}","received_events_url":"https://api.github.com/users/heifner/received_events","type":"User","site_admin":false},"open_issues":2,"closed_issues":0,"state":"open","created_at":"2018-08-28T14:18:56Z","updated_at":"2018-08-28T14:19:26Z","due_on":null,"closed_at":null},"comments":3,"created_at":"2018-08-28T00:41:51Z","updated_at":"2018-08-28T14:26:27Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/EOSIO/eos/pulls/5451","html_url":"https://github.com/EOSIO/eos/pull/5451","diff_url":"https://github.com/EOSIO/eos/pull/5451.diff","patch_url":"https://github.com/EOSIO/eos/pull/5451.patch"},"body":"This PR introduces an optional (but enabled by default) subjective soft-fix for the issue of allowing notified contracts to charge RAM to any of the authorizers of the original action. It does so by subjectively (i.e. only during block production and not validation) failing a transaction if at any point in its execution an unprivileged contract executing under the context of handling a notification tries to bill additional RAM to an account other than itself (reducing RAM is still allowed). \r\n\r\nThis is a restriction in previously allowed behavior for a contract executing under the context of handling a notification. This means that if all active block producers of an EOSIO blockchain chose to enable this soft-fix, they would potentially restrict the ability of some existing contracts utilizing this behavior to fully function on that blockchain, at least until the contract code was updated to use a more appropriate pattern that does not rely on the restricted behavior. Note that block producers can still use a version of nodeos including these changes but without enforcing the soft-fix by setting the `disable-ram-billing-notify-checks` field in config.ini to true.\r\n\r\nThe most common pattern which utilizes the effected behavior is immediately creating a table row, if an appropriate one does not already exist, in response to receiving tokens from a user, and charging that user for the RAM costs of the table row. This is a pattern that was even used in an example exchange contract for depositing tokens into the exchange.\r\n\r\nUnfortunately, supporting this particular pattern on EOSIO blockchains opens up contract developers and users to the potential of wasting their available RAM when interacting with accounts with malicious contracts deployed. While it is possible to mitigate the risk by carefully auditing the contracts deployed on accounts that will be notified as a result of a user executing an action, the existing behavior puts an unreasonable burden on contract developers and even users and can be easily argued to not be worth the benefits.\r\n\r\nThis is especially the case considering there is a straightforward alternative to the common pattern described above. Instead of creating a table row (and paying for that RAM then) in the notify handlers as a result of a transfer of tokens, the pattern could instead be:\r\n\r\n1. The user first executes an action that creates a table row (perhaps initialized to a state that indicates it hasn't been fully initialized according to the application logic yet) of sufficient size to hold the later data that the table row will need to be mutated to hold.\r\n2. Then, the transfer notification handler modifies that table row (which it will require to exist at that point) to hold the appropriate data. \r\n\r\nAssuming the data modification of the table rows during the execution of the transfer notification handler does not require changing a primary key (there are future changes planned to address even this corner case) nor does it require increasing the size of the table row data, then the mutation should be successful even under the new stricter behavior. Note that these two actions can still occur atomically as before by putting them (in the right order) within the same transaction. Also note that another action may sometimes be desired to explicitly erase the table row (returning that RAM costs back to the user that payed for it) under certain circumstances; for example, if the table row tracks the balance of tokens deposited in the contract, then if all those tokens have been fully withdrawn, it would be sensible for the contract to allow the user to free that 0-balance table row.\r\n\r\nFurthermore, the two-step pattern described above assumes the contract requires another user to pay for RAM costs of table row. If instead the contract can simply pay for the table row RAM costs itself, there is no need for any of the additional complication."},"comment":{"url":"https://api.github.com/repos/EOSIO/eos/issues/comments/416605475","html_url":"https://github.com/EOSIO/eos/pull/5451#issuecomment-416605475","issue_url":"https://api.github.com/repos/EOSIO/eos/issues/5451","id":416605475,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNjYwNTQ3NQ==","user":{"login":"nsjames","id":10360675,"node_id":"MDQ6VXNlcjEwMzYwNjc1","avatar_url":"https://avatars0.githubusercontent.com/u/10360675?v=4","gravatar_id":"","url":"https://api.github.com/users/nsjames","html_url":"https://github.com/nsjames","followers_url":"https://api.github.com/users/nsjames/followers","following_url":"https://api.github.com/users/nsjames/following{/other_user}","gists_url":"https://api.github.com/users/nsjames/gists{/gist_id}","starred_url":"https://api.github.com/users/nsjames/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nsjames/subscriptions","organizations_url":"https://api.github.com/users/nsjames/orgs","repos_url":"https://api.github.com/users/nsjames/repos","events_url":"https://api.github.com/users/nsjames/events{/privacy}","received_events_url":"https://api.github.com/users/nsjames/received_events","type":"User","site_admin":false},"created_at":"2018-08-28T14:26:27Z","updated_at":"2018-08-28T14:26:27Z","author_association":"CONTRIBUTOR","body":"> To me, the main downside of an action batching would be that users can no longer use my dApp with just wallet transfers.\r\n\r\nIndeed this is the one sad reality about this. "}}
{"actor":{"display_login":"nsjames"}}