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