Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.

Conversation

@tomusdrw
Copy link
Contributor

@tomusdrw tomusdrw commented Mar 18, 2019

Related #2022

Uses AnySignature for node/runtime and MultiSignature for test-runtime.

Superceded by #2028

jacogr
jacogr previously approved these changes Mar 18, 2019
Copy link
Contributor

@jacogr jacogr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It solves the ed25519 signature issue, was able to submit both sr25519 and ed25519 signed transactions. (The CantPay which can be fixed with a restart issue is still there, but not meant to be fixed here)

@jacogr
Copy link
Contributor

jacogr commented Mar 18, 2019

Also included in #2028

@tomusdrw tomusdrw added A0-please_review Pull request needs code review. and removed A1-onice labels Mar 25, 2019
@tomusdrw
Copy link
Contributor Author

tomusdrw commented Mar 25, 2019

Removing onice since I think it was only blocked by #2048 / #2028

sr25519::Pair::from_string(&format!("//{}", seed), None)
.expect("static values are valid; qed")
.public()
.unchecked_into()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unchecked_into is semantically unsafe, so shouldn't be in any production code. though it's kind of safe here, i'd prefer to use a real .into() since we are after all converting between two strong types.

let key = AccountKeyring::from_public(&signed).unwrap();
let signature = payload.using_encoded(|b| {
let key = AccountKeyring::from_h256_public(signed.clone().into()).unwrap();
let signature = UncheckedFrom::unchecked_from(payload.using_encoded(|b| {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would prefer to keep strong types here, too.

let payload = (index.into(), xt.function, era, GENESIS_HASH);
let key = AccountKeyring::from_public(&signed).unwrap();
let signature = payload.using_encoded(|b| {
let key = AccountKeyring::from_h256_public(signed.clone().into()).unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

converting via H256 kills semantics. this stuff should retain strong typing as before.

Copy link
Member

@gavofyork gavofyork left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few instances where type-unsafety is being created.

@gavofyork gavofyork added A4-gotissues and removed A0-please_review Pull request needs code review. A4-gotissues labels Mar 26, 2019
@tomusdrw
Copy link
Contributor Author

tomusdrw commented Apr 4, 2019

I've removed AnySigner and used MultiSigner instead, that should give us strong typing.

@tomusdrw tomusdrw added A0-please_review Pull request needs code review. and removed A5-grumble labels Apr 4, 2019
@gavofyork
Copy link
Member

There's not much point using MultiSigner for AnySignature; the point of AnySigner was to keep compatibility with both straight Ed25519 and Sr25519 signers. The current code keeps that compatibility and doesn't have the additional type-punning.

@tomusdrw
Copy link
Contributor Author

tomusdrw commented Apr 4, 2019

@gavofyork so current code is cheating a bit cause it uses AnySignature, but the Signer type is sr25519::Public (even though the signature might be ed25519) - I guess it works since they are the same width and have the same basic encoding.

  1. If we use AnySigner(H256) I don't think we can escape unsafe/unchecked conversions.
  2. We could introduce an encoding-compatible type enum AnySigner { Sd2519(..), Ed25519(..) } but Decode for such type would be defaulting to only one as well same as how UncheckedFrom<H256> is now.

I can implement the second option, cause I till believe this PR is worth merging, since it simplifies a bunch of code where we create transactions and uses the MulitSignature in the test-runtime, which required adding a bunch of trait implementations, cause otherwise the type is not usable in any runtime at all.

@gavofyork
Copy link
Member

The extra 84 lines and semantic clutter (additional .into()s) it introduces doesn't seem to buy much. MultiSigner shouldn't be used with AnySignature, the point of it was only to type-pun between sr25519 and ed25519 and therefore it's fine to assume they're the same size.

I would be ok with a PR that purely made MultiSignature work correctly. I'm not especially bothered about having it as the default in the staging runtime though.

@Demi-Marie
Copy link
Contributor

@gavofyork is there any chance that this could be merged soon? It might be a substantial help for BABE, which uses sr25519 everywhere.

@tomusdrw tomusdrw added A3-in_progress Pull request is in progress. No review needed at this stage. and removed A0-please_review Pull request needs code review. labels Apr 19, 2019
@tomusdrw
Copy link
Contributor Author

I'll take another shot on this (from scratch)

@tomusdrw tomusdrw changed the title Allow both ed25519 and sr25519 signatures in node/runtime Fix MultiSigner, simplify tests Apr 19, 2019
@tomusdrw tomusdrw dismissed stale reviews from jacogr and gavofyork April 19, 2019 15:16

new take

@tomusdrw
Copy link
Contributor Author

Ok, current approach fixes MultiSigner, adds a convenience From<ed255519::Signature> for AnySignature and doesn't touch Signer of AnySignature at all.
Additionally creation of signed extrinsics in tests has been simplfiied to use into_signed_tx()

@tomusdrw
Copy link
Contributor Author

I'd really like to have a way to write some test and make sure that MultiSignature/MultiSigner is not broken in the future other than using MultiSignature in test-runtime which was rejected. So let me know if you have any ideas other than creating entire runtime as a test.

@tomusdrw
Copy link
Contributor Author

@demimarie-parity How exactly did you expect this PR to help you with Sr signatures? node/runtime and node-template should already support both types with no issue.

@tomusdrw tomusdrw added A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Apr 19, 2019
@gavofyork gavofyork merged commit 7a8c3d7 into master Apr 23, 2019
@gavofyork gavofyork deleted the td-fix-accounts branch April 23, 2019 16:18
@burdges
Copy link

burdges commented Jun 4, 2019

Just fyi, schnorrkel 0.2's Signature::from_bytes now gives an error if you pass it an Ed25519 signature: https://github.com/w3f/schnorrkel/blob/master/src/sign.rs#L113

This should make batch verification of AnySignature's possible.

MTDK1 pushed a commit to bdevux/substrate that referenced this pull request Jul 10, 2019
* Fix MultiSigner, use `into_signed_tx`

* Rebuild.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

A0-please_review Pull request needs code review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants