Skip to content

Conversation

@drskalman
Copy link
Collaborator

✄ -----------------------------------------------------------------------------

Thank you for your Pull Request! 🙏 Please make sure it follows the contribution guidelines outlined in this
document
and fill out the
sections below. Once you're ready to submit your PR for review, please delete this section and leave only the text under
the "Description" heading.

Description

A concise description of what your PR is doing, and what potential issue it is solving. Use Github semantic
linking

to link the PR to an issue that must be closed once this is merged.

Integration

In depth notes about how this PR should be integrated by downstream projects. This part is
mandatory, and should be reviewed by reviewers, if the PR does NOT have the
R0-no-crate-publish-required label. In case of a R0-no-crate-publish-required, it can be
ignored.

Review Notes

In depth notes about the implementation details of your PR. This should be the main guide for reviewers to
understand your approach and effectively review it. If too long, use
<details>
.

Imagine that someone who is depending on the old code wants to integrate your new code and the only information that
they get is this section. It helps to include example usage and default value here, with a diff code-block to show
possibly integration.

Include your leftover TODOs, if any, here.

Checklist

  • My PR includes a detailed description as outlined in the "Description" and its two subsections above.
  • My PR follows the labeling requirements of this project (at minimum one label for T required)
    • External contributors: ask maintainers to put the right label on your PR.
  • I have made corresponding changes to the documentation (if applicable)
  • I have added tests that prove my fix is effective or that my feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank you for your contribution!

✄ -----------------------------------------------------------------------------

bkchr and others added 21 commits August 15, 2024 14:41
…ech#9949)

# Description

This is an amendment to
paritytech#1739 to use the newly
developed ProofOfPossessionGenerator/Verifier API instead of using
`sign` and `verify` in order to generate and validate key ownership
proofs. This is necessary because BLS keys need more complicated proofs
which are not possible to be produced using `sign`.

From the specification point of view, this PR only adds a context prefix
of "POP_" to the ownership statement, otherwise its behaviour is
identical to paritytech#1739.
…polkadot-sdk into skalman--set-keys-proof-with-rt-proof-of-possession-function
…paritytech#10002)

To solve the CI Build errors in the implementation of
`generate_session_key for the following runtimes:
-  cumulus/parachains/runtimes/testing/yet-another-parachain
- cumulus/polkadot-omni-node/lib/src/fake_runtime_api
-  substrate/frame/revive/dev-node/runtime
…aritytech#10033)

Also update `/cumulus/pallets/collator-selection/` to actually generate
proof when setting keys.
…polkadot-sdk into skalman--set-keys-proof-with-rt-proof-of-possession-function
…lman--set-keys-proof-with-rt-proof-of-possession-function
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants