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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rebroad@gmail.com>) id 1SZPJz-0003Rd-LF
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 16:30:59 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=rebroad@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SZPJy-0003rp-Qh
for bitcoin-development@lists.sourceforge.net;
Tue, 29 May 2012 16:30:59 +0000
Received: by werg55 with SMTP id g55so3487843wer.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 29 May 2012 09:30:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.215.153 with SMTP id e25mr7903016wep.189.1338309052623;
Tue, 29 May 2012 09:30:52 -0700 (PDT)
Sender: rebroad@gmail.com
Received: by 10.223.77.65 with HTTP; Tue, 29 May 2012 09:30:52 -0700 (PDT)
In-Reply-To: <4FC0C401.1040600@justmoon.de>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<CANdZDc7+_xBH0DhujnXbh7gVB603qMQdQ7yOO5qq3HEfsJ2Lpw@mail.gmail.com>
<4FC0C401.1040600@justmoon.de>
Date: Tue, 29 May 2012 17:30:52 +0100
X-Google-Sender-Auth: 4TA4joB7-zCRThbrOXXnKJlvX24
Message-ID: <CAFBxzADDbBZ94ckDHEBccNbPQzfW7NWYfC4AibJZYk654bQ87A@mail.gmail.com>
From: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=0016e6d77c4cae6ac704c12f5be3
X-Spam-Score: 0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(rebroad[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.2 HTML_OBFUSCATE_10_20 BODY: Message is 10% to 20% HTML obfuscation
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-1.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SZPJy-0003rp-Qh
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 16:30:59 -0000
--0016e6d77c4cae6ac704c12f5be3
Content-Type: text/plain; charset=ISO-8859-1
I'd like to garner consensus on whether anyone else thinks it desirable to
have a flag option for bitcoin to punish blocks for not including
transactions. I notice there are already pro-miner options, such as the
restricting the relaying of free transactions, and so including an option
to restrict relaying of blocks from "stingy" miners to balance against the
current bias, so that the default bitcoin client can be run as much
pro-miner as pro-non-miner.
On Monday, May 28, 2012, rebroad@gmail.com wrote:
> What i think this thread reveals is whether a bitcoin client is pro-miner
> or pro-non-miner. What i think is needed is a fork where one benefits
> miners (e.g. Limits relaying of free transactions, as has been added to the
> current default client), and one that benefits non-miners (e.g. Limits
> relaying of blocks not including free transactions). Then people can vote
> based on the client they use.
>
> It seems to me that the current main client is a pro-miner one, and
> possibly not what most people would vote for if they were given an easier
> choice.
--0016e6d77c4cae6ac704c12f5be3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I'd like to garner consensus on whether anyone else thinks it desirable=
to have a flag option for bitcoin to punish blocks for not including trans=
actions. I notice there are already pro-miner options, such as the restrict=
ing the relaying of free transactions, and so including an option to restri=
ct relaying of blocks from "stingy" miners to balance against the=
current bias, so that the default bitcoin client can be run as much pro-mi=
ner as pro-non-miner.<br>
<br>On Monday, May 28, 2012, <a href=3D"mailto:rebroad@gmail.com">rebroad@g=
mail.com</a>=A0wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">
What i think this thread reveals is whether a bitcoin client is pro-miner o=
r pro-non-miner. What i think is needed is a fork where one benefits miners=
(e.g. Limits relaying of free transactions, as has been added to the curre=
nt default client), and one that benefits non-miners (e.g. Limits relaying =
of blocks not including free transactions). Then people can vote based on t=
he client they use.<br>
<br>It seems to me that the current main client is a pro-miner one, and pos=
sibly not what most people would vote for if they were given an easier choi=
ce.</blockquote>
--0016e6d77c4cae6ac704c12f5be3--
|
