From: "Jorge Timón" <jtimon@jtimon•cc>
To: Alex Mizrahi <alex.mizrahi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Date: Thu, 14 May 2015 01:46:04 +0200 [thread overview]
Message-ID: <CABm2gDoOGcdUeo_xgPp7w7AFs3Fza5VdeqSyV-T9MNhuN3RMeA@mail.gmail.com> (raw)
In-Reply-To: <CAE28kURWFveC0B-WvFebMpGm1GY-8juxQ+UDpuYtOwVnbOgu-A@mail.gmail.com>
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
> But this matters if a new node has access to the globally strongest chain.
> If attacker is able to block connections to legitimate nodes, a new node
> will happily accept attacker's chain.
If you get isolated from the network you may not get the longest valid
chain. I don't think any other consensus mechanism deals with this
better than Bitcoin.
> So PoW, by itself, doesn't give strong security guarantees. This problem is
> so fundamental people avoid talking about it.
>
> 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.
Checkpoints are NOT part of the consensus rules, they're just an
optimization that can be removed.
Try keeping the genesis block as your only checkpoint and rebuild: it
will work. You can also define your own checkpoints, there's no need
for everyone to use the same ones.
In a future with committed utxo the optimization could be bigger, but
still, we shouldn't rely on checkpoints for consensus, they're just an
optimization and you should only trust checkpoints that are buried in
the chain. Trusting a committed utxo checkpoint from 2 years ago
doesn't seem very risky. If the code is not already done (not really
sure if it was done as part of auto-prune), we should be prepared for
reorgs that invalidate checkpoints.
So, no, Bitcoin does NOT rely on that "weak subjectivity" thing.
next prev parent reply other threads:[~2015-05-14 0:38 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
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 [this message]
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=CABm2gDoOGcdUeo_xgPp7w7AFs3Fza5VdeqSyV-T9MNhuN3RMeA@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--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