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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DA592847
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 21:30:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com
[209.85.215.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18F7C1A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 21:30:30 +0000 (UTC)
Received: by lady2 with SMTP id y2so12276221lad.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Aug 2015 14:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=MJWcVcPraG97uEWeEizq32dMTfxdZ+8Gpuv6oxraPEs=;
b=c7LC7HPzCHsuwr4JZnah6I1djkZv1Cx72RoX/n+zI8DPCE3fnc8tT784TuAn6Whiv1
HhPueOCZJSJsvsZR6/PoWDlVL5hxul1vfLOzcPxJwxDjnG3qKRYWNYwo9SoiVyRI/A1V
wHbIqh4BYU4wFBGiCC4vb5ZG4gQ0nSHrg6bCghcWocMqrEO+hQIxLF2jtqMPLGUCkf3Q
zv6FZmwPky/iTxgpRWDwleyjFgMP4ycduh7Z+nfNHYPBNziZ5zQXB5SQ3Z3y7Q79hKkX
qk7xrYoFXre9YNi0AL4rAOHyqg8ndE1lLVi5IlJ2bZHrsZz47owfpXmn2mV+AV9RbjMM
Hgzw==
MIME-Version: 1.0
X-Received: by 10.112.239.43 with SMTP id vp11mr6309061lbc.75.1438723828140;
Tue, 04 Aug 2015 14:30:28 -0700 (PDT)
Received: by 10.25.143.195 with HTTP; Tue, 4 Aug 2015 14:30:28 -0700 (PDT)
In-Reply-To: <3162BC78-EC0B-4DAA-A472-D143389DDD8A@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>
Date: Tue, 4 Aug 2015 17:30:28 -0400
Message-ID: <CABsx9T0yad_2NOYEdrJbqX48wCvuQiYb=zP1eC3YwOCc1ODN9w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Dave Hudson <dave@hashingit.com>
Content-Type: multipart/alternative; boundary=001a113492b8b4d077051c82fe2a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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 21:30:31 -0000
--001a113492b8b4d077051c82fe2a
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Fundamentally a block maker (pool or aggregation of pools) does not orphan
> its own blocks.
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.
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....
--
--
Gavin Andresen
--001a113492b8b4d077051c82fe2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Fundamentally a block maker (pool or aggregation of p=
ools) does not orphan its own blocks.</blockquote></div><br>Unless the bloc=
k 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 W=
ILL 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 th=
e rest of the hashing units.</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">That's getting into "how many miners can da=
nce on the head of a pin" territory, though. I don't think we know=
whether the communication advantages of putting lots of hashing power phys=
ically 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 fin=
e topic for another paper....</div><div class=3D"gmail_extra"><div><br></di=
v>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a113492b8b4d077051c82fe2a--
|
