From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V3VvP-0006pa-Bd for bitcoin-development@lists.sourceforge.net; Sun, 28 Jul 2013 18:42:35 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com designates 209.85.215.193 as permitted sender) client-ip=209.85.215.193; envelope-from=john.dillon892@googlemail.com; helo=mail-ea0-f193.google.com; Received: from mail-ea0-f193.google.com ([209.85.215.193]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V3VvN-0003OA-93 for bitcoin-development@lists.sourceforge.net; Sun, 28 Jul 2013 18:42:35 +0000 Received: by mail-ea0-f193.google.com with SMTP id z7so79909eaf.8 for ; Sun, 28 Jul 2013 11:42:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.1.70 with SMTP id 46mr56432184eec.82.1375036946946; Sun, 28 Jul 2013 11:42:26 -0700 (PDT) Received: by 10.223.12.131 with HTTP; Sun, 28 Jul 2013 11:42:26 -0700 (PDT) In-Reply-To: References: <20130724094255.GB12568@savin> Date: Sun, 28 Jul 2013 18:42:26 +0000 Message-ID: From: John Dillon To: Tier Nolan Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V3VvN-0003OA-93 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Distributing low POW headers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 18:42:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan wrote: > Distributing headers with 1/64 of the standard POW means that a header would > be broadcast approximately once every 9 seconds (assuming a 10 minute block > time). This was picked because sending 80 byte headers every 9 seconds > shouldn't represent much load on the network. As Peter said, "much" should be quantified. Remember that there is a statistical distribution here, what is the probability of how many seconds per headers? > This creates an incentive for miners to take headers into account. If all > the headers were worth less than a full block, then a fork which was losing > would suddenly be winning if a block is found. A fork will only become the > main chain due to a new block, if it is within 16 mini-confirms. Sounds like you are changing economics and requiring miners to have even better network connections. This is not a thing to do lightly and it probably a bad idea. > Second, if a header builds on a header that is in the header tree, then it > is broadcast, even if it doesn't meet full POW (only 1/64 required). This > gives information on which fork is getting the most power. > > It gives information about potential "consensus loss" forks, where a > significant number of miners are following an alternative chain. > > In fact, this is probably worth doing as an initial step. I understand Pieter Wuille is working on letting Bitcoin propagate and make use of pure block headers, a step towards SPV and partial UTXO mode. Orphan measurement would be very useful for a lot of reasons, how about you think about that first? It wouldn't have the potential data rate issues either and should be a very simple change. Just set some threshold relative to the height of the best block where you will not further propagate and orphan block(header) and prior to that limit do so freely. I believe the change would be 100% compatible with the P2P protocol as it is based on inventories. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9WXdAAoJEEWCsU4mNhiPBUYIALgg3ylA5mkciT3W/kb+qXCp spYlPwAU/HVUrd/p6Ra6xAOOa224BE018FHRx7cJ31AQdVPsKhC1XiQCeYMv14Cj 5LstO2VTzxLovfs1lTVnekt+xVo6EHP47Qhmhdfo1AQWHS2njIp2lT9gAlNgMYoI Twu0FLfJFwg14HlueLhTNvGo3TeVpGhTV3HYTbjWGBuPeroaaPCKKQOy/jmA9mnZ 1x4MjQZ+AkGA3+vrinyRZ1FQsp1pOUZMZx5UFYDOOPS3TysxttiHF/Vkdmy9dNVf 5zbXrEDImlariRnyxCf6sn4Fpu9H9bt6yttCez6NHqAoZCwciXyo+UrZjFawSVg= =8gci -----END PGP SIGNATURE-----