-
Notifications
You must be signed in to change notification settings - Fork 402
Description
When reviewing #1225 I noticed that the definition of stop_gap
we currently use is different from the one I had in mind. In any case, we should clearly define it and document it.
The PR fixes a bug and then adds a gap limit test. In the test, we generate 10 spks, and then we send sats on the 4th one (spks[3]
). What is the minimum gap limit we should use in order to see the transaction?
The test currently doesn't find any transaction with stop_gap = 2
, but does find a transaction with stop_gap = 3
. I think this is wrong.
If we define the stop gap as "the maximum number of consecutive unused addresses" (as electrum does https://electrum.readthedocs.io/en/latest/faq.html#what-is-the-gap-limit) (and also btcpayserver, it seems? https://docs.btcpayserver.org/FAQ/Wallet/#the-gap-limit-problem), I think stop_gap = 3
shouldn't find the tx, but stop_gap = 4
should:
- With
stop_gap = 3
, we searchspk0
,spk1
,spk2
, none of this contain a tx, and since 3 is the maximum number of consecutive unused addresses, we stop - With
stop_gap = 4
we searchspk0
,spk1
,spk2
,spk3
, we find the transaction, and then we continue searching until we stop atspk7
(included)
Also, with this definition, stop_gap
should be always nonzero I think? As, if you use stop_gap = 0
and check spk0
and it doesn't have any tx, you have checked one unused address, and violated the definition (0 should be "the maximum number of consecutive unused addresses" ).
Does this make sense?
Metadata
Metadata
Assignees
Labels
Type
Projects
Status