Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C3032C for ; Fri, 12 Aug 2016 15:49:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C8591F7 for ; Fri, 12 Aug 2016 15:49:26 +0000 (UTC) Received: by mail-ua0-f178.google.com with SMTP id 74so48241489uau.0 for ; Fri, 12 Aug 2016 08:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iYpwdJxfjXRfXxXAwJfzDan4cvfjPPZuv/+Prjx9vek=; b=FYw/a3UadclOvuF3zkidnACCe56K3SvkbvYa/iF9GzP8XBaA4r9xxYIiNvNe8yoVSH uT09HIG3Fz0x8de+UUslj2T6kLdqsIkBRJjro3Zmhq4u9a97wZYyMhTydOCkajZ/Lx9e jVcllyhJ04+vTPEV0VMAG0d6GjuRlSxtXm5+y12cCddx04vEqgiYZ7E2O11wtbtZQJVi h0svQ6eG9xO23t/CQaC3csKzjlxQbwnu8AaXaO6VcMsedk+ZyWZDYWy6i5ENhzuDHZa7 AxoLFn29DdWWCq/jiUnj4d3ZzdpiEIabqJ/Si1tso4XuvciR8EsyEdJtPbj2c7nRnI2y 4KOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iYpwdJxfjXRfXxXAwJfzDan4cvfjPPZuv/+Prjx9vek=; b=OLlBCByCOlwg6SxA/7sS/KlpeycgZGBdQGCE4FoHljRgyPxmeH6S5Bu0YSxUzGjMxH 6Eo1eVuU4NJrJbyJre+1dVVzS7XHepMxt5fjyleQz2TD55s0/bPO/iin5SC8rAeybQfC PbCrcIvB42hQ7KSxPrKiq3t7LljjDdYaeAGTZatz8TSZsyepmN/Vt7CZwoiGxLrxsd/8 nFwLnCC4nlbcVyh8IdO825hqTr6iY1uPX7ky/E0+t464TUw6Njiftz5G3YZ23pT5tfOh jIamzH3scTGlZk5q7E0BqoTuXRBv3JlHlFyNLP/xrqgKTM3rfFb48tOklyQAkVr7SGcV StNQ== X-Gm-Message-State: AEkoouuUDzIVUsFYyJNS1vpKBfSm4b+hN3Bb7maqZtgyKPLOQOf0g6uVr2CiFS49V4yOKkrrUbK/dBDrxHCacA== X-Received: by 10.176.83.34 with SMTP id x31mr3636907uax.85.1471016965293; Fri, 12 Aug 2016 08:49:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.155.136 with HTTP; Fri, 12 Aug 2016 08:49:23 -0700 (PDT) Received: by 10.31.155.136 with HTTP; Fri, 12 Aug 2016 08:49:23 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Fri, 12 Aug 2016 17:49:23 +0200 Message-ID: To: Erik Aronesty , Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c18fcdcacdcf70539e1d3b2 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Fri, 12 Aug 2016 15:49:30 -0000 --94eb2c18fcdcacdcf70539e1d3b2 Content-Type: text/plain; charset=UTF-8 No, anyone with the bip32 public seed can do the same as the receiver as "watch only". The only difference is rhat the receiver can actually spend the coins. As gmaxwell explained, if it's expensive for everyone, it will be also expensive for the receiver (assuming no interaction after the bip32 public seed is transfered). Something different would be to give a different bip32 public seed to each payer. That way they can simply start with zero an increment with each new payment. With those assumptions, the receiver could start listening to new addresses only after they receive something in the previous address. Probably not useful for this case, just thinking out loud about using bip32 public seeds instead of one use addresses when there's going to be several payments from the same payer to the payee. On Aug 12, 2016 2:37 PM, "Erik Aronesty via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I'm imagining a "publishable seed" such that: > > - someone can derive a random bitcoin address from it - and send funds to it. > - the possible derived address space is large enough that generating all possible addresses would be a barrier > - the receiver, however, knowing the private key, can easily scan the blockchain fairly efficiently and determine which addresses he has the keys to > - another interested party cannot easily do so > > Perhaps homomorphic encryption may need to be involved? > > > On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell wrote: >> >> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev >> wrote: >> > 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? >> >> Which would take a quad core laptop about 8 hours with competent software >> >> And presumably you're not using the whole 2^31 space else the receiver >> also has to do that computation... > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c18fcdcacdcf70539e1d3b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No, anyone with the bip32 public seed can do the same as the= receiver as "watch only". The only difference is rhat the receiv= er can actually spend the coins. As gmaxwell explained, if it's expensi= ve for everyone, it will be also expensive for the receiver (assuming no in= teraction after the bip32 public seed is transfered).

Something different would be to give a different bip32 publi= c seed to each payer.=C2=A0 That way they can simply start with zero an inc= rement with each new payment. With those assumptions, the receiver could st= art listening to new addresses only after they receive something in the pre= vious address.

Probably not useful for this case, just thinking out loud ab= out using bip32 public seeds instead of one use addresses when there's = going to be several payments from the same payer to the payee.

On Aug 12, 2016 2:37 PM, "Erik Aronesty via bitcoin-dev= " <bitcoin= -dev@lists.linuxfoundation.org> wrote:
>
> I'm imagining a "publishable seed" such that:
>
> =C2=A0- someone can derive a random bitcoin address from it -=C2=A0 an= d send funds to it.
> =C2=A0- the possible derived address space is large enough that genera= ting all possible addresses would be a barrier
> =C2=A0- the receiver, however, knowing the private key, can easily sca= n the blockchain fairly efficiently and determine which addresses he has th= e keys to
> =C2=A0- another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?=C2=A0=C2=A0 >
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg@xiph.org> wrote:
>>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>> > Still not sure how you can take a BIP32 public seed and figur= e out if an
>> > address was derived from it though.=C2=A0 =C2=A0I mean, would= n't I have to compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent s= oftware
>>
>> And presumably you're not using the whole 2^31 space else the = receiver
>> also has to do that computation...
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c18fcdcacdcf70539e1d3b2--