1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C3032C
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Aug 2016 15:49:26 +0000 (UTC)
Received: by mail-ua0-f178.google.com with SMTP id 74so48241489uau.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@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>
<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
<CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
<CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>
<CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 12 Aug 2016 17:49:23 +0200
Message-ID: <CABm2gDrBcq5Eipq1Rhq2sap=yKd_gWFtvQAB1Smc13DkNM9EUw@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <greg@xiph.org> wrote:
>>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> 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
<p dir=3D"ltr">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).</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">On Aug 12, 2016 2:37 PM, "Erik Aronesty via bitcoin-dev=
" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>> wrote:<br>
><br>
> I'm imagining a "publishable seed" such that:<br>
><br>
> =C2=A0- someone can derive a random bitcoin address from it -=C2=A0 an=
d send funds to it. <br>
> =C2=A0- the possible derived address space is large enough that genera=
ting all possible addresses would be a barrier<br>
> =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<br>
> =C2=A0- another interested party cannot easily do so<br>
><br>
> Perhaps homomorphic encryption may need to be involved?=C2=A0=C2=A0 <b=
r>
><br>
><br>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <<a href=3D"mailto=
:greg@xiph.org">greg@xiph.org</a>> wrote:<br>
>><br>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br>
>> > Still not sure how you can take a BIP32 public seed and figur=
e out if an<br>
>> > address was derived from it though.=C2=A0 =C2=A0I mean, would=
n't I have to compute all<br>
>> > 2^31 possible public child addresses?<br>
>><br>
>> Which would take a quad core laptop about 8 hours with competent s=
oftware<br>
>><br>
>> And presumably you're not using the whole 2^31 space else the =
receiver<br>
>> also has to do that computation...<br>
><br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
></p>
--94eb2c18fcdcacdcf70539e1d3b2--
|
