Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B0A687A for ; 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 ; 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 ) 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 In-Reply-To: Date: Tue, 4 Aug 2015 16:37:57 -0700 Message-Id: <2A7FC602-A8A1-4C56-B8F4-92DB411B4AED@hashingit.com> References: <1438640036.2828.0.camel@auspira.com> <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> To: Gavin Andresen 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = wrote: >=20 > On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev = > 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
On 4 Aug 2015, at 14:30, Gavin Andresen <gavinandresen@gmail.com> wrote:

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....

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--