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; 
MIME-Version: 1.0
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Precedence: list

--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 &quot;bitcoin-y&quot; than my sug=
gestion.<div><br></div><div>It&#39;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&#39;m just one voice, but I persist in believing that=
 the &#39;lighter&#39; 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&#39;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">&lt;<a href=3D"mai=
lto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</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"><div class=3D"im">On Tuesday, May 29, 2012 3=
:36:34 PM Peter Vessenes wrote:<br>
&gt; I suppose I mean that I don&#39;t understand how to reverse that into =
a URL<br>
&gt; when one is presented only with a block, or perhaps a coinbase in a<br=
>
&gt; 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&#39;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,&#39;Lucida Grande&#39;,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--