You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The signer data model ties Stacks (and bitcoin) transaction data to the bitcoin blockchain. So when there is a reorg of the bitcoin blockchain, we are supposed to know which Stacks transactions have been invalidated. The problem is we haven't yet explicitly linked Stacks transactions to the bitcoin blockchain.
This issue is about completing the final step of linking Stacks blocks to Bitcoin blocks, and thus the canoncial bitcoin blockchain.
1.1 Context & Purpose
Knowing which Stacks transactions are invalid is needed for figuring out a number of important things, such as:
Whether a withdrawal request has actually occurred.
Whether we still need to mint sBTC for an accepted deposit request.
Whether the last step of the withdrawal request has been fulfilled.
And probably other stuff too.
2. Technical Details:
The signer already listens for new Stacks blocks via the stacks-core event observer. These stacks-core new block webhooks include the chain tip of the bitcoin blockchain in the message, so storing that would get us a long way there for linking Stacks blocks to bitcoin blocks.
The remaining work is in ensuring that we can still link Stacks blocks with bitcoin blocks if a signer misses these webhooks for any reason. This can be done by using one of the newly added endpoints to stacks-core for fetching "sortition" info, which includes the associated bitcoin block for a consensus hash.
2.1 Acceptance Criteria:
For each Stacks block, store the associated bitcoin block as part of processing POST /new_block webhooks.
We add functionality for fetching the latest sortition information from stacks-core, which returns the bitcoin block that is tied to a consensus hash (and consensus hashes are included in Nakamoto block headers).
We fetch and store the associated bitcoin block when doing any backfilling of the stacks block chain.
Feature - Link Stacks blocks with Bitcoin blocks
1. Description
The signer data model ties Stacks (and bitcoin) transaction data to the bitcoin blockchain. So when there is a reorg of the bitcoin blockchain, we are supposed to know which Stacks transactions have been invalidated. The problem is we haven't yet explicitly linked Stacks transactions to the bitcoin blockchain.
This issue is about completing the final step of linking Stacks blocks to Bitcoin blocks, and thus the canoncial bitcoin blockchain.
1.1 Context & Purpose
Knowing which Stacks transactions are invalid is needed for figuring out a number of important things, such as:
And probably other stuff too.
2. Technical Details:
The signer already listens for new Stacks blocks via the stacks-core event observer. These stacks-core new block webhooks include the chain tip of the bitcoin blockchain in the message, so storing that would get us a long way there for linking Stacks blocks to bitcoin blocks.
The remaining work is in ensuring that we can still link Stacks blocks with bitcoin blocks if a signer misses these webhooks for any reason. This can be done by using one of the newly added endpoints to stacks-core for fetching "sortition" info, which includes the associated bitcoin block for a consensus hash.
2.1 Acceptance Criteria:
POST /new_block
webhooks.3. Related Issues and Pull Requests (optional):
The stacks-core event observer was added in #474.
Solving this ticket would help solve these issues:
get_withdrawal_requests
always returns an empty vector #524The text was updated successfully, but these errors were encountered: