Shunkichi Sato

As long as `transaction.payload.authority` is `AccountId`, aliases should be resolved before the transaction building. Otherwise the transaction signature will be affected by aliases, which means verifiers should consider alias history...

My last post didn't say anything so let me redefine the motive to external name services: Since the transaction authority is the client itself, it is already in the config...

> My last post didn't say anything No, it said something: if clients built a transaction with unresolved names, the signature should be verified with that unresolved names, which means...

### Draft happy path Prerequisites: - A resolver is a Torii endpoint of a node of another Iroha network deployed as a name service - An alias is an asset...

- Made GENESIS_PUBLIC_KEY an arg in kagami. See [diff](https://github.com/hyperledger/iroha/compare/45189ee7f43e1c6a6eab063740fd5242e9ebde36..0eb152b4cbbce30181419a7c8bdf54f038c97c15) - `cargo test -p iroha_core --lib -- snapshot::tests::can_read_snapshot_after_writing` seems to be failing since 1606d088f

- Reverted it to be ignored: `cargo test --all-features -p iroha_smart_contract --doc -- parse` has been failing even before this PR

- blocked by #4373

I think #4788 realized multisig by combination of some existing instructions, which would require no additional commands to clients. What is your opinion @Erigara ?

### current implementation policy ```rust struct AccountId(PublicKey) struct Domain { accounts: Map, // snip } struct Account { id: AccountId, domain: DomainId, // snip } ``` - A provisional account...

Indeed, it can be misimplementation to equate the domain membership and the account activation e.g. someone can stash an account to another domain and an admin of the original domain...