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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3847BB7B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 20:01:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com [74.125.83.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C78EA1E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 20:01:20 +0000 (UTC)
Received: by mail-pg0-f52.google.com with SMTP id g2so49783997pge.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 13:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=YKI/8nKg0k99IFdmVGpELAvPnaRJLF4LMUdoW8paJkk=;
b=l+UYRtg+YV+syV9/zSFSJ0Ku4vYP33+cEUmXazneZEfW0AsfSDOvAWRo5zkfyuODac
c6GvBe180NdN1xriRgicwmL/QXlGtHZFNYMMn7t4f2509L9T2A959YGHZ9uDBAr3O7xS
KveqTU6Jof1hQiiX23Whs2fSIZLMJhiBRdrFR2HNsM3hOAK5gBKdIMXVOCgSbMx5zFOy
FlT9EcsDAO6I4pgNdXIENoWfqcWIInME3WU/GvaH2EvEsSeudmj6pyL6B6hD+Bpgpw5H
cfyQX07HuWLqsAdMlR+8wi9Yl0LucDaxWoyjkxDPTppgoHKJsLXyGeuHKF1AsNrnuLMf
aIpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=YKI/8nKg0k99IFdmVGpELAvPnaRJLF4LMUdoW8paJkk=;
b=uQXgV6WAbuInaassPIF0+X2+SbjQyAKeCnttjLaQLw1bsCW3wrFz2cUx9A0q7sHWCz
aqF2N3GiOGW9n3ZRucAeCCQp5CuU0q/oNeDwb1KZ6FYxKv+waj0WrIX5LUaf2ij+uydq
KA4h/WFe6/JFFUcf0BF3kNIRuJxMKDnXFu5z71UjueXxGMR756ro59+i6ZX/liUqERof
UMI/NvUGw4fJh3Q8pP+jMPDGCDlasz+bs/I4o16ALZecZELU+jh/YwIJfEkFOPm2QQJl
AA98iEknw5RGSEPAlcWqouU+kYjClro216LvWBtActySlyYpLMCVY2ek2QD9YFOzRfQz
VdiA==
X-Gm-Message-State: AFeK/H2RRXscP16EFhX1OprewpfOXNxrm/Jt3J1jZboIteAzmmz7XHbDp8a2BNsECDVHeQ==
X-Received: by 10.99.109.67 with SMTP id i64mr20641677pgc.56.1490644880295;
Mon, 27 Mar 2017 13:01:20 -0700 (PDT)
Received: from ?IPv6:2601:600:9000:d69e:8c11:8163:4024:ef42?
([2601:600:9000:d69e:8c11:8163:4024:ef42])
by smtp.gmail.com with ESMTPSA id g5sm2822468pfe.12.2017.03.27.13.01.19
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 27 Mar 2017 13:01:19 -0700 (PDT)
To: Tom Zander <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Btc Ideas <btcideas@protonmail.com>
References: <uQBxE-Qbd-osime4uulMZZHdF_D7usA2EKsPjkTyXCHM0OakN2Wdoeriyrc73yWp5c5ULQNkIsRXAM64cCom7ecPvdwmatOyc9Kh1sTDpl4=@protonmail.com>
<7350662.8AQMRkRU5C@cherry>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <b99eda2f-b638-e188-e678-f93bba147404@voskuil.org>
Date: Mon, 27 Mar 2017 13:01:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <7350662.8AQMRkRU5C@cherry>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 27 Mar 2017 20:03:18 +0000
Subject: Re: [bitcoin-dev] Encouraging good miners
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 20:01:21 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/27/2017 10:29 AM, Tom Zander via bitcoin-dev wrote:
> For some time now the relation between block size and propagation
> speed has been decoupled. Using xthin/compact blocks miners only
> send a tiny version of a block which then causes the receiving node
> to re-create it using the memory pool. Immediately getting double
> benefits by including pre-verified transactions from the memory
> pool you avoid the old problem of having to validate them again
> when a block was mined.
>
> As such there is no downside to a miner creating a bigger block, as
> long as all the transactions they include are actually in the
> mempool.
All transactions being publicly available is not something that can be
assumed.
With no opportunity cost for a miner to generate withheld
transactions, a larger miner still maintains the economic advantage of
latency as a function of block size. Fast relay works to reduce
latency in relation to the opportunity cost created by the space
constraint. IOW, the more fees a miner must give up to mine withheld
transactions, the greater the economic disadvantage of doing so. So
there is a "downside" (i.e. centralization pressure) up to the point
where the advantage gained from withholding transactions turns negative.
The rational competing miner must presume that a block is valid upon
confirming the announcement's PoW. He then has the choice of mining on
top of the (partially-visible) block, or ignoring it until it can be
fully populated. The former *eliminates fee opportunity*, since the
next block must remain free of all public fee-generating transactions
until all of the preceding block's transactions are visible. The
latter increases orphaning probability, since it implies mining on the
weak chain, which *increases total reward loss*.
One can conclude that no matter how much space is created, it will
always be filled by a rational miner, as a competitive necessity,
given the centralizing effect of latency. Making blocks big enough to
include low cost transactions nullifies the benefits of fast relay
techniques based on your above assumption, since a rational miner will
simply substitute withheld transactions.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY2W+bAAoJEDzYwH8LXOFOzkwH+wUulsdvUcfEHMspolfDjTD+
f4egP1FDoOFgXzaGJ+Bq1AjWP+CDYup9msYhp1NTk6xRnG4uGvaEA3DFYGbAzLut
INtkpCi38O1QGtDJaxmkJHXLoWJPS6VudcDEoam4W6qSKgHFB+ZRnIN4T7jnGMLI
rp/cGdom9wE/pcq/fvF/fonGfVWf/YP2YjBzJzaJy+zOYPTH2rNcnYBCHFPs4/KX
9Gu7tDw9WNxM5idnd0TiidublQhYui6xo7ZbZpmXQePcHQoQO5XqaO6yWwiWRWaU
mqXhalASOtP6xnPzj6FfAHYS7qA7JCaDfwT8UIzt9xv9XsPrhQ/r6Sfgfhvbm2k=
=b9sf
-----END PGP SIGNATURE-----
|
