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+