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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1RJ44n-0004Pm-PR
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Oct 2011 14:03:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.182 as permitted sender)
client-ip=209.85.216.182; envelope-from=gmaxwell@gmail.com;
helo=mail-qy0-f182.google.com;
Received: from mail-qy0-f182.google.com ([209.85.216.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RJ44j-00030O-V2
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Oct 2011 14:03:29 +0000
Received: by qyg14 with SMTP id 14so2156746qyg.13
for <bitcoin-development@lists.sourceforge.net>;
Wed, 26 Oct 2011 07:03:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.3.141 with SMTP id 13mr1332955qcn.147.1319637800518; Wed,
26 Oct 2011 07:03:20 -0700 (PDT)
Received: by 10.229.21.135 with HTTP; Wed, 26 Oct 2011 07:03:20 -0700 (PDT)
In-Reply-To: <7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com>
References: <CANEZrP1ic4RXFzoqf66MGv=rJe3MgWxVi5nnk2VKkMc4VMCDyw@mail.gmail.com>
<CABsx9T3WKv3RLWT+Q6s7cCLzDL3sVRCWfmPiKcSp=_Re05m+zQ@mail.gmail.com>
<CAAS2fgSYwUdiyY2XfHhWn+aN_6a72XRKs-8W7ibZM5t0tZ28rg@mail.gmail.com>
<CALf2ePy=3N1JQodP3s9PzH=Af1z-7qGdy_4=QW9-CJmaxYGz5Q@mail.gmail.com>
<7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com>
Date: Wed, 26 Oct 2011 10:03:20 -0400
Message-ID: <CAAS2fgTx8gEztUt-UrDObMCQtfdzZc52fzS6c1q8mm+a-TjwjQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= <gronager@ceptacle.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RJ44j-00030O-V2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are
to you
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2011 14:03:29 -0000
On Wed, Oct 26, 2011 at 4:58 AM, Michael Gr=C3=B8nager <gronager@ceptacle.c=
om> wrote:
> I think it is a very important feature to be able to extract transaction =
to/from you only from your private keys. In the standard transactions this =
is easily accomplished - in the case you only want to find the addr to tx m=
apping:
The additional material _IS_ then part of the private key. It's not
something seperate. Its something you need to know in order to author
the address. This was fundamentally my argument. Not that you could
hide information, but that information was already hidden.
Right now under conventional uses I can't identify all the
transactions that land in your wallet, because I don't know the keys
it contains. With the proposal it's the same situation.
> This possibility is used today in:
> * blockexplorer
> * bitcoin-js
> * my own tiered implementation for thin clients
[snip]
> So, if we introduce a standard (multikey) payment that hides the address =
(or makes it overly complicated to extract it) it will be a major problem f=
or the projects that I listed above.
These projects will be able to use the _same_ procedure to extract the
identifying information. Except now instead of
ripemd160(sha256(pubkey)) it will be more like ripemd160(sha256([some
extra bytes generated by the wallet holder]||pubkey)) that you
extract. If the former is not a problem for these applications, why
is the latter?
|
