From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsUqv-0007sE-DT for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 11:29:29 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.171 as permitted sender) client-ip=209.85.220.171; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f171.google.com; Received: from mail-qk0-f171.google.com ([209.85.220.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsUqu-000362-G8 for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 11:29:29 +0000 Received: by qku63 with SMTP id 63so25504399qku.3 for ; Wed, 13 May 2015 04:29:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.150.209 with SMTP id 200mr27153675qhw.9.1431516563136; Wed, 13 May 2015 04:29:23 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 04:29:23 -0700 (PDT) In-Reply-To: References: <5550D8BE.6070207@electrum.org> <5551F376.4050008@electrum.org> <555210AF.3090705@electrum.org> <55531E19.3090503@electrum.org> Date: Wed, 13 May 2015 12:29:23 +0100 Message-ID: From: Tier Nolan To: Alex Mizrahi Content-Type: multipart/alternative; boundary=001a11356f763caa1e0515f4ec16 X-Spam-Score: 0.9 (/) 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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 1.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YsUqu-000362-G8 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Long-term mining incentives 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: Wed, 13 May 2015 11:29:29 -0000 --001a11356f763caa1e0515f4ec16 Content-Type: text/plain; charset=UTF-8 On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi wrote: > > But this matters if a new node has access to the globally strongest chain. > A node only needs a path of honest nodes to the network. If a node is connected to 99 dishonest nodes and 1 honest node, it can still sync with the main network. > > In practice, Bitcoin already embraces "weak subjectivity" e.g. in form of > checkpoints embedded into the source code. So it's hard to take PoW purists > seriously. > > That isn't why checkpoints exist. They are to prevent a disk consumption DOS attack. They also allow verification to go faster. Signature operations are assumed to be correct without checking if they are in blocks before the last checkpoint. They do protect against multi-month forks though, even if not the reason that they exist. If releases happen every 6 months, and the checkpoint is 3 months deep at release, then for the average node, the checkpoint is 3 to 9 months old. A 3 month reversal would be devastating, so the checkpoint isn't adding much extra security. With headers first downloading, the checkpoints could be removed. They could still be used for speeding up verification of historical blocks. Blocks behind the last checkpoint wouldn't need their signatures checked. Removing them could cause a hard-fork though, so maybe they could be defined as legacy artifacts of the blockchain. Future checkpoints could be advisory. --001a11356f763caa1e0515f4ec16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi <alex.mizrahi@gmai= l.com> wrote:

But this matters if a new node has access to the globally stro= ngest chain.

A node only = needs a path of honest nodes to the network.

If a node is= connected to 99 dishonest nodes and 1 honest node, it can still sync with = the main network.
=

In practice,= Bitcoin already embraces "weak subjectivity" e.g. in form of che= ckpoints embedded into the source code. So it's hard to take PoW purist= s seriously.


That isn't why checkpoints exist.= =C2=A0 They are to prevent a disk consumption DOS attack.

They also allow verification to go faster.=C2=A0 Signature operations are = assumed to be correct without checking if they are in blocks before the las= t checkpoint.

They do protect against multi-month forks t= hough, even if not the reason that they exist.

If release= s happen every 6 months, and the checkpoint is 3 months deep at release, th= en for the average node, the checkpoint is 3 to 9 months old.

=
A 3 month reversal would be devastating, so the checkpoint isn't a= dding much extra security.

With headers first downloading= , the checkpoints could be removed.=C2=A0 They could still be used for spee= ding up verification of historical blocks.=C2=A0 Blocks behind the last che= ckpoint wouldn't need their signatures checked.

Removing them could cause a hard-fork though, so maybe they could be = defined as legacy artifacts of the blockchain.=C2=A0 Future checkpoints cou= ld be advisory.
--001a11356f763caa1e0515f4ec16--