From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsWiR-0004uW-Bs for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 13:28:51 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.170 as permitted sender) client-ip=209.85.220.170; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f170.google.com; Received: from mail-qk0-f170.google.com ([209.85.220.170]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsWiQ-0002iR-DQ for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 13:28:51 +0000 Received: by qkgx75 with SMTP id x75so27815296qkg.1 for ; Wed, 13 May 2015 06:28:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.107.165 with SMTP id h34mr25979392qgf.63.1431523725014; Wed, 13 May 2015 06:28:45 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 06:28:44 -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 14:28:44 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1139594e1dfb140515f697dd X-Spam-Score: 2.2 (++) 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.2 MISSING_HEADERS Missing To: header 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.9 MALFORMED_FREEMAIL Bad headers on message from free email service -0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YsWiQ-0002iR-DQ 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 13:28:51 -0000 --001a1139594e1dfb140515f697dd Content-Type: text/plain; charset=UTF-8 On Wed, May 13, 2015 at 1:26 PM, Alex Mizrahi wrote: > He tries to investigate, and after some time discovers that his router (or > his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of > the legitimate nodes, and thus got a complete fake chain from the attacker. > Bitcoins he received were totally fake. > > Bitcoin Core did a shitty job and confirmed some fake transactions. > 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. Even encrypted connections are pointless without authentication of who you are communicating with. Again, it is part of the security model that you can connect to at least one honest node. Someone tweated all the bitcoin headers at one point. The problem is that if everyone uses the same check, then that source can be compromised. > WIthout checkpoints an attacker could prepare a fork for $10. > With checkpoints, it would cost him at least $1000, but more likely upwards of $100000. > That's quite a difference, no? Headers first mean that you can't knock a synced node off the main chain without winning the POW race. Checkpoints can be replaced with a minimum amount of POW for initial sync. This prevents spam of low POW blocks. Once a node is on a chain with at least that much POW, it considers it the main chain., --001a1139594e1dfb140515f697dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 13, 2015 at 1:26 PM, Alex Mizrahi <alex.mizrahi@gmail.com= > wrote:
He tries to investigate, and after some time discovers t= hat his router (or his ISP's router) was hijacked. His Bitcoin node cou= ldn't connect to any of the legitimate nodes, and thus got a complete f= ake chain from the attacker.
Bitcoins he received were totally fa= ke.

Bitcoin Core did a shitty job and confirmed so= me fake transactions.

I don'= ;t really see how you can protect against total isolation of a node (POS or= POW).=C2=A0 You would need to find an alternative route for the informatio= n.=C2=A0

Even encrypted connections are pointless withou= t authentication of who you are communicating with.=C2=A0

Again, it is part of the security model that you can connect to at least = one honest node.

Someone tweated al= l the bitcoin headers at one point.=C2=A0 The problem is that if everyone u= ses the same check, then that source can be compromised.

> WIthout checkpoints an = attacker could prepare a fork for $10.
> With checkpoints, it would = cost him at least $1000, but more likely upwards of $100000.
>= That's quite a difference, no?

Headers first mean th= at you can't knock a synced node off the main chain without winning the= POW race.=C2=A0

Checkpoints can be replaced with a minimum amount = of POW for initial sync.=C2=A0 This prevents spam of low POW blocks.=C2=A0 = Once a node is on a chain with at least that much POW, it considers it the = main chain.,
--001a1139594e1dfb140515f697dd--