Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CCC433EE for ; Thu, 11 Aug 2016 20:37:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.161.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1783E115 for ; Thu, 11 Aug 2016 20:37:07 +0000 (UTC) Received: by mail-yw0-f177.google.com with SMTP id z8so4448582ywa.1 for ; Thu, 11 Aug 2016 13:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=8AFHAe/Z/gbMvGaVjxYpR7WcjcYycfduViJ20kKdqek=; b=EBPyS7nTxjuWpDTSEGo8lw2/vASGlgCJC6qXmfoSbR1HYgrcvFDy3/yOMGj0OiNkmf 2iWNqglXsnggg/1HjsjtvulmrnB4knnwAldXUqbaG5+DQOOPNt4kDgDgwJczTwvzQWFs 1ZeWrJbBItvhHlV+q6q+H02gUn8Y6e+NY6RX4RTIrjZFNR0I8OcDOjVwhdj11y4gPnzJ iSmrnKrRU4fCXzxD2yMLBjWgF+eTD5m/bCkr8lWcLAii+1gUmWqNw/EzuKISXHrPWM1q JD8rivU1mJifHV4NEWl8JXxao/ZM122hYiOIl1zsfgscKqgdEux3jbRs+GwyON4H3aXS wUnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=8AFHAe/Z/gbMvGaVjxYpR7WcjcYycfduViJ20kKdqek=; b=g0CJumL9PmbEFMgVro7oK/Gy1M/b+w1SBKcdT+ZF9QzmQGw6GVRkTIZqfoPV3a1gaB blwmCv8NWZISnvFHzBsa1nr4ZPZjACFMOBNikX7uN6okgky1x2rwmAfojTyKwFVgVkWS 05x0M+PMKuMVlU9wtEXI1KivGB83aE6R4ynqK3cpDz77uBFp7BUdKZNmzN6jan1a5Nj1 fJgyihT9GdSbTNV/n63ALhYOIaa25wY6pr/uJCJTcLQXtppiRRJBrnEEYuIGuGmEI/Cm 5IUanBK7oZzPn4SKgiGFIEAC6as9++tt6gl8e5wSyWjhA7tY71sjG1gCOwF9F/uNJlSv +zKA== X-Gm-Message-State: AEkooutpiWldgG5x5f5KrL8PPsflceLvrjkCeLXPYTTSiH3xFAk7ZEPIDY8OI7ohx4/aBRGYvPQyD+4OQ8t/Rw== X-Received: by 10.129.83.193 with SMTP id h184mr8848108ywb.52.1470947826336; Thu, 11 Aug 2016 13:37:06 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.37.88.214 with HTTP; Thu, 11 Aug 2016 13:37:04 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Thu, 11 Aug 2016 16:37:04 -0400 X-Google-Sender-Auth: OS8SHIbBNLruJyog51s8Xwk564U Message-ID: To: Tier Nolan , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114d6f1cac09190539d1badc X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP Number Request: Addresses over Audio X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 20:37:07 -0000 --001a114d6f1cac09190539d1badc Content-Type: text/plain; charset=UTF-8 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 > > DROP DUP HASH160 > 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 > > --001a114d6f1cac09190539d1badc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can't have shared secrets or interactiv= ity for a public address to have the love it needs.=C2=A0

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





On Thu, Aug 11, 2016 at 11:13 AM, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Thu, Aug 1= 1, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:
Sorr, I thought= there was some BIP for a public seed such that someone can generate new ra= ndom addresses, but cannot trivially verify whether an address was derived = from the seed.

If you take a public key an= d multiply it by k, then the recipient can work out the private key by mult= iplying their master private key by k.=C2=A0

If k is random, t= hen the recipient wouldn't be able to work it out, but if it is non-ran= dom, then everyone else can work it out.=C2=A0 You need some way to get k t= o 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 script= PubKey (or the more socially conscientious option, an OP_RETURN).

The address would indicate the master public key.

master_pu= blic =3D master_private * G

The transaction co= ntains k*G.

Both sides can compute the shared secret.
=
secret =3D k*master_private*G =3D 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.=C2=A0 You have to check every transaction output = to see if it is the given template.=C2=A0 Then you have to do an ECC multip= ly 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 publ= ic key hash in the output.=C2=A0

This is approx one ECC multiply pe= r output and is similar CPU load to what you would need to do to actually v= erify a block.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a114d6f1cac09190539d1badc--