Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXYEX-0001av-Sm for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 15:46:45 +0000 X-ACL-Warn: Received: from mail-ve0-f170.google.com ([209.85.128.170]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WXYES-0000gG-6L for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 15:46:45 +0000 Received: by mail-ve0-f170.google.com with SMTP id pa12so955016veb.29 for ; Tue, 08 Apr 2014 08:46:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=EHgc+msymCHdIHBn8n9VIUcAkBL3f8djg4OIcQxeZ4A=; b=DoF33AtyWVYVDNzfswD+UnzA3wfyqidFXG2+nwv9H+qug/d2V/VVSPoIS3jybBLkyy P3OArVgNy4Y9AEzcLEPGLnYiZ0SFFt8kvI1GtZvxtP3rgJha27O452jG604WjGJghKqM 87i1yhuMp+NbvR4BI4e3sP6WsRDZvlC2Cw8FNYzXrsY4kIofM6tQvuIB6auTM4ss026a abSXQzlaIksgNjjqjVVh0koFBmNFMhEcxl44EunvpXXg6LQQSp/qPrCo9VElw2Cr74en a4LrHCVY/PWyKWW3VvNUbLYSjYTC1ugvLqkuXgFD+yv/zl68KiJEZduok97baO0k2KiQ ZYmg== X-Gm-Message-State: ALoCoQneR80wALPhvV+Dnqri5NagP0CaaNUz3ZLR856kevEM8b3lEt5+1CXuMt9VfnlMrDbJcub3 X-Received: by 10.220.163.3 with SMTP id y3mr3822528vcx.7.1396971994604; Tue, 08 Apr 2014 08:46:34 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.234.100 with HTTP; Tue, 8 Apr 2014 08:46:04 -0700 (PDT) In-Reply-To: References: <53344FF8.7030204@gk2.sk> From: slush Date: Tue, 8 Apr 2014 17:46:04 +0200 X-Google-Sender-Auth: JSoVyBMYO42wGZxAw0huFYOjuLg Message-ID: To: Andreas Schildbach Content-Type: multipart/alternative; boundary=001a1133da667fef5704f689e38e X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXYES-0000gG-6L Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:46:46 -0000 --001a1133da667fef5704f689e38e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach 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



On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach <andreas@sc= hildbach.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 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.
=A0
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 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't work. But I don't see tha= t as a problem.
=A0
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<= br> the money of users.

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't BIP XX comp= atible.
=A0
=A0
I propose we keep our chains deliberately separate and only try
standardizing after each of us has a feel for the specific requirements.
<= /blockquote>

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

Marek
--001a1133da667fef5704f689e38e--