MIME-Version: 1.0
In-Reply-To: <CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Thu, 11 Aug 2016 16:13:19 +0100
Message-ID: <CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c072efecd38330539cd3424
Subject: Re: [bitcoin-dev] BIP Number Request: Addresses over Audio
Precedence: list

--94eb2c072efecd38330539cd3424
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Sorr, I thought there was some BIP for a public seed such that someone can
> generate new random addresses, but cannot trivially verify whether an
> address was derived from the seed.
>

If you take a public key and multiply it by k, then the recipient can work
out the private key by multiplying their master private key by k.

If k is random, then the recipient wouldn't be able to work it out, but if
it is non-random, then everyone else can work it out.  You need some way to
get k to the recipient without others figuring it out.

This means either the system is interactive or you use a shared secret.

The info about the shared secret is included in the scriptPubKey (or the
more socially conscientious option, an OP_RETURN).

The address would indicate the master public key.

master_public = master_private * G

The transaction contains k*G.

Both sides can compute the shared secret.

secret = k*master_private*G = master_private*k*G

<encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub key))>
EQUALVERIFY CHECKSIG

This adds 34 bytes to the scriptPubKey.

This is pretty heavy for scanning for transactions sent to you.  You have
to check every transaction output to see if it is the given template.  Then
you have to do an ECC multiply to compute the shared secret.  Once you have
the shared secret, you need to do an ECC addition and a hash to figure out
if it matches the public key hash in the output.

This is approx one ECC multiply per output and is similar CPU load to what
you would need to do to actually verify a block.

--94eb2c072efecd38330539cd3424
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin=
-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</s=
pan> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Sorr, I though=
t there was some BIP for a public seed such that someone can generate new r=
andom addresses, but cannot trivially verify whether an address was derived=
 from the seed.<br></div></blockquote><br>If you take a public key and mult=
iply it by k, then the recipient can work out the private key by multiplyin=
g their master private key by k.=C2=A0 <br><br><div>If k is random, then th=
e recipient wouldn&#39;t be able to work it out, but if it is non-random, t=
hen everyone else can work it out.=C2=A0 You need some way to get k to the =
recipient without others figuring it out.<br><div><br></div><div>This means=
 either the system is interactive or you use a shared secret.<br></div><br>=
</div><div>The info about the shared secret is included in the scriptPubKey=
 (or the more socially conscientious option, an OP_RETURN).<br><br></div><d=
iv>The address would indicate the master public key.<br><br>master_public =
=3D master_private * G<br></div><div><br></div><div>The transaction contain=
s k*G.<br><br></div><div>Both sides can compute the shared secret.<br><br>s=
ecret =3D k*master_private*G =3D master_private*k*G<br></div><div><br></div=
><div>&lt;encode(k*G)&gt; DROP DUP HASH160 &lt;hash160(encode(secret + pub =
key))&gt; EQUALVERIFY CHECKSIG<br><br></div><div>This adds 34 bytes to the =
scriptPubKey.<br><br></div><div>This is pretty heavy for scanning for trans=
actions sent to you.=C2=A0 You have to check every transaction output to se=
e if it is the given template.=C2=A0 Then you have to do an ECC multiply to=
 compute the shared secret.=C2=A0 Once you have the shared secret, you need=
 to do an ECC addition and a hash to figure out if it matches the public ke=
y hash in the output.=C2=A0 <br><br>This is approx one ECC multiply per out=
put and is similar CPU load to what you would need to do to actually verify=
 a block.<br></div><div></div></div></div></div>

--94eb2c072efecd38330539cd3424--