Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A0F49E7 for ; 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 ; Tue, 12 Mar 2019 05:53:57 +0000 (UTC) Received: by mail-it1-f180.google.com with SMTP id w18so2507696itj.4 for ; 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: In-Reply-To: From: Omar Shibli Date: Tue, 12 Mar 2019 07:53:45 +0200 Message-ID: To: Gregory Maxwell 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 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: 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 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 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/ >> payment address (customer commitment): >> contract_base// >> >> 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: >>> > >>> 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 >>> > >>> /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
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 Blo= ckstream.
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.

I've submitted fixe= s to your concerns here:

Would appreciate your review.

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've not managed to get forma= l proof, so I fallback'ed to add this patch for security=C2=A0reasons.<= /div>

Best regards,
Omar

<= div>



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 multipart= y key derivation scheme which hopefully addresses your concerns.
=
Please have a look at the updated draft of the BIP at the li= nk below:


Any feedback is highly appreciated.

Regards,
Omar

On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <omarshib@gmail.com> wrote:
Thank y= ou 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 ap= plication, we should have two cryptographic signatures from both sides, I d= on't think in that case your scenario would be an issue.

=
More specifically in our application, we do the following constr= uction:

contract base: m/200'/0'/<contr= act_number>'
payment base (merchant commitment): contract_= base/<merchant_contract_signature>
payment address (custome= r commitment): contract_base/<merchant_contract_signature>/<custom= er_contract_signature>

payment address f= unds could be reclaimed only if the customer_contract_signature is provided= by the customer.

In terms of durability, ou= r app is pretty simple at this point, we don't store anything, we let c= ustomer download and manage the files.

I wi= ll update the BIP to address your concerns.

On Tue, Aug 15, 2017 at 8:12 AM= , Gregory Maxwell <greg@xiph.org> wrote:
This construction ap= pears to me to be completely 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:
> xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ES= u7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
> coin type: 0
> contract id: 7777777
>
> contract base computation :
>
> derivation path:
> m/999'/0'/7777777'
> contract base public extended key:
> xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBw= haem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>
> 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/747= 2/16692/4930/11632/25731/49056/63882/24200/25190/59310
> or
> <contract_base_extended_pub_key>/11302/46187/26879/50831/63899/1= 7724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>
> Contract commitment pub key:
> xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBv= cQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>
> Contract commitment address:
> 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
>
>
> You can find the full BIP draft in the following link:
> https://github.com/commerceblock/pay-to-contract-protocol-specifica= tion/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--