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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 07A8F71
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Aug 2016 15:13:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
[209.85.220.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80714226
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Aug 2016 15:13:21 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id l2so7302249qkf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Aug 2016 08:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=w4h+Z0gxosXdak4E5151fNCMxkmf4qtYhy5cJKxp8Co=;
b=hD7NpU3xczn4LlE6B3z2Wy43I1lrI7d/w/g/lnU6ryGm53tBcCXyW2z2DKfNfQEQay
aRC2DBOPzknpeWFAGU5hMH84lK81R2goMjMMJPsHMVsa0TudMKOZHD3wnAaetlJdEOus
YMOsrFg3tAhPzMOjDOZydL2Wun4GHv6Y8Zl4oHUlJ4P7UNatyqDCNEELqshXKX3E3mMx
YyS77C2eQdDKKF2YV9cBG6fwD04/Ym3FVSS/KqY3v3I7WllxYRHSpKQORE4I6e7AhfeT
wnB/M+XtDXetSg0hHvfzZksIVuJquDzNXLMke7mb6NsjdBqxDwo9Ac772tvYJS1HkAv9
PEEg==
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;
bh=w4h+Z0gxosXdak4E5151fNCMxkmf4qtYhy5cJKxp8Co=;
b=C3axKyPQpjFnOXGAK+EVXOy0NwIAG39CNempupKYj8ofIiawJEz9c06STWwX/mdsxs
gPxFXq4v12D5y50ucUU/LxduQhD86yBkrNpv6cnrVHHbuDO7UN+/20QkuxtYKPt6LaPS
zSadNDhalbiDqWum2RV/Vesu+rbLS+HiNoYz/Rwv0AhnIYRS63BNp422sMgzyEVqmfXn
zkbouKi2RdGpNFSadIK6XS1AVQXgpSs3frdaggbLJdn5+Yg6ZirTiIJpRF45/YRBibXm
MsU61YaMtxMOCGgkMVQ0+Sai/1GpPtNKC0NkjzYLVqw74JVWrFgT6dtwapPB8mGhdpCl
+EdQ==
X-Gm-Message-State: AEkoousAWGHRyUUK5+WVJuo0YDGQ8CrgcSAiQAo5Ojq2MbHeyQkDEzOxnBSJ0Quj+vaOT4mtKbPpU72I8O9Y1w==
X-Received: by 10.55.133.197 with SMTP id h188mr11204887qkd.58.1470928400493;
Thu, 11 Aug 2016 08:13:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.193 with HTTP; Thu, 11 Aug 2016 08:13:19 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Thu, 11 Aug 2016 15:13:22 -0000
--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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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'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><encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub =
key))> 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--
|
