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.

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

Secondary mechanism to trigger watches for transactions from past blocks #3002

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Feb 6, 2025

When a new block is found, we want to check its confirmed transactions to potentially trigger watches. This is especially important when a channel is spent and we haven't seen the spending transaction in our mempool before receiving it in a block.

This is already handled through the ZMQ rawtx topic, where bitcoind sends us every transaction it receives (either in the mempool or in a block). But when using remote bitcoind instances, ZMQ seems to sometimes be unreliable and silently drop some events (mostly when the connection is unstable with the bitcoind instance). That's why we add another mechanism for extra safety, where whenever a new block is found, we fetch the last N blocks and re-process their transactions. We keep a cache of the processed blocks to ensure that we don't needlessly re-process them multiple times.

@t-bast t-bast requested review from sstone and pm47 February 6, 2025 14:58
When a new block is found, we want to check its confirmed transactions
to potentially trigger watches. This is especially important when a
channel is spent and we haven't seen the spending transaction in our
mempool before receiving it in a block. This is already supposed to be
handled through the ZMQ `rawtx` topic, where bitcoind should send us
every transaction it receives (either in the mempool or in a block).
But when using remote `bitcoind` instances, ZMQ seems to sometimes be
unreliable and silently drop some events. That's why we add another
mechanism for extra safety, where whenever a new block is found, we
fetch the last `N` blocks and re-process their transactions. We keep
a cache of the processed blocks to ensure that we don't needlessly
re-process them multiple times.
@t-bast t-bast force-pushed the zmq-check-latest-blocks branch from d7d00fb to d32a21a Compare February 6, 2025 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant