[documentation] Bash tutorial, transferring assets, access rights and account auth

[6r1d]

Documentation URL(s)

Bash guide: transferring assets

Description

Sungod reported an issue with our current documentation: the Bash guide can't be finished, and step 6, "transferring assets", is the reason.

./iroha_client_cli account grant --id "mad_hatter@looking_glass" --permission permission_token.json

The error he sees in the logs is: The signer does not own the asset specified in the permission token.
Repeating the attempt causes the same error no matter how often he tries it.

Log contents

User: alice@wonderland
{"PUBLIC_KEY":"ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0","PRIVATE_KEY":{"digest_function":"ed25519","payload":"9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"},"ACCOUNT_ID":"alice@wonderland","BASIC_AUTH":{"web_login":"mad_hatter","password":"ilovetea"},"TORII_API_URL":"http:\/\/127.0.0.1:8080","TORII_TELEMETRY_URL":"http:\/\/127.0.0.1:8180","TRANSACTION_TIME_TO_LIVE_MS":100000,"TRANSACTION_STATUS_TIMEOUT_MS":15000,"TRANSACTION_LIMITS":{"max_instruction_number":4096,"max_wasm_size_bytes":4194304},"ADD_TRANSACTION_NONCE":false}
Error:
 0: Failed to grant permission to the account
 1: Failed to submit transaction SignedTransaction { payload: Payload { account_id: Id { name: "alice", domain_id: Id { name: "wonderland" } }, instructions: Instructions([Grant(GrantBox { object: EvaluatesTo { expression: Raw(PermissionToken(Token { definition_id: Id { name: "can_transfer_user_assets" }, params: {"asset_id": Id(AssetId(Id { definition_id: DefinitionId { name: "tea", domain_id: Id { name: "looking_glass" } }, account_id: Id { name: "mad_hatter", domain_id: Id { name: "looking_glass" } } }))} })), _value_type: PhantomData<iroha_data_model::Value> }, destination_id: EvaluatesTo { expression: Raw(Id(AccountId(Id { name: "mad_hatter", domain_id: Id { name: "looking_glass" } }))), _value_type: PhantomData<iroha_data_model::IdBox> } })]), creation_time: 1677062642194, time_to_live_ms: 100000, nonce: None, metadata: {} }, signatures: {iroha_crypto::signature::SignatureOf<iroha_data_model::transaction::Payload>({ pub_key: ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0, payload: 3BD290B7A7540D7FE610C031EF60234D71A00E0E275D4A0E62851DAB0F85946708BFC3DA7E24462755C8E951C8FCA74F495255DB0D35F63FD732DAE00467F70A })} }
 2: Transaction rejected
 3: Action not permitted: Validator ``Grant validator` with nested checking` denied the operation `GRANT `can_transfer_user_assets: {`asset_id` : `tea##mad_hatter@looking_glass`}` TO `mad_hatter@looking_glass`` by `alice@wonderland`: Validator `Allow to grant `can_transfer_user_assets` permission token if `the signer is the asset owner`` denied the operation: The signer does not own the asset specified in the permission token
 4: Action not permitted: Validator ``Grant validator` with nested checking` denied the operation `GRANT `can_transfer_user_assets: {`asset_id` : `tea##mad_hatter@looking_glass`}` TO `mad_hatter@looking_glass`` by `alice@wonderland`: Validator `Allow to grant `can_transfer_user_assets` permission token if `the signer is the asset owner`` denied the operation: The signer does not own the asset specified in the permission token
 5: Action not permitted: Validator ``Grant validator` with nested checking` denied the operation `GRANT `can_transfer_user_assets: {`asset_id` : `tea##mad_hatter@looking_glass`}` TO `mad_hatter@looking_glass`` by `alice@wonderland`: Validator `Allow to grant `can_transfer_user_assets` permission token if `the signer is the asset owner`` denied the operation: The signer does not own the asset specified in the permission token

Location:
 client/src/client.rs:524

The configuration file is not outdated and was previously copied from configs/client_cli/config.json.

{
  "PUBLIC_KEY": "ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0",
  "PRIVATE_KEY": {
    "digest_function": "ed25519",
    "payload": "9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"
  },
  "ACCOUNT_ID": "alice@wonderland",
  "BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },
  "TORII_API_URL": "http://127.0.0.1:8080",
  "TORII_TELEMETRY_URL": "http://127.0.0.1:8180",
  "TRANSACTION_TIME_TO_LIVE_MS": 100000,
  "TRANSACTION_STATUS_TIMEOUT_MS": 15000,
  "TRANSACTION_LIMITS": {
    "max_instruction_number": 4096,
    "max_wasm_size_bytes": 4194304
  },
  "ADD_TRANSACTION_NONCE": false
}

Sungod noted that even if steps are completed successfully, some errors appear in Compose logs:

iroha-iroha2-1  | 2023-02-22T09:57:11.296032Z ERROR run: iroha_core::sumeragi::main_loop: The block is rejected as it is not signed by the leader. addr=iroha2:1339 role=ProxyTail leader=iroha3:1340 hash=e74a5d5178e8f1e9f4b0de86e6954939f4b2623709eca14b019903c360413e13
iroha-iroha0-1  | 2023-02-22T09:57:11.314676Z ERROR run: iroha_core::sumeragi::main_loop: The block is rejected as it is not signed by the leader. addr=iroha0:1337 role=ObservingPeer leader=iroha3:1340 hash=e74a5d5178e8f1e9f4b0de86e6954939f4b2623709eca14b019903c360413e13

I was told that such errors sometimes happen in the Sumeragi consensus algorithm by @mversic.
The most probable cause is the delayed packet from the previous round that reaches the node after a change. However, it does not affect the function of the Sumeragi consensus algorithm.

As @mversic suggested, the account id in the config file should apply to the mad_hatter@looking_glass instead of alice@wonderland, so I've altered the config by replacing the ACCOUNT_ID:

{
  "PUBLIC_KEY": "ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0",
  "PRIVATE_KEY": {
    "digest_function": "ed25519",
    "payload": "9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"
  },
  "ACCOUNT_ID": "mad_hatter@looking_glass",
  "BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },
  "TORII_API_URL": "http://127.0.0.1:8080",
  "TORII_TELEMETRY_URL": "http://127.0.0.1:8180",
  "TRANSACTION_TIME_TO_LIVE_MS": 100000,
  "TRANSACTION_STATUS_TIMEOUT_MS": 15000,
  "TRANSACTION_LIMITS": {
    "max_instruction_number": 4096,
    "max_wasm_size_bytes": 4194304
  },
  "ADD_TRANSACTION_NONCE": false
}

There lies a problem: we have a public and private key assigned to the mad_hatter@looking_glass account, and I don't know where those are located. Using cargo run --bin kagami -- crypto did not help because some keys are generated beforehand.

I also need clarification about the whole situation with the accounts here.

• We have Kagami passwords and access keys at the same time.
• We have a pre-defined public key in "Registering an account" section, possibly with a lost private one.
• Is Alice an already existing account?
• How do we replace public and private keys for registered users?

Your suggestions

We'll have to alter the tutorial right after this is fixed.

Who can help?

@mversic @appetrosyan @outoftardis

[outoftardis]

Is Alice an already existing account?

Yes. And in client config, the ACCOUNT_ID should be an account that already exists (was previously registered).

We have a pre-defined public key in "Registering an account" section, possibly with a lost private one.

Since this is an example, should we just generate a new key pair for mad_hatter and include it in the tutorial?

[mversic]

@6r1d can you move this to the iroha2-docs repo?