path: root/f3/8a9cce293daa60dd4aa457da6a1b7339bc17c4

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 1SZOpM-0001Iw-Ab
	for bitcoin-development@lists.sourceforge.net;
	Tue, 29 May 2012 15:59:20 +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 1SZOpK-0000I8-OR
	for bitcoin-development@lists.sourceforge.net;
	Tue, 29 May 2012 15:59:20 +0000
Received: by dalh21 with SMTP id h21so5517189dal.34
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 29 May 2012 08:59:12 -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=TcNFaSkwa9qtKM9ZRxD5TwEMZwuDLdpggeKXITj66ko=;
	b=o6V8OjyvtBkjuV7cou/v2Y6HhDM9yuU+9LQYOesGd0Vb18zcyIrRR4Ee6tAQpN6R3h
	ADHVkSHEhni0jnnSOfGP+nERBry4bhca5xTR3rM5STIzmv5qdhrZnx0Mwh7xLCjCX5Dr
	YYa/oyKb66GIcrFyHkb470Z8AZWTk511DXe7sgtj7F10FeZA1oi9uu0ZWSYv2UXim1wx
	WTGXg3FUV+mDrzSLPxPxtxBhlPtdlSbXdnN3va79Ua6DDGUMnU694T4OP99yy43SXa6S
	ySyQdrYzR6WUctNk9zYCvU6Eu7wf7/JbPLVX4v9QNqzvdM9c67GJQ3UJOccYuq/FJ8EY
	KijA==
Received: by 10.68.130.9 with SMTP id oa9mr39120007pbb.95.1338305357444; Tue,
	29 May 2012 08:29:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.13.1 with HTTP; Tue, 29 May 2012 08:28:56 -0700 (PDT)
In-Reply-To: <201205291518.56618.luke@dashjr.org>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
	<201205291447.29823.luke@dashjr.org>
	<CAMGNxUs9KBDE7T4YgX+NH3j=VURffLjOEih8nEODohUeyn1=Vw@mail.gmail.com>
	<201205291518.56618.luke@dashjr.org>
From: Peter Vessenes <peter@coinlab.com>
Date: Tue, 29 May 2012 11:28:56 -0400
Message-ID: <CAMGNxUvWZziLppNoqntKgLVmBs_H1Ka_qH6qUtYskJovx5HgiA@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=e89a8ffbaec56e773a04c12e7f52
X-Gm-Message-State: ALoCoQkwnv8E6jkOVE7XsXYxZPRX+udjqSCTjV8+uDBR9Isc6pwBV0LJRuJDmHL2beVCzgRBnm70
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 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SZOpK-0000I8-OR
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:59:20 -0000

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

I disagree with a bunch of your points, but I'll wait on others to comment,
except I will say that I don't understand what the 20 byte keyhash is. Can
you elucidate?

I am assuming major mining folks have written their own coinbasing
facilities, but perhaps this is not the case -- if so, I agree that some
work is necessary for such miners.

Finally I will just comment that I am guided by the general perspective
that many things about bitcoins are opt-in; therefore it makes sense to me
put difficult work onto those who are motivated to do it, and keep things
as easy as possible for the 'maybes' to participate -- hence small
courtesies like allowing text/plain or text/html.

Peter

On Tue, May 29, 2012 at 11:18 AM, Luke-Jr <luke@dashjr.org> wrote:

> On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
> > 1) Germane to the original conversation, anything hard to implement will
> > not get implemented by miners.
>
> Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
> anything modifying the coinbase is hard to implement.
>
> > 2) Coinbase is hard-limited to 100 bytes; this has to include space for
> > voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
> > good plan.
>
> Rather, I would suggest a 20 byte keyhash, which allows the owner to
> broadcast
> a full URI out-of-band.
>
> > 1) They shall prepend \mi: to the url to designate it as a url for miner
> > info, and append a trailing \ to the url
>
> How about a simple prefix to the fixed-size keyhash?
> Perhaps "MFR=" (Mining Fee Rules)
>
> > 2) The url given in the coinbase shall have http:// prepended to it
> before
> > processing.
>
> I would recommend miners use https, with a specified SSL keyhash in the URI
> (so we don't need to pay for a "proper" SSL cert).
>
> > 3) The destination may be a redirect (to allow short URLs), or may
> deliver
> > content
>
> Clients should simply be required to follow the relevant HTTP
> specification.
>
> > 4) The content-type returned by the final site post-redirect shall be
> > either (preferred text/json) or text/plain or text/html
>
> text/plain and text/html are just wrong and don't make any sense here.
>
> > Inre: Luke's complaint about JSON, it is the language of the web. There
> is
> > no easier format for both computers and humans to read, and in this case,
> > it includes extensibility, which is nice, since we have no idea how
> miners
> > will wish to divvy up their services; I think one would need to make a
> > strong case against JSON for a specific reason to not choose it by
> default.
>
> Bitcoin isn't "the web", it's a complicated script-based cryptocurrency.
> Everything in the Bitcoin protocol requires a computer's interpretation for
> humans, and there's no reason to stray from this default. Also, JSON is not
> extensible in any of the ways needed for this specific purpose.
>
> > 4) The text of the document delivered shall be a JSON format dictionary,
> > and shall include at minimum the following fields: 'min_fee',
> 'pool_name',
> > and 'last_modified' Optional fields can be determined over time as
> > necessary by the mining community
>
> Last Modified and other caching rules are dealt with in the relevant HTTP
> specification...
>
> > 5) The Service Level Agreement isn't binding, but miners who implement it
> > are expected to make a best efforts attempt to follow it.
>
> While it doesn't make sense to give it the full legal force of a contract,
> I
> think it should be expressed as a "MUST" in the BIP.
>
> > Generally a miner would occasionally publish the \mi:\ when they had
> > updated their SLA, or just every so often, but the canonical location
> would
> > be the final destination URL from the redirects.
>
> The coinbase advertisement MUST be part of every coinbase mined by the
> miner,
> or there's no reliable way to prove which blocks are theirs.
>



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

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

I disagree with a bunch of your points, but I&#39;ll wait on others to comm=
ent, except I will say that I don&#39;t understand what the 20 byte keyhash=
 is. Can you elucidate?<div><br></div><div>I am assuming major mining folks=
 have written their own coinbasing facilities, but perhaps this is not the =
case -- if so, I agree that some work is necessary for such miners.</div>


<div><br></div><div>Finally I will just comment that I am guided by the gen=
eral perspective that many things about bitcoins are opt-in; therefore it m=
akes sense to me put difficult work onto those who are motivated to do it, =
and keep things as easy as possible for the &#39;maybes&#39; to participate=
 -- hence small courtesies like allowing text/plain or text/html.</div>

<div><br></div><div>Peter</div><div><br><div class=3D"gmail_quote">On Tue, =
May 29, 2012 at 11:18 AM, Luke-Jr <span dir=3D"ltr">&lt;<a href=3D"mailto:l=
uke@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>On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:<br>
&gt; 1) Germane to the original conversation, anything hard to implement wi=
ll<br>
&gt; not get implemented by miners.<br>
<br>
</div>Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser bra=
nch,<br>
anything modifying the coinbase is hard to implement.<br>
<div><br>
&gt; 2) Coinbase is hard-limited to 100 bytes; this has to include space fo=
r<br>
&gt; voting as well as extra nonce, etc. So, I&#39;m not sure that a full U=
RL is a<br>
&gt; good plan.<br>
<br>
</div>Rather, I would suggest a 20 byte keyhash, which allows the owner to =
broadcast<br>
a full URI out-of-band.<br>
<div><br>
&gt; 1) They shall prepend \mi: to the url to designate it as a url for min=
er<br>
&gt; info, and append a trailing \ to the url<br>
<br>
</div>How about a simple prefix to the fixed-size keyhash?<br>
Perhaps &quot;MFR=3D&quot; (Mining Fee Rules)<br>
<div><br>
&gt; 2) The url given in the coinbase shall have http:// prepended to it be=
fore<br>
&gt; processing.<br>
<br>
</div>I would recommend miners use https, with a specified SSL keyhash in t=
he URI<br>
(so we don&#39;t need to pay for a &quot;proper&quot; SSL cert).<br>
<div><br>
&gt; 3) The destination may be a redirect (to allow short URLs), or may del=
iver<br>
&gt; content<br>
<br>
</div>Clients should simply be required to follow the relevant HTTP specifi=
cation.<br>
<div><br>
&gt; 4) The content-type returned by the final site post-redirect shall be<=
br>
&gt; either (preferred text/json) or text/plain or text/html<br>
<br>
</div>text/plain and text/html are just wrong and don&#39;t make any sense =
here.<br>
<div><br>
&gt; Inre: Luke&#39;s complaint about JSON, it is the language of the web. =
There is<br>
&gt; no easier format for both computers and humans to read, and in this ca=
se,<br>
&gt; it includes extensibility, which is nice, since we have no idea how mi=
ners<br>
&gt; will wish to divvy up their services; I think one would need to make a=
<br>
&gt; strong case against JSON for a specific reason to not choose it by def=
ault.<br>
<br>
</div>Bitcoin isn&#39;t &quot;the web&quot;, it&#39;s a complicated script-=
based cryptocurrency.<br>
Everything in the Bitcoin protocol requires a computer&#39;s interpretation=
 for<br>
humans, and there&#39;s no reason to stray from this default. Also, JSON is=
 not<br>
extensible in any of the ways needed for this specific purpose.<br>
<div><br>
&gt; 4) The text of the document delivered shall be a JSON format dictionar=
y,<br>
&gt; and shall include at minimum the following fields: &#39;min_fee&#39;, =
&#39;pool_name&#39;,<br>
&gt; and &#39;last_modified&#39; Optional fields can be determined over tim=
e as<br>
&gt; necessary by the mining community<br>
<br>
</div>Last Modified and other caching rules are dealt with in the relevant =
HTTP<br>
specification...<br>
<div><br>
&gt; 5) The Service Level Agreement isn&#39;t binding, but miners who imple=
ment it<br>
&gt; are expected to make a best efforts attempt to follow it.<br>
<br>
</div>While it doesn&#39;t make sense to give it the full legal force of a =
contract, I<br>
think it should be expressed as a &quot;MUST&quot; in the BIP.<br>
<div><br>
&gt; Generally a miner would occasionally publish the \mi:\ when they had<b=
r>
&gt; updated their SLA, or just every so often, but the canonical location =
would<br>
&gt; be the final destination URL from the redirects.<br>
<br>
</div>The coinbase advertisement MUST be part of every coinbase mined by th=
e miner,<br>
or there&#39;s no reliable way to prove which blocks are theirs.<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: <a href=3D"tel:206.595.9839" value=
=3D"+12065959839" target=3D"_blank">206.595.9839</a><br>Skype: vessenes<br>=
<a href=3D"https://plus.google.com/112885659993091300749" target=3D"_blank"=
>Google+</a></div>

</td></tr></tbody></table><br>
</div>

--e89a8ffbaec56e773a04c12e7f52--