Vote for aggregated public key #4116
Conversation
This commit addresses an issue where lease timings were not correctly adjusted for compatibility with epoch 2.4. The epoch 2.4 update introduced an extra block in the simnet start sequence, causing names to expire one block later than before. This fix ensures that lease timings align with the updated epoch requirements.
…ng-epoch-2.4 Argon: Pox 4 - Adjust Lease Timing for Epoch 2.4 Compatibility in BNS tests
| (define-read-only (current-reward-cycle) | ||
| u0) | ||
|
|
||
| (define-public (vote-for-aggreated-public-key (key (buff 33)) (reward-cycle uint) (round uint) (tapleaves (list 4001 (buff 33)))) |
There was a problem hiding this comment.
@setzeus What must be contained in a vote?
There was a problem hiding this comment.
Discussed during 12/5 Clarity WG
Possibly missing hardcoded internal key so we can guarantee that KeyPath isn't spendable.
contrib/core-contract-tests/contracts/pox/pox-4-aggregated-public-key.clar
Outdated
Show resolved
Hide resolved
friedger
force-pushed
the
feat/pox-4-disallow-stacking-during-prepare-phase
branch
from
ff2c499
to
6ed2a25
Compare
… feat/pox-4-aggregated-public-key-vote
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## feat/pox-4-disallow-stacking-during-prepare-phase #4116 +/- ##
=====================================================================================
+ Coverage 76.96% 82.78% +5.82%
=====================================================================================
Files 420 421 +1
Lines 296655 299227 +2572
=====================================================================================
+ Hits 228318 247727 +19409
+ Misses 68337 51500 -16837 ☔ View full report in Codecov by Sentry. |
| u0) | ||
|
|
||
| (define-public (vote-for-aggregated-public-key (key (buff 33)) (reward-cycle uint) (round uint) (tapleaves (list 4001 (buff 33)))) |
There was a problem hiding this comment.
Where is the tally-check / consensus (>70%) update happening?
In sBTC-mini, this function checked if the latest vote pushed an existing signing-key vote above the 70% threshold & updated state accordingly.
Is that logic handled elsewhere at the moment or is that logic missing?
There was a problem hiding this comment.
I don't know where to get the weight of a stacker from. Should I rebase on #4164 ?
| (define-map tally {reward-cycle: uint, round: uint, aggregate-public-key: (buff 33)} uint) | ||
|
|
||
| (define-constant err-not-allowed (err u10000)) |
There was a problem hiding this comment.
Can you relocate to batch w/ rest of errors & update the format to match existing? (capitalized, currently in the 30s index).
(define-constant ERR_INCORRECT_REWARD_CYCLE 32)
friedger
changed the base branch from
feat/pox-4-disallow-stacking-during-prepare-phase
to
next
|
Replaced by #4239 |
Description
This PR adds voting for the aggregated public key submitted by signers.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yamlandrpc-endpoints.mdfor v2 endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepobitcoin-tests.yml