path: root/c3/f730ba3289a5eb4fdf70dfc9c4fe1e8fa11876

Return-Path: <omarshib@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1D888D80
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  1 Sep 2017 07:16:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3E14113
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  1 Sep 2017 07:16:43 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id u26so3081811wma.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 01 Sep 2017 00:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=V/5rP5t/nxlPSiACAKnGhlcxgpCpnHx7eveIyqE/PKw=;
	b=l1j3/jOCN3kwL81LjarWNKg1wIx60Px+IhLhW7alzzxXRy2FrHMx451OiXgJkcCBee
	SAP01vvYe/fUzcFzkyI6694cASQp8wFaM5PGrhA1A11mztvOjDWZKmZEgPafCPxthl6R
	G/L1UFW4MGbdYCpm4qjUUkLcDwrIqCIKBqAO4ag5kTYTfDeMzOmFTRqRv8tvZbfRXfYZ
	8RDSGtUwr4TGPL8/EEwKYckgUAOTFoPwwbXp6PHzYB6yzDkLdOsEzCDbicejNNPPcoLw
	50Pd2HerQ77jEYPwSBwVlD7rvf36x0UvuZYx8+nhicnnkigK6XLG+MNu6J35prUPYWU9
	Z9Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=V/5rP5t/nxlPSiACAKnGhlcxgpCpnHx7eveIyqE/PKw=;
	b=BEqKsmD9XiJIvbrxfzr/nx2nH4wxzaeE2XGxzTiqxJkyuAjg7kOCdruCtDCjc38Ve2
	4hU28rAqNL6x1h4o38rbbssfvzWj+NFAmJIOP0ilsuVH80ElkEaMWZF1NNFMxVa0DqFt
	bm9HjbpjRNKu7T+nAQygQjBdIpw0D8NuWOqcoYRW6FyNfeTeE/h+xgsM/pWOe6MdtHml
	up3uMvjGCM8mwOyWp3G43LawksX9Qb1b3RYV0eIeZIk5kDe75/ZfZpuovylKf5nwxsqN
	6bGTWfYCzfNLRszd5WjQHafOQWCmxIOheSoZBx7X0bLZHiU2h8t8PuUjx7OTBHZFbDex
	aYSA==
X-Gm-Message-State: AHPjjUgq9Ynk8wqqm0TwKqPXWx8rDCZ7QWEv8YvExTgO072cWizeaPmv
	X6Su4B2VlBzvoYNYOsAEs0y6rmYVWg==
X-Google-Smtp-Source: ADKCNb7Pm5g6nqf0BBZzCbxlrnMnD3ehE7qXeontN8YSMXy9/TcyM+4N7Wm0eeIslcer/gk/MJGeIWRLWLQgNZoQNF4=
X-Received: by 10.28.212.7 with SMTP id l7mr458866wmg.173.1504250201999; Fri,
	01 Sep 2017 00:16:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.183.67 with HTTP; Fri, 1 Sep 2017 00:16:41 -0700 (PDT)
In-Reply-To: <CAE3EOfh+mEB6P0ZO7AVs-i92Y1Fyppj+zNHGF4MbCohFCyZaSg@mail.gmail.com>
References: <CAE3EOfgJdrO29GCftwORcq0087X0Y74gYtuMWvO1EWEkrT-7rg@mail.gmail.com>
	<CAAS2fgSbK=Hf7nViHScLezCAUdKkFT1MxEM4VZhZxoj990O8PQ@mail.gmail.com>
	<CAE3EOfh+mEB6P0ZO7AVs-i92Y1Fyppj+zNHGF4MbCohFCyZaSg@mail.gmail.com>
From: Omar Shibli <omarshib@gmail.com>
Date: Fri, 1 Sep 2017 10:16:41 +0300
Message-ID: <CAE3EOfgSEveQQesGLDAAwOgHn8+sjkzc1ayvv7ieRS19k=d63A@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="001a1146ede2f18eb305581b8a94"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,HTML_OBFUSCATE_05_10,
	RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 01 Sep 2017 12:55:07 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Sep 2017 07:16:45 -0000

--001a1146ede2f18eb305581b8a94
Content-Type: text/plain; charset="UTF-8"

Hello Gregory,

Thanks for you feedback.

The BIP has been updated to explicitly specify the multiparty key
derivation scheme which hopefully addresses your concerns.

Please have a look at the updated draft of the BIP at the link below:

https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki

Any feedback is highly appreciated.

Regards,
Omar

On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <omarshib@gmail.com> wrote:

> Thank you for your time Gregory, I really appreciate that.
>
> What we are describing here is a method to embed cryptographic signatures
> into a public key based on HD Wallets - BIP32.
> In a practical application, we should have two cryptographic signatures
> from both sides, I don't think in that case your scenario would be an issue.
>
> More specifically in our application, we do the following construction:
>
> contract base: m/200'/0'/<contract_number>'
> payment base (merchant commitment): contract_base/<merchant_
> contract_signature>
> payment address (customer commitment): contract_base/<merchant_
> contract_signature>/<customer_contract_signature>
>
> payment address funds could be reclaimed only if the
> customer_contract_signature is provided by the customer.
>
> In terms of durability, our app is pretty simple at this point, we don't
> store anything, we let customer download and manage the files.
>
> I will update the BIP to address your concerns.
>
> On Tue, Aug 15, 2017 at 8:12 AM, Gregory Maxwell <greg@xiph.org> wrote:
>
>> This construction appears to me to be completely insecure.
>>
>>
>> Say my pubkey (the result of the derivation path) is P.
>>
>> We agree to contract C1.   A payment is made to P + G*H(C1).
>>
>> But in secret, I constructed contract C2 and pubkey Q and set P = Q +
>> G*H(C2).
>>
>> Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert
>> it was in act a payment to P' + G*H(C2).   (P' is simply Q + G*H(C1))
>>
>> I don't see anything in the proposal that addresses this. Am I missing it?
>>
>> The applications are also not clear to me, and it doesn't appear to
>> address durability issues (how do you avoid losing your funds if you
>> lose the exact contract?).
>>
>>
>>
>>
>> On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Hey all,
>> >
>> > A lot of us familiar with the pay to contract protocol, and how it uses
>> > cleverly the homomorphic property of elliptic curve encryption system to
>> > achieve it.
>> > Unfortunately, there is no standard specification on how to conduct such
>> > transactions in the cyberspace.
>> >
>> > We have developed a basic trade finance application that relies on the
>> > original idea described in the Homomorphic Payment Addresses and the
>> > Pay-to-Contract Protocol paper, yet we have generalized it and made it
>> BIP43
>> > complaint.
>> >
>> > We would like to share our method, and get your feedback about it,
>> hopefully
>> > this effort will result into a standard for the benefit of the
>> community.
>> >
>> > Abstract idea:
>> >
>> > We define the following levels in BIP32 path.
>> > m / purpose' / coin_type' / contract_id' / *
>> >
>> > contract_id is is an arbitrary number within the valid range of indices.
>> >
>> > Then we define, contract base as following prefix:
>> > m / purpose' / coin_type' / contract_id'
>> >
>> > contract commitment address is computed as follows:
>> > hash document using cryptographic hash function of your choice (e.g.
>> blake2)
>> > map hash to partial derivation path
>> > Convert hash to binary array.
>> > Partition the array into parts, each part length should be 16.
>> > Convert each part to integer in decimal format.
>> > Convert each integer to string.
>> > Join all strings with slash `/`.
>> > compute child public key by chaining the derivation path from step 2
>> with
>> > contract base:
>> > m/<contract_base>/<hash_derivation_path>
>> > compute address
>> > Example:
>> >
>> > master private extended key:
>> > xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4Ux
>> FVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
>> > coin type: 0
>> > contract id: 7777777
>> >
>> > contract base computation :
>> >
>> > derivation path:
>> > m/999'/0'/7777777'
>> > contract base public extended key:
>> > xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnnii
>> D5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>> >
>> > Contract content:
>> > foo
>> >
>> > Contract sha256 signature:
>> > 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
>> >
>> > Contract partial derivation path:
>> > 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25
>> 731/49056/63882/24200/25190/59310
>> >
>> > Contract commitment pub key path:
>> > m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/
>> 16692/4930/11632/25731/49056/63882/24200/25190/59310
>> > or
>> > <contract_base_extended_pub_key>/11302/46187/26879/50831/638
>> 99/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>> >
>> > Contract commitment pub key:
>> > xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj
>> 8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>> >
>> > Contract commitment address:
>> > 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
>> >
>> >
>> > You can find the full BIP draft in the following link:
>> > https://github.com/commerceblock/pay-to-contract-protocol-
>> specification/blob/master/bip-draft.mediawiki
>> >
>> >
>> > Regards,
>> > Omar
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>
>

--001a1146ede2f18eb305581b8a94
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Gregory,</div><div><br></div><div>Thanks for yo=
u feedback.</div><div><br></div><div>The BIP has been updated to explicitly=
 specify the multiparty key derivation scheme which hopefully addresses you=
r concerns.</div><div><br></div><div>Please have a look at the updated draf=
t of the BIP at the link below:</div><div><br></div><div><a href=3D"https:/=
/github.com/commerceblock/pay-to-contract-protocol-specification/blob/maste=
r/bip-draft.mediawiki">https://github.com/commerceblock/pay-to-contract-pro=
tocol-specification/blob/master/bip-draft.mediawiki</a></div><div><br></div=
><div>Any feedback is highly appreciated.</div><div><br></div><div>Regards,=
</div><div>Omar</div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <span dir=3D"ltr">&l=
t;<a href=3D"mailto:omarshib@gmail.com" target=3D"_blank">omarshib@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<span class=3D""><div>Thank you for your time Gregory, I really appreciate =
that.</div><div><br></div><div>What we are describing here is a method to e=
mbed cryptographic signatures into a public key based on HD Wallets - BIP32=
.</div><div>In a practical application, we should have two cryptographic si=
gnatures from both sides, I don&#39;t think in that case your scenario woul=
d be an issue.</div><div><br></div><div>More specifically in our applicatio=
n, we do the following construction:</div><div><br></div><div>contract base=
: m/200&#39;/0&#39;/&lt;contract_number&gt;&#39;</div><div>payment base (me=
rchant commitment): contract_base/&lt;merchant_<wbr>contract_signature&gt;<=
/div><div>payment address (customer commitment): contract_base/&lt;merchant=
_<wbr>contract_signature&gt;/&lt;customer_<wbr>contract_signature&gt;</div>=
<div><br></div></span><div>payment address funds could be reclaimed only if=
 the customer_contract_signature is provided by the customer.</div><span cl=
ass=3D""><div><br></div><div>In terms of durability, our app is pretty simp=
le at this point, we don&#39;t store anything, we let customer download and=
 manage the files.</div><div><br></div></span><div>I will update the BIP to=
 address your concerns.</div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote"><span class=3D"">On Tue, Aug 15, 2017 at 8:12 AM, Gregory=
 Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:greg@xiph.org" target=3D"_=
blank">greg@xiph.org</a>&gt;</span> wrote:<br></span><div><div class=3D"h5"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">This construction appears to me to be compl=
etely insecure.<br>
<br>
<br>
Say my pubkey (the result of the derivation path) is P.<br>
<br>
We agree to contract C1.=C2=A0 =C2=A0A payment is made to P + G*H(C1).<br>
<br>
But in secret, I constructed contract C2 and pubkey Q and set P =3D Q + G*H=
(C2).<br>
<br>
Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert<br>
it was in act a payment to P&#39; + G*H(C2).=C2=A0 =C2=A0(P&#39; is simply =
Q + G*H(C1))<br>
<br>
I don&#39;t see anything in the proposal that addresses this. Am I missing =
it?<br>
<br>
The applications are also not clear to me, and it doesn&#39;t appear to<br>
address durability issues (how do you avoid losing your funds if you<br>
lose the exact contract?).<br>
<div><div class=3D"m_620485692497789117h5"><br>
<br>
<br>
<br>
On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt; Hey all,<br>
&gt;<br>
&gt; A lot of us familiar with the pay to contract protocol, and how it use=
s<br>
&gt; cleverly the homomorphic property of elliptic curve encryption system =
to<br>
&gt; achieve it.<br>
&gt; Unfortunately, there is no standard specification on how to conduct su=
ch<br>
&gt; transactions in the cyberspace.<br>
&gt;<br>
&gt; We have developed a basic trade finance application that relies on the=
<br>
&gt; original idea described in the Homomorphic Payment Addresses and the<b=
r>
&gt; Pay-to-Contract Protocol paper, yet we have generalized it and made it=
 BIP43<br>
&gt; complaint.<br>
&gt;<br>
&gt; We would like to share our method, and get your feedback about it, hop=
efully<br>
&gt; this effort will result into a standard for the benefit of the communi=
ty.<br>
&gt;<br>
&gt; Abstract idea:<br>
&gt;<br>
&gt; We define the following levels in BIP32 path.<br>
&gt; m / purpose&#39; / coin_type&#39; / contract_id&#39; / *<br>
&gt;<br>
&gt; contract_id is is an arbitrary number within the valid range of indice=
s.<br>
&gt;<br>
&gt; Then we define, contract base as following prefix:<br>
&gt; m / purpose&#39; / coin_type&#39; / contract_id&#39;<br>
&gt;<br>
&gt; contract commitment address is computed as follows:<br>
&gt; hash document using cryptographic hash function of your choice (e.g. b=
lake2)<br>
&gt; map hash to partial derivation path<br>
&gt; Convert hash to binary array.<br>
&gt; Partition the array into parts, each part length should be 16.<br>
&gt; Convert each part to integer in decimal format.<br>
&gt; Convert each integer to string.<br>
&gt; Join all strings with slash `/`.<br>
&gt; compute child public key by chaining the derivation path from step 2 w=
ith<br>
&gt; contract base:<br>
&gt; m/&lt;contract_base&gt;/&lt;hash_deriva<wbr>tion_path&gt;<br>
&gt; compute address<br>
&gt; Example:<br>
&gt;<br>
&gt; master private extended key:<br>
&gt; xprv9s21ZrQH143K2JF8RafpqtKiTb<wbr>sbaxEeUaMnNHsm5o6wCW3z8ySyH4Ux<wbr>=
FVSfZ8n7ESu7fgir8imbZKLYVBxFPN<wbr>D1pniTZ81vKfd45EHKX73<br>
&gt; coin type: 0<br>
&gt; contract id: 7777777<br>
&gt;<br>
&gt; contract base computation :<br>
&gt;<br>
&gt; derivation path:<br>
&gt; m/999&#39;/0&#39;/7777777&#39;<br>
&gt; contract base public extended key:<br>
&gt; xpub6CMCS9rY5GKdkWWyoeXEbmJmxG<wbr>gDcbihofyARxucufdw7k3oc1JNnnii<wbr>=
D5H2HynKBwhaem4KnPTue6s9R2tcro<wbr>qkHv7vpLFBgbKRDwM5WEE<br>
&gt;<br>
&gt; Contract content:<br>
&gt; foo<br>
&gt;<br>
&gt; Contract sha256 signature:<br>
&gt; 2c26b46b68ffc68ff99b453c1d3041<wbr>3413422d706483bfa0f98a5e886266<wbr>=
e7ae<br>
&gt;<br>
&gt; Contract partial derivation path:<br>
&gt; 11302/46187/26879/50831/63899/<wbr>17724/7472/16692/4930/11632/25<wbr>=
731/49056/63882/24200/25190/59<wbr>310<br>
&gt;<br>
&gt; Contract commitment pub key path:<br>
&gt; m/999&#39;/0&#39;/7777777&#39;/11302/46187<wbr>/26879/50831/63899/1772=
4/7472/<wbr>16692/4930/11632/25731/49056/<wbr>63882/24200/25190/59310<br>
&gt; or<br>
&gt; &lt;contract_base_extended_pub_ke<wbr>y&gt;/11302/46187/26879/50831/63=
8<wbr>99/17724/7472/16692/4930/11632<wbr>/25731/49056/63882/24200/25190<wbr=
>/59310<br>
&gt;<br>
&gt; Contract commitment pub key:<br>
&gt; xpub6iQVNpbZxdf9QJC8mGmz7cd3Cs<wbr>wt2itcQofZbKmyka5jdvQKQCqYSDFj<wbr>=
8KCmRm4GBvcQW8gaFmDGAfDyz887ms<wbr>EGqxb6Pz4YUdEH8gFuaiS<br>
&gt;<br>
&gt; Contract commitment address:<br>
&gt; 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhv<wbr>mM5R<br>
&gt;<br>
&gt;<br>
&gt; You can find the full BIP draft in the following link:<br>
&gt; <a href=3D"https://github.com/commerceblock/pay-to-contract-protocol-s=
pecification/blob/master/bip-draft.mediawiki" rel=3D"noreferrer" target=3D"=
_blank">https://github.com/commerceblo<wbr>ck/pay-to-contract-protocol-<wbr=
>specification/blob/master/bip-<wbr>draft.mediawiki</a><br>
&gt;<br>
&gt;<br>
&gt; Regards,<br>
&gt; Omar<br>
&gt;<br>
</div></div>&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;<br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>

--001a1146ede2f18eb305581b8a94--