subkey and polkadot-js tools

[chesterliliang]

I am testing the sr25519 signatures both using subkey tool and polkadot-js tool. I found the signature made by js tool could be verified by subkey, but subkey's signature could not be verified by js any way.

network: kusama
substrate version:
commit 3ba0f2a
(HEAD -> polkadot-master, origin/polkadot-master)
sr25519 for subkey: 0.8.4
url for js tool:https://polkadot.js.org/apps/#/toolbox/verify
setting: to kusama host by parity

account:

./subkey --network 'kusama' inspect 'decrease reveal tunnel future ring month oxygen business orient nice save frost'
Secret phrase `decrease reveal tunnel future ring month oxygen business orient nice save frost` is account:
  Secret seed: 0x3b702c543136cb64abffc0740f0cc2fe6c6b7cd0e36fea4ebf3a220a3879a83d
  Public key (hex): 0x2e0a685d757d6904785b1dc01e6e67aecb8675a84bde3a1da85386c2fbb09279
  Address (SS58): Dcgp4X57UXtxRrAiFyP2Gq8qRVLhfmVYacRC9CDwMjtbP3A

subkey verify data=12 in textbox on page

 echo -n '12' | ./subkey --network 'kusama' verify 7eacf1c22fc05166dbd0c6cf95a9c12305a48847ffbe6bc0a318440f489a9851cfdb960da7ca686cb84f616ed2e45a9a12e28ac194a67fae0102bd598ec4db0a 'decrease reveal tunnel future ring month oxygen business orient nice save frost'
verify message [49, 50]
Signature verifies correctly.

sign cmd on subkey

echo -n '12' | ./subkey --network 'kusama' sign 'decrease reveal tunnel future ring month oxygen business orient nice save frost'

[burdges]

Is your js running schnorrkel 0.1.1 or 0.8.*? We verify correctly the deprecated schnorrkel 0.1.1 signatures in polkadot, but we'll disable this once all the testnets have transitioned.

[chesterliliang]

Thanks Jeff.
I am trying to figure out which version in js. We are not running js by our own but just use the online one. All rust code turned into asm.js and we can not track the version so far. So may be we need some one from js team to ask..

[bkchr]

CC @jacogr

[jacogr]

The JS side is on 0.1.1 - since it still needs Alexander and (some other, e.g. templates) 1.x chain support. The PR is completed, but marked as on-ice until Substrate 1.x support is dropped. polkadot-js/wasm#29

[chesterliliang]

@jacogr Thanks. I verified 0.1.1 is ok.

And BTW, the readme of subkey:

echo <msg> | subkey sign <seed,mnemonic>

There is a little small issue that we will get an '0x0a' in the end of message without -n. Nothing a big deal but will be better if

echo -n <msg> | subkey sign <seed,mnemonic>

[bkchr]

@chesterliliang ty for reporting back! I will close this now.

[burdges]

Could we suggest different branches of polkadot-js for different chains? I'm wondering how long these deployments persist.

[jacogr]

I have a whole chain of dependencies -

• WASM interfaces - https://github.com/polkadot-js/wasm
• utility libraries (wraps above) - https://github.com/polkadot-js/common
• API (uses above) - https://github.com/polkadot-js/api
• UI (uses above) - https://github.com/polkadot-js/apps

There will be a final version of the api that still supports 1.x before that gets dropped (for chains that are based on Substrate 1.x, while e.g. the UI will just immediately "stop"), but while we still have in-use chains with no actual other options, i.e. we don't have an Alexander replacement as of yet, there is not much room to move to just "drop stuff randomly".

While all do-able, I'm not jumping up and down with joy at the prospect of having to manage multiples of each of the above alongside everything else, I only have so many hours a day and stretched as it is. While there are still compatibility options, not creating extra work.

[burdges]

I see. We're not going to upgrade Alexander either? Do we know how long it'll live?

[jacogr]

Don't let my lack of action stop anything, there are ways to manage this (it just adds overhead and some additional support/confusion), but nothing should be a show-stopper in the name of progress. The path of least friction till now is "having the work done, but not merged".

Alexander is 6+ months old and really cannot be upgraded from Polkadot 0.4 to 0.5 (lots of things moved around, the trie has changed, etc. It can be done with migration scripts, but is is easier to re-launch a testnet in the same vein without wasted effort)