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.

Sign up for GitHub

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

Jump to bottom

BTC-timestamping public randomness #8

Closed
gitferry opened this issue Aug 1, 2024 · 1 comment · Fixed by #12, #23 or #51
Closed

BTC-timestamping public randomness #8

gitferry opened this issue Aug 1, 2024 · 1 comment · Fixed by #12, #23 or #51
Assignees
@gitferry
Labels
phase-2-readiness

Comments

@gitferry
Copy link
Contributor

gitferry commented Aug 1, 2024

In the Babylon Bitcoin-staking protocol, finality providers are required to commit a range of public randomness before sending finality signatures. However, if the honest majority assumption does not hold, the attacker might commit conflicting randomness on forks and escape from being slashed with performing equivocation attack. Therefore, BTC-timestamping is introduced to address the issue.

Required changes from Babylon:

  • Introduce epoch to each randomness commit to enforce that the committed randomness takes effect only after the relevant epoch is finalized
  • Do not assign voting power to finality providers that do not have finalized randomness for a particular block
@gitferry gitferry self-assigned this Aug 1, 2024
@KonradStaniec
Copy link
Collaborator

ref: https://github.com/babylonlabs-io/pm/issues/11

@gitferry gitferry mentioned this issue Aug 6, 2024
Merged
This was referenced Aug 19, 2024
Merged
Closed
gitferry added a commit that referenced this issue Aug 22, 2024
@gitferry
feat(ADR-024): Exclude voting power for fps who do not have timestamp…
439bb01 
…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24
gitferry added a commit that referenced this issue Aug 27, 2024
@gitferry
feat(ADR-024): Exclude voting power for fps who do not have timestamp…
921f163 
…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24
@gitferry gitferry mentioned this issue Aug 27, 2024
Closed
6 tasks
gitferry added a commit that referenced this issue Sep 2, 2024
@gitferry
feat(ADR-024): Exclude voting power for fps who do not have timestamp…
d1af08f 
…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24
gitferry added a commit that referenced this issue Sep 2, 2024
@gitferry
feat(ADR-024): Exclude voting power for fps who do not have timestamp…
aac5312 
…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24
gitferry added a commit that referenced this issue Sep 3, 2024
@gitferry
feat(ADR-024): Exclude voting power for fps who do not have timestamp…
0fd948d 
…ed pub rand (#23)

This closes the second part of #8. In particular, this PR:
* Implemented `HasTimestampedPubRand` in the finality keeper to check
whether a pub rand at a given height is BTC-timestamped
* Added expected finality keeper to btcstaking keeper so that
`HasTimestampedPubRand` can be called within the module
* When signing voting power to fps in `btcstaking`'s begin blocker, if
the fp does not have timestamped pub rand, voting power will not be
assigned

Note that this PR introduced circular dependency between the btc staking
module and finality module, which should be addressed by moving the
voting power table to the finality module, tracked by issue #24
@gitferry gitferry mentioned this issue Sep 3, 2024
Merged
6 tasks
gitferry added a commit that referenced this issue Sep 4, 2024
@gitferry
feat(ADR-024): Enable BTC-timestamping public randomness (#51)
00330e4 
This PR collects sub-PRs to close #8 and complete the whole feature
defined in
[ADR-024](https://github.com/babylonlabs-io/pm/blob/main/adr/adr-024-timestamping-public-randomness.md)
@gitferry gitferry mentioned this issue Sep 10, 2024
Closed
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gitferry gitferry

Labels
phase-2-readiness
Projects
None yet
Milestone
No milestone
2 participants
@gitferry @KonradStaniec