Tracking issue for BLS implementation

[ogabrielides]

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

[PastaPastaPasta]

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

[ogabrielides]

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]

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

[ogabrielides]

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