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
|
Return-Path: <dave@hashingit.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 88EC57AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 22:44:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from heron.directrouter.co.uk (heron.directrouter.co.uk
[89.145.69.228])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B721A1A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 22:44:23 +0000 (UTC)
Received: from [207.140.24.78] (port=43894 helo=[10.0.0.145])
by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85) (envelope-from <dave@hashingit.com>)
id 1ZN7Q5-001YL2-LE; Wed, 05 Aug 2015 22:44:21 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com>
Date: Wed, 5 Aug 2015 15:44:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com>
References: <CABsx9T1E1s=4h-SxLTOAXK4GniZrUekcEb6zDdTDFG+h7X98MA@mail.gmail.com>
<1438640036.2828.0.camel@auspira.com>
<CABsx9T2A-Mz9z=TTifbL2_sKCDvy8coRpNse+0vff6EbXbp8cg@mail.gmail.com>
<BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com>
<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com>
<7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com>
To: Peter R <peter_r@gmx.com>
X-Mailer: Apple Mail (2.2102)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hashingit.com
X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id:
dave@hashingit.com
X-Source:
X-Source-Args:
X-Source-Dir:
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block
Size Limit"--new research paper suggests
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: Wed, 05 Aug 2015 22:44:24 -0000
>=20
> On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx.com> wrote:
>=20
> Hi Dave,
>=20
> Thank you for the feedback regarding my paper. =20
>=20
>> The paper is nicely done, but I'm concerned that there's a real =
problem with equation 4. The orphan rate is not just a function of time; =
it's also a function of the block maker's proportion of the network hash =
rate. Fundamentally a block maker (pool or aggregation of pools) does =
not orphan its own blocks.
>=20
> With the benefit of hindsight, I think the paper would be stronger if =
it also analyzed how the model changes (or doesn't) if we assume zero =
propagation impedance for intra-miner communication, as you suggested =
(the "you don't orphan your own blocks" idea). Note that the paper did =
briefly discuss miner-dependent propagation times in the second =
paragraph of page 9 and in note 13.
I think this would be really interesting. It's an area that seems to be =
lacking research.
While I've not had time to model it I did have a quick discussion with =
the author of the Organ-of-Corti blog a few months ago and he seemed to =
think that the Poisson process model isn't quite accurate here. =
Intuitively this makes sense as until a block has fully propagated we're =
only seeing some fraction of the actual hashing network operating on the =
same problem, so we actually see slightly fewer very quick blocks than =
we might expect.
I do suspect that if we were to model this more accurately we might be =
able to infer the "typical" propagation characteristics by measuring the =
deviation from the expected distribution.
>> Consider that a 1% miner must assume a greater risk from orphaning =
than, say, a pool with 25%, or worse 40% of the hash rate.
>=20
> I'd like to explore this in more detail. Although a miner may not =
orphan his own block, by building on his own block he may now orphan two =
blocks in a row. At some point, his solution or solutions must be =
communicated to his peers. And if there's information about the =
transactions in his blocks to communicate, I think there's a cost =
associated with that. It's an interesting problem and I'd like to =
continue working on it. \
Agreed - I think this would be really interesting!
>> I suspect this may well change some of the conclusions as larger =
block makers will definitely be able to create larger blocks than their =
smaller counterparts.
>=20
> It will be interesting to see. I suspect that the main result that "a =
healthy fee market exists" will still hold (assuming of course that a =
single miner with >50% of the hash power isn't acting maliciously). =
Whether miners with larger value of h/H have a profit advantage, I'm not =
sure (but that was outside the scope of the paper anyways).
I really look forward to seeing the revised version. Seeing the =
differences will also help assess how much impact there is from =
simplified models.
Regards,
Dave
|
