From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DA592847 for ; 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 ; Tue, 4 Aug 2015 21:30:30 +0000 (UTC) Received: by lady2 with SMTP id y2so12276221lad.0 for ; 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: <1438640036.2828.0.camel@auspira.com> <3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com> Date: Tue, 4 Aug 2015 17:30:28 -0400 Message-ID: From: Gavin Andresen To: Dave Hudson 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 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 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
On T= ue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
Fundamentally a block maker (pool or aggregation of p= ools) does not orphan its own blocks.

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.

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

--
--
Gavin Andresen
--001a113492b8b4d077051c82fe2a--