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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1SZOCu-0007Wj-OA
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 15:19:36 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SZOCt-0001Dh-AP for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 15:19:36 +0000
Received: from ishibashi.localnet (unknown [97.96.85.141])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 49D97560594;
Tue, 29 May 2012 15:19:27 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: Peter Vessenes <peter@coinlab.com>
Date: Tue, 29 May 2012 15:18:54 +0000
User-Agent: KMail/1.13.7 (Linux/3.2.12-gentoonestfix-intelwr; KDE/4.8.1; x86_64;
; )
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<201205291447.29823.luke@dashjr.org>
<CAMGNxUs9KBDE7T4YgX+NH3j=VURffLjOEih8nEODohUeyn1=Vw@mail.gmail.com>
In-Reply-To: <CAMGNxUs9KBDE7T4YgX+NH3j=VURffLjOEih8nEODohUeyn1=Vw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201205291518.56618.luke@dashjr.org>
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SZOCt-0001Dh-AP
Cc: bitcoin-development@lists.sourceforge.net, Michael
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:19:36 -0000
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.
|
