path: root/08/c87ef218e979845b3f3ad741e8b8564d19c7cd

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 7A0F49E7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 05:53:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f180.google.com (mail-it1-f180.google.com
	[209.85.166.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E5872C4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 05:53:57 +0000 (UTC)
Received: by mail-it1-f180.google.com with SMTP id w18so2507696itj.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Mar 2019 22:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=ebKRyXZqF5QOOdGXiXodcFhJdQCCbsQF3CVKMkTwAh4=;
	b=GE0Mfk9oXwTzgrirJEgADNz9UkQDl9SYGGV0Qb+AKsN97SpPhWSo4xZFw2tACNj3v7
	ocUGK7A4gkY+rVxq1y0PAcJoT5Vf6IYusZ7qIbspJ60oWR2NjaORJcHIAZROXH9cxgvB
	jem6WaDi4mZ2mnqNsvHvjGUz6H6tAJqJm4eWBKBmVW/PrUzBMhyqM4cYUPIddiwXdfKU
	XnlJgCecILhnWfFo1I5uStgKI6ADvyUKAdPOF8WW7gejQwOwXnT6wzXL/M7KqKM0pvBs
	w/X4GQBVGvfTN4ebNvT93fni/qezGm73d/Uj3S0cPlLBHKb0DkLPh9gHBIwCOfUhyapA
	6ICg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=ebKRyXZqF5QOOdGXiXodcFhJdQCCbsQF3CVKMkTwAh4=;
	b=pJRwoAFzDMzcOj0ZqWS5UR5JEllQpt1PRw6GC5AUNNg1odsjPaZFrJ0U6rWHy8Fuss
	4lfrQnCGegqFUijEijTN1Ms29MFlzA39aYp0YoQvRlUasy7crnxK1fN9tdc64psAd5BQ
	Ds4yo5pR0+fso6RlCe2AHAulK91l2nEUXOSEZzhVayepq5FPm3KMpSl27DtSrh6/8Cn1
	85sgddVvcSasaoVjD2Ee2V5DlH+9xEnPA/Wl7Pm+VdurgpfZ8Ugq+F3s8sZ9uAwGMOUm
	fkwQUlgIeZG8QHnSYjJPnUhZnafRUCulmxqWj6d1c9Ajl/VEp2nJ/Yv662GcYHWJh5Kw
	f9Uw==
X-Gm-Message-State: APjAAAV2wQu6ZV6w63GAupFhdQ2OLMG0HT6aNhcpOfydJsZT/AUpJZT2
	dTH0RGE55ji7qG2k8xP7OZOPTpcc7xzxJzhYfHoUAnTV
X-Google-Smtp-Source: APXvYqyjMDZGzgZbBaCLXdJl+JOyo4WCDsRSKd40pDRBEa0ygCOcEX9kT0MYKJrUsy2Smuh1Rej+vtaBCJURdZVBLGM=
X-Received: by 2002:a24:3610:: with SMTP id l16mr954008itl.154.1552370036383; 
	Mon, 11 Mar 2019 22:53:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAE3EOfgJdrO29GCftwORcq0087X0Y74gYtuMWvO1EWEkrT-7rg@mail.gmail.com>
	<CAAS2fgSbK=Hf7nViHScLezCAUdKkFT1MxEM4VZhZxoj990O8PQ@mail.gmail.com>
	<CAE3EOfh+mEB6P0ZO7AVs-i92Y1Fyppj+zNHGF4MbCohFCyZaSg@mail.gmail.com>
	<CAE3EOfgSEveQQesGLDAAwOgHn8+sjkzc1ayvv7ieRS19k=d63A@mail.gmail.com>
In-Reply-To: <CAE3EOfgSEveQQesGLDAAwOgHn8+sjkzc1ayvv7ieRS19k=d63A@mail.gmail.com>
From: Omar Shibli <omarshib@gmail.com>
Date: Tue, 12 Mar 2019 07:53:45 +0200
Message-ID: <CAE3EOfisNJS+xkppNvZ-LxAGzP1_aBicFwtQyZ_jS-Y1kSHdCA@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="0000000000009426a10583df50b9"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 12 Mar 2019 06:03:16 +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, 12 Mar 2019 05:53:58 -0000

--0000000000009426a10583df50b9
Content-Type: text/plain; charset="UTF-8"

Dear Gregory,

First of all, I would like to express my deep appreciation to your entire
craft in the FOSS ecosystem, specially in Bitcoin, even more In Blockstream.
I think you are a brilliant engineer and very principled leader. your
efforts are an inspiration for many, a truly enduring forever mark in
history of FOSS.

I've submitted fixes to your concerns here:
https://github.com/bitcoin/bips/commit/b63ed0e17e872b7e7b8634591b0ddfa3dedfdc73#diff-deacf3a22d788a10ce12e4d92ee814ff

Would appreciate your review.

On other note, I still think that this security fix is redundant, I believe
CKD function (BIP32) does encapsulate sufficient amount of entropy, but due
to lack of formal knowledge and assistance, I've not managed to get formal
proof, so I fallback'ed to add this patch for security reasons.

Best regards,
Omar





On Fri, Sep 1, 2017 at 10:16 AM Omar Shibli <omarshib@gmail.com> wrote:

> 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:
>>> >
>>> xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
>>> > coin type: 0
>>> > contract id: 7777777
>>> >
>>> > contract base computation :
>>> >
>>> > derivation path:
>>> > m/999'/0'/7777777'
>>> > contract base public extended key:
>>> >
>>> xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>>> >
>>> > 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:
>>> >
>>> xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>>> >
>>> > 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
>>> >
>>>
>>
>>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Dear Gregory,<div><br></=
div><div>First of all, I would like to express my deep appreciation to your=
 entire craft in the FOSS ecosystem, specially in Bitcoin, even more In Blo=
ckstream.</div><div>I think you are a brilliant engineer and very principle=
d leader. your efforts are an inspiration for many, a truly enduring foreve=
r mark in history of FOSS.</div><div><br></div><div>I&#39;ve submitted fixe=
s to your concerns here:</div><div><a href=3D"https://github.com/bitcoin/bi=
ps/commit/b63ed0e17e872b7e7b8634591b0ddfa3dedfdc73#diff-deacf3a22d788a10ce1=
2e4d92ee814ff">https://github.com/bitcoin/bips/commit/b63ed0e17e872b7e7b863=
4591b0ddfa3dedfdc73#diff-deacf3a22d788a10ce12e4d92ee814ff</a><br></div><div=
><br></div><div>Would appreciate your review.</div><div><br></div><div>On o=
ther note, I still think that this security fix is redundant, I believe CKD=
 function (BIP32) does encapsulate sufficient amount of entropy, but due to=
 lack of formal knowledge and assistance, I&#39;ve not managed to get forma=
l proof, so I fallback&#39;ed to add this patch for security=C2=A0reasons.<=
/div><div><br></div><div>Best regards,</div><div>Omar</div><div><br></div><=
div><br></div><div><br></div><div><br></div></div></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 1, 2017=
 at 10:16 AM Omar Shibli &lt;<a href=3D"mailto:omarshib@gmail.com">omarshib=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
Hello Gregory,</div><div><br></div><div>Thanks for you feedback.</div><div>=
<br></div><div>The BIP has been updated to explicitly specify the multipart=
y key derivation scheme which hopefully addresses your concerns.</div><div>=
<br></div><div>Please have a look at the updated draft of the BIP at the li=
nk below:</div><div><br></div><div><a href=3D"https://github.com/commercebl=
ock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki"=
 target=3D"_blank">https://github.com/commerceblock/pay-to-contract-protoco=
l-specification/blob/master/bip-draft.mediawiki</a></div><div><br></div><di=
v>Any feedback is highly appreciated.</div><div><br></div><div>Regards,</di=
v><div>Omar</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:omarshib@gmail.com" target=3D"_blank">omarshib@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span><div>Thank y=
ou for your time Gregory, I really appreciate that.</div><div><br></div><di=
v>What we are describing here is a method to embed cryptographic signatures=
 into a public key based on HD Wallets - BIP32.</div><div>In a practical ap=
plication, we should have two cryptographic signatures from both sides, I d=
on&#39;t think in that case your scenario would be an issue.</div><div><br>=
</div><div>More specifically in our application, we do the following constr=
uction:</div><div><br></div><div>contract base: m/200&#39;/0&#39;/&lt;contr=
act_number&gt;&#39;</div><div>payment base (merchant commitment): contract_=
base/&lt;merchant_contract_signature&gt;</div><div>payment address (custome=
r commitment): contract_base/&lt;merchant_contract_signature&gt;/&lt;custom=
er_contract_signature&gt;</div><div><br></div></span><div>payment address f=
unds could be reclaimed only if the customer_contract_signature is provided=
 by the customer.</div><span><div><br></div><div>In terms of durability, ou=
r app is pretty simple at this point, we don&#39;t store anything, we let c=
ustomer download and manage the files.</div><div><br></div></span><div>I wi=
ll update the BIP to address your concerns.</div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote"><span>On Tue, Aug 15, 2017 at 8:12 AM=
, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:greg@xiph.org" ta=
rget=3D"_blank">greg@xiph.org</a>&gt;</span> wrote:<br></span><div><div cla=
ss=3D"gmail-m_-2645249074182253397h5"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex">This construction ap=
pears to me to be completely 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"gmail-m_-2645249074182253397m_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.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_derivation_path&gt;<br>
&gt; compute address<br>
&gt; Example:<br>
&gt;<br>
&gt; master private extended key:<br>
&gt; xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ES=
u7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73<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; xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBw=
haem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE<br>
&gt;<br>
&gt; Contract content:<br>
&gt; foo<br>
&gt;<br>
&gt; Contract sha256 signature:<br>
&gt; 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae<br>
&gt;<br>
&gt; Contract partial derivation path:<br>
&gt; 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/=
63882/24200/25190/59310<br>
&gt;<br>
&gt; Contract commitment pub key path:<br>
&gt; m/999&#39;/0&#39;/7777777&#39;/11302/46187/26879/50831/63899/17724/747=
2/16692/4930/11632/25731/49056/63882/24200/25190/59310<br>
&gt; or<br>
&gt; &lt;contract_base_extended_pub_key&gt;/11302/46187/26879/50831/63899/1=
7724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310<br>
&gt;<br>
&gt; Contract commitment pub key:<br>
&gt; xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBv=
cQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS<br>
&gt;<br>
&gt; Contract commitment address:<br>
&gt; 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R<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/commerceblock/pay-to-contract-protocol-specifica=
tion/blob/master/bip-draft.mediawiki</a><br>
&gt;<br>
&gt;<br>
&gt; Regards,<br>
&gt; Omar<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.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.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</blockquote></div>

--0000000000009426a10583df50b9--