Fedimint wallet module's finality_delay configuration variable means "how many blocks do we want to trail bitcoin blockchain". The federation can handle re-orgs up to this size. For example, if you set it to 0 then a federation can't handle reorgs at all. If set to 10 it can handle 10 block re-orgs.
When the guardian UI asks the user "how many block confirmations?", it uses the value supplied by the user for finality_delay. But the correct relationship is num_block_confirmations = finality_delay + 1. For example, if you set the finality_delay to 1 and 1 block is mined, you still can't peg-in because the federation is trailing bitcoin blockchain by 1 block so this most recently mined block still isn't confirmed from it's POV. But after another block is mined, then it will be visible to the federation.
What we should do is subtract 1 from what is entered into "how many block confirmations?"
Fedimint wallet module's
finality_delayconfiguration variable means "how many blocks do we want to trail bitcoin blockchain". The federation can handle re-orgs up to this size. For example, if you set it to0then a federation can't handle reorgs at all. If set to10it can handle 10 block re-orgs.When the guardian UI asks the user "how many block confirmations?", it uses the value supplied by the user for
finality_delay. But the correct relationship isnum_block_confirmations = finality_delay + 1. For example, if you set thefinality_delayto1and1block is mined, you still can't peg-in because the federation is trailing bitcoin blockchain by1block so this most recently mined block still isn't confirmed from it's POV. But after another block is mined, then it will be visible to the federation.What we should do is subtract
1from what is entered into "how many block confirmations?"