public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Thomas Voegtlin <thomasv1@gmx.de>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Date: Thu, 27 Mar 2014 16:04:31 +0100	[thread overview]
Message-ID: <53343DFF.2070406@gmx.de> (raw)
In-Reply-To: <CAJna-HitjJbL9TnfxTY=+TvfaeNvZM6aPWmNYmHUCwmw6V8PUg@mail.gmail.com>

>
>     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...)




  parent reply	other threads:[~2014-03-27 15:04 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 20:49 [Bitcoin-development] New BIP32 structure Mike Hearn
2014-03-26 23:37 ` Andreas Schildbach
2014-03-27  1:01   ` Alan Reiner
2014-03-27  6:15     ` Mike Belshe
2014-03-27 10:57   ` Thomas Voegtlin
2014-03-27 11:39     ` Mike Hearn
2014-03-27 13:30       ` Thomas Voegtlin
2014-03-27 13:38         ` Mike Hearn
2014-03-27  1:13 ` Allen Piscitello
2014-03-27  5:34 ` Troy Benjegerdes
2014-03-27  7:09 ` Tamas Blummer
2014-03-27  9:42   ` Mike Hearn
2014-03-27 11:35   ` Pavol Rusnak
2014-03-27 15:43   ` Jeff Garzik
2014-03-27 15:57     ` Allen Piscitello
2014-03-27 16:06       ` Pavol Rusnak
2014-03-27 16:13         ` Allen Piscitello
2014-03-27 16:07       ` Tamas Blummer
2014-03-27 16:14       ` Pieter Wuille
2014-03-27 16:21         ` Pavol Rusnak
2014-03-27 16:28           ` Pieter Wuille
2014-03-27 17:49             ` Allen Piscitello
2014-03-28 14:59             ` slush
2014-04-08 12:43               ` slush
2014-04-08 13:18                 ` Pieter Wuille
2014-04-08 13:40                   ` slush
2014-04-08 13:43                     ` slush
2014-04-08 13:53                       ` Pieter Wuille
2014-04-08 13:59                         ` Thomas Voegtlin
2014-04-08 14:00                         ` Tamas Blummer
2014-04-08 14:35                         ` Pavol Rusnak
2014-04-08 15:41                         ` slush
2014-04-23 17:42                           ` Pieter Wuille
2014-04-23 18:01                             ` slush
2014-04-23 18:18                               ` slush
2014-04-23 18:39                                 ` Tier Nolan
2014-04-23 18:46                                   ` Pavol Rusnak
2014-04-23 19:00                                     ` Tier Nolan
2014-04-23 19:06                                       ` slush
2014-04-23 19:36                                         ` Tamas Blummer
2014-04-23 19:46                                           ` slush
2014-04-23 19:07                                       ` Tamas Blummer
2014-04-23 19:29                                       ` Pavol Rusnak
2014-04-23 19:44                                         ` Luke-Jr
2014-04-23 19:49                                           ` Pavol Rusnak
2014-04-23 19:55                                             ` Luke-Jr
2014-04-23 19:57                                               ` slush
2014-04-23 20:01                                                 ` Luke-Jr
2014-04-23 20:04                                                   ` Pavol Rusnak
2014-04-23 20:09                                                     ` Luke-Jr
2014-04-23 20:16                                                       ` Pavol Rusnak
2014-04-23 20:32                                                         ` Luke-Jr
2014-04-23 20:35                                                           ` Pavol Rusnak
2014-04-23 20:41                                                             ` Luke-Jr
2014-04-23 20:43                                                               ` Pavol Rusnak
2014-04-23 20:54                                                                 ` Pieter Wuille
2014-04-23 21:06                                                                   ` Pavol Rusnak
2014-04-23 21:18                                                                     ` Luke-Jr
2014-04-23 21:22                                                                       ` Gregory Maxwell
2014-04-23 21:33                                                                         ` Pavol Rusnak
2014-04-23 21:42                                                                           ` Pieter Wuille
2014-04-23 21:44                                                                             ` Pavol Rusnak
2014-04-23 21:48                                                                             ` Gregory Maxwell
2014-04-23 21:53                                                                           ` Luke-Jr
2014-04-23 21:24                                                                       ` Pavol Rusnak
2014-04-23 21:07                                                                   ` slush
2014-04-23 20:59                                                                 ` Luke-Jr
2014-04-23 20:17                                                       ` Tamas Blummer
2014-04-23 20:12                                                     ` Pieter Wuille
2014-04-23 20:08                                                   ` Pieter Wuille
2014-04-23 20:01                                               ` Tamas Blummer
2014-04-23 20:02                                                 ` Luke-Jr
2014-04-23 20:04                                                   ` Tamas Blummer
2014-04-24  6:54                                           ` Thomas Voegtlin
2014-04-24  7:10                                             ` Pieter Wuille
2014-04-24  7:21                                               ` Gregory Maxwell
2014-04-24  8:15                                                 ` Thomas Voegtlin
2014-04-24  7:42                                               ` Thomas Voegtlin
2014-04-24  8:09                                               ` Mike Hearn
2014-04-23 18:48                                   ` Tamas Blummer
2014-04-08 14:49                 ` Andreas Schildbach
2014-04-08 15:46                   ` slush
2014-04-08 15:58                     ` Andreas Schildbach
2014-04-08 16:24                       ` slush
2014-03-27 11:20 ` Thomas Voegtlin
     [not found]   ` <CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
2014-03-27 12:06     ` Thomas Voegtlin
2014-03-27 12:28       ` Mike Hearn
2014-03-27 12:49         ` Mike Hearn
2014-03-27 13:12           ` Thomas Kerin
2014-03-27 13:19             ` Mike Hearn
2014-03-27 13:49           ` Thomas Voegtlin
2014-03-27 13:58             ` Jim
2014-03-27 14:20               ` Mike Hearn
2014-03-27 15:17             ` Troy Benjegerdes
2014-03-27 13:07         ` Matias Alejo Garcia
2014-03-27 13:44       ` Pavol Rusnak
2014-03-27 13:53         ` Thomas Voegtlin
2014-03-27 14:03           ` Pavol Rusnak
     [not found]       ` <CAJna-HitjJbL9TnfxTY=+TvfaeNvZM6aPWmNYmHUCwmw6V8PUg@mail.gmail.com>
2014-03-27 15:04         ` Thomas Voegtlin [this message]
2014-03-27 11:36 ` Pavol Rusnak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53343DFF.2070406@gmx.de \
    --to=thomasv1@gmx.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox