summaryrefslogtreecommitdiff
path: root/54/6f77b912ec270f592fb6e27e425a0ff8eb7bc9
blob: 01c4b526908a6cce6a5b0d0fb955a565ad871ab0 (plain)
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
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 <luke@dashjr.org>) id 1SXehS-0003RX-Mp
	for bitcoin-development@lists.sourceforge.net;
	Thu, 24 May 2012 20:31:58 +0000
X-ACL-Warn: 
Received: from zinan.dashjr.org ([173.242.112.54])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1SXehO-0002A5-OH for bitcoin-development@lists.sourceforge.net;
	Thu, 24 May 2012 20:31:58 +0000
Received: from ishibashi.localnet (unknown [97.96.85.141])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 0887A56056E;
	Thu, 24 May 2012 20:31:47 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 24 May 2012 20:31:38 +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>
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@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-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201205242031.39804.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
X-Headers-End: 1SXehO-0002A5-OH
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: Thu, 24 May 2012 20:31:58 -0000

On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks.  Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
> 
> Therefore I was wondering what people thought about a client
> implementation change:
> 
>      - Do not store or relay empty blocks, if time since last block < X
>        (where X = 60 minutes, perhaps)
> 
> or even stronger,
> 
>      - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs

These are problematic for legitimate miners:
1) The freedom to reject transactions based on fees or spam filters, is 
severely restricted. As mentioned in other replies, this is an important point 
of Bitcoin's design.
1b) This punishes miners with superior transaction spam filtering. As with all 
spam filtering, it is often an "arms race" and therefore the filter rules must 
be kept private by the miners, and therefore cannot be disclosed for the 
validating clients to take into consideration.
2) For a few seconds after a new block is received, the new transaction merkle 
root(s) are not finished calculating. During this time, most miners are 
working on "blank" blocks with the new previousblockhash but no transactions. 
If those blocks are ignored, miners are forced to shutdown mining during this 
time.
3) As you mentioned, illegitimate miners can easily workaround these 
restrictions (even the second one, by flooding the network with their own 
transactions). This puts the legitimate miners at a disadvantage in their own 
search for valid blocks, unless they also come up with counter-measures 
themselves.

The argument that these are not rule changes is flawed:
1) As of right now, 99% of the network runs a single client. Anything this 
client rejects does de facto become a rule change.
2) Even if there were a diverse ecosystem of clients in place, discouragement 
rules that potentially affect legitimate miners significantly mess with the 
odds of finding a block.
3) If legitimate miners do not adopt counter-rules to bypass these new 
restrictions, the illegitimate miners are left with an even larger percentage 
of blocks found.

To summarize, I believe such a change as proposed would be very harmful to 
Bitcoin.

Luke