path: root/67/587d0a93f8988ca7c17243c424b75642bbe32e

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 05B85902
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 15 Aug 2017 16:40:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94B341A2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 15 Aug 2017 16:40:38 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id m85so12645194wma.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 15 Aug 2017 09:40:38 -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=dkuZ8ehGGOuo4ydryH5FSY1LRV7Vjmxb8azV0bcPh5Q=;
	b=EodLqZvkJJd8Oh1n3HB8aPulPd4IHHHAIkjwVyAwXoczPCUbGBRL/U6AToWQljzjdE
	NgIg3lxeC9DguP3Mv8Cl3x3zocUr3tou11PTwNaVjh+hDY8fQrR67RbA4QxvGTPwVdZS
	m5PMQsm9tGChowzIe8RAM/7xwcM4983kIILkzVenqhOLdpvtSfzDgNsvSY/7hnE2d6rA
	MIx344D6Ym2GHfqubVPQuK7BFbPIufPE/DybV8t2UqVF0CgPjZrKkN6MChQsu+HhLT+t
	VFIgLKp065d+7r/SPXw1+tijcl0ka3ygDq4nChxDOfBoA1awwv+A5+bbG1AigPCrZiTR
	CmMw==
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=dkuZ8ehGGOuo4ydryH5FSY1LRV7Vjmxb8azV0bcPh5Q=;
	b=FR9yNk8sZtLV5kQBibROQswuFkqLKRtheVkNsy1p8/9oj4NRNSUvd7p72be0Yw/upH
	ZGRxdSneUFsZAD5yN9Rytcsds7j0Q+xSvu4C5aMgb2mTtYam/JamBMU1dv9JQ6eu9iau
	pc0qTJr1gA8z2cxQ+hoBvbGaRjrtcc/IcAox3c9pMyAHZSb5gXLX82j9wx+mHdp4TzlC
	NXZDNE5Ye4Zp6YGIvJtDu1zQkVDZwfoLUDsqlLRwo8vQjSapcjFT/AbLvAMQ0iD3w0IB
	ca6EwkKpUim3RJ5QeekXju69U6r2KHoBhRAbAmJFY/EMdfOhA/6IkQ0UUgnQ/ilXkUsr
	AZAw==
X-Gm-Message-State: AHYfb5g5wYSHOYnPNM1/j3Mb9zpr2u7M8NmNj4+ka6IsmHvKKca/Ls40
	aoNdQbY4+QWCIaWbViQIM9ec69BAzA==
X-Received: by 10.28.193.203 with SMTP id r194mr1671475wmf.85.1502815237181;
	Tue, 15 Aug 2017 09:40:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.146.161 with HTTP; Tue, 15 Aug 2017 09:40:36 -0700 (PDT)
In-Reply-To: <CAAS2fgSbK=Hf7nViHScLezCAUdKkFT1MxEM4VZhZxoj990O8PQ@mail.gmail.com>
References: <CAE3EOfgJdrO29GCftwORcq0087X0Y74gYtuMWvO1EWEkrT-7rg@mail.gmail.com>
	<CAAS2fgSbK=Hf7nViHScLezCAUdKkFT1MxEM4VZhZxoj990O8PQ@mail.gmail.com>
From: omar shibli <omarshib@gmail.com>
Date: Tue, 15 Aug 2017 19:40:36 +0300
Message-ID: <CAE3EOfh+mEB6P0ZO7AVs-i92Y1Fyppj+zNHGF4MbCohFCyZaSg@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="94eb2c13158e6017200556cd70af"
X-Mailman-Approved-At: Tue, 15 Aug 2017 16:43:56 +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: Tue, 15 Aug 2017 16:40:39 -0000

--94eb2c13158e6017200556cd70af
Content-Type: text/plain; charset="UTF-8"

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/
> 25731/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/
> 63899/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
> >
>

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

<div dir=3D"ltr"><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_contract_signature&gt;</div>=
<div>payment address (customer commitment): contract_base/&lt;merchant_cont=
ract_signature&gt;/&lt;customer_contract_signature&gt;</div><div><br></div>=
<div>payment address funds could be reclaimed only if the customer_contract=
_signature is provided by the customer.</div><div><br></div><div>In terms o=
f durability, our app is pretty simple at this point, we don&#39;t store an=
ything, we let customer download and manage the files.</div><div><br></div>=
<div>I will update the BIP to address your concerns.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 15, 2017 at 8:1=
2 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><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">This construction appears to me to be completely insecure.<b=
r>
<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"h5"><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">bitcoin-dev@li=
sts.<wbr>linuxfoundation.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_<wbr>derivation_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/<wbr>25=
731/49056/63882/24200/25190/<wbr>59310<br>
&gt;<br>
&gt; Contract commitment pub key path:<br>
&gt; m/999&#39;/0&#39;/7777777&#39;/11302/<wbr>46187/26879/50831/63899/1772=
4/<wbr>7472/16692/4930/11632/25731/<wbr>49056/63882/24200/25190/59310<br>
&gt; or<br>
&gt; &lt;contract_base_extended_pub_<wbr>key&gt;/11302/46187/26879/50831/<w=
br>63899/17724/7472/16692/4930/<wbr>11632/25731/49056/63882/24200/<wbr>2519=
0/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/<wbr>commerceblock/pay-to-contract-<wbr>protocol=
-specification/blob/<wbr>master/bip-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">bitcoin-dev@l=
ists.<wbr>linuxfoundation.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-<wbr>dev</a><br>
&gt;<br>
</blockquote></div><br></div>

--94eb2c13158e6017200556cd70af--