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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <watsonbladd@gmail.com>) id 1S54xs-0003qU-6B
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Mar 2012 00:42:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.46 as permitted sender)
client-ip=209.85.210.46; envelope-from=watsonbladd@gmail.com;
helo=mail-pz0-f46.google.com;
Received: from mail-pz0-f46.google.com ([209.85.210.46])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1S54xr-00042U-AN
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Mar 2012 00:42:48 +0000
Received: by dajr28 with SMTP id r28so8606251daj.33
for <bitcoin-development@lists.sourceforge.net>;
Tue, 06 Mar 2012 16:42:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.189.5 with SMTP id ge5mr914798pbc.50.1331080961195; Tue, 06
Mar 2012 16:42:41 -0800 (PST)
Sender: watsonbladd@gmail.com
Received: by 10.142.153.8 with HTTP; Tue, 6 Mar 2012 16:42:41 -0800 (PST)
In-Reply-To: <CAAS2fgSHsuhHOXXdAvgLZqF7ozLrzu-2wDikVxd0z6bPiCo+Hg@mail.gmail.com>
References: <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
<CACsn0cne5An+SyKDf9w4o4Secn7C9wqqbG7ff0HB3Dvk-XxHRg@mail.gmail.com>
<CAAS2fgSHsuhHOXXdAvgLZqF7ozLrzu-2wDikVxd0z6bPiCo+Hg@mail.gmail.com>
Date: Tue, 6 Mar 2012 18:42:41 -0600
X-Google-Sender-Auth: sDI1ECVN6Q-p38uR0D1g36r_znY
Message-ID: <CACsn0cm6wgPdNvVr6Q4yS+cGP-kpUJxtXsL1mZS502UTOx8t0g@mail.gmail.com>
From: Watson Ladd <wbl@uchicago.edu>
To: Gregory Maxwell <gmaxwell@gmail.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
(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: 1S54xr-00042U-AN
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, 07 Mar 2012 00:42:48 -0000
On Tue, Mar 6, 2012 at 6:05 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago.edu> wrote:
>> 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.
>
> I believe I understand what the opcode does directly=E2=80=94 it just
> validates an opaque signautre. I don't understand how it enables
> anonymous transactions.
>
> Can you spell this out for me?
One doesn't use this opcode as the sole thing to secure a transaction.
Instead this opcode prevents double spend attacks against
anonymization schemes. The idea is for Alice to give signatures to the
recipients of funds, all signatures being equivalent. To avoid this
from leading to a double-spend, we use a quorum method based on
showing earlier redemptions happened.
>
> In particular I don't see why it is not, from the perspective of the
> blockchain, isomorphic to a hash locked transaction. =C2=A0 (This
> equivalence is more obvious when you think about how lamport
> signtures turn simple hashing into a one time signature).
Because you can't blind a lamport signature, it isn't. I'm searching
for a place to post the current draft: it's not ready for anything
official yet, but does seem to be of interest. Drop me a (offlist)line
if you have ideas about where I can put it.
Sincerely,
Watson Ladd
--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin
|
