path: root/7d/88dfb4f23262d02ce47ff120b4b8083820634b

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <vertoe@qhor.net>) id 1Yijs1-0001ny-QT
	for bitcoin-development@lists.sourceforge.net;
	Thu, 16 Apr 2015 13:30:17 +0000
Received-SPF: softfail (sog-mx-3.v43.ch3.sourceforge.com: transitioning domain
	of qhor.net does not designate 31.47.248.165 as permitted
	sender) client-ip=31.47.248.165; envelope-from=vertoe@qhor.net;
	helo=leon.servertools24.de; 
Received: from mail.leon.servertools24.de ([31.47.248.165]
	helo=leon.servertools24.de)
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Yijrz-0002gi-6m
	for bitcoin-development@lists.sourceforge.net;
	Thu, 16 Apr 2015 13:30:17 +0000
Received: from [192.168.137.104] (p5DC47304.dip0.t-ipconnect.de [93.196.115.4])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: web458p3)
	by leon.servertools24.de (Postfix) with ESMTP id 82FC73B18006
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 16 Apr 2015 15:11:02 +0200 (CEST)
Message-ID: <552FB4E5.1010103@qhor.net>
Date: Thu, 16 Apr 2015 15:11:01 +0200
From: Vertoe Qhor <vertoe@qhor.net>
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>	<CABjHNoTbLz+dCPkctk95jPkdnagQQxOintYgswKCE6wB=TS9xg@mail.gmail.com>	<CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com>	<CABjHNoR_Tg6bq3mJ8vkFAOPNHz8RS-FKAEx9APMZAVhct5H0SA@mail.gmail.com>
	<5526DE29.1060605@maza.club>
In-Reply-To: <5526DE29.1060605@maza.club>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
X-Headers-End: 1Yijrz-0002gi-6m
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 16 Apr 2015 13:30:17 -0000

I'm supporting this proposal and since I'm already using the Encompass
wallet software I would like to highlight that this use case is not only
practical but has already a working reference implementation.

The only donwside I see is that it means we get yet another HD wallet
definition.

Is there anything else what would speak against assigning a BIP number
to this proposal? This would allow kefkius and his team to use the
standard in Encompass and share it with other software packages which
might be interested in using deterministic cross-currency wallets.

On 04/09/2015 10:16 PM, Kefkius wrote:
> 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, =E6=9C=A8=E3=83=8E=E4=B8=8B=E3=81=98=E3=
=82=87=E3=81=AA <kinoshitajona@gmail.com> 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 ea=
ch
>>> other's public keys, rather than needing to distribute public keys fo=
r each
>>> coin."
>>>
>>> BIP44 has a coin level, but it's a private derived level, so cosigner=
s would
>>> not be able to generate multiple crypto currencies of each others' wi=
thout
>>> 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 withou=
t your
>>> permission...
>>>
>>> Kefkius,
>>>
>>> This BIP seems like a good fit for multi-currency wallets based on mu=
ltisig.
>>> So kudos for putting it in writing.
>>>
>>> However, I don't know if this is really a BIP thing. It's not improvi=
ng
>>> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by defi=
nition
>>> 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 <swansontec@gmail.com>:
>>>> 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 differe=
nt
>>>> 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 ne=
ed
>>>> 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, ther=
e
>>>> 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 <kefkius@maza.club> 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 exe=
rcises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event=
?utm_
>> source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaign=3D=
VA_SF
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> -----------------------------------------------------------------------=
-------
> 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 exer=
cises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?=
utm_
> source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaign=3D=
VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development