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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1SZOSN-0000ab-WD
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 15:35:36 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=peter@coinlab.com;
helo=mail-yw0-f47.google.com;
Received: from mail-yw0-f47.google.com ([209.85.213.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SZOSI-00080J-7p
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 15:35:35 +0000
Received: by yhjj56 with SMTP id j56so2808024yhj.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 29 May 2012 08:35:24 -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=g1gmnN+O4hSbKGvJu1yOQCVKizAOKwYDJF2Nr6EezSs=;
b=VcMAptEeLMHznNyCVLPJZR6+sATWbiTCYd/gSJY1a3ZGmvLlvoUuAlczDN3vndKZGh
YVJWF2Za0zeyjcQh7Mw90kTkr73/lRdUDSHd641PfIZuLK0c55JU3pYS2bgBV9VvRehT
UdPUkhtuqd4lCwx3afu3+QwtZp9Zbp4sxliOmcXD+CVrDXrNzIKfYqB5dr9RzVMT5a9T
ksW5MlSkTwRUEfOy2N8hHRiH0TLXfcJNtBLzIyfbYtT0y1uGARa0xGuiSn60nskfrfTB
S0Ki655lBz9lpCorzLtDuuUgJD3qljuNJ+hdkCPVDuxvo1twAxZEqAiFEDzK+46PI9xw
44Mg==
Received: by 10.68.217.138 with SMTP id oy10mr38933215pbc.30.1338303939167;
Tue, 29 May 2012 08:05:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.13.1 with HTTP; Tue, 29 May 2012 08:05:18 -0700 (PDT)
In-Reply-To: <201205291447.29823.luke@dashjr.org>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<CAMGNxUv3jX+bdEyF8p-y3i93yLySxyT=7Qy336dPw9vgDKG51w@mail.gmail.com>
<5C824F0D-6025-4630-965B-E6C685588250@mac.com>
<201205291447.29823.luke@dashjr.org>
From: Peter Vessenes <peter@coinlab.com>
Date: Tue, 29 May 2012 11:05:18 -0400
Message-ID: <CAMGNxUs9KBDE7T4YgX+NH3j=VURffLjOEih8nEODohUeyn1=Vw@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=047d7b2ee639e544ca04c12e2a26
X-Gm-Message-State: ALoCoQmJW3Ah5bkR+4EkKi3cvStCZAjSc7wA2/BpttwEy3ROUagDaYWrlVkdoJtLJH4duVMnc8MN
X-Spam-Score: -0.5 (/)
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
X-Headers-End: 1SZOSI-00080J-7p
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:35:36 -0000
--047d7b2ee639e544ca04c12e2a26
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
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.
3) I'm a little fuzzy on the details of BIP governance; but I'm happy to
write one up and get my thoughts down, or someone who's more familiar could
do it, I suppose.
I propose the following spec:
periodically a miner may choose to publish a url through their coinbase as
follows:
1) They shall prepend \mi: to the url to designate it as a url for miner
info, and append a trailing \ to the url
2) The url given in the coinbase shall have http:// prepended to it before
processing.
3) The destination may be a redirect (to allow short URLs), or may deliver
content
4) The content-type returned by the final site post-redirect shall be
either (preferred text/json) or text/plain or text/html
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
5) The Service Level Agreement isn't binding, but miners who implement it
are expected to make a best efforts attempt to follow it.
So a valid coinbase could be:
/P2SH/\mi:goo.gl/mr2D\extra_nonce:2110
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.
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.
Thoughts welcome!
Best,
Peter
On Tue, May 29, 2012 at 10:47 AM, Luke-Jr <luke@dashjr.org> wrote:
> On Tuesday, May 29, 2012 8:52:49 AM Michael Gr=F8nager wrote:
> > The format of the sla.php page should then be specified too - but it
> could
> > be a json-rpc call returning a json object like (as result): {
> > sla_version: "0.1",
> > accept_no_fee_tx: false,
> > min_fee: 50000,
> > big_tx_fee: 10000, // extra fee pr kb
> > }
> > I guess miners could work out a more suitable set of fees...
>
> Please not JSON, and not hard-coded logic. Bitcoin already has a secure
> scripting system - perhaps we can decide on an initial stack format and
> run a
> script retrieved from the URI?
>
>
--=20
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
--047d7b2ee639e544ca04c12e2a26
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
OK, I have a few thoughts on this:<div><br></div><div>1) Germane to the ori=
ginal conversation, anything hard to implement will not get implemented by =
miners.</div><div>2) Coinbase is hard-limited to 100 bytes; this has to inc=
lude space for voting as well as extra nonce, etc. So, I'm not sure tha=
t a full URL is a good plan.</div>
<div>3) I'm a little fuzzy on the details of BIP governance; but I'=
m happy to write one up and get my thoughts down, or someone who's more=
familiar could do it, I suppose.</div><div><br></div><div>I propose the fo=
llowing spec:</div>
<div><br></div><div>periodically a miner may choose to publish a url throug=
h their coinbase as follows:=A0</div><div><br></div><div>1) They shall prep=
end \mi: to the url to designate it as a url for miner info, and append a t=
railing \ to the url</div>
<div>2) The url given in the coinbase shall have http:// prepended to it be=
fore processing.</div><div>3) The destination may be a redirect (to allow s=
hort URLs), or may deliver content</div><div>4) The content-type returned b=
y the final site post-redirect shall be either (preferred text/json) or tex=
t/plain or text/html</div>
<div>4) The text of the document delivered shall be a JSON format dictionar=
y, and shall include at minimum the following fields:=A0'min_fee', =
'pool_name', and 'last_modified' Optional fields can be det=
ermined over time as necessary by the mining community</div>
<div>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.</div><div=
><br></div><div>So a valid coinbase could be:</div><div>/P2SH/\mi:<a href=
=3D"http://goo.gl/mr2D\extra_nonce:2110">goo.gl/mr2D\extra_nonce:2110</a></=
div>
<div><br></div><div>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.</div><div>
<br></div><div>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 n=
o idea how miners will wish to divvy up their services; I think one would n=
eed to make a strong case against JSON for a specific reason to not choose =
it by default.</div>
<div><br></div><div>Thoughts welcome!</div><div><br></div><div>Best,</div><=
div><br></div><div>Peter</div><div><br></div><div><br></div><div><br><div c=
lass=3D"gmail_quote">On Tue, May 29, 2012 at 10:47 AM, Luke-Jr <span dir=3D=
"ltr"><<a href=3D"mailto: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 8=
:52:49 AM Michael Gr=F8nager wrote:<br>
> The format of the sla.php page should then be specified too - but it c=
ould<br>
> be a json-rpc call returning a json object like (as result): {<br>
> =A0 =A0 sla_version: "0.1",<br>
> =A0 =A0 accept_no_fee_tx: false,<br>
> =A0 =A0 min_fee: 50000,<br>
> =A0 =A0 big_tx_fee: 10000, // extra fee pr kb<br>
> }<br>
> I guess miners could work out a more suitable set of fees...<br>
<br>
</div>Please not JSON, and not hard-coded logic. Bitcoin already has a secu=
re<br>
scripting system - perhaps we can decide on an initial stack format and run=
a<br>
script retrieved from the URI?<br>
<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>
--047d7b2ee639e544ca04c12e2a26--
|
