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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1SZOce-0000R2-Te
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 15:46:12 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.210.47 as permitted sender)
client-ip=209.85.210.47; envelope-from=peter@coinlab.com;
helo=mail-pz0-f47.google.com;
Received: from mail-pz0-f47.google.com ([209.85.210.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SZOcZ-0008BU-2W
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 15:46:12 +0000
Received: by dalh21 with SMTP id h21so5499075dal.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 29 May 2012 08:46:01 -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=27BqUJWp0CfKf0LX+EoRZxudd5vCoMIoNZQwfofNTLY=;
b=b/nprA/teJCzyB9xsvBPA+YpgMF93JU+b2SnItBSUW+MterF3uaT8F2UABGGsgwi8O
SJLWfTAf4vseMXtkbPIWO2zk1ItGubYeuvUk7h7GpvZk1vYJSmtMQVoP/TJrNxCypuu3
psJXDle+dsRl/jYFY31O0rhT37GLFTU8HTjZQQX6F27yTxK8GYNMYHJovwNcZ21edwUl
sW+7t3BQmMjm/wW8PnA3HMPLsAwxUqr2U49M/zYh5Q3pNsfMqZLx+LToB3/8ejCCGAPl
yqv261sXDKSkIEbzih8AAs4HQWzaleUMz6+7kmAbic3xZsd2qngSQ0yysg4uD/B9xVXc
feGw==
Received: by 10.68.194.201 with SMTP id hy9mr17184419pbc.69.1338306361072;
Tue, 29 May 2012 08:46:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.13.1 with HTTP; Tue, 29 May 2012 08:45:39 -0700 (PDT)
In-Reply-To: <201205291539.57824.luke@dashjr.org>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<201205291534.40364.luke@dashjr.org>
<CAMGNxUtMmrT=J+SwpZvT0n-Uj_LoRuMwbEx10PoJo2BvfLFacA@mail.gmail.com>
<201205291539.57824.luke@dashjr.org>
From: Peter Vessenes <peter@coinlab.com>
Date: Tue, 29 May 2012 11:45:39 -0400
Message-ID: <CAMGNxUvw0NL3ih6okTBMj6x=O4d-8RakCWZpj4-7DMaPbhb-YA@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=047d7b10cb0f409c7904c12ebb4d
X-Gm-Message-State: ALoCoQled7eXx+gDfCWkp9AQC4OUuWHth1vabZVR6cBdWqXLm5vjp8qb03+qut+t5we2ElsjsZjx
X-Spam-Score: -0.0 (/)
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
0.7 HTML_IMAGE_ONLY_28 BODY: HTML: images with 2400-2800 bytes of words
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 T_REMOTE_IMAGE Message contains an external image
-0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SZOcZ-0008BU-2W
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: Tue, 29 May 2012 15:46:13 -0000
--047d7b10cb0f409c7904c12ebb4d
Content-Type: text/plain; charset=ISO-8859-1
I see. That is undeniably more secure and "bitcoin-y" than my suggestion.
It's also really a lot more work, especially in that it requires extra
linkages between codebases that in my mind are largely separate.
I'm just one voice, but I persist in believing that the 'lighter' solution,
especially for something that may not be a particularly big problem in the
bitcoin world is good -- it carries much less technical implementation debt
going forward, and has a lower risk of sort of seizing up development with
additional necessary code to worry about for those implementing to-spec
clients.
If that lighter solution turns out to be gameable, or has problems that
require the full force of the bitcoin network and concepts, that would be
the time to implement the improved version. That's just my approach,
however. I worry that building in any additional requirements to the
protocol or codebase adds significant cost to the network as a whole over
the next 10 years.
Peter
On Tue, May 29, 2012 at 11:39 AM, Luke-Jr <luke@dashjr.org> wrote:
> On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
> > I suppose I mean that I don't understand how to reverse that into a URL
> > when one is presented only with a block, or perhaps a coinbase in a
> > transaction.
>
> A new message can be added to the p2p relay network, similar to tx and
> alert
> broadcasts, that allow miners to publish/update their policy URI signed by
> the
> key in question. Counter-DDoS rules could decline to relay or store URIs
> for
> keys that haven't been published in - or achieved statistical significance
> in
> - the last N blocks.
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
--047d7b10cb0f409c7904c12ebb4d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I see. That is undeniably more secure and "bitcoin-y" than my sug=
gestion.<div><br></div><div>It's also really a lot more work, especiall=
y in that it requires extra linkages between codebases that in my mind are =
largely separate.=A0</div>
<div><br></div><div>I'm just one voice, but I persist in believing that=
the 'lighter' solution, especially for something that may not be a=
particularly big problem in the bitcoin world is good -- it carries much l=
ess technical implementation debt going forward, and has a lower risk of so=
rt of seizing up development with additional necessary code to worry about =
for those implementing to-spec clients.</div>
<div><br></div><div>If that lighter solution turns out to be gameable, or h=
as problems that require the full force of the bitcoin network and concepts=
, that would be the time to implement the improved version. That's just=
my approach, however. I worry that building in any additional requirements=
to the protocol or codebase adds significant cost to the network as a whol=
e over the next 10 years.</div>
<div><br></div><div>Peter</div><div><div><br><div class=3D"gmail_quote">On =
Tue, May 29, 2012 at 11:39 AM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mai=
lto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote=
:<br>
<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">On Tuesday, May 29, 2012 3=
:36:34 PM Peter Vessenes wrote:<br>
> I suppose I mean that I don't understand how to reverse that into =
a URL<br>
> when one is presented only with a block, or perhaps a coinbase in a<br=
>
> transaction.<br>
<br>
</div>A new message can be added to the p2p relay network, similar to tx an=
d alert<br>
broadcasts, that allow miners to publish/update their policy URI signed by =
the<br>
key in question. Counter-DDoS rules could decline to relay or store URIs fo=
r<br>
keys that haven't been published in - or achieved statistical significa=
nce in<br>
- the last N blocks.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><table style=
=3D"font-family:Times"><tbody><tr><td><img src=3D"http://coinlab.com/images=
/coinlab-logo.png"></td><td valign=3D"bottom"><div style=3D"font-family:Rob=
otoLight,'Lucida Grande',Helmet,Freesans,sans-serif;font-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></div>
--047d7b10cb0f409c7904c12ebb4d--
|
