From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 527E28DC for ; Thu, 25 Aug 2016 08:08:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B097B133 for ; Thu, 25 Aug 2016 08:08:31 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 82EFC2E6063F; Thu, 25 Aug 2016 10:08:30 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro-2.local (84-73-208-41.dclient.hispeed.ch [84.73.208.41]) by server3 (Postfix) with ESMTPSA id CCF582D0002E for ; Thu, 25 Aug 2016 10:08:29 +0200 (CEST) To: bitcoin-dev@lists.linuxfoundation.org References: <201608232012.12588.luke@dashjr.org> <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org> <57BDACB2.9040307@jonasschnelli.ch> <278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com> <57BEA0B0.3090308@jonasschnelli.ch> <756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org> From: Jonas Schnelli Message-ID: <57BEA775.4020701@jonasschnelli.ch> Date: Thu, 25 Aug 2016 10:08:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ogllOdkK2qUVOfkLckKci5dtWgUcpOCdj" Subject: Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 08:08:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ogllOdkK2qUVOfkLckKci5dtWgUcpOCdj Content-Type: multipart/mixed; boundary="BfjnrahLVT1b1ghN8ixIn0vAB591Flxwn" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <57BEA775.4020701@jonasschnelli.ch> Subject: Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 References: <201608232012.12588.luke@dashjr.org> <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org> <57BDACB2.9040307@jonasschnelli.ch> <278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com> <57BEA0B0.3090308@jonasschnelli.ch> <756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org> In-Reply-To: <756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org> --BfjnrahLVT1b1ghN8ixIn0vAB591Flxwn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > Le 25/08/2016 =E0 09:39, Jonas Schnelli via bitcoin-dev a =E9crit : >> (I think this case if not completely unrealistic): >> >> What would happen, if a user gave out 21 addresses, then address0 had >> receive funds in +180 days after generation where address21 had receiv= e >> funds immediately (all other addresses never received a tx). >> >> In a scan, address0 would be detected at +180 days >> which would trigger the resize+20 of the address-lookup-window, but, w= e >> would require to go back 180day in order to detect received transactio= n >> of address21 (new lookup-window) in that case. >> >> Or do I misunderstand something? >> >> >=20 > That case is not unrealistic; a merchant might generate addresses that > are beyond their gap limit, and orders get filled at a later date. >=20 > In that case you will not get the same result when restoring your walle= t > in a block-scanning wallet and in Electrum. >=20 > The lack of consideration for these cases is another issue with BIP44. The development paradigm of "maybe detect funds" is not something we should *not* encourage for Bitcoin IMO. Users might sweep their existing bip32/bip44 seed (which could miss funds according to the problem above) to a new wallet and discard the previous seed. But I agree with Luke-Jr. This Thread is not about specification, it's about what's used and what should be marked as standard. New BIPs could cover "overhauled" proposals for BIP39 and BIP44. Otherwise =96 very likely =96 nothing will happen. --BfjnrahLVT1b1ghN8ixIn0vAB591Flxwn-- --ogllOdkK2qUVOfkLckKci5dtWgUcpOCdj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXvqd1AAoJECnUvLZBb1Psx2wQAK2P8Jn4/9svLdYdWHdxRGlE +8c54Pw9VcG3gaT1cWQNKZdhWUeSvaaPwKKAR78Qzg6s8YIWr+RS+72bSN0Z9zPE 0ZFkINkWlI5Y42T4sYqK/LkSl06H1G6DtmhfbZnV/FyUtbI4T+d0OngTp57Fkmfw 9zyww+h3gfeXNe7OBhZJwda9TuAcfdlMHztKzoMzqrwI/iFkXjIippKOxV6t+vq7 bpOndNycT9qRQcMz4T6sWkCXNlYVlRYadPlqDJs+tvxY/HO3wvww+lTeDeAhCYEv 4kUKgk1Wc2fQM/4AROdKw0Qp1f/s7/TmFvYojCXxpednKxv12S/BlIUOzkXPdWBW eHbAR02bBcvrhRhqCUp5zejeUf5jJnoIYJakmLlWs46h4CXIRT+Nn8XNUpo7g96M irZjsuJi2Ut/EDDyiqlJH8Zh0x0bMydekU4YU9KAH9ofFl9rgZ055+floUvVG0Fy byfExoetNMsjNhaYaBQrDZh6HqPLq8W+xAn/5cc6RcwptZXsVIA/tZiBHop00S7k FnzdtKczwzeWy/um92gGvMRwZSuB00s/Wg0iJvpjuFmKQxZ6QDfLn+oQAQV5Zl4f PtPKklkJP+bCrVgoXcaUMoR3fmGUHhCq61v9KiJ8VPNaY7sHL3gNjRPQXUJVrtH1 lNHkB5bNX4ZoMN/Bx82T =z1R9 -----END PGP SIGNATURE----- --ogllOdkK2qUVOfkLckKci5dtWgUcpOCdj--