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 ) 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 ; 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: <201205291447.29823.luke@dashjr.org> <201205291518.56618.luke@dashjr.org> From: Peter Vessenes Date: Tue, 29 May 2012 11:28:56 -0400 Message-ID: To: Luke-Jr 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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+ --e89a8ffbaec56e773a04c12e7f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I disagree with a bunch of your points, but I'll wait on others to comm= ent, 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 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 '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 wi= ll
> not get implemented by miners.

Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser bra= nch,
anything modifying the coinbase is hard to implement.

> 2) Coinbase is hard-limited to 100 bytes; this has to include space fo= r
> voting as well as extra nonce, etc. So, I'm not sure that a full U= RL 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 min= er
> info, and append a trailing \ to the url

How about a simple prefix to the fixed-size keyhash?
Perhaps "MFR=3D" (Mining Fee Rules)

> 2) The url given in the coinbase shall have http:// prepended to it be= fore
> processing.

I would recommend miners use https, with a specified SSL keyhash in t= he 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 del= iver
> content

Clients should simply be required to follow the relevant HTTP specifi= cation.

> 4) The content-type returned by the final site post-redirect shall be<= br> > 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 ca= se,
> it includes extensibility, which is nice, since we have no idea how mi= ners
> 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 def= ault.

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 dictionar= y,
> and shall include at minimum the following fields: 'min_fee', = 'pool_name',
> and 'last_modified' Optional fields can be determined over tim= e 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 imple= ment 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 th= e 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+

--e89a8ffbaec56e773a04c12e7f52--