To: Eric Lombrozo <elombrozo@gmail.com>, bitcoin-dev@lists.linuxfoundation.org
References: <5717AF19.1030102@gmail.com>
	<CF7E1C6B-F52F-4658-AB24-553AC3493A86@gmail.com>
From: Jochen Hoenicke <hoenicke@gmail.com>
Message-ID: <5719EB7E.5000203@gmail.com>
Date: Fri, 22 Apr 2016 11:14:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CF7E1C6B-F52F-4658-AB24-553AC3493A86@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Proposal to update BIP-32
Precedence: list

Am 21.04.2016 um 17:28 schrieb Eric Lombrozo:
> In practice the probability of this case triggering is on the order of
> 2^-128 or something astronomically tiny. I've been using BIP32 for a few
> years already as have many others...I don't think we've ever had to
> handle this case. Justifiably, many app developers feel like the
> additional complexity of properly handling this case is not worth the
> effort.
> 
> Having said that, if the handling of this case is simple to implement
> and easy to isolate in the program flow, I am in favor of doing
> something along the lines of what you propose.
> 

Yes, the idea is to handle the problem in the library so that app
developers don't have to handle the case of missing addresses or just
ignore the problem.  It also doesn't add much complexity to the library
as the current implementations already test for invalid keys.  The
library would then just retry instead of returning an error (that most
app developers would then ignore).

  Jochen