gap limit for change addresses is too small and cannot be changed

[Fonta1n3]

It seems impossible to increase the range of change addresses (change) that electrum watches for, therefore my balance is completely incorrect. The information is not easy to find in the docs or google, the existing poor answers I have found result in a crash in the electrum console.

[SomberNight]

What version of Electrum are you using? Starting with version 4.0.1, the gap limit for change is 10; was 6 previously.

Changing the gap limit for receiving (external) addresses is possible via CLI/RPC commands (see changegaplimit) as there are good usecases for it, but it is not exposed in the GUI as it caused too many misunderstanding for newbies in the past. Changing the gap limit for change (internal) addresses is only possible via hacking the source code; or using the Qt console (as it is a full featured python interpreter); it is even less exposed as there are even fewer good usecases for modifying it.

Anyway, if you know what you are doing, you can change the gap limit for receiving addresses and the gap limit for change addresses like this, in the Qt console tab:

wallet.change_gap_limit(100)
wallet.gap_limit_for_change = 100
wallet.synchronize()

[Fonta1n3]

What version of Electrum are you using?

Starting with version 4.0.1, the gap limit for change is 10; was 6 previously.

Changing the gap limit for receiving (external) addresses is possible via CLI/RPC commands (see changegaplimit) as there are good usecases for it, but it is not exposed in the GUI as it caused too many misunderstanding for newbies in the past.

Changing the gap limit for change (internal) addresses is only possible via hacking the source code; or using the Qt console (as it is a full featured python interpreter); it is even less exposed as there are even fewer good usecases for modifying it.

Anyway, if you know what you are doing, you can change the gap limit for receiving addresses and the gap limit for change addresses like this, in the Qt console tab:

wallet.change_gap_limit(100)

wallet.gap_limit_for_change = 100

wallet.synchronize()

Even fewer good use cases? Huh... not being able to see my balance or spend my btc is a fairly good use case.

[SomberNight]

Sure but this situation only arose because you did something special using another application, so you are now trying to fix a previous mess. Instead, it's better to avoid creating the mess in the first place.

Re there not being many good usecases, I meant for changing it in the first place.

May I ask why you have a large gap in your change addresses, and how big it is?

[Fonta1n3]

All I did was create a wallet and use it. And recreated it in Electrum, this is where multi-sig shines, the ability to use multiple applications. I did not create a mess, and there is no large gap limit in my change addresses.

In Fully Noded the address index gets incremented by one for every invoice that is created and for every utxo that is seen, the index is similar for change and receive keys to keep the code simple. Fully Noded by default watches for 2500 receive keys and 2500 change keys, it does not differentiate gap limits between the two types of keys.

"The mess" you refer to was probably caused by the fact I receive more btc then I spend, hence the lag between gap limits between my change keys and receive keys.

I simply think to make the UX far better for multi-sig users who want to use Electrum in their existing multi-sig quorum (e.g. import their multi-sig wallets to Electrum) instead of forcing the user to manually type code into the console which frankly is scary, that they should just have a button which automatically watches the next X addresses. Or even better detects if the addresses have a history near the gap limit and automatically increase it if it does.

[SomberNight]

Or even better detects if the addresses have a history near the gap limit and automatically increase it if it does.

That's exactly how the gap limit works. If addresses near the end have a history, new addresses are generated, i.e. the gap is rolled forward. What you are suggesting, I suspect, is having a gap limit on top of the gap limit.

You still haven't explained however why you have so many unused change addresses in a row. Maybe it's a bug in Fully Noded. It makes little sense to skip so many change addresses. I understand the gap limit is 2500 or whatever but does the code just take an address at random out of those?! :)

[Fonta1n3]

Or even better detects if the addresses have a history near the gap limit and automatically increase it if it does.

That's exactly how the gap limit works. If addresses near the end have a history, new addresses are generated, i.e. the gap is rolled forward.

What you are suggesting, I suspect, is having a gap limit on top of the gap limit.

You still haven't explained however why you have so many unused change addresses in a row. Maybe it's a bug in Fully Noded. It makes little sense to skip so many change addresses. I understand the gap limit is 2500 or whatever but does the code just take an address at random out of those?! :)

it increments by every invoice created and the max utxo address index seen, by one, for both the change and receive index. 2500 is not a gap limit in FN its just the default range the node watches, it generates them in order starting at 0.

I had barely gone over 20... Seems software that indexes addresses should be able to handle that and users shouldn’t have to code is my only point here :)

Maybe the confusion is I don’t use electrum to generate invoices, I think that is why it was “stuck” at the original gap limit, issue of course is you can not generate change invoices.

[SomberNight]

I understand that Fully Noded generates a lot of change addresses, that is fine. I am missing how those get used however. Did you manually give out a change address to receive coins on to someone?

Electrum, for example, when constructing a tx, typically just picks the first unused change address to send change to. That way there will hardly ever be any gaps.

[Fonta1n3]

I understand that Fully Noded generates a lot of change addresses, that is fine. I am missing how those get used however. Did you manually give out a change address to receive coins on to someone?

Electrum, for example, when constructing a tx, typically just picks the first unused change address to send change to. That way there will hardly ever be any gaps.

It increments the index by one, for every invoice created, the highest utxo seen, and every change address used. It keeps the same address index for both key types to reduce confusion for users.

[SomberNight]

But how is the change address to be used to send coins to, when constructing a new transaction, chosen?

[SomberNight]

It increments the index by one, for every invoice created, the highest utxo seen, and every change address used. It keeps the same address index for both key types to reduce confusion for users.

Oh, maybe I understand. Is it that you just have a single global counter, which determines which "receive address" to give out for the next invoice, and you reuse this counter for the next change address when you construct a tx? You will have many problems as no other wallet works like that. Your users will always have gap limit problems that way.

[Fonta1n3]

addressIndex += 1

It will automatically set the index to +1 whatever the highest seen utxo address index is.

[Fonta1n3]

It increments the index by one, for every invoice created, the highest utxo seen, and every change address used. It keeps the same address index for both key types to reduce confusion for users.

Oh, maybe I understand. Is it that you just have a single global counter, which determines which "receive address" to give out for the next invoice, and you reuse this counter for the next change address when you construct a tx? You will have many problems as no other wallet works like that. Your users will always have gap limit problems that way.

Hmm haven't had a single user have an issue. I give users the ability to manually increase the gap limit, giving them two separate gap limits to increase would be kind of silly.

[mariaa144]

Loading in an xpub from a JoinMarket maker bot can also have this issue. Changing the gap_limit_for_change in source temporarily worked for me. It is nice to know the console will work also.

[ReichardKonige]

Similar issue. In may case Blockstream Jade used with green wallet and electrum. The commands to increase change gap limit corrected it all.