MIME-Version: 1.0
Sender: marek@palatinus.cz
In-Reply-To: <li12a7$i8o$1@ger.gmane.org>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
	<CAJHLa0PPAsBLgsy0vgPpUp=UzeR_fWUEzFb5+xtmODEk4MGPVQ@mail.gmail.com>
	<CAJfRnm7V6fgcj=TMfa2ZTYWOKtE5aoUT1xnVtKUSyriB=6cagQ@mail.gmail.com>
	<CAPg+sBjwf1TcK1CGKVKFzYbV-78j8t-pav7=PEgG7Yqi6-yE7A@mail.gmail.com>
	<53344FF8.7030204@gk2.sk>
	<CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com>
	<CAJna-Hi0JnrF2_rUx0rGkdnsuCoaD01e3Gobpn+QqbL=D1Uivg@mail.gmail.com>
	<CAJna-HirtsGLfAhfUf9dAYEGWo6g=o=eAU187c2pdW8vDFGkPw@mail.gmail.com>
	<li12a7$i8o$1@ger.gmane.org>
From: slush <slush@centrum.cz>
Date: Tue, 8 Apr 2014 17:46:04 +0200
Message-ID: <CAJna-HgVs1ahhNKswaKPudwc1AvrBGgdfbZwNCvUPHFzHbh1WA@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a1133da667fef5704f689e38e
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

--001a1133da667fef5704f689e38e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach <andreas@schildbach.de>wrote:

> While there is an agreement that a standard would be useful for sharing
> wallets, we certainly didn't agree on every aspect of a standard. At
> least not on this thread, and also not at the Berlin meeting.
>
>
We're going to write down BIP describing such structure. If any wallet want
to be BIP XX compatible, then it has chance to. Of course if any wallet
want to use another format, then it cannot call itself BIP XX compatible,
thus nobody will expect that such software will see/recover all keys
generated by BIP XX wallet.


> I understand each client will implement things a little bit different,
> for example the current plan is bitcoinj will hold all keys in memory
> and start reusing keys on low resources. Electrum uses a chain for their
> private purpose. Etc.
>
>
It still doesn't mean that bitcoinj or Electrum cannot share the bare
minimum of BIP XX. Of course if somebody will use Electrum for 2to3
transactions and then move wallet to client which does not offer such
feature, it won't work. But I don't see that as a problem.


> If we cannot 100% agree on a standard and also agree it will not be
> extended in future, I think we should not even try. It's dangerous for
> the money of users.


If some developers agree on some specific BIP, then it should be cross
compatible.  Of course if somebody implements BIP XX in different way, then
it isn't BIP XX compatible.


>
>
I propose we keep our chains deliberately separate and only try
> standardizing after each of us has a feel for the specific requirements.
>

Of course, if somebody don't want to generate compatible bip32 paths, no
problem. It will be the same situation as now.

Marek

--001a1133da667fef5704f689e38e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach <span dir=3D"ltr=
">&lt;<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@sc=
hildbach.de</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">While there is an agreement =
that a standard would be useful for sharing<br></div>
wallets, we certainly didn&#39;t agree on every aspect of a standard. At<br=
>
least not on this thread, and also not at the Berlin meeting.<br>
<br></blockquote><div><br></div><div>We&#39;re going to write down BIP desc=
ribing such structure. If any wallet want to be BIP XX compatible, then it =
has chance to. Of course if any wallet want to use another format, then it =
cannot call itself BIP XX compatible, thus nobody will expect that such sof=
tware will see/recover all keys generated by BIP XX wallet.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
I understand each client will implement things a little bit different,<br>
for example the current plan is bitcoinj will hold all keys in memory<br>
and start reusing keys on low resources. Electrum uses a chain for their<br=
>
private purpose. Etc.<br>
<br></blockquote><div><br></div><div>It still doesn&#39;t mean that bitcoin=
j or Electrum cannot share the bare minimum of BIP XX. Of course if somebod=
y will use Electrum for 2to3 transactions and then move wallet to client wh=
ich does not offer such feature, it won&#39;t work. But I don&#39;t see tha=
t as a problem.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
If we cannot 100% agree on a standard and also agree it will not be<br>
extended in future, I think we should not even try. It&#39;s dangerous for<=
br>
the money of users.</blockquote><div><br></div><div>If some developers agre=
e on some specific BIP, then it should be cross compatible. =A0Of course if=
 somebody implements BIP XX in different way, then it isn&#39;t BIP XX comp=
atible.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">=A0<br></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">


I propose we keep our chains deliberately separate and only try<br>
standardizing after each of us has a feel for the specific requirements.<br=
>
<div class=3D"im HOEnZb"><span style=3D"color:rgb(34,34,34)"></span></div><=
/blockquote><div><br></div><div>Of course, if somebody don&#39;t want to ge=
nerate compatible bip32 paths, no problem. It will be the same situation as=
 now.</div>

<div><br></div><div>Marek</div></div></div></div>

--001a1133da667fef5704f689e38e--