<oembed><type>rich</type><version>1.0</version><author_name>npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47</author_name><author_url>https://nostr.ae/npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-03-27&#xA;📝 Original message:Le 27/03/2014 12:30, Marek Palatinus a écrit :&#xA;&gt; Ah, I forget to two things, which should be into the BIP as well:&#xA;&gt;&#xA;&gt; a) Gap factor for addresses; as Thomas mentioned, although some software&#xA;&gt; can watch almost unlimited amount of unused addresses, this is serious&#xA;&gt; concern for lightweight or server-based wallets like Electrum or&#xA;&gt; myTREZOR. myTREZOR currently uses gap factor 10, which is (from my&#xA;&gt; experience so far) quite sane for most of users.&#xA;&#xA;&#xA;Yes, I was planning to increase the number of available unused addresses &#xA;to 10 or 20 in the bip32 version of Electrum.&#xA;&#xA;Related to this, here is another idea I would like to submit:&#xA;&#xA;Instead of using a &#34;gap limit&#34; (maximal number of consecutive unused &#xA;addresses), I think we should get rid of the topology, and simply count &#xA;the number of unused addresses since the beginning of the sequence. &#xA;Indeed, the topology of the sequence of addresses is of no interest to &#xA;the user. Users often misinterpret &#34;gap limit&#34; as the &#34;number of unused &#xA;addresses available&#34;, so I think we should just give them what they want &#xA;:) This is easier to understand, and it makes things more predictable, &#xA;because the wallet will always display the same number of unused &#xA;addresses (except when it is waiting for confirmations).</html></oembed>