Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

From: Erik Aronesty <erik@q32•com>
To: Tier Nolan <tier.nolan@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Number Request: Addresses over Audio
Date: Thu, 11 Aug 2016 16:37:04 -0400	[thread overview]
Message-ID: <CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>

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

Can't have shared secrets or interactivity for a public address to have the
love it needs.

Still not sure how you can take a BIP32 public seed and figure out if an
address was derived from it though.   I mean, wouldn't I have to compute
all 2^31 possible public child addresses?

On Thu, Aug 11, 2016 at 11:13 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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