Skip to content

Instantly share code, notes, and snippets.

@vladimirfomene

vladimirfomene/anchor_explanation.md

Last active October 31, 2023 09:12
Show Gist options
  • Save vladimirfomene/1ea3b8e79f8ec59a0c6211ad8dac1784 to your computer and use it in GitHub Desktop.
Save vladimirfomene/1ea3b8e79f8ec59a0c6211ad8dac1784 to your computer and use it in GitHub Desktop.
Download ZIP
Why BDK anchors are important?
Raw
anchor_explanation.md

Anchor is:

If this block exists in the best chain (or a chain of given chain_tip), then we know that this transaction is confirmed in the best chain.

Blocks in bdk_chain are identified by BlockId which is block_height+block_hash. So we anchor transactions to BlockIds and we just need to know whether this BlockId is in the best chain.

Sometimes we know the confirmation height of a transaction, but we don't know the confirmation block hash (Electrum). So we have a looser definition for Anchor, so that the anchor BlockId can be of a different height to the confirmation height of the transaction.

For Electrum (as @Steve Myers mentioned), we need to get the tip before getting tx data, and ensure the tip still exists in the best chain after grabbing all the tx data. We use the tip as the anchor BlockId in this scenario.

For Esplora, we can know the confirmation block hash, so the confirmation block is the same as the anchor block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment