summaryrefslogtreecommitdiff
path: root/53/5f0bada0454d9a170b0d30ee4b1bf307e1c8d5
blob: 4b2a03d54f29813cf3aa58d082afae2f7f53638d (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
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <peter@coinlab.com>) id 1SZ1LM-000380-Sw
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 May 2012 14:54:48 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175; envelope-from=peter@coinlab.com;
	helo=mail-ob0-f175.google.com; 
Received: from mail-ob0-f175.google.com ([209.85.214.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1SZ1LL-00061A-J5
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 May 2012 14:54:48 +0000
Received: by obhx4 with SMTP id x4so543675obh.34
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 28 May 2012 07:54:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=n1x59ASOHBIQCyWunexuFn41KOPJpr3Gwwe8f3b/Nuo=;
	b=R5oD3PaFE3PVm+H9zrqCDCvBgzk9BZIMkZ6bKQ0nPdY6bhpL4zWalP6r7OLoQfN2/0
	fxtIjuafinUJSywbS79sJ9HfFystdZHidLI4823r3dL1gPyICPMGnrSOaKVoXwwDLpOy
	00XutFCajAeM7KFHsJF3GzJK2leqyw9y1bzFpoX4kHlJ5Q8jdlKGNdlkydqZ+eLBwxQi
	d+HG+uYlTih4nzH6naciHB79YYtF3wvvEs/lxMjt6PrsIHF+f5WvAEvaqvXC+Im3bBle
	VQN1XcxmhKlEI2xHTG0EGZnnSTvAuaHlX/pkqhQrXJp1yjnKS2FF+cCLS6oDOvG/GVT9
	b5BA==
Received: by 10.182.139.2 with SMTP id qu2mr8175826obb.34.1338216881882; Mon,
	28 May 2012 07:54:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.41.200 with HTTP; Mon, 28 May 2012 07:54:21 -0700 (PDT)
In-Reply-To: <4FC0C401.1040600@justmoon.de>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
	<CANdZDc7+_xBH0DhujnXbh7gVB603qMQdQ7yOO5qq3HEfsJ2Lpw@mail.gmail.com>
	<4FC0C401.1040600@justmoon.de>
From: Peter Vessenes <peter@coinlab.com>
Date: Mon, 28 May 2012 10:54:21 -0400
Message-ID: <CAMGNxUv3jX+bdEyF8p-y3i93yLySxyT=7Qy336dPw9vgDKG51w@mail.gmail.com>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: multipart/alternative; boundary=e89a8f838db1e0844c04c119e52e
X-Gm-Message-State: ALoCoQkgUBM+aS6P1hEY9rkBhHycvc/YEhkaGCSrgDw97Mii6h9GOkurt2BoTDttnpQFfnT2/GYx
X-Spam-Score: -0.5 (/)
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
X-Headers-End: 1SZ1LL-00061A-J5
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Punishing empty 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: Mon, 28 May 2012 14:54:49 -0000

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

One of the issues here though is that it would be nice if miners published
their own tx rules -- it might be hard to impute them from data.

I had started a thread about this on bitcoin.org some time ago, and I don't
recall what the general outcome was.

I had imagined an open service whereby a miner could publish a short string
in their conbase tying to the service and the service would have different
metadata, including the miner's transaction guarantees.

We offered to host this before, and would still be willing to host such a
service.

Peter

On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <moon@justmoon.de> wrote:

> Zooko is spot on - slower confirmations will give people a reason to set
> higher fees. As soon as fees reach a level where they matter, even
> botnet operators will be looking into ways of including transactions for
> some extra profit.
>
> In the meantime slightly slower confirmations aren't a problem. Consider
> that even if it takes four blocks to get your transaction included
> instead of one, once it is included, you still benefit from every new
> block in terms of security. So if you're looking for six confirmations
> for example, even a three block delay will only be a 50% delay for you.
> And of course there are techniques for instant transactions which
> continue to be refined and improved.
>
> As for the proposed solutions: Punishing 1-tx blocks is complete and
> utter nonsense. It's trivial to include a bogus second transaction.
>
> Any additional challenges towards miners like hashes of the previous
> block are at best useless. If I was running a botnet, I'd just grab that
> hash from a website (pretty good chance Blockchain.info will have it :P)
> or mining pool or wherever and keep going undeterred. At worst they may
> affect scalability one day. You might imagine a peer-to-peer network of
> miners who for cost reasons don't download all blocks anymore, but
> verify only a percentage of them at random. They might then exchange
> messages about invalid blocks including a proof (invalid tx, merkle
> branch) why the block is invalid. This is just one idea, the point is
> that assumptions about what a legitimate miner looks like may not always
> hold in the future.
>
> Finally, there is an ethical aspect as well. If a miner wishes not to
> include my transaction that is his choice. He has no more an obligation
> to sell his service to me than I have to buy it from him. If I really,
> really want him to include my transaction I will have to offer to pay more.
>
> If we as developers think that confirmations are too slow or that more
> blocks should include transactions, then the right measures would be:
>
> - Educating users about the relationship between confirmation speed and
> fees
> - Raising the default transaction fee
>
> Every market has a supply curve, so it is economically to be expected
> that there will be some miners who don't include transactions, simply
> because they are at that end of the supply curve where it is not worth
> it for them to sell their service. All markets must have a certain
> tension - there must be miners who don't include transactions for there
> to be users who want their transactions included more quickly. In other
> words there must be somebody not confirming if confirmations are to have
> value. If you interfere with that all you'll accomplish is keep
> transaction fees below market level, which will make the transition from
> inflation-financed hashing to transaction-financed hashing more painful
> and disruptive.
>
> Cheers,
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>

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

One of the issues here though is that it would be nice if miners published =
their own tx rules -- it might be hard to impute them from data.<div><br></=
div><div>I had started a thread about this on <a href=3D"http://bitcoin.org=
">bitcoin.org</a> some time ago, and I don&#39;t recall what the general ou=
tcome was.</div>

<div><br></div><div>I had imagined an open service whereby a miner could pu=
blish a short string in their conbase tying to the service and the service =
would have different metadata, including the miner&#39;s transaction guaran=
tees.</div>

<div><br></div><div>We offered to host this before, and would still be will=
ing to host such a service.</div><div><br></div><div>Peter<br><br><div clas=
s=3D"gmail_quote">On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <span dir=
=3D"ltr">&lt;<a href=3D"mailto:moon@justmoon.de" target=3D"_blank">moon@jus=
tmoon.de</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Zooko is spot on - slower confirmations will=
 give people a reason to set<br>
higher fees. As soon as fees reach a level where they matter, even<br>
botnet operators will be looking into ways of including transactions for<br=
>
some extra profit.<br>
<br>
In the meantime slightly slower confirmations aren&#39;t a problem. Conside=
r<br>
that even if it takes four blocks to get your transaction included<br>
instead of one, once it is included, you still benefit from every new<br>
block in terms of security. So if you&#39;re looking for six confirmations<=
br>
for example, even a three block delay will only be a 50% delay for you.<br>
And of course there are techniques for instant transactions which<br>
continue to be refined and improved.<br>
<br>
As for the proposed solutions: Punishing 1-tx blocks is complete and<br>
utter nonsense. It&#39;s trivial to include a bogus second transaction.<br>
<br>
Any additional challenges towards miners like hashes of the previous<br>
block are at best useless. If I was running a botnet, I&#39;d just grab tha=
t<br>
hash from a website (pretty good chance Blockchain.info will have it :P)<br=
>
or mining pool or wherever and keep going undeterred. At worst they may<br>
affect scalability one day. You might imagine a peer-to-peer network of<br>
miners who for cost reasons don&#39;t download all blocks anymore, but<br>
verify only a percentage of them at random. They might then exchange<br>
messages about invalid blocks including a proof (invalid tx, merkle<br>
branch) why the block is invalid. This is just one idea, the point is<br>
that assumptions about what a legitimate miner looks like may not always<br=
>
hold in the future.<br>
<br>
Finally, there is an ethical aspect as well. If a miner wishes not to<br>
include my transaction that is his choice. He has no more an obligation<br>
to sell his service to me than I have to buy it from him. If I really,<br>
really want him to include my transaction I will have to offer to pay more.=
<br>
<br>
If we as developers think that confirmations are too slow or that more<br>
blocks should include transactions, then the right measures would be:<br>
<br>
- Educating users about the relationship between confirmation speed and fee=
s<br>
- Raising the default transaction fee<br>
<br>
Every market has a supply curve, so it is economically to be expected<br>
that there will be some miners who don&#39;t include transactions, simply<b=
r>
because they are at that end of the supply curve where it is not worth<br>
it for them to sell their service. All markets must have a certain<br>
tension - there must be miners who don&#39;t include transactions for there=
<br>
to be users who want their transactions included more quickly. In other<br>
words there must be somebody not confirming if confirmations are to have<br=
>
value. If you interfere with that all you&#39;ll accomplish is keep<br>
transaction fees below market level, which will make the transition from<br=
>
inflation-financed hashing to transaction-financed hashing more painful<br>
and disruptive.<br>
<br>
Cheers,<br>
<br>
Stefan<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<table style=3D"font-family:Times"><tbody><tr><td><img src=3D"http://coinla=
b.com/images/coinlab-logo.png"></td><td valign=3D"bottom"><div style=3D"fon=
t-family:RobotoLight,&#39;Lucida Grande&#39;,Helmet,Freesans,sans-serif;fon=
t-size:16px;line-height:20px">

Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br>=
<a href=3D"https://plus.google.com/112885659993091300749" target=3D"_blank"=
>Google+</a></div></td></tr></tbody></table><br>
</div>

--e89a8f838db1e0844c04c119e52e--