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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1W3rXV-00044o-PG
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 18:19:37 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W3rXR-0005YO-Fu for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 18:19:37 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Thu, 16 Jan 2014 12:19:26 -0600
id 000000000006A33E.0000000052D822AE.00006532
Date: Thu, 16 Jan 2014 12:19:26 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20140116181925.GB3180@nl.grid.coop>
References: <20140113133746.GI38964@giles.gnomon.org.uk>
<CANEZrP1KAVhi_-cxCYe0rR9LUSYJ8MyW8=6eSJZ65FeY5ZJNuQ@mail.gmail.com>
<20140114225321.GT38964@giles.gnomon.org.uk>
<CANAnSg0tH_bK_19rsRRHOeZgrGYeWMhW89fXPyS4DQGmS4r_7A@mail.gmail.com>
<CALimQCXgc0eXeOcqFGUaCpSF7gKEe87KzvLqHZwUysV3WyjjGw@mail.gmail.com>
<CAAS2fgShChAQryfUOBp60jB-zxn2tH986fu1HfT+LsNdBYnoYg@mail.gmail.com>
<CAJHLa0P5r2+kxy7w8G=h=TAhdk1jUoW5UOiv-euo47uQY0u9ZA@mail.gmail.com>
<20140115230901.GA25135@netbook.cypherspace.org>
<op.w9q85wkhyldrnw@laptop-air.hsd1.ca.comcast.net>
<20140116114242.GA30432@netbook.cypherspace.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <20140116114242.GA30432@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1W3rXR-0005YO-Fu
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] unlinakble static address? & spv-privacy
(Re: Stealth Addresses)
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 Jan 2014 18:19:38 -0000
> >But I think it's great people can choose how to trade privacy for
> >computation/bandwidth however they want, and services can compete to
> >offer monitoring for 0+ bit prefixes.
>
> Its not a decision with user localised effect. If most users use it with
> parameters giving high elimination probability, that affects everyone else's
> privacy also. Also statistical effects are accumulative as more plausibly
> related addresses are eliminated at each potentially linked transaction. I
> think once the network flow analysis guys are done with incorporating it,
> and if reusable addresses saw significant use, my prediction is the result
> will be pretty close to privacy game over and it will undo most if not all
> of the hard-won privacy benefit of CoinJoin. (Recalling CoinJoin is only
> adding a bit or two of entropy per join, this elimination effect could
> easily undo more than that).
You've got a major social engineering problem here.
1) who is marketing privacy
2) how do you validate 'privacy providers'
Just like all the scamcoins, there will be scamprivacy providers, which will
drive the market price of privacy down to zero.
Who's paying the network/development/bandwidth/etc cost for privacy?
I'd guess 85% of real users don't really care about some abstract 'privacy'
ideal, they just want payments to work and to download cat pictures.
If you say 'regular address re-use is deprecated, and the top 1% in bitcoin
weatlh who own 95% of the miners want privacy', well fine. But you just
opened yourself up to 'OccupyBitcoin', and an altcoin that ENCOURAGES plain
old regular address re-use and transparency.
Does this stuff still work if regular address re-use is a transparency feature
and not a bug?
|
