Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YgIsi-0005jB-Rs for bitcoin-development@lists.sourceforge.net; Thu, 09 Apr 2015 20:16:56 +0000 X-ACL-Warn: Received: from mail-pd0-f176.google.com ([209.85.192.176]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YgIsh-0003U1-EK for bitcoin-development@lists.sourceforge.net; Thu, 09 Apr 2015 20:16:56 +0000 Received: by pdbqa5 with SMTP id qa5so107039630pdb.1 for ; Thu, 09 Apr 2015 13:16:49 -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=2zcVfWmteK95Eh19kpvEdRhBVvmPWaZfc2u7OdyFr+0=; b=cncPDmnpJqXe9Q6rdziM1SEYIlj64Z3Cq96oALfRdCB8gPPYzxwIVhTrfzHv9xK7wO dqFEN+FNH5Fjw8llOAMAISFBvv5PzXwfu0Lpx10QvQo7uv7LxuacGCn3/U+blyOUnn0U 2pF+HyaWz2nY69jVl/P1VxTwP3NkACuYMLXNv33ScmM378MOLkpwHcIfOSzW/+tuvG0D l0omcLsGPXaoUnFDUWuZUZNm3ZwbEC0FG+pW9uDkqN4L3AiOPll/l+d/RrAOZKj/F8l5 X7QromqGRGpTZkMrR0tFqxt1MuMogmulL8Hc/7VpIXq05Fr243kycPNK+N+T78Hu0qg9 kdSw== X-Gm-Message-State: ALoCoQlL5AjxXCQORk0qJEu4uZxncfnUTRbsksF9U7vmAQH/WffLR90moo7o41FL60wUI/PXTXWV X-Received: by 10.70.53.40 with SMTP id y8mr59468352pdo.61.1428610609637; Thu, 09 Apr 2015 13:16:49 -0700 (PDT) Received: from [192.168.1.100] (nc-67-232-10-161.dhcp.embarqhsd.net. [67.232.10.161]) by mx.google.com with ESMTPSA id 4sm15444541pdo.19.2015.04.09.13.16.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 13:16:48 -0700 (PDT) Message-ID: <5526DE29.1060605@maza.club> Date: Thu, 09 Apr 2015 16:16:41 -0400 From: Kefkius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <5524D347.4040507@maza.club> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: 1YgIsh-0003U1-EK Subject: Re: [Bitcoin-development] Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets 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: Thu, 09 Apr 2015 20:16:56 -0000 William, I've amended the proposal's "Motivation" section slightly for clarification. I'm not sure how a "cosigner_index" branch would benefit this proposal. Granted, I don't fully understand the benefits of the "cosigner_index" branch in BIP-0045. From what I understand, the "wallet" branch of my proposal seems to accomplish a similar goal. Jona, Your explanation is correct. As for this being appropriate as a BIP, I agree that it's an arguable point to say it improves Bitcoin. However, this proposal exists because of BIP-0044, which also describes a multi-currency hierarchy. For that reason, I think this is an appropriate proposal. Thank you both for your feedback. On 04/08/2015 12:41 PM, William Swanson wrote: > Oops, sorry I missed that. > > Since that's the reason this proposal exists, I would consider putting > it right up top where people can see it. Also, since this proposal is > specifically designed for multi-sig, I would look at what BIP45 is > doing and maybe incorporate a "cosigner_index" branch. Otherwise, this > idea seems like a reasonable way to organize a wallet. > > -William > > On Wed, Apr 8, 2015 at 9:28 AM, 木ノ下じょな wrote: >> William, >> >> I believe the reasoning for this is stated in the Coin Type section. >> >> "Public derivation is used so that cosigners need only know one of each >> other's public keys, rather than needing to distribute public keys for each >> coin." >> >> BIP44 has a coin level, but it's a private derived level, so cosigners would >> not be able to generate multiple crypto currencies of each others' without >> giving each other n xpubs where n is the number of currencies shared. This >> new proposal basically sticks coin type on the public derivation side of >> things so that I could generate litecoin or darkcoin multisigs without your >> permission... >> >> Kefkius, >> >> This BIP seems like a good fit for multi-currency wallets based on multisig. >> So kudos for putting it in writing. >> >> However, I don't know if this is really a BIP thing. It's not improving >> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definition >> it is improving altcoin usability. >> >> For that reason alone I will say I disagree for a BIP for this. >> - Jona >> >> >> 2015-04-08 16:46 GMT+09:00 William Swanson : >>> It's not really clear why this is better than BIP 44 as it already >>> stands. You have the same fields, but they are just in a different >>> order. Couldn't you just use the existing BIP 44 hierarchy, but add >>> the convention that "wallet/account N" is the same wallet in each >>> supported currency? >>> >>> For example, if I have a wallet called "business expenses", which >>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same >>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5' >>> for Litecoin. >>> >>> I am trying to think of examples where your proposal is better than >>> BIP 44, but I can't think of any. Even backup recovery works fine. I >>> assume that your idea is to continue iterating over the different >>> wallet indices as long as you are finding funds in *any* currency. >>> Well, you can still do that with BIP 44. The fields are in a different >>> order, but that doesn't affect the algorithm in any way. >>> >>> Maybe you have some deeper insight I'm not seeing, but if so, you need >>> to clearly explain that in your motivation section. The current >>> explanation, "This limits the possible implementations of >>> multi-currency, multisignature wallets," is pretty vauge. Also, there >>> is nothing in this spec that addresses the multisignature use-case. >>> The BIP 45 spec does a lot of extra work to make multisignature work >>> smoothly. >>> >>> I'm not trying to criticize your proposal. I'm just trying to >>> understand what it's trying to accomplish. >>> >>> -William Swanson >>> >>> >>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius wrote: >>>> I have a potential BIP, "Multi-Currency Hierarchy For Use In >>>> Multisignature Deterministic Wallets." I'm requesting discussion on it, >>>> and possibly assignment of a BIP number. >>>> >>>> It's located in this github gist: >>>> https://gist.github.com/Kefkius/1aa02945e532f8739023 > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development