Subkey をバージョンアップしたら restore が使えなくなった

参考：Installing Substrate

リンク先のページに書かれている手順でツールをインストールしました。
Subkey をインストールしたのは2019年2月25日です。（記事を書いているのは2019年4月8日）

バージョンアップしたことにより使用方法が変わったのでメモ
必要となる場面としては、古いバージョンの Substrate を起動したときくらいなので
このメモを清書する予定はありません。

$ subkey --version
1.0.0

使用方法は下記参照
README.adoc

以前のバージョン

$ subkey restore Matsuda
Seed 0x4d61747375646120202020202020202020202020202020202020202020202020 is account:
 Public key (hex): 0x9d361c06d36e411422e49d14d00f5128662b8f84567400ee26aaeb3cfc8f7f77
 Address (SS58): 5FcqSzTdr3zeiMan8S48Rz7yP8fG3YYkzjpD1iaSBAuihkME

subkey_1.0.0

$ subkey -e inspect 0x4d61747375646120202020202020202020202020202020202020202020202020
Secret Key URI `0x4d61747375646120202020202020202020202020202020202020202020202020` is account:
  Seed: 0x4d61747375646120202020202020202020202020202020202020202020202020
  Public key (hex): 0x9d361c06d36e411422e49d14d00f5128662b8f84567400ee26aaeb3cfc8f7f77
  Address (SS58): 5FcqSzTdr3zeiMan8S48Rz7yP8fG3YYkzjpD1iaSBAuihkME

SUBCOMMAND が restore がなくなり inspect を使う。
暗号化が ed25519 から sr25519 がデフォルトになっている。
ed25519 を使う場合は FLAG に -e を指定する。
シードをプレーンテキストで渡していたが、HEX で渡す。

subkey_1.0.0

$ subkey inspect //Matsuda
Secret Key URI `//Matsuda` is account:
  Public key (hex): 0xb6abcbae9fe7a7fbe97b807c0fcddb9f828926c93946e263d2481f4f6f11582b
  Address (SS58): 5GCDc7Jm4xniPX292ueq8Vu13gwCmE1yKxupTZJaHjc8jbNQ

v1.0.0 の書き方ではシードは // を最初に書く。
/ （スラッシュひとつ）の場合は、DEV_PHRASE が前について、、、、、、（略）
暗号化が異るので結果は異る

subkey_1.0.0

$ subkey -e inspect //Matsuda
Secret Key URI `//Matsuda` is account:
  Seed: 0xdcc2c44b58d9abaf03ff7bfa24a7a7ef9f670f9a46971c1e928c49b87e13c22f
  Public key (hex): 0xc34895f70cea7f32e7cc8d4301edec66c1381ef9f176a3dd25cdbd1398677834
  Address (SS58): 5GUkksMZ2CPmPvCtD7GDH3dLfGSnxLZVHK7k8L9dqjoSLdr6

FLAG -e をつけても Seed が変わるので同じ結果は得られない。
古いバージョンと同じ結果を得るには、シードにするテキスト（プレーンテキスト）を HEX に変換して FLAG -e をつける。

substrate/core/primitives/src/crypto.rs

pub trait Pair: Sized {
	/// Interprets the string `s` in order to generate a key Pair.
	///
	/// This takes a helper function to do the key generation from a phrase, password and
	/// junction iterator.
	///
	/// - If `s` is a possibly `0x` prefixed 64-digit hex string, then it will be interpreted
	/// directly as a `MiniSecretKey` (aka "seed" in `subkey`).
	/// - If `s` is a valid BIP-39 key phrase of 12, 15, 18, 21 or 24 words, then the key will
	/// be derived from it. In this case:
	///   - the phrase may be followed by one or more items delimited by `/` characters.
	///   - the path may be followed by `///`, in which case everything after the `///` is treated
	/// as a password.
	/// - If `s` begins with a `/` character it is prefixed with the Substrate public `DEV_PHRASE` and
	/// interpreted as above.
	///
	/// In this case they are interpreted as HDKD junctions; purely numeric items are interpreted as
	/// integers, non-numeric items as strings. Junctions prefixed with `/` are interpreted as soft
	/// junctions, and with `//` as hard junctions.
	///
	/// There is no correspondence mapping between SURI strings and the keys they represent.
	/// Two different non-identical strings can actually lead to the same secret being derived.
	/// Notably, integer junction indices may be legally prefixed with arbitrary number of zeros.
	/// Similarly an empty password (ending the SURI with `///`) is perfectly valid and will generally
	/// be equivalent to no password at all.
	///
	/// `None` is returned if no matches are found.
	fn from_string(s: &str, password_override: Option<&str>) -> Result<Self, SecretStringError> {
	}
}