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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SARcG-0008ML-0l
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Mar 2012 19:54:40 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.175 as permitted sender)
client-ip=209.85.160.175; envelope-from=gmaxwell@gmail.com;
helo=mail-gy0-f175.google.com;
Received: from mail-gy0-f175.google.com ([209.85.160.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SARcC-0005ee-CV
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Mar 2012 19:54:39 +0000
Received: by ghbz2 with SMTP id z2so1629527ghb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 21 Mar 2012 12:54:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.202.66 with SMTP id fd2mr7751874qab.9.1332359670928; Wed,
21 Mar 2012 12:54:30 -0700 (PDT)
Received: by 10.229.14.211 with HTTP; Wed, 21 Mar 2012 12:54:30 -0700 (PDT)
In-Reply-To: <CACsn0cne5An+SyKDf9w4o4Secn7C9wqqbG7ff0HB3Dvk-XxHRg@mail.gmail.com>
References: <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
<CACsn0cne5An+SyKDf9w4o4Secn7C9wqqbG7ff0HB3Dvk-XxHRg@mail.gmail.com>
Date: Wed, 21 Mar 2012 15:54:30 -0400
Message-ID: <CAAS2fgRQrD0=3p2aXUpXVWV3PeWw+=Do=2CAvx1cOqwYUFrOQw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Watson Ladd <wbl@uchicago.edu>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
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.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SARcC-0005ee-CV
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: 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 19:54:40 -0000
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. 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). 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). The 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. Users validate
that their address is in the set and sign the entire set. Once all
involved users have signed, the exchange pays.
This requires no changes to the Bitcoin system and could be trivially
implemented by anyone interested. It provides anonymity which is
strong so long as any one of the mixers is uncompromised. It has very
low overhead. 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?
|
