rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2014-03-27 📝 Original message:By the way, I just noticed that greenaddress.it is creating seeds that have 24 words instead of 12. Does anyone know what's up with that? They claim to be using BIP32 wallets so I wanted to see if they were using the default structure and if so, whether bitcoinj was compatible with it (before I switch to the one discussed here). But it seems we fall at the first hurdle ... On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1 at gmx.de> wrote: > > > Le 27/03/2014 12:30, Marek Palatinus a écrit : > > Ah, I forget to two things, which should be into the BIP as well: > > > > a) Gap factor for addresses; as Thomas mentioned, although some software > > can watch almost unlimited amount of unused addresses, this is serious > > concern for lightweight or server-based wallets like Electrum or > > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my > > experience so far) quite sane for most of users. > > > Yes, I was planning to increase the number of available unused addresses > to 10 or 20 in the bip32 version of Electrum. > > 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). > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/4dc427dd/attachment.html>