Open djordon opened 2 months ago
I'm planning to do this with a few atomic changes:
u32
time
field to the BitcoinBlock
representation in our database that we'll populate here with block.header.time
from the Bitcoin library.here
based on the field added in the config earlier.The too close for comfort will be determined based on the least forgiving interpretation of the closeness of the chain tip. I'm not clear on the best way to assess the median of the last 11 blocks, or rather how best to get the last 11 blocks from the SQL table, but that's how I intend to do it.
@djordon @matteojug any initial thoughts?
1. Add a field to the signer config here that specifies how far from the reclaim script's lock time the deposit needs to be for the signer to accept it.
Yeah a config option is okay but I think using some hard-coded constant is a little better. This isn't something that we want the signer operators to change, at least not yet.
This will be in seconds and we'll interpret blocks to each be 512 seconds
I was thinking that we'd need two values, one for the number of bitcoin blocks and another for actual time.
2. Add a
u32
time
field to theBitcoinBlock
representation in our database that we'll populate here withblock.header.time
from the Bitcoin library.
Yeah that makes sense.
3. When deciding whether to sign for the transaction we'll reject if the reclaim time is too close for comfort
here
based on the field added in the config earlier.
Oh, well I don't think that we want to handle this check there. Instead we want to handle it when fetching deposit requests to sweep in, which happens here. As time passes a deposit request will go from being acceptable to unacceptable, so we need to make sure that we catch that.
The too close for comfort will be determined based on the least forgiving interpretation of the closeness of the chain tip.
Yeah that makes the most sense to me.
I'm not clear on the best way to assess the median of the last 11 blocks, or rather how best to get the last 11 blocks from the SQL table, but that's how I intend to do it.
For finding the 11 blocks, you want to do something like the query here, which uses a recursive query to fetch some number of blocks from some starting block hash. That's how we typically identify some part of a blockchain in our queries.
The good folks over at Asymmetric have pointed out something that I had misunderstood (https://github.com/stacks-network/sbtc/issues/516#issuecomment-2438070688). Basically, we the sbtc
library should note how a lock time will be interpreted when it does validation. How to do so is specified in BIP-68. This doesn't change the work here that much, just thought that I'd point this out.
Feature - Handle lock times in deposit requests
1. Description
The signers need to properly handle the lock times encoded in their deposit scripts in order to properly filter out requests that can be reclaimed "soon".
1.1 Context & Purpose
Right now the signers fetch all deposit requests that have been confirmed for a certain number bitcoin blocks from the chain tip. This is has two problems:
2. Technical Details:
We need to track each blocks
time
and filter deposit requests based both their relative height and the actual time by tracking by the MTP.2.1 Acceptance Criteria:
3. Related Issues and Pull Requests (optional):