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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <calebdelisle@lavabit.com>) id 1Ucr7T-0006BE-3g
for bitcoin-development@lists.sourceforge.net;
Thu, 16 May 2013 05:52:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of lavabit.com
designates 72.249.41.33 as permitted sender)
client-ip=72.249.41.33; envelope-from=calebdelisle@lavabit.com;
helo=karen.lavabit.com;
Received: from karen.lavabit.com ([72.249.41.33])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Ucr7Q-0004Rc-ON for bitcoin-development@lists.sourceforge.net;
Thu, 16 May 2013 05:52:50 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id 6CBD711BDE3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 16 May 2013 00:52:43 -0500 (CDT)
Received: from 192.168.1.3 (c-174-62-136-247.hsd1.ct.comcast.net
[174.62.136.247]) by lavabit.com with ESMTP id 7IAKPAQ0Y78Z
for <bitcoin-development@lists.sourceforge.net>;
Thu, 16 May 2013 00:52:43 -0500
Message-ID: <51947429.8010100@lavabit.com>
Date: Thu, 16 May 2013 01:52:41 -0400
From: Caleb James DeLisle <calebdelisle@lavabit.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
<CAAS2fgQP6mFb0izQxZcBwqBWdxKUiAy1sG23ScAZ+tEMvGU0WQ@mail.gmail.com>
<CANEZrP2dFi-3nZhYpaA9RfJ8N2e-GQ_YQtKMdnFfPx-9YLU6MA@mail.gmail.com>
<CAAS2fgQQk0Lhmon4FxK7NATDVkaY13DBmJgQk4riJLE1h_Ak0w@mail.gmail.com>
In-Reply-To: <CAAS2fgQQk0Lhmon4FxK7NATDVkaY13DBmJgQk4riJLE1h_Ak0w@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
2.1 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [72.249.41.33 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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: 1Ucr7Q-0004Rc-ON
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 05:52:51 -0000
Not only does the size of the proof grow endlessly as the coin is
passed around, the size of the UTXO set grows endlessly as more and
more of the already spent coins cannot be proven to have been spent
because the proofs are passed out-of-band. I never said the idea was
good, just interesting :)
Thanks,
Caleb
On 05/15/2013 10:45 PM, Gregory Maxwell wrote:
> On Wed, May 15, 2013 at 7:22 PM, Mike Hearn <mike@plan99.net> wrote:
>> Conceptually it sounds a lot like ZeroCoin (not in implementation)?
>
> Zerocoin conceals the connection from everyone forever, assuming the
> underlying trapdoor problem is computational infeasible, but at great
> cost.
>
> Adamcoin, depending on how its done, at most conceals the transactions
> from people who aren't a party to them... though as time goes on
> eventually everyone becomes a party to a sufficiently old coin, and
> avoiding publication creates quadratic costs in evaluating a private
> clique's claims.... so instead an implementation would make the
> identities public but only once they're burred a bit.
>
> Perhaps an extreme version of the idea is easier to understand. Ignore
> DOS attacks for a moment and pretend there is never any address reuse:
>
> Everyone creates txouts paying a P2SH addresses that have a OP_PUSH
> nonce in them and tell you recipient the nonce out of band.
>
> When the recipients spend those coins they provide the script but not the nonce.
>
> The recipient knows what coins he's spending, but the public does not.
>
> The public can tell there is no double spend though, because they'd
> see the same script twice. The person he's paying may be skeptical
> that he actually has any coin and didn't just mine some gibberish, but
> our spender tells that their receiver the nonce, and that person can
> see the coin available for spending in the chain and also see that
> there are no double spends.
>
> This could actually go on forever with no ambiguity over who owns
> what, but the out of band proofs that you have to give people when you
> spend coins would grow with the history of the coins.
>
> Since there wouldn't be much privacy once a transaction was
> sufficiently split up in any case, you instead just publish the
> unblindings once transactions are sufficiently buried. Thus bounding
> the growth of the proofs. The reason I say I need to internalize
> this more is mostly that I need to think about attacks on the
> publication for 'tained' transactions being more or less isomorphic
> to just refusing to allow spending of the 'tainted' coins in any case.
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
