Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsXch-0006CG-R5 for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 14:26:59 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.182 as permitted sender) client-ip=209.85.212.182; envelope-from=alex.mizrahi@gmail.com; helo=mail-wi0-f182.google.com; Received: from mail-wi0-f182.google.com ([209.85.212.182]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsXcg-0000aD-MH for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 14:26:59 +0000 Received: by widdi4 with SMTP id di4so58130606wid.0 for ; Wed, 13 May 2015 07:26:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.78.49 with SMTP id y17mr19312056wjw.131.1431527212663; Wed, 13 May 2015 07:26:52 -0700 (PDT) Received: by 10.27.102.73 with HTTP; Wed, 13 May 2015 07:26:52 -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 17:26:52 +0300 Message-ID: From: Alex Mizrahi To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7bfcf1deff52bb0515f766c8 X-Spam-Score: -0.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 (alex.mizrahi[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 X-Headers-End: 1YsXcg-0000aD-MH 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 14:26:59 -0000 --047d7bfcf1deff52bb0515f766c8 Content-Type: text/plain; charset=UTF-8 > 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. --047d7bfcf1deff52bb0515f766c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
<= div class=3D"gmail_quote">
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.=C2= =A0

"Alternati= ve route for the information" is the whole point of weak subjectivity,= no?

PoS depends on weak subjectivity to prevent &= quot;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 impleme= ntation of PoW will also have to rely on weak subjectivity to be secure aga= inst isolation attack.
And if we have to rely on weak subjectivit= y anyway, then why not PoS?
=C2=A0
Again, = it is part of the security model that you can connect to at least one hones= t node.

This is= the security model of PoW-based consensus. If you study PoW-consensus, the= n yes, this is the model you have to use.

But peop= le use Bitcoin Core as a piece of software. They do not care what security = model you use, they expect it to work.=C2=A0
If there are realist= ic 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.
=C2=A0
The problem is that if everyone uses t= he 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 no= n-decentralized, trust-based solutions: refuse to work if none of well-know= n nodes are accessible.
Well-known nodes are already used for boo= tstrapping, and this is another point which can be attacked.
So i= f it's impossible to make it 100% decentralized and secure, why not mak= e it 99% decentralized and secure?

2. It is a comm= on practice to check sha256sum after downloading the package, and this is u= sually done manually.
Why can't checking block hashes against= some source become a common practice as well?

=C2=A0
Also it's worth noting that these security measures a= re additive.
Isolating a node AND hijacking one of well-known nod= es AND hijacking a block explorer site user checks hashes against is expone= ntially harder than defeating a single measure.

<= /div>
--047d7bfcf1deff52bb0515f766c8--