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
|
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 0B0A687A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 23:38:02 +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 68BCA107
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 23:38:01 +0000 (UTC)
Received: from [207.140.24.78] (port=28137 helo=[10.0.0.243])
by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85) (envelope-from <dave@hashingit.com>)
id 1ZMlmR-001nSG-3b; Tue, 04 Aug 2015 23:37:59 +0000
Content-Type: multipart/alternative;
boundary="Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <CABsx9T0yad_2NOYEdrJbqX48wCvuQiYb=zP1eC3YwOCc1ODN9w@mail.gmail.com>
Date: Tue, 4 Aug 2015 16:37:57 -0700
Message-Id: <2A7FC602-A8A1-4C56-B8F4-92DB411B4AED@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>
<CABsx9T0yad_2NOYEdrJbqX48wCvuQiYb=zP1eC3YwOCc1ODN9w@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.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,HTML_MESSAGE
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: Tue, 04 Aug 2015 23:38:02 -0000
--Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> On 4 Aug 2015, at 14:30, Gavin Andresen <gavinandresen@gmail.com> =
wrote:
>=20
> On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Fundamentally a block maker (pool or aggregation of pools) does not =
orphan its own blocks.
>=20
> Unless the block maker has an infinitely fast connection to it's =
hashpower OR it's hashpower is not parallelized at all, that's not =
strictly true -- it WILL orphan its own blocks because two hashing units =
will find solutions in the time it takes to communicate that solution to =
the block maker and to the rest of the hashing units.
>=20
> That's getting into "how many miners can dance on the head of a pin" =
territory, though. I don't think we know whether the communication =
advantages of putting lots of hashing power physically close together =
will outweigh the extra cooling costs of doing that (or maybe some other =
tradeoff I haven't thought of). That would be a fine topic for another =
paper....
Yes, but the block maker won't publish the second block it finds for the =
same set of transactions. It won't orphan its own block. In fact even if =
it does it still doesn't matter because the block maker still gets the =
block reward irrespective of which of the two solutions are published.
It's not about which hash wins, the issue is who gets paid as a result.
--Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 4 Aug 2015, at 14:30, Gavin Andresen <<a =
href=3D"mailto:gavinandresen@gmail.com" =
class=3D"">gavinandresen@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, =
Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <span dir=3D"ltr" =
class=3D""><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>></span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fundamentally a =
block maker (pool or aggregation of pools) does not orphan its own =
blocks.</blockquote></div><br class=3D"">Unless the block maker has an =
infinitely fast connection to it's hashpower OR it's hashpower is not =
parallelized at all, that's not strictly true -- it WILL orphan its own =
blocks because two hashing units will find solutions in the time it =
takes to communicate that solution to the block maker and to the rest of =
the hashing units.</div><div class=3D"gmail_extra"><br =
class=3D""></div><div class=3D"gmail_extra">That's getting into "how =
many miners can dance on the head of a pin" territory, though. I don't =
think we know whether the communication advantages of putting lots of =
hashing power physically close together will outweigh the extra cooling =
costs of doing that (or maybe some other tradeoff I haven't thought of). =
That would be a fine topic for another =
paper....</div></div></div></blockquote><br class=3D""></div><div>Yes, =
but the block maker won't publish the second block it finds for the same =
set of transactions. It won't orphan its own block. In fact even if it =
does it still doesn't matter because the block maker still gets the =
block reward irrespective of which of the two solutions are =
published.</div><div><br class=3D""></div><div>It's not about which hash =
wins, the issue is who gets paid as a result.</div><br =
class=3D""></body></html>=
--Apple-Mail=_3E1D36B6-5BAC-4F05-8886-EE777A669663--
|
