Date: Tue, 12 Mar 2019 07:05:37 +0000
To: Omar Shibli <omarshib@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <SkOWAXn3N6gldZ75_ilatRtYejTWfdra7MltS567InRXSy__m-PV0I4j2zYYfA3-7FqeqeM5IlwOegyn_AiUmXvhyy6v8HSuWO7HcU8q7SQ=@protonmail.com>
In-Reply-To: <CAE3EOfisNJS+xkppNvZ-LxAGzP1_aBicFwtQyZ_jS-Y1kSHdCA@mail.gmail.com>
References: <CAE3EOfgJdrO29GCftwORcq0087X0Y74gYtuMWvO1EWEkrT-7rg@mail.gmail.com>
	<CAAS2fgSbK=Hf7nViHScLezCAUdKkFT1MxEM4VZhZxoj990O8PQ@mail.gmail.com>
	<CAE3EOfh+mEB6P0ZO7AVs-i92Y1Fyppj+zNHGF4MbCohFCyZaSg@mail.gmail.com>
	<CAE3EOfgSEveQQesGLDAAwOgHn8+sjkzc1ayvv7ieRS19k=d63A@mail.gmail.com>
	<CAE3EOfisNJS+xkppNvZ-LxAGzP1_aBicFwtQyZ_jS-Y1kSHdCA@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application
Precedence: list

Good morning Omar,

BIP32 includes this text:

> In case parse_256(I_L) >=3D n or K_i is the point at infinity, the result=
ing 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 c=
ompute 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 co=
ntracting 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 interpre=
tation 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 committe=
d to some innocuous contract in one contracting system, only to reveal late=
r that the same sequence of bytes encoding that innocuous contract also cor=
responds to a more vicious contract in another contracting system.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Tuesday, March 12, 2019 1:53 PM, Omar Shibli via bitcoin-dev <bitcoin-de=
v@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 Blockstrea=
m.
> I think you are a brilliant engineer and very principled leader. your eff=
orts 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/b63ed0e17e872b7e7b8634591b0ddfa3de=
dfdc73#diff-deacf3a22d788a10ce12e4d92ee814ff
>
> Would appreciate your review.
>
> On other note, I still think that this security fix is redundant, I belie=
ve CKD function (BIP32) does encapsulate sufficient amount of entropy, but =
due to lack of formal knowledge and assistance, I've not managed to get for=
mal proof, so I fallback'ed to add this patch for security=C2=A0reasons.
>
> 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 deriv=
ation 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 signat=
ures into a public key based on HD Wallets - BIP32.
> > > In a practical application, we should have two cryptographic signatur=
es from both sides, I don't think in that case your scenario would be an is=
sue.
> > >
> > > More specifically in our application, we do the following constructio=
n:
> > >
> > > contract base: m/200'/0'/<contract_number>'
> > > payment base (merchant commitment): contract_base/<merchant_contract_=
signature>
> > > payment address (customer commitment): contract_base/<merchant_contra=
ct_signature>/<customer_contract_signature>
> > >
> > > payment address funds could be reclaimed only if the customer_contrac=
t_signature is provided by the customer.
> > >
> > > In terms of durability, our app is pretty simple at this point, we do=
n'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> wrot=
e:
> > >
> > > > 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.=C2=A0 =C2=A0A payment is made to P + G*H(C=
1).
> > > >
> > > > 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 asse=
rt
> > > > 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 miss=
ing 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 yo=
u
> > > > 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 i=
t uses
> > > > > cleverly the homomorphic property of elliptic curve encryption sy=
stem to
> > > > > achieve it.
> > > > > Unfortunately, there is no standard specification on how to condu=
ct such
> > > > > transactions in the cyberspace.
> > > > >
> > > > > We have developed a basic trade finance application that relies o=
n the
> > > > > original idea described in the Homomorphic Payment Addresses and =
the
> > > > > Pay-to-Contract Protocol paper, yet we have generalized it and ma=
de 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 co=
mmunity.
> > > > >
> > > > > 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 i=
ndices.
> > > > >
> > > > > 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 ste=
p 2 with
> > > > > contract base:
> > > > > m/<contract_base>/<hash_derivation_path>
> > > > > compute address
> > > > > Example:
> > > > >
> > > > > master private extended key:
> > > > > xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ=
8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
> > > > > coin type: 0
> > > > > contract id: 7777777
> > > > >
> > > > > contract base computation :
> > > > >
> > > > > derivation path:
> > > > > m/999'/0'/7777777'
> > > > > contract base public extended key:
> > > > > xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2H=
ynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
> > > > >
> > > > > Contract content:
> > > > > foo
> > > > >
> > > > > Contract sha256 signature:
> > > > > 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
> > > > >
> > > > > Contract partial derivation path:
> > > > > 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/4=
9056/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/17=
724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
> > > > >
> > > > > Contract commitment pub key:
> > > > > xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmR=
m4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
> > > > >
> > > > > Contract commitment address:
> > > > > 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
> > > > >
> > > > >
> > > > > You can find the full BIP draft in the following link:
> > > > > https://github.com/commerceblock/pay-to-contract-protocol-specifi=
cation/blob/master/bip-draft.mediawiki
> > > > >
> > > > >
> > > > > Regards,
> > > > > Omar
> > > > >
> > > > > _______________________________________________
> > > > > bitcoin-dev mailing list
> > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > >