From: Tier Nolan <tier.nolan@gmail•com>
To: Alex Mizrahi <alex.mizrahi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Date: Wed, 13 May 2015 12:29:23 +0100 [thread overview]
Message-ID: <CAE-z3OVBUu=6sqNc3RUJqFPuqhPdw1Ej0RZ-tSygoQ6LowhVXg@mail.gmail.com> (raw)
In-Reply-To: <CAE28kURWFveC0B-WvFebMpGm1GY-8juxQ+UDpuYtOwVnbOgu-A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi <alex.mizrahi@gmail•com>
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.
[-- Attachment #2: Type: text/html, Size: 2276 bytes --]
next prev parent reply other threads:[~2015-05-13 11:29 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 16:28 Thomas Voegtlin
2015-05-11 16:52 ` insecurity
2015-05-11 17:29 ` Gavin Andresen
2015-05-12 12:35 ` Thomas Voegtlin
[not found] ` <CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
[not found] ` <555210AF.3090705@electrum.org>
2015-05-12 16:10 ` Gavin Andresen
2015-05-12 16:21 ` Dave Hudson
2015-05-12 21:24 ` Pedro Worcel
2015-05-12 23:48 ` Adam Back
2015-05-13 15:41 ` Gavin Andresen
2015-05-13 20:05 ` Pedro Worcel
2015-05-13 9:49 ` Thomas Voegtlin
2015-05-13 10:14 ` Tier Nolan
2015-05-13 10:31 ` Alex Mizrahi
2015-05-13 11:29 ` Tier Nolan [this message]
2015-05-13 12:26 ` Alex Mizrahi
2015-05-13 13:24 ` Gavin
2015-05-13 13:28 ` Tier Nolan
2015-05-13 14:26 ` Alex Mizrahi
2015-05-13 23:46 ` Jorge Timón
2015-05-14 0:11 ` Jorge Timón
2015-05-14 0:48 ` Aaron Voisine
2015-05-14 0:58 ` Pieter Wuille
2015-05-14 1:13 ` Aaron Voisine
2015-05-14 1:19 ` Pieter Wuille
2015-05-14 1:31 ` Aaron Voisine
2015-05-14 2:34 ` Aaron Voisine
2015-05-16 20:35 ` Owen Gunden
2015-05-16 22:18 ` Tom Harding
2015-05-17 1:08 ` Aaron Voisine
2015-05-14 0:44 ` Melvin Carvalho
2015-05-25 18:31 ` Mike Hearn
2015-05-26 18:47 ` Thomas Voegtlin
2015-05-27 21:59 ` Mike Hearn
2015-05-27 22:22 ` Gregory Maxwell
2015-05-28 10:30 ` Mike Hearn
2015-05-13 17:49 Damian Gomez
2015-05-18 2:29 Michael Jensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE-z3OVBUu=6sqNc3RUJqFPuqhPdw1Ej0RZ-tSygoQ6LowhVXg@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=alex.mizrahi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox