summaryrefslogtreecommitdiff
path: root/06/56e32b52b0ff63cfaef943b4ad0be8f633015d
blob: deeaa8dd7da279d94ded41346f86dea0d341938f (plain)
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
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 <christophe.biocca@gmail.com>) id 1W4cSd-0001Jj-Bf
	for bitcoin-development@lists.sourceforge.net;
	Sat, 18 Jan 2014 20:25:43 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.170 as permitted sender)
	client-ip=209.85.192.170;
	envelope-from=christophe.biocca@gmail.com;
	helo=mail-pd0-f170.google.com; 
Received: from mail-pd0-f170.google.com ([209.85.192.170])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W4cSc-0007oS-Aj
	for bitcoin-development@lists.sourceforge.net;
	Sat, 18 Jan 2014 20:25:43 +0000
Received: by mail-pd0-f170.google.com with SMTP id p10so1071096pdj.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 18 Jan 2014 12:25:36 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.68.138.165 with SMTP id qr5mr9663905pbb.123.1390076736217;
	Sat, 18 Jan 2014 12:25:36 -0800 (PST)
Received: by 10.68.146.72 with HTTP; Sat, 18 Jan 2014 12:25:36 -0800 (PST)
In-Reply-To: <20140118174452.GG3180@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>
	<CAAS2fgTRKgkO15VUvVgttP-iEBNF4=G+++Xo-XsaRBmOxyXXKA@mail.gmail.com>
	<20140118174452.GG3180@nl.grid.coop>
Date: Sat, 18 Jan 2014 15:25:36 -0500
Message-ID: <CANOOu=9t7UxBQWHXS4hVziWqaaDx-D6POK23RNhL5CM8m_JQqg@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Troy Benjegerdes <hozer@hozed.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [209.85.192.170 listed in list.dnswl.org]
	-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
	(christophe.biocca[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: 1W4cSc-0007oS-Aj
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: Sat, 18 Jan 2014 20:25:43 -0000

Like any other mechanism that puts extra data in the blockchain, the
sender pays the fees.

This mechanism is to improve privacy for static addresses (donation
links on websites and so on). I personally don't think it will be used
nearly as much as BIP0032 or the payment protocol (both of which don't
need on-blockchain data), precisely because it increases the fees
required to send funds, but this doesn't externalize costs anymore
than any other use of the blockchain does.

People who don't care about privacy and want smallest cost and maximum
convenience already use SPV nodes. Their resource usage will not be
affected in the least.

On Sat, Jan 18, 2014 at 12:44 PM, Troy Benjegerdes <hozer@hozed.org> wrote:
> On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
>> On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
>> > Choosing how many bits to put in the prefix may be difficult, particularly
>> > if transaction load changes dramatically over time. 0 or 1 bits may be
>> > just fine for a single user running their own node, whereas a central
>> > service might want 4 or 5 bits to keep their computation costs scalable.
>>
>> Ignoring prefixes the cost for each reusable address is only a small
>> percentage of the full node cost (rational: each transaction has one
>> or more ECDSA signatures, and the derivation is no more expensive), so
>> I would only expect computation to be an issue for large centralized
>> services. (non-full nodes suffer more from just the bandwidth impact).
>
> I have not seen anyone address my high-level question to (somewhat) complicated
> mechanisms to keep coin flows private.
>
> Who pays for it? From what I see it's going to double the amount of data
> needed per address, further centralizing 'full' nodes. I'm fine if the NSA
> is paying for privacy (I actually trust them more than banks and advertisers),
> but let's just be honest, okay?
>
> If socializing the cost of privacy is Bitcoin's goal, and giving the benefits
> to a few that understand it and/or have the resources to determine privacy
> providers that won't scam them, then say so, so I can get on with launching
> a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses
> addresses, and has miners and pools that charge more for addresses they have
> never seen before. I bet it will be more distributed and have about half the
> average transaction cost of Bitcoin, because most people *just don't care*
> about privacy if they get cheap and/or free services.
>
>
> -- Troy, transparency advocate who is quite transparent that if you buy me
> farmland, I'll shut up about transparency, because I'll be too busy growing
> food and giving part of it away.
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development