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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F735E0C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 02:33:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79EBDA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 02:33:40 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 09C2E57BB2;
Sun, 30 Aug 2015 02:33:38 +0000 (UTC)
To: Peter R <peter_r@gmx.com>
References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
<55E21F2E.9000308@mattcorallo.com>
<786493BB-2136-4587-A309-B8B1A34ED568@gmx.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55E26B82.2070805@mattcorallo.com>
Date: Sun, 30 Aug 2015 02:33:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <786493BB-2136-4587-A309-B8B1A34ED568@gmx.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org,
Daniele Pinna <daniele.pinna@gmail.com>
Subject: Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped
Block Size Fee Markets
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 30 Aug 2015 02:33:41 -0000
It is not a purely academic scenario that blocks contain effectively no
information (that was not previously relayed). I'm not aware of any
public code to do so, but I know several large miners who pre-relay the
block(s) they are working on to other nodes of theirs around the globe.
This means at announce-time you have only a few bytes to broadcast (way
less than a packet, and effects of using smaller packets to relay things
vs larger packets are very small, if anything). After you've broadcast
to all of your nodes, hops to other mining nodes are probably only a
handful of ms away with very low packet loss, so relay time is no longer
connected to transaction inclusion at all (unless you're talking about
multi-GB blocks). Of course, this is relay time for large miners who can
invest time and money to build such systems. Small miners are completely
screwed in such a system.
Thus, the orphan risk for including a transaction is related to the
validation time (which is only DB modify-utxo-set time, essentially,
which maybe you can optimize much of that away, too, and only have to
pass over mempool or so). Anyway, my point, really, is that though
miners will have an incentive to not include transactions which will
trigger validation by other nodes (ie things not already in their
mempool), the incentive to not include transactions which have already
been relayed around sufficiently is, while not theoretically zero, as
near to zero in practice as you can get.
Matt
On 08/29/15 23:17, Peter R wrote:
> Hello Matt and Daniele,
>
>> this seems to ignore the effects of transaction validation caches and
>> *block
>> compression protocols. *
>
> The effect of block compression protocols is included. This is what I
> call the "coding gain" and use the Greek letter "gamma" to represent.
>
> As long as the block solution announcements contain information (i.e.,
> Shannon Entropy) about the transactions included in a block, then the
> fee market will be "healthy" according to the definitions given in the
> linked paper (see below). This is the case right now, this is the case
> with your relay network, and this would be the case using any
> implementation of IBLTs that I can imagine, so long as miners can still
> construct blocks according to their own volition. The "healthy fee
> market" result follows from the Shannon-Hartley theorem; the SH-theorem
> describes the maximum rate at which information (Shannon Entropy) can be
> transmitted over a physical communication channel.
>
> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>
> I've exchanged emails with Greg Maxwell about (what IMO is) an academic
> scenario where the block solutions announcements contain *no information
> at all* about the transactions included in the blocks. Although the fee
> market would not be healthy in such a scenario, it is my feeling that
> this also requires miners to relinquish their ability to construct
> blocks according to their own volition (i.e., the system would already
> be centralized). I look forward to a white paper demonstrating otherwise!
>
> Best regards,
> Peter
>
>
>
> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>> I believe it was pointed out previously in the discussion of the Peter R
>> paper, but I'll repeat it here so that its visible - this seems to
>> ignore the effects of transaction validation caches and block
>> compression protocols. Many large miners already have their own network
>> to relay blocks around the globe with only a few bytes on the wire at
>> block-time, and there is also the bitcoinrelaynetwork.org
>> <http://bitcoinrelaynetwork.org> network, which
>> does the same for smaller miners, albeit with slightly less efficiency.
>> Also, transaction validation time upon receiving a block can be rather
>> easily made negligible (ie the only validation time you should have is
>> the DB modify-utxo-set time). Thus, the increased orphan risk for
>> including a transaction can be reduced to a very, very tiny amount,
>> making the optimal blocksize, essentially, including everything that
>> you're confident is in the mempool of other reasonably large miners.
>>
>> Matt
>>
>> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
>>> I'd like to submit this paper to the dev-list which analyzes how miner
>>> advantages scale with network and mempool properties in a scenario of
>>> uncapped block sizes. The work proceeds, in a sense, from where Peter
>>> R's work left off correcting a mistake and addressing the critiques made
>>> by the community to his work.
>>>
>>> The main result of the work is a detailed analysis of mining advantages
>>> (defined as the added profit per unit of hash) as a function of miner
>>> hashrate. In it, I show how large block subsidies (or better, low
>>> mempool fees-to-subsidy ratios) incentivize the pooling of large
>>> hashrates due to the steady increasing of marginal profits as hashrates
>>> grow.
>>>
>>> The paper also shows that part of the large advantage the large miners
>>> have today is due to there being a barrier to entry into a
>>> high-efficiency mining class which has access to expected profits an
>>> order of magnitude larger than everyone else. As block subsidies
>>> decrease, this high-efficiency class is expected to vanish leading to a
>>> marginal profit structure which decreases as a function of hashrate.
>>>
>>> This work has vacuumed my entire life for the past two weeks leading me
>>> to lag behind on a lot of work. I apologize for typos which I may not
>>> have seen. I stand by for any comments the community may have and look
>>> forward to reigniting consideration of a block size scaling proposal
>>> (BIP101) which, due to the XT fork drama, I believe has been placed
>>> hastily and undeservedly on the chopping block.
>>>
>>> https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
>>>
>>>
>>> Regards,
>>> Daniele
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
