Skip to content

fix(dashmate): form accepts invalid BLS key - #961

Merged
shumkov merged 2 commits into
v0.24-devfrom
fix/dashmate_bls_validate_pk_validation
Apr 24, 2023
Merged

fix(dashmate): form accepts invalid BLS key#961
shumkov merged 2 commits into
v0.24-devfrom
fix/dashmate_bls_validate_pk_validation

Conversation

@shuplenkov

@shuplenkov shuplenkov commented Apr 21, 2023

Copy link
Copy Markdown

Issue being fixed or feature implemented

Dashmate setup allow to input invalid BLS private key

What was done?

Fixed BLS private key validation function usage

How Has This Been Tested?

Manual

Breaking Changes

No

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

@shuplenkov shuplenkov added this to the v0.24.0 milestone Apr 21, 2023
@shuplenkov shuplenkov changed the title fix(dashamte): form accepts invalid BLS key fix(dashmate): form accepts invalid BLS key Apr 24, 2023

@shumkov shumkov left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

👍

@shumkov
shumkov merged commit 824c360 into v0.24-dev Apr 24, 2023
@shumkov
shumkov deleted the fix/dashmate_bls_validate_pk_validation branch April 24, 2023 15:36
HashEngineering pushed a commit to HashEngineering/platform that referenced this pull request Aug 20, 2026
Brings in dashpay/rust-dashcore#961, which stops a never-broadcast
transaction from crediting money that does not exist, plus the seven
commits ahead of the previous pin.

dashpay#961 adds `WalletEvent::TransactionsSwept`, the first subtractive event
on the wallet bus: it names transactions the wallet removed because a
later, final transaction provably beat them to their inputs. Three
consumers matched exhaustively on `WalletEvent` and now handle it.

- The balance handler routes it like any other balance-bearing variant.
  A sweep is the one event that can lower the balance, and its snapshot
  is post-removal like every other; dropping it would leave the
  corrected-away amount on screen until some later event happened to
  arrive.
- The DashPay payment hooks ignore it: it carries txids, not records.
  A sent payment whose transaction was swept stays `Pending` — the hooks
  only advance a payment forward, and inventing a failure transition is
  a change to the payment state machine, not to event routing.
- The core bridge projects it into a new `CoreChangeSet.swept_txids`,
  the only subtractive field on that type, and `is_empty_no_records`
  counts it — that filter decides whether the persister is called at
  all, so a sweep-only round has to survive it on the strength of the
  txids alone.

Nothing consumes `swept_txids` yet; the persistence seam follows.
llbartekll added a commit that referenced this pull request Aug 22, 2026
…arsing)

Pin fix/mnemonic-any-language-173ffac: the cherry-pick of
dashpay/rust-dashcore#980 onto 173ffac0, the rev v4.2-dev already pins.
This lands the BIP-39 fix without crossing the breaking key-wallet
sweep changes (rust-dashcore #961/#962/#966/#969) that #4406 adapts
platform to; once #4406 bumps onto rust-dashcore dev proper, the pin
rejoins dev and this branch can be deleted.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.

2 participants