Thomas Voegtlin [ARCHIVE] on Nostr: š
Original date posted:2014-03-27 š Original message:> > Related to this, here ...
š
Original date posted:2014-03-27
š Original message:>
> Related to this, here is another idea I would like to submit:
>
> Instead of using a "gap limit" (maximal number of consecutive unused
> addresses), I think we should get rid of the topology, and simply count
> the number of unused addresses since the beginning of the sequence.
> Indeed, the topology of the sequence of addresses is of no interest to
> the user. Users often misinterpret "gap limit" as the "number of unused
> addresses available", so I think we should just give them what they want
> :) This is easier to understand, and it makes things more predictable,
> because the wallet will always display the same number of unused
> addresses (except when it is waiting for confirmations).
>
>
> I'm not convinced that it is either simpler to implement nor simpler to
> understand. I considering every "account" as completely independent
> structure (except that it has been derived from master seed). Because of
> this, I don't see a reason why number of generated addresses in one
> account should affect available addresses of other account.
Sorry if I was not clear, but no, I was not proposing that... I propose
to count the number of unused addresses in each account, independently.
Here is an explanation with pictures:
Currently, Electrum does this:
x = used address
o = unused address
x x x o o x x x x o o o o o
| āāāāāāāāā 5 unused addresses at the end (gap limit =5)
existing gap, size 2
Case 1:
Suppose the user decides to use the 4th address starting from the end:
x x x o o x x x x x o o o o
After 3 confirmations, Electrum will create one extra address:
x x x o o x x x x x o o o o o
āāāāāāāāā 5 final address (one new)
Case 2:
The user, who understands nothing about topology, decides to use the
final address:
x x x o o x x x x o o o o x
After 3 confirmations, Electrum will create 5 new addresses:
x x x o o x x x x o o o o x o o o o o
| āāāāāāāāā 5 new addresses
new gap (size 4)
You see that this leads to a number of newly created addresses that
depends on the address picked by the user. This is the behaviour that I
want to fix. I think it is bad for two reasons: First, because it is
unpredictable (I had a user who set his gap limit to 100, and then was
systematically using the last address of the list, ending up with a lot
of wasted addresses). Second, because the worst case scenario (case 2)
creates large gaps, which are less robust to blockchain reorgs than in
case 1. A reorg in case 1, where the last tx is cancelled will create no
gap. A reorg in case 2 can result in a gap that is larger than the limit
(5), if another transaction uses the final addresses. (this is why
Electrum has to wait for a few confirmations before adding addresses)
So, what I propose is to always have a constant number of unused
addresses in each account, instead of something that depends on the
topology. (this number can be 10 or 20, I don't mind, but I guess Mike
might prefer 20...)
Published at
2023-06-07 15:16:24Event JSON
{
"id": "6727873676bcb05fb55cf4c5686da45b2b254597c095cc7bcf01ae62b8c741f1",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686150984,
"kind": 1,
"tags": [
[
"e",
"d9ddea79394f356d989e65ab112610cc90e9929cf3c160da3cfe266aeba22200",
"",
"root"
],
[
"e",
"f501723f69bbef8911dd67ee3974dc878cd2e437169ce963ed1d637d9883f6b3",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "š
Original date posted:2014-03-27\nš Original message:\u003e\n\u003e Related to this, here is another idea I would like to submit:\n\u003e\n\u003e Instead of using a \"gap limit\" (maximal number of consecutive unused\n\u003e addresses), I think we should get rid of the topology, and simply count\n\u003e the number of unused addresses since the beginning of the sequence.\n\u003e Indeed, the topology of the sequence of addresses is of no interest to\n\u003e the user. Users often misinterpret \"gap limit\" as the \"number of unused\n\u003e addresses available\", so I think we should just give them what they want\n\u003e :) This is easier to understand, and it makes things more predictable,\n\u003e because the wallet will always display the same number of unused\n\u003e addresses (except when it is waiting for confirmations).\n\u003e\n\u003e\n\u003e I'm not convinced that it is either simpler to implement nor simpler to\n\u003e understand. I considering every \"account\" as completely independent\n\u003e structure (except that it has been derived from master seed). Because of\n\u003e this, I don't see a reason why number of generated addresses in one\n\u003e account should affect available addresses of other account.\n\n\nSorry if I was not clear, but no, I was not proposing that... I propose \nto count the number of unused addresses in each account, independently.\n\nHere is an explanation with pictures:\n\nCurrently, Electrum does this:\n\nx = used address\no = unused address\n\nx x x o o x x x x o o o o o\n | āāāāāāāāā 5 unused addresses at the end (gap limit =5)\n existing gap, size 2\n\nCase 1:\nSuppose the user decides to use the 4th address starting from the end:\nx x x o o x x x x x o o o o\n\nAfter 3 confirmations, Electrum will create one extra address:\nx x x o o x x x x x o o o o o\n āāāāāāāāā 5 final address (one new)\n\nCase 2:\nThe user, who understands nothing about topology, decides to use the \nfinal address:\nx x x o o x x x x o o o o x\n\nAfter 3 confirmations, Electrum will create 5 new addresses:\nx x x o o x x x x o o o o x o o o o o\n | āāāāāāāāā 5 new addresses\n new gap (size 4)\n\n\nYou see that this leads to a number of newly created addresses that \ndepends on the address picked by the user. This is the behaviour that I \nwant to fix. I think it is bad for two reasons: First, because it is \nunpredictable (I had a user who set his gap limit to 100, and then was \nsystematically using the last address of the list, ending up with a lot \nof wasted addresses). Second, because the worst case scenario (case 2) \ncreates large gaps, which are less robust to blockchain reorgs than in \ncase 1. A reorg in case 1, where the last tx is cancelled will create no \ngap. A reorg in case 2 can result in a gap that is larger than the limit \n(5), if another transaction uses the final addresses. (this is why \nElectrum has to wait for a few confirmations before adding addresses)\n\n\nSo, what I propose is to always have a constant number of unused \naddresses in each account, instead of something that depends on the \ntopology. (this number can be 10 or 20, I don't mind, but I guess Mike \nmight prefer 20...)",
"sig": "d9b73d241469aa8362d71c5e783e4e78299144fe25f722217554188ab175033d889d113066f4d3fa83660aeeafe6a1b8eb628a0cd9be579b4a9f0ed47991c6e1"
}