From: Alex Mizrahi <alex.mizrahi@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Date: Wed, 13 May 2015 17:26:52 +0300 [thread overview]
Message-ID: <CAE28kUQveZ9BVAG9XSnwxv0aGBx7sMpe7kPXvvO0Zr7Q9A3vjA@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWBVjUog7m9C4P4BHeZe6dy7Dt9f3+kSa6f3v3=oNQJmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
> I don't really see how you can protect against total isolation of a node
> (POS or POW). You would need to find an alternative route for the
> information.
>
"Alternative route for the information" is the whole point of weak
subjectivity, no?
PoS depends on weak subjectivity to prevent "long term reversals", but
using it also prevents "total isolation" attacks.
The argument that PoW is better than PoS because PoS has to depend on weak
subjectivity, but PoW doesn't is wrong.
Any practical implementation of PoW will also have to rely on weak
subjectivity to be secure against isolation attack.
And if we have to rely on weak subjectivity anyway, then why not PoS?
> Again, it is part of the security model that you can connect to at least
> one honest node.
>
This is the security model of PoW-based consensus. If you study
PoW-consensus, then yes, this is the model you have to use.
But people use Bitcoin Core as a piece of software. They do not care what
security model you use, they expect it to work.
If there are realistic scenarios in which it fails, then this must be
documented. Users should be made aware of the problem, should be able to
take preventative measures (e.g. manually check the latest block against
sources they trust), etc.
> The problem is that if everyone uses the same check, then that source can
> be compromised.
>
Yes, this problem cannot be solved in a 100% decentralized and automatic
way.
Which doesn't mean it's not worth solving, does it?
1. There are non-decentralized, trust-based solutions: refuse to work if
none of well-known nodes are accessible.
Well-known nodes are already used for bootstrapping, and this is another
point which can be attacked.
So if it's impossible to make it 100% decentralized and secure, why not
make it 99% decentralized and secure?
2. It is a common practice to check sha256sum after downloading the
package, and this is usually done manually.
Why can't checking block hashes against some source become a common
practice as well?
Also it's worth noting that these security measures are additive.
Isolating a node AND hijacking one of well-known nodes AND hijacking a
block explorer site user checks hashes against is exponentially harder than
defeating a single measure.
[-- Attachment #2: Type: text/html, Size: 3696 bytes --]
next prev parent reply other threads:[~2015-05-13 14:26 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 [this message]
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=CAE28kUQveZ9BVAG9XSnwxv0aGBx7sMpe7kPXvvO0Zr7Q9A3vjA@mail.gmail.com \
--to=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