summaryrefslogtreecommitdiff
path: root/ac/53007d46a0e9cd09b65da8c302a51e7df66805
blob: 2136a96438b5848ff2f3d735cf157d3cb868a69c (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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
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 <andreas@antonopoulos.com>) id 1Ukgc3-00024y-Ie
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Jun 2013 20:16:47 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
	antonopoulos.com designates 209.85.219.43 as permitted sender)
	client-ip=209.85.219.43; envelope-from=andreas@antonopoulos.com;
	helo=mail-oa0-f43.google.com; 
Received: from mail-oa0-f43.google.com ([209.85.219.43])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Ukgc2-0003Vn-Jm
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Jun 2013 20:16:47 +0000
Received: by mail-oa0-f43.google.com with SMTP id i7so1064155oag.30
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 06 Jun 2013 13:16:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=6P6wS8IWEC6CCfcVaMwnWYq2EDhNk4h7SDAfBf/raI0=;
	b=LGm8qbhp5SsSQ2AsBT4W0vLUiiOf+snAa4CP6Igu2oCOfGNZDu4lC5uCKE1CL2AdXB
	K4BEAGSIdJmB52V5Eq/k7X4S2Kze6+FrJbws9xcbrmJgOtnLH2IXY/93/hj1Pkgt0MWf
	PxghKMPaohN9AqbOOJ0u8SVkvsEYGwhngjhEv9eDID+FVGAl3Ci2TkKv0ZVcLT1IcWFd
	fc7dFQ5Aupdz6XNVYndv8bEPLeXb7vgGI5pRrVXOqFy+YllxAvKRPg1v+vURVV7Uj91x
	lMozaPo3lULp6mUuQZfjFIBaqikFroyhg6WaL6BOgiaV6hbfYZoKyaGA1qC7vns8Ia9k
	xh5g==
MIME-Version: 1.0
X-Received: by 10.60.135.134 with SMTP id ps6mr18868850oeb.114.1370549801086; 
	Thu, 06 Jun 2013 13:16:41 -0700 (PDT)
Sender: andreas@antonopoulos.com
Received: by 10.182.17.9 with HTTP; Thu, 6 Jun 2013 13:16:40 -0700 (PDT)
In-Reply-To: <201306062007.41398.luke@dashjr.org>
References: <201306061914.20006.luke@dashjr.org>
	<CAFmyj8zG7iLnwm7iUwxyOXTe3SZxAOFoZdy3=oRa2WqYbiWsHQ@mail.gmail.com>
	<201306062007.41398.luke@dashjr.org>
Date: Thu, 6 Jun 2013 13:16:40 -0700
X-Google-Sender-Auth: _BdsrxHIjWLV_3LqY47DVcLexMA
Message-ID: <CAFmyj8zDCjGR6cLUXQnWP4G0k6A85vdNW03k5NPAVyoJj0eEnQ@mail.gmail.com>
From: "Andreas M. Antonopoulos" <andreas@rooteleven.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=047d7b33ce8c0a823904de81fedf
X-Gm-Message-State: ALoCoQkYo94GEhfy8qKiw28KK+vuCop/hDtit2G6GU0NDsDmjOUS2Yo8r7KSL2+GevD5HITBwR+E
X-Spam-Score: -0.4 (/)
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 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1Ukgc2-0003Vn-Jm
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make
 anyone-can-spend outputs unspendable for 100 blocks
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, 06 Jun 2013 20:16:47 -0000

--047d7b33ce8c0a823904de81fedf
Content-Type: text/plain; charset=ISO-8859-1

> This doesn't work like you might think: first of all, the fees today are
> greatly subsidized - the actual cost to store data in the blockchain is
> much
> higher than most storage solutions. Secondly, only the miner receives the
> fees, not the majority of nodes which have to bear the burden of the data.
> That is, the fee system is setup as an antispam/deterrant, not as payment
> for
> storage.
>

There's a difference between storing the content itself, and storing just a
hash to content (which however is not spendable payment). I undertand why
content itself doesn't belong. But it goes too far to say that only
payments should be allowed.

If the fees are not enough, fix the fee structure, don't stop incredibly
innovative and promising uses of the distributed timestamping database.
That is definitely throwing the baby out with the bathwater. If the issue
is size, then address that, rather than the content itself.

Have I misunderstood this discussion or are some proposing than nothing
except payments be allowed?

Discriminating based on transaction content violates neutrality of the
protocol and in my mind removes a very very large possibility of future
innovation. If bitcoin is a *platform* and not just a payment system, then
it needs to be neutral to content, like TCP/IP so that other protocols can
be layered. Solve the size problem itself, without picking and chosing
which uses of bitcoin are good and which are "bad" or "spam". I think it
risks killing a tremendous amount of innovation just as it is starting.

>
>
>
> Not the same thing at all; nobody is forced to store/relay
> video/voice/images
> without reimbursement. On the other hand, any full Bitcoin node is
> required to
> at least download the entire blockchain once. And the network as a whole
> suffers if nodes decide to start not-storing parts of the blockchain they
> don't want to deal with.
>
> So don't store content, but allow hashes of content.
Again, I think it is extreme and extremely restrictive to say that ONLY
payments are allowed.



> This is how merged mining solves the problem. A single extra hash in the
> coinbase can link the bitcoin blockchain up with unlimited other data.
>
>
>
Can you explain this part or refer me to some docs? What do you mean by
"coinbase", I assume not the company.


Thanks for the reply and explanation!

>

--047d7b33ce8c0a823904de81fedf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This doesn&#39;t work like you might think: =
first of all, the fees today are<br>

greatly subsidized - the actual cost to store data in the blockchain is muc=
h<br>
higher than most storage solutions. Secondly, only the miner receives the<b=
r>
fees, not the majority of nodes which have to bear the burden of the data.<=
br>
That is, the fee system is setup as an antispam/deterrant, not as payment f=
or<br>
storage.<br></blockquote><div>=A0</div><div style>There&#39;s a difference =
between storing the content itself, and storing just a hash to content (whi=
ch however is not spendable payment). I undertand why content itself doesn&=
#39;t belong. But it goes too far to say that only payments should be allow=
ed.=A0</div>
<div style><br></div><div style>If the fees are not enough, fix the fee str=
ucture, don&#39;t stop incredibly innovative and promising uses of the dist=
ributed timestamping database. That is definitely throwing the baby out wit=
h the bathwater. If the issue is size, then address that, rather than the c=
ontent itself.=A0<br>
</div><div style><br></div><div style>Have I misunderstood this discussion =
or are some proposing than nothing except payments be allowed?</div><div st=
yle><br></div><div style>Discriminating based on transaction content violat=
es neutrality of the protocol and in my mind removes a very very large poss=
ibility of future innovation. If bitcoin is a <b>platform</b> and not just =
a payment system, then it needs to be neutral to content, like TCP/IP so th=
at other protocols can be layered. Solve the size problem itself, without p=
icking and chosing which uses of bitcoin are good and which are &quot;bad&q=
uot; or &quot;spam&quot;. I think it risks killing a tremendous amount of i=
nnovation just as it is starting.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"im"><br><br>
<br>
</div>Not the same thing at all; nobody is forced to store/relay video/voic=
e/images<br>
without reimbursement. On the other hand, any full Bitcoin node is required=
 to<br>
at least download the entire blockchain once. And the network as a whole<br=
>
suffers if nodes decide to start not-storing parts of the blockchain they<b=
r>
don&#39;t want to deal with.<br>
<div class=3D"im"><br></div></blockquote><div style>So don&#39;t store cont=
ent, but allow hashes of content.=A0</div><div style>Again, I think it is e=
xtreme and extremely restrictive to say that ONLY payments are allowed. =A0=
<br>
</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"im">
</div>This is how merged mining solves the problem. A single extra hash in =
the<br>
coinbase can link the bitcoin blockchain up with unlimited other data.<br>
<div class=3D"im"><br><br></div></blockquote><div><br></div><div style>Can =
you explain this part or refer me to some docs? What do you mean by &quot;c=
oinbase&quot;, I assume not the company.=A0</div><div style><br></div><div =
style>
<br></div><div style>Thanks for the reply and explanation!</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div class=3D"HOEnZb"></div></blockquote></div></div></=
div>

--047d7b33ce8c0a823904de81fedf--