search

stacks-network / sbtc

Repo containing sbtc
GNU General Public License v3.0
285 stars 9 forks source link

[Feature]: Revisit `fetch_unknown_ancestors` in stacks `api.rs` #637

Open cylewitruk opened 1 month ago

cylewitruk commented 1 month ago

Feature - Revisit fetch_unknown_ancestors in stacks api.rs

1. Description

The assumptions in this method are wrong, it uses the Stacks block height but the Nakamoto start height is defined as a bitcoin block height.

1.1 Context & Purpose

More context in issue https://github.com/stacks-network/sbtc/pull/633#discussion_r1793194207 from #643.

2. Technical Details:

We should find a way to get the burnchain block height for the stacks block, or we could potentially keep looping until we get a 404 (not found) from the Stacks RPC endpoint, which is what it returns for /v3 endpoints when requesting data for non-nakamoto blocks.

2.1 Acceptance Criteria:

3. Related Issues and Pull Requests (optional):

djordon commented 1 month ago

The assumptions in this method are wrong, it uses the Stacks block height but the Nakamoto start height is defined as a bitcoin block height.

Sorry, forgot to comment here and in the PR where we changed fetch_unknown_ancestors. I think what we should do is tie Stacks blocks with their anchored bitcoin block height and provide a final backstop that way. We set a bitcoin start height for which all signers need to have block headers for and use that to define a stopping point for fetch_unknown_ancestors when we are just starting out. So once we solve https://github.com/stacks-network/sbtc/issues/559, we can revisit that function and use bitcoin blocks as a backstop.

djordon commented 1 month ago

I opened https://github.com/stacks-network/sbtc/issues/685 which proposes us backfilling stacks blocks up until their bitcoin anchor block height equals some bitcoin start height. If we adopt the proposal in https://github.com/stacks-network/sbtc/issues/685, then some of the work on the stacks side would likely relate to this issue.