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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SAWDX-0001Tt-19
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Mar 2012 00:49:27 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.54 as permitted sender)
client-ip=209.85.216.54; envelope-from=gmaxwell@gmail.com;
helo=mail-qa0-f54.google.com;
Received: from mail-qa0-f54.google.com ([209.85.216.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SAWDW-0003uE-9l
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Mar 2012 00:49:26 +0000
Received: by qao25 with SMTP id 25so42628qao.13
for <bitcoin-development@lists.sourceforge.net>;
Wed, 21 Mar 2012 17:49:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.202.66 with SMTP id fd2mr8777961qab.9.1332377360845; Wed,
21 Mar 2012 17:49:20 -0700 (PDT)
Received: by 10.229.14.211 with HTTP; Wed, 21 Mar 2012 17:49:20 -0700 (PDT)
In-Reply-To: <CACsn0cn70Kj+HbhNHEJtdbNSFQM_aeUWJ=dc+gDjpseRivT-qg@mail.gmail.com>
References: <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
<CACsn0cne5An+SyKDf9w4o4Secn7C9wqqbG7ff0HB3Dvk-XxHRg@mail.gmail.com>
<CAAS2fgRQrD0=3p2aXUpXVWV3PeWw+=Do=2CAvx1cOqwYUFrOQw@mail.gmail.com>
<CACsn0cmfwuBpFTTMZ9psOoTKb3ovmAdb=VTSYQ7LJaf8+YzTUg@mail.gmail.com>
<CACsn0cn70Kj+HbhNHEJtdbNSFQM_aeUWJ=dc+gDjpseRivT-qg@mail.gmail.com>
Date: Wed, 21 Mar 2012 20:49:20 -0400
Message-ID: <CAAS2fgT1ZkGYx8y48SMSApMMYfaOOLwjsC-q0fTXGs1KHUfRMQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Watson Ladd <wbl@uchicago.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
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.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SAWDW-0003uE-9l
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal for a new opcode
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: Thu, 22 Mar 2012 00:49:27 -0000
On Wed, Mar 21, 2012 at 6:02 PM, Watson Ladd <wbl@uchicago.edu> wrote:
> -My protocol works, your's doesn't. It's not enough to have a mix, the
> mix needs to be verifiable to avoid
> one of the mixers inserting their own key and removing a key that
> should be in there. That doesn't mean you can't make your protocol
> work with some more magic, but magic is required.
If the final step fails (someone says their address is missing) you
challenge the mixes to disclose half of their correspondences. You can
then prove which (if any) mixes defected.
Why I didn't bother elaborating is ... I think you can even avoid the
fancy protocol where you must take care to only disclose alternating
halves at each mix because the addresses are throwaway: If the it
fails in the final stage everyone publishes _everything_ and the
cheater is instantly and provably identified and can be excluded from
the next attempt which is then performed using totally new addresses
and the disclosed addresses are never used. Care would need to be
taken to avoid fake-failures (e.g. the exchange says 'it fails'
triggering disclosure then sending anyways=E2=80=94 but the participants co=
uld
prove this cheating and stop using the exchange), I think there isn't
much risk there if the participants are themselves the mixes. I need
to think this through a bit more.
[snip]
> On a related note, private keys and signatures have better proofs of
> knowledge then hashes. Has this been considered in the P2SH
> conversation? There might be ways to use this to make even better
> methods for enhancing anonymity.
It's not something I thought about=E2=80=94 In general the P2SH tends to be
a superset of other schemes, e.g. you can do a signature to prove you
access to a private key, then you can show someone a script using that
key to show control of a P2SH address.
There are lot of interesting things you can do with bitcoin if you can
construct (potentially interactive) proofs for knowing the preimages of has=
hes.
|
