Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1D888D80 for ; 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 ; Fri, 1 Sep 2017 07:16:43 +0000 (UTC) Received: by mail-wm0-f47.google.com with SMTP id u26so3081811wma.0 for ; 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: References: From: Omar Shibli Date: Fri, 1 Sep 2017 10:16:41 +0300 Message-ID: To: Gregory Maxwell 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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'/' > payment base (merchant commitment): contract_base/ contract_signature> > payment address (customer commitment): contract_base/ 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 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 >> 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// >> > 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 >> > /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
Hello Gregory,

Thanks for yo= u feedback.

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

Please have a look at the updated draf= t of the BIP at the link below:


Any feedback is highly appreciated.

Regards,=
Omar

On Tue, Aug 15, 2017 at 7:40 PM, omar shibli &l= t;omarshib@gmail.co= m> wrote:
=
Thank you for your time Gregory, I really appreciate = that.

What we are describing here is a method to e= mbed cryptographic signatures into a public key based on HD Wallets - BIP32= .
In a practical application, we should have two cryptographic si= gnatures from both sides, I don't think in that case your scenario woul= d be an issue.

More specifically in our applicatio= n, we do the following construction:

contract base= : m/200'/0'/<contract_number>'
payment base (me= rchant commitment): contract_base/<merchant_contract_signature><= /div>
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 simp= le 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 compl= etely insecure.


Say my pubkey (the result of the derivation path) is P.

We agree to contract C1.=C2=A0 =C2=A0A payment is made to P + G*H(C1).

But in secret, I constructed contract C2 and pubkey Q and set P =3D 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).=C2=A0 =C2=A0(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 use= s
> cleverly the homomorphic property of elliptic curve encryption system = to
> achieve it.
> Unfortunately, there is no standard specification on how to conduct su= ch
> 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, hop= efully
> this effort will result into a standard for the benefit of the communi= ty.
>
> 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 indice= s.
>
> 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. b= lake2)
> 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 w= ith
> 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:
> 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266= e7ae
>
> 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/1772= 4/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
> or
> <contract_base_extended_pub_key>/11302/46187/26879/50831/63= 899/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--