[UX] User can't mint it's own asset

[mversic]

GIT commit hash

5ff6b67d392a0f8238d483918ea36e82d9a22937

Minimum working example

use core::str::FromStr as _;
use iroha_client::{client::Client, Configuration};
use iroha_data_model::prelude::*;

fn main() -> Result<(), &'static str> {
    // NOTE: It is assumed that the genesis block contained the following instructions:
    // 1. register user `alice@wonderland`
    // 2. register asset definition `rose@wonderland`
    // 3. mint asset `rose` for user `alice`

    let config = Configuration::from_path("./config.json").unwrap();
    let client = Client::new(&config).unwrap();

    let account_id = AccountId::from_str("alice@wonderland").expect("Valid");
    let asset_definition_id = AssetDefinitionId::from_str("rose#wonderland").expect("Valid");

    let mint: Instruction = MintBox::new(
        Fixed::try_from(1.00_f64).unwrap(),
        IdBox::AssetId(AssetId::new(asset_definition_id, account_id)),
    )
    .into();

    // Submit a transaction
    client
        .submit_blocking(mint)
        .expect("I can't mint an asset `rose@wonderland` under my account");

    // Exit normally
    Ok(())
}

Steps to reproduce (from QA)

 $ ./iroha_client_cli account register \
    --id="mad_hatter@looking_glass" \
    --key="ed0120a753146e75b910ae5e2994dc8adea9e7d87e5d53024cfa310ce992f17106f92c"
 $ ./iroha_client_cli account register \
    --id="white_rabbit@looking_glass" \
    --key="ed0120a4c4dadd9f18b0f63d6a420151fe0748d785475dec63034a15fcf999ceda1e65"
 $ ./iroha_client_cli asset register \  
    --id="tea#looking_glass" \
    --value-type=Quantity
 $ ./iroha_client_cli asset register \  
    --id="coffee#looking_glass" \
    --value-type=Quantity
 $ ./iroha_client_cli asset mint \     
    --account="white_rabbit@looking_glass" \
    --asset="rose#looking_glass" \
    --quantity="100"

Expected behaviour

alice can mint it's own asset rose

Actual behaviour

alice doesn't have the permission to mint it's own asset rose because the asset was registered with the genesis account

Operating system

Arch Linux

LibC type and version

No response

Current environment

Source code build

CLI output

Caused by:
   0: Transaction rejected due to insufficient authorisation
   1: Action not permitted: Failed to pass first check with Can't mint assets with definitions registered by other accounts. and second check with Account does not have the needed permission token: PermissionToken { name: "can_mint_user_asset_definitions", params: {"asset_definition_id": Id(AssetDefinitionId(DefinitionId { name: "rose", domain_id: Id { name: "wonderland" } }))} }..

To reproduce you can use the default genesis.json located in configs/peer

With the current state of Iroha this effectively means that alice has no control over it's own asset rose unless given the permission by the genesis account. Should alice be able to mint it's own asset if it was registered from another account?

[6r1d]

Should alice be able to mint it's own asset if it was registered from another account?

I'd describe it a bit differently: the UX is currently confusing here. Let's say I'm running this command:

./iroha_client_cli asset register --id="rose#wonderland" --value-type=Quantity

I expect the Alice account to be used due to the tutorial JSON file AND I expect said account to either have a full control or to see a message like "warning: this is a tutorial asset, generated on the genesis account, so only genesis has control over it".

Moreover, let's look at the command again:

./iroha_client_cli asset mint --account="alice@wonderland" --asset="rose#wonderland" --quantity="100"

We'd even see said account in the output:

User: alice@wonderland
{"PUBLIC_KEY":"ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0","PRIVATE_KEY":{"digest_function":"ed25519","payload":"9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"},"ACCOUNT_ID":{"name":"alice","domain_id":{"name":"wonderland"}},"BASIC_AUTH":{"web_login":"alice","password":"mystery_drinks"},"TORII_API_URL":"http://127.0.0.1:8080","TORII_TELEMETRY_URL":"127.0.0.1:8180","TRANSACTION_TIME_TO_LIVE_MS":100000,"TRANSACTION_STATUS_TIMEOUT_MS":10000,"TRANSACTION_LIMITS":{"max_instruction_number":4096,"max_wasm_size_bytes":4194304},"ADD_TRANSACTION_NONCE":false,"LOGGER_CONFIGURATION":{"MAX_LOG_LEVEL":"INFO","TELEMETRY_CAPACITY":1000,"COMPACT_MODE":false,"LOG_FILE_PATH":null,"TERMINAL_COLORS":true}}

The relatively useful error appears on Iroha peer log and it doesn't tell the user enough info to proceed.

[s8sato]

I think it is proper as the default permission that only the registerer can mint. Minting will be a very privileged instruction, just like that only the central banks or equivalents mint fiat currencies and most of customers just transfer it.

As for https://github.com/hyperledger/iroha/issues/2518#issuecomment-1192487010 I'd recommend to create another issue because it aims to improve the UX around the CLI, which is different from what this issue targets. You can suggest your design in the new issue @6r1d

[mversic]

I think it is proper as the default permission that only the registerer can mint. Minting will be a very privileged instruction, just like that only the central banks or equivalents mint fiat currencies and most of customers just transfer it.

Ok, but if the genesis mints the asset for alice, alice can only look at it's asset and nothing else. This effectively, makes alice a storage for genesis assets

[mversic]

either we leave it like this, or we make it so that user can always access assets stored under their account without requiring any additional permission. User must still not be able to mint(i.e. add to their account) any other asset not registered by them unless given the permission to. They also can't mint another instance of the same asset. If someone else mints the asset (that they don't have the permission to mint) for them, then they are allowed to continue minting that asset

[AlexStroke]

Fully reproducible

Pipeline(
    Event {
        entity_kind: Transaction,
        status: Validating,
        hash: { Hash(1633388433a611a1cc1db63f3c518f1575a420e15c26e9c9a44a879102bfb21d) },
    },
)
Pipeline(
    Event {
        entity_kind: Block,
        status: Validating,
        hash: { Hash(bbe90f2a122e6c16c6f76ea14dd15b98ab2df17afb73d4ea823757bd89f29f98) },
    },
)
Pipeline(
    Event {
        entity_kind: Transaction,
        status: Rejected(
            Transaction(
                NotPermitted(
                    NotPermittedFail {
                        reason: "Failed to pass first check with Can't mint assets with definitions registered by other accounts. and second check with Account does not have the needed permission token: PermissionToken { name: \"can_mint_user_asset_definitions\", params: {\"asset_definition_id\": Id(AssetDefinitionId(DefinitionId { name: \"rose\", domain_id: Id { name: \"looking_glass\" } }))} }..",
                    },
                ),
            ),
        ),
        hash: { Hash(1633388433a611a1cc1db63f3c518f1575a420e15c26e9c9a44a879102bfb21d) },
    },
)
Pipeline(
    Event {
        entity_kind: Block,
        status: Committed,
        hash: { Hash(bbe90f2a122e6c16c6f76ea14dd15b98ab2df17afb73d4ea823757bd89f29f98) },
    },
)```

[Arjentix]

@mversic , I didn't understand your last suggestion. Do you suggest to give access to mint assets you have or not?

[Arjentix]

I vote to leaving that as is. To me this looks like a right behaviour.

For our testing purposes we can always grant (in genesis.json) alice permission to mint rose.

[mversic]

@mversic , I didn't understand your last suggestion. Do you suggest to give access to mint assets you have or not?

My suggestion was to make an exception and allow the user to mint the asset if asset is already registered for them.

I am not very keen on handling corner cases

[Arjentix]

My suggestion was to make an exception and allow the user to mint the asset if asset is already registered for them.

What do you mean by registered for them? Registered by user? Or if someone has transfered it to user?

[Erigara]

@Arjentix how is this related to permission validator approach you proposed? That everything is allowed until explicitly prohibited by some validator?

[appetrosyan]

No UX issues. Should use genesis block generator. Keep blockchain simple