[bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[omar shibli]

[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3770 bytes --]

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[Gregory Maxwell]

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
>

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[omar shibli]

[-- Attachment #1: Type: text/plain, Size: 5075 bytes --]

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
> >
>

[-- Attachment #2: Type: text/html, Size: 6810 bytes --]

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[Omar Shibli]

[-- Attachment #1: Type: text/plain, Size: 5719 bytes --]

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
>> >
>>
>
>

[-- Attachment #2: Type: text/html, Size: 8022 bytes --]

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[Omar Shibli]

[-- Attachment #1: Type: text/plain, Size: 6814 bytes --]

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
>>> >
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 9643 bytes --]

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

[ZmnSCPxj]

Good morning Omar,

BIP32 includes this text:

> In case parse_256(I_L) >= n or K_i is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.

This seems to suggest that it is possible for an attacker with sufficient compute power to find two contracts whose derivations alias each other if we "proceed with the next value for i".


More generally, have you considered the possibility of multiple separate contracting systems?

It may be possible to have a particular sequence of bytes that has a valid interpretation under one contracting system, that also has a valid interpretation under another contracting system.
I bring this up here: https://github.com/rgb-org/spec/issues/61
and: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016354.html

It would then be possible to fool some victim into thinking it has committed to some innocuous contract in one contracting system, only to reveal later that the same sequence of bytes encoding that innocuous contract also corresponds to a more vicious contract in another contracting system.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, March 12, 2019 1:53 PM, Omar Shibli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> > > > >