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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UcnAs-0006LS-4Q
for bitcoin-development@lists.sourceforge.net;
Thu, 16 May 2013 01:40:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.179 as permitted sender)
client-ip=209.85.217.179; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f179.google.com;
Received: from mail-lb0-f179.google.com ([209.85.217.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UcnAr-0008OI-EW
for bitcoin-development@lists.sourceforge.net;
Thu, 16 May 2013 01:40:06 +0000
Received: by mail-lb0-f179.google.com with SMTP id d10so2578402lbj.38
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 May 2013 18:39:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.185.67 with SMTP id fa3mr15100733lbc.118.1368668398697;
Wed, 15 May 2013 18:39:58 -0700 (PDT)
Received: by 10.112.71.97 with HTTP; Wed, 15 May 2013 18:39:58 -0700 (PDT)
In-Reply-To: <BF1C6C71-9EE5-4A2F-8B73-3E8F934A7CAE@gmail.com>
References: <20130514115151.GA21600@netbook.cypherspace.org>
<20130514140902.GA22447@netbook.cypherspace.org>
<20130515102509.GA3401@netbook.cypherspace.org>
<20130515111906.GA26020@savin>
<20130515114956.GA5863@netbook.cypherspace.org>
<5193825B.20909@lavabit.com>
<20130515162129.GB6156@netbook.cypherspace.org>
<20130515234030.GA17920@netbook.cypherspace.org>
<BF1C6C71-9EE5-4A2F-8B73-3E8F934A7CAE@gmail.com>
Date: Wed, 15 May 2013 18:39:58 -0700
Message-ID: <CAAS2fgQP6mFb0izQxZcBwqBWdxKUiAy1sG23ScAZ+tEMvGU0WQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
X-Headers-End: 1UcnAr-0008OI-EW
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger
byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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, 16 May 2013 01:40:06 -0000
On Wed, May 15, 2013 at 6:24 PM, Gavin <gavinandresen@gmail.com> wrote:
> Busy with pre-conference stuff, not following details of this conversatio=
n...
>
> ... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking=
about a year or so ago.
Sort of, but in a guy fawkes signature you use the commitment to hide
the preimage that proves you had authority to spend a coin. Adam
proposes you do this in order to hide _which coin you're spending_.
This has obvious anti-DOS complications, but Adam deftly dodged my
initial attempts to shoot him down on these grounds by pointing out
that you could mix blinded and blinded inputs and have priority and
transaction fees come from only the unblinded ones.
Effectively, it means that so long as you could convince the network
to let you spend some coins, you could also spend other ones along for
the ride and the network wouldn't know which ones those were until it
was too late for it to pretend it never saw them.
I think there are all kinds of weird economic implications to this=E2=80=94=
a
blinded payment would seem to have a different utility level to an
unblinded one: you can't use it for fees=E2=80=94 except you can unblind it=
at
any time. And the discontinuousness ("two types of inputs") and that
it would enable mining gibberish (though perhaps not data storage, if
you see my preimage solution to that) seems awkward and I think I have
to spend some time internalizing it before I can really think through
the implications.
|
