{"action":"created","issue":{"url":"https://api.github.com/repos/stellar/stellar-protocol/issues/99","repository_url":"https://api.github.com/repos/stellar/stellar-protocol","labels_url":"https://api.github.com/repos/stellar/stellar-protocol/issues/99/labels{/name}","comments_url":"https://api.github.com/repos/stellar/stellar-protocol/issues/99/comments","events_url":"https://api.github.com/repos/stellar/stellar-protocol/issues/99/events","html_url":"https://github.com/stellar/stellar-protocol/issues/99","id":316507930,"node_id":"MDU6SXNzdWUzMTY1MDc5MzA=","number":99,"title":"Proposal: accounts with deterministic sequence numbers","user":{"login":"robdenison","id":38080851,"node_id":"MDQ6VXNlcjM4MDgwODUx","avatar_url":"https://avatars1.githubusercontent.com/u/38080851?v=4","gravatar_id":"","url":"https://api.github.com/users/robdenison","html_url":"https://github.com/robdenison","followers_url":"https://api.github.com/users/robdenison/followers","following_url":"https://api.github.com/users/robdenison/following{/other_user}","gists_url":"https://api.github.com/users/robdenison/gists{/gist_id}","starred_url":"https://api.github.com/users/robdenison/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/robdenison/subscriptions","organizations_url":"https://api.github.com/users/robdenison/orgs","repos_url":"https://api.github.com/users/robdenison/repos","events_url":"https://api.github.com/users/robdenison/events{/privacy}","received_events_url":"https://api.github.com/users/robdenison/received_events","type":"User","site_admin":false},"labels":[{"id":1012947435,"node_id":"MDU6TGFiZWwxMDEyOTQ3NDM1","url":"https://api.github.com/repos/stellar/stellar-protocol/labels/core","name":"core","color":"1d76db","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2018-04-21T17:04:45Z","updated_at":"2018-11-15T01:07:09Z","closed_at":null,"author_association":"NONE","body":"(EDITED to revise details of proposal)\r\n\r\nThis proposes a new operation, `create_account_2`. The `create_account_2` operation creates a new account, with the following differences from accounts created with `create_account`:\r\n\r\n* The account ID is `0x18 ++ sha256(masterKey, creatingTransactionSourceAccountId, creatingTransactionSequenceNumber, creatingOperationIndex, salt) ++ checksum`, rather than `0x30 ++ masterKey ++ checksum`. (The different prefix byte means that in base32, deterministic account IDs start with a \"D\", while `create_account`'s account IDs start with a \"G\".)\r\n  * `masterKey` is the initial master key on the account\r\n  * `creatingTransactionSourceAccountId` is the source account of the transaction that created the account (not necessarily the source account of the `create_account_2` operation)\r\n  * `creatingTransactionSequenceNumber` is the sequence number of the transaction that created the account\r\n  * `creatingOperationIndex` is the index of the `create_account_2` operation in the transaction that created the account\r\n* The initial sequence number is 0.\r\n\r\n## Rationale\r\n\r\nThis allows users to presign transactions from an account before that account is created, which is otherwise impossible because the sequence number is not predictable. This would enable a wide range of protocols that involve presigning chains of transactions. (Right now, such protocols are limited to ones that send transactions from accounts that already exist at the time the transactions are being signed.) \r\n\r\nThese accounts are also impossible to resurrect if deleted, since the creating account's sequence number will never go down. This makes them safe from any kind of replaying.\r\n\r\nOther potential advantages:\r\n\r\n* any presigned transaction can be assured that its `createAccount2` operations (and Lumen payments into those newly created accounts) will succeed (whereas `createAccount` operations can be made to fail by creating the account before the transaction is published).\r\n* sequence numbers that start with 0 are easy to reason about and work with (particularly in languages like JavaScript that do not yet have native support for 64-bit integers)\r\n* a user can create multiple accounts with the same initial signer\r\n\r\n## XDR\r\n\r\n```\r\nstruct CreateAccount2Op\r\n{\r\n    Signer initialSigner;\r\n    uint256* salt; // defaults to 0\r\n    int64 startingBalance;\r\n};\r\n\r\n/******* CreateAccount2 Result ********/\r\n\r\nenum CreateAccount2ResultCode\r\n{\r\n    // codes considered as \"success\" for the operation\r\n    CREATE_ACCOUNT_2_SUCCESS = 0, // account was created\r\n\r\n    // codes considered as \"failure\" for the operation\r\n    CREATE_ACCOUNT_2_UNDERFUNDED = -1, // not enough funds in source account\r\n    CREATE_ACCOUNT_2_LOW_RESERVE =\r\n        -2, // would create an account below the min reserve\r\n};\r\n\r\nunion CreateAccount2Result switch (CreateAccount2ResultCode code)\r\n{\r\ncase CREATE_ACCOUNT_2_SUCCESS:\r\n    void;\r\ndefault:\r\n    void;\r\n};\r\n```\r\n\r\n## Alternatives\r\n\r\n* Allowing transactions with flexible sequence numbers (as suggested in some of the comments on #88) would also allow users to presign transactions from not-yet-existing accounts, solving most of the problems addressed by this change. (Limiting this feature to preauthorized transactions would _not_ be sufficient; it would have to work with presigned transactions as well.) As noted in that issue, that change might cause some issues with replayability and malleability.\r\n* The initial sequence number could be the initial sequence number on the source account. 0 seems simpler (and easier to work with than 64-bit numbers), but it might potentially conflict with an alternative meaning for 0 sequence numbers, such as the one proposed in #88 (although that one could be adapted to use -1 or MIN_INT64 instead).\r\n* We could exclude the optional `salt` argument entirely. This would slightly simplify the operation, but would prevent a user from creating multiple accounts with the same master key in the same transaction, which allows for a minor optimization to Lightning.\r\n\r\n## Compatibility\r\n\r\n* Explorers would need to change any hard-coded dependencies on accounts having a \"G\" prefix.\r\n* Wallet compatibility with deterministic accounts would be desirable eventually but would not be a priority, because at first, these accounts would primarily be used as part of some special protocol like Lightning, rather than as accounts for ordinary users. "},"comment":{"url":"https://api.github.com/repos/stellar/stellar-protocol/issues/comments/438877644","html_url":"https://github.com/stellar/stellar-protocol/issues/99#issuecomment-438877644","issue_url":"https://api.github.com/repos/stellar/stellar-protocol/issues/99","id":438877644,"node_id":"MDEyOklzc3VlQ29tbWVudDQzODg3NzY0NA==","user":{"login":"MonsieurNicolas","id":4213763,"node_id":"MDQ6VXNlcjQyMTM3NjM=","avatar_url":"https://avatars3.githubusercontent.com/u/4213763?v=4","gravatar_id":"","url":"https://api.github.com/users/MonsieurNicolas","html_url":"https://github.com/MonsieurNicolas","followers_url":"https://api.github.com/users/MonsieurNicolas/followers","following_url":"https://api.github.com/users/MonsieurNicolas/following{/other_user}","gists_url":"https://api.github.com/users/MonsieurNicolas/gists{/gist_id}","starred_url":"https://api.github.com/users/MonsieurNicolas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MonsieurNicolas/subscriptions","organizations_url":"https://api.github.com/users/MonsieurNicolas/orgs","repos_url":"https://api.github.com/users/MonsieurNicolas/repos","events_url":"https://api.github.com/users/MonsieurNicolas/events{/privacy}","received_events_url":"https://api.github.com/users/MonsieurNicolas/received_events","type":"User","site_admin":false},"created_at":"2018-11-15T01:07:09Z","updated_at":"2018-11-15T01:07:09Z","author_association":"CONTRIBUTOR","body":"Interesting idea in [CAP-0007 proposal](https://github.com/stellar/stellar-protocol/pull/203) to add placeholders.\r\n\r\nIf we do this, we probably want to differentiate `AccountID` used in Ledger Entries and `AccountID` used in transactions as placeholders are not valid in the context of ledger entries.\r\n\r\n[CAP-0008](https://github.com/stellar/stellar-protocol/pull/209) seems to  also introduce a (third ) `AccountID` type, different from the one that can be used in operations and ledger entries."}}
{"actor":{"display_login":"MonsieurNicolas"}}