From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsH5f-0001ZX-7Z for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 20:47:47 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.174 as permitted sender) client-ip=209.85.223.174; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f174.google.com; Received: from mail-ie0-f174.google.com ([209.85.223.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsH5e-00028z-IR for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 20:47:47 +0000 Received: by iecmd7 with SMTP id md7so13410511iec.1 for ; Tue, 12 May 2015 13:47:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.142.67 with SMTP id ru3mr6324883igb.40.1431463661358; Tue, 12 May 2015 13:47:41 -0700 (PDT) Received: by 10.107.15.82 with HTTP; Tue, 12 May 2015 13:47:41 -0700 (PDT) In-Reply-To: References: <20150512171640.GA32606@savin.petertodd.org> Date: Tue, 12 May 2015 20:47:41 +0000 Message-ID: From: Gregory Maxwell To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1YsH5e-00028z-IR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed additional options for pruned nodes 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: Tue, 12 May 2015 20:47:47 -0000 On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik wrote: > True. Part of the issue rests on the block sync horizon/cliff. There is a > value X which is the average number of blocks the 90th percentile of nodes > need in order to sync. It is sufficient for the [semi-]pruned nodes to keep > X blocks, after which nodes must fall back to archive nodes for older data. Prior discussion had things like "the definition of pruned means you have and will serve at least the last 288 from your tip" (which is what I put in the pruned service bip text); and another flag for "I have at least the last 2016". (2016 should be reevaluated-- it was just a round number near where sipa's old data showed the fetch probability flatlined. But that data was old, but what it showed that the probability of a block being fetched vs depth looked like a exponential drop-off (I think with a 50% at 3-ish days); plus a constant low probability. Which is probably what we should have expected. > There was even a more radical suggestion years ago - refuse to sync if too > old (>2 weeks?), and force the user to download ancient data via torrent. I'm not fond of this; it makes the system dependent on centralized services (e.g. trackers and sources of torrents). A torrent also cannot very efficiently handle fractional copies; cannot efficiently grow over time. Bitcoin should be complete-- plus, many nodes already have the data.