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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1SXcap-0005u2-Ik
for bitcoin-development@lists.sourceforge.net;
Thu, 24 May 2012 18:16:59 +0000
X-ACL-Warn:
Received: from mail-lpp01m010-f47.google.com ([209.85.215.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SXcao-0001Ha-G8
for bitcoin-development@lists.sourceforge.net;
Thu, 24 May 2012 18:16:59 +0000
Received: by lags15 with SMTP id s15so81125lag.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 May 2012 11:16:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=dJm/GSeK4A+JSk4IaenhyMG9X//r1M6xfGtKaAxlKXA=;
b=iJfgbjFdnJ6qx14REDPd467B9kC7NuK9vIqm0RBBeHhpSk2WiIQ/9IhrQBzEgfqF4n
A0ahy/wzse2zGMCWO4EsvuvLrpaP5aZrfDrfnkgecHdHZ10owJiJKcyhcXIXGC21Qz9u
0R6navNtE8vw4NrnWLhVJ6UMErgoI7Zrq8MhHJ7cKaJqSZdpxvz0nrKP5385bta3F5iD
tD2vKG4SF3z+r2ZEmYDXUcxYo+yhl5OxZ2ql165TW0sJ3u+B6iB84vWwD8s4654EB8LB
FsY1mXDSUqs7vVuMnBJHIn06D+1utJoYha1aATCUrw8qBDY4S7rUp0Z8HseOzQJ44e3F
sEdQ==
MIME-Version: 1.0
Received: by 10.112.45.230 with SMTP id q6mr138311lbm.94.1337883411810; Thu,
24 May 2012 11:16:51 -0700 (PDT)
Received: by 10.114.0.103 with HTTP; Thu, 24 May 2012 11:16:51 -0700 (PDT)
X-Originating-IP: [99.43.178.25]
In-Reply-To: <81d184ee3a3f5386f6b23090a2a55718@webmail.mckay.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<81d184ee3a3f5386f6b23090a2a55718@webmail.mckay.com>
Date: Thu, 24 May 2012 14:16:51 -0400
Message-ID: <CA+8xBpdzPqGEtuh=EMq8HbVYObX29HL5u4XU_0wpgdX0VnbQqQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Robert McKay <robert@mckay.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkU21KVNVz2m08Cz52KrWqlB3fpDzZ2yUI9m1zhJ0oQcATwqRZRU6IX3U3bxIeYcY9KGHYb
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 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SXcao-0001Ha-G8
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: Thu, 24 May 2012 18:16:59 -0000
On Thu, May 24, 2012 at 1:27 PM, Robert McKay <robert@mckay.com> wrote:
> If miners wanted to continue mining empty blocks without bothering to
> monitor the Tx pool they would just switch to stuffing the empty blocks
> with a dummy transaction of their own to get round your new rules.
Yes. This was stated in the original email.
> Once the block reward halves in a few months time then receiving
> transaction fees will probably become more important to the miner's
> profit and loss calculations and they'll spend the extra time to
> implement proper transaction processing. I suspect if we do nothing this
> particular issue will go away. Perhaps it could be helped along by
> publishing some example code to make it easier for them.
At current rates it is potentially years before that point is reached
-- years of degraded service for existing users.
> The ability to refuse transactions seems like an important part of the
> game theory of transaction pricing. Miners are supposed to be able to
> jack up transaction costs by declining to process no fee or too low fee
> (in their opinion) transactions.. the counter balance is that they are
> losing money by doing that and leaving more on the table for the next
> miner to score a block.
>
> I expect that in the future there will be other instances when people
> complain that the miners are being 'unfair' and that the rules should be
> changed in some way to lower transaction fees (ie: increase block size).
If you see a rule change, you have misunderstood the proposal.
This is an -implementation- change, which users and miners are free to
accept or reject as part of their choice of software to use in the
bitcoin ecosystem.
As such, miners continue to be free to build upon empty blocks, and
let those blocks become part of a useful chain. You would not simply
/ban/ empty blocks completely, but avoid relaying top-of-chain empty
blocks.
Mining power and network collaborate to choose the best chain at that
point -- perhaps even including those empty blocks. Clients will
continue to follow the longest, strongest chain, even after this
implementation change.
An implementation change is a soft vote of choice by the user, not a
hard requirement on all users.
> I think it should be legitimate not to publish a transaction
> to the p2p network at all.. in the future there will probably be lots of
> networks other than the p2p network.. right now we have the IPv6 network
> and the IPv4 network.. in the future there could be many other protocols
> and perhaps not all transactions will make it back to the old legacy
> ipv4 p2p network or into the mempool of bitcoin nodes on that network..
> but they should still be able to get into the block chain.
See above -- such behavior is perfectly fine.
It should be noted that out of band (OOB) TXs, transited through third
party means outside P2P network, would not cause _empty_ blocks, as
the block chain will continue to have traffic for the foreseeable
future.
OOB TXs are a great idea, too. In a hyperscaled bitcoin future, OOB
TXs might even be the norm.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
