From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd3Az-0005dH-FT for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:49:49 +0000 X-ACL-Warn: Received: from mail-ee0-f50.google.com ([74.125.83.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd3Ax-0003MN-Ku for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:49:49 +0000 Received: by mail-ee0-f50.google.com with SMTP id c13so1155603eek.9 for ; Wed, 23 Apr 2014 12:49:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=I22NvN1jwYRkxzuajijFylJp/Af6tZ2vriq00ew6+xA=; b=emOaDzilJFNHnDl5g/gJ+7dB7NKPSvbCvOLwSbwKuYnMqkCHT1J6yQIUJ3qPAkpq2F E4A9Fr+3dyMFLpGJBnI8xigDHf7iSlRamTEnqzR+JsiL6bbkCv8IXXm3S4WuuEtreuvN 9cDSOw8SIEFXy9hdlKYF9bUpVELKMNiXF8U9vye3O4O1Gz6C2tH7adM/s1fRa5c0y7Tm fd+5WCCDqczA0707vBl+NthDsIabNC7qnUdHXECx2qqWPZvWJRMmyeW1tuh8lA6nUEO7 VqQtc3Ag3O582KXGq4kZ+JaCoPDNG1SmpA59Zq6xt9ZwdvRMJemo6WrvE5BqXFM8uQdn s+8A== X-Gm-Message-State: ALoCoQnOOliJQm5AXtxZkyqEBGTHmqsz/bzJ+8bz3hPo4JqvnovaO4AJ91rn3qM7WKvmUCDEMV8J X-Received: by 10.14.95.136 with SMTP id p8mr11678263eef.103.1398282580955; Wed, 23 Apr 2014 12:49:40 -0700 (PDT) Received: from tetra.site (nat-0-15.lam.cz. [80.92.242.254]) by mx.google.com with ESMTPSA id q41sm9070008eez.7.2014.04.23.12.49.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 12:49:40 -0700 (PDT) Message-ID: <53581952.1050602@gk2.sk> Date: Wed, 23 Apr 2014 21:49:38 +0200 From: Pavol Rusnak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Luke-Jr , bitcoin-development@lists.sourceforge.net References: <53581480.5060103@gk2.sk> <201404231944.14256.luke@dashjr.org> In-Reply-To: <201404231944.14256.luke@dashjr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Wd3Ax-0003MN-Ku 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: Wed, 23 Apr 2014 19:49:49 -0000 On 04/23/2014 09:44 PM, Luke-Jr wrote: > Why do clients need to use the features in BIP 64? If Electrum doesn't want to > use accounts, then it can just use account 0 for everything. Refund chains are As Andreas wrote earlier in this thread: "There is no "bare minimum". Either you implement the "BIP" fully or not." What you suggest does not follow the principle of least surprise. Suppose user imports his BIP64 compatible wallet into Electrum, which claims it is BIP64 compatible, but actually implements just a subset of the spec (sticking account index to 0). The user now sees just a fraction of his coins and is puzzled. -- Best Regards / S pozdravom, Pavol Rusnak