Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for BLS implementation #5001

Closed
14 of 15 tasks
ogabrielides opened this issue Sep 8, 2022 · 4 comments
Closed
14 of 15 tasks

Tracking issue for BLS implementation #5001

ogabrielides opened this issue Sep 8, 2022 · 4 comments
Assignees
Milestone

Comments

@ogabrielides
Copy link
Collaborator

ogabrielides commented Sep 8, 2022

Tracking issue for BLS implementation

Subtasks:

  • BIP9 fork implementation + helper functions
  • Insertion and propagation of fLegacyScheme flag on below parts (flag will be set regarding on fork activation status):
    • BLS classes
    • DKG classes: Perform all processing using the active BLS scheme
    • LLMQ signing classes: sign and verify based on the active BLS scheme
  • New version of below txs + implemented new serialization/unserialization
    • proRegTx, proUpRegTx, proUpServTx, proUpRevTx
  • New version of qcommit + implemented new serialization/unserialization
  • Investigation if new serialization/unserialization is needed on DKG llmq messages (once the fork is active):
    • qcontrib, qcomplaint, qjustify: Update: Not needed
  • Investigation if new serialization/unserialization is needed on llmq signatures messages (once the fork is active):
    • qsigsesann, qsigsinv, qgetsigs, qbsigs, qsigrec, qsigshare Update: Not needed
  • Investigation if new serialization/unserialization is needed on qdata message (once the fork is active)
  • Investigation if new serialization/unserialization is needed on dsq and dstx messages (once the fork is active). Update: Signing and serialisation of objects is done using active scheme. No object versioning support.
  • Update unit test with expected values when using the basic BLS scheme.
  • Update: unit tests bloom_tests, evo_simplifiedmns_tests and evo_trivialvalidation with raw data using basic BLS scheme.
  • Backport Chia-Network/bls-signatures into dashpay/bls-signatures Update: PR already opened by @UdjinM6 (Merge chia tag 1.0.15 into develop bls-signatures#44)
  • Update bls-signatures to latest version in makefile of core #5025
@ogabrielides ogabrielides self-assigned this Sep 8, 2022
@ogabrielides ogabrielides added this to the 19 milestone Sep 8, 2022
PastaPastaPasta added a commit that referenced this issue Dec 30, 2022
Tracking issue is:
[(#5001)

Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: pasta <pasta@dashboost.org>
@PastaPastaPasta
Copy link
Member

With this merged, should the params passed to masternodeblsprivkey be legacy or non-legacy keys?

@ogabrielides
Copy link
Collaborator Author

With this merged, should the params passed to masternodeblsprivkey be legacy or non-legacy keys?

Once the v19 HF is active, then they need to be non-legacy. legacy schemes are also supported via the protx legacy family RPCs. Please check release notes in https://github.com/dashpay/dips/pull/122/files

@UdjinM6
Copy link

UdjinM6 commented Jan 4, 2023

masternodeblsprivkey is a privkey and privkey serialization is not affected by this migration afaik

@ogabrielides
Copy link
Collaborator Author

masternodeblsprivkey is a privkey and privkey serialization is not affected by this migration afaik

Right. I misread and thought he was talking about BLS operator key

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

No branches or pull requests

3 participants