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 <dev@jonasschnelli.ch>
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
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ogllOdkK2qUVOfkLckKci5dtWgUcpOCdj
Content-Type: multipart/mixed; boundary="BfjnrahLVT1b1ghN8ixIn0vAB591Flxwn"
From: Jonas Schnelli <dev@jonasschnelli.ch>
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 <address-birthday>+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.

</jonas>


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