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
Comments
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>
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 |
|
Right. I misread and thought he was talking about BLS operator key |
Tracking issue for BLS implementation
Subtasks:
fLegacyScheme
flag on below parts (flag will be set regarding on fork activation status):proRegTx
,proUpRegTx
,proUpServTx
,proUpRevTx
qcommit
+ implemented new serialization/unserializationqcontrib
,qcomplaint
,qjustify
: Update: Not neededqsigsesann
,qsigsinv
,qgetsigs
,qbsigs
,qsigrec
,qsigshare
Update: Not neededqdata
message (once the fork is active)dsq
anddstx
messages (once the fork is active). Update: Signing and serialisation of objects is done using active scheme. No object versioning support.bloom_tests
,evo_simplifiedmns_tests
andevo_trivialvalidation
with raw data using basic BLS scheme.The text was updated successfully, but these errors were encountered: