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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <watsonbladd@gmail.com>) id 1SATcL-0008TM-7Z
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Mar 2012 22:02:53 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=watsonbladd@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SATcK-00065H-I3
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Mar 2012 22:02:53 +0000
Received: by pbcum15 with SMTP id um15so1238603pbc.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 21 Mar 2012 15:02:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.218.134 with SMTP id pg6mr14788880pbc.111.1332367366655;
Wed, 21 Mar 2012 15:02:46 -0700 (PDT)
Sender: watsonbladd@gmail.com
Received: by 10.142.58.3 with HTTP; Wed, 21 Mar 2012 15:02:46 -0700 (PDT)
In-Reply-To: <CACsn0cmfwuBpFTTMZ9psOoTKb3ovmAdb=VTSYQ7LJaf8+YzTUg@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>
Date: Wed, 21 Mar 2012 18:02:46 -0400
X-Google-Sender-Auth: dTF0OyeFjy9QgNQRE8vakUM7uQU
Message-ID: <CACsn0cn70Kj+HbhNHEJtdbNSFQM_aeUWJ=dc+gDjpseRivT-qg@mail.gmail.com>
From: Watson Ladd <wbl@uchicago.edu>
To: bitcoin-development@lists.sourceforge.net
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
(watsonbladd[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
X-Headers-End: 1SATcK-00065H-I3
Subject: [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: Wed, 21 Mar 2012 22:02:53 -0000
On Wed, Mar 21, 2012 at 3:54 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote=
:
> On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago.edu> wrote:
>> Dear all,
>> I am proposing a new opcode for the purposes of anonymous
>> transactions. This new opcode enables scripts to be given proof that
>> the receiver can carry out or has carried out a previous transaction.
>> I'm currently working on a paper that discusses using this opcode for
>> anonymous transactions.
>
>
> Here is an alternative protocol:
>
>
> N parties wish to purchase equal amounts of Bitcoin without the
> exchange being able to link their future transactions, they each put
> the relevant amount of gold/whatever up at the exchange.
>
> The exchange provides the exchanges public key, and the user provides
> a public key for signing. =C2=A0 Externally the N participants agree on a
> collection of non-cooperating mixers (the mixers may actually just be
> the participants themselves, independent third parties, etc). =C2=A0 Each
> participant generates a new bitcoin address, and encrypts it with the
> the public keys of the the exchange and all the mixers using an
> appropriate communicative homorophic scheme (or just a layers stack of
> regular encryption keys). =C2=A0The participants then combine their
> encrypted addresess into a block and hand it off to the mixing chain.
> Each mixer randomizes the order and decrypts all the messages with its
> key.
>
> At the end of the chain the exchange does the final decryption and
> presents a list of addresses to the involved users. =C2=A0Users validate
> that their address is in the set and sign the entire set. =C2=A0Once all
> involved users have signed, the exchange pays.
>
>
> This requires no changes to the Bitcoin system and could be trivially
> implemented by anyone interested. =C2=A0It provides anonymity which is
> strong so long as any one of the mixers is uncompromised. =C2=A0It has ve=
ry
> low overhead. =C2=A0 It is not directly resistant to disruption, but if
> participation in an identified round requires a key provided by the
> exchange, abusive users can be detected and excluded.
>
> Have I explained this clearly enough? I could probably implement the
> whole system it if its unclear.
>
> Can you contrast this with your proposal for me?
Contrasts
-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.
-You need a lot of online computation: the recipients need to be
involved with validating the mix. By contrast in mine you need to wait for
enough people to get their bitcoins to avoid partitioning. But this
might be a strength,
not a weakness.
-You avoid the problem of de-anonymizing through having the protocol
run incompletely: if the permutation is correctly computed the
transaction goes through.
-You also avoid all the problems with modifications to the bitcoin
clients and miners.
It's definitely a good alternative, once you fix the problem in 1.
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.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin
--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin
|
