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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsWe0-0003YI-En for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 13:24:16 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.42 as permitted sender) client-ip=209.85.192.42; envelope-from=gavinandresen@gmail.com; helo=mail-qg0-f42.google.com; Received: from mail-qg0-f42.google.com ([209.85.192.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsWdx-0002Z8-7C for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 13:24:16 +0000 Received: by qgeb100 with SMTP id b100so20995382qge.3 for ; Wed, 13 May 2015 06:24:07 -0700 (PDT) X-Received: by 10.140.28.102 with SMTP id 93mr26365505qgy.78.1431523447797; Wed, 13 May 2015 06:24:07 -0700 (PDT) Received: from ?IPv6:2600:1000:b11c:b9df:2d87:d588:1c81:617a? ([2600:1000:b11c:b9df:2d87:d588:1c81:617a]) by mx.google.com with ESMTPSA id 10sm15521129qhv.27.2015.05.13.06.24.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 May 2015 06:24:06 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1D350ADE-A483-4CFC-A151-4F92256CF5F9 Mime-Version: 1.0 (1.0) From: Gavin X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 13 May 2015 09:24:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5550D8BE.6070207@electrum.org> <5551F376.4050008@electrum.org> <555210AF.3090705@electrum.org> <55531E19.3090503@electrum.org> To: Alex Mizrahi 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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars -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: 1YsWdx-0002Z8-7C Cc: Bitcoin Dev 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:24:16 -0000 --Apple-Mail-1D350ADE-A483-4CFC-A151-4F92256CF5F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Checkpoints will be replaced by compiled-in 'at THIS timestamp the main chai= n had THIS much proof of work.' That is enough information to prevent attacks and still allow optimizations l= ike skipping signature checking for ancient transactions. I don't think anybody is proposing replacing checkpoints with nothing. -- Gavin Andresen > On May 13, 2015, at 8:26 AM, Alex Mizrahi wrote: >=20 > Let's consider a concrete example: >=20 > 1. User wants to accept Bitcoin payments, as his customers want this. > 2. He downloads a recent version of Bitcoin Core, checks hashes and so on.= (Maybe even builds from source.) > 3. Let's it to sync for several hours or days. > 4. After wallet is synced, he gives his address to customer. > 5. Customer pays.=20 > 6. User waits 10 confirmations and ships the goods. (Suppose it's somethin= g very expensive.) > 7. Some time later, user wants to convert some of his bitcoins to dollars.= He sends his bitcoins to an exchange but they never arrive. >=20 > 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. >=20 > Bitcoin Core did a shitty job and confirmed some fake transactions. > User doesn't care that if his network was not impaired, Bitcoin Core would= have worked properly. > The main duty of Bitcoin Core is to check whether transactions are confirm= ed, and if it can be fooled by a simple router hack, then it does its job po= orly. >=20 > If you don't see it being a problem, you should't be allowed to develop an= ything security-related. >=20 >> If a node is connected to 99 dishonest nodes and 1 honest node, it can st= ill sync with the main network. >=20 > Yes, it is good against Sybil attack, but not good against a network-level= attack. > Attack on user's routers is a very realistic, plausible attack. > Imagine if SSL could be hacked by hacking a router, would people still use= it? >=20 > Fucking no. > =20 >> A 3 month reversal would be devastating, so the checkpoint isn't adding m= uch extra security. >=20 > WIthout checkpoints an attacker could prepare a fork for $10. > With checkpoints, it would cost him at least $1000, but more likely upward= s of $100000. > That's quite a difference, no? >=20 > I do not care what do you think about the reasons why checkpoints were add= ed, but it is a fact that they make the attack scenario I describe above har= d to impossible. >=20 > Without checkpoints, you could perform this attack using a laptop. > With checkpoints, you need access to significant amounts of mining ASICs. >=20 > --------------------------------------------------------------------------= ---- > One dashboard for servers and applications across Physical-Virtual-Cloud=20= > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail-1D350ADE-A483-4CFC-A151-4F92256CF5F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Checkpoints will be replaced by compil= ed-in 'at THIS timestamp the main chain had THIS much proof of work.'
<= div>
That is enough information to prevent attacks and still a= llow optimizations like skipping signature checking for ancient transactions= .

I don't think anybody is proposing replacing chec= kpoints with nothing.

--
Gavin Andresen


On May 13, 2015, at 8:26 AM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:

Let's consider a concrete examp= le:

1. User wants to accept Bitcoin payments, as his cust= omers want this.
2. He downloads a recent version of Bitcoin Core,= checks hashes and so on. (Maybe even builds from source.)
3. Let'= s it to sync for several hours or days.
4. After wallet is synced,= he gives his address to customer.
5. Customer pays. 
6. User waits 10 confirmations and ships the goods. (Suppose it's somethi= ng very expensive.)
7. Some time later, user wants to convert some= of his bitcoins to dollars. He sends his bitcoins to an exchange but they n= ever arrive.

He tries to investigate, and after som= e time discovers that his router (or his ISP's router) was hijacked. His Bit= coin node couldn't connect to any of the legitimate nodes, and thus got a co= mplete fake chain from the attacker.
Bitcoins he received were tot= ally fake.

Bitcoin Core did a shitty job and confir= med some fake transactions.
User doesn't care that if his n= etwork was not impaired, Bitcoin Core would have worked properly.
The main duty of Bitcoin Core is to check whether transactions are co= nfirmed, and if it can be fooled by a simple router hack, then it does its j= ob poorly.

If you don't see it being a problem, you= should't be allowed to develop anything security-related.

If a node is connected to 99 dishonest nodes and 1 honest no= de, it can still sync with the main network.

Yes, it is good against Sybil attack, but not g= ood against a network-level attack.
Attack on user's routers is a v= ery realistic, plausible attack.
Imagine if SSL could be hacked by= hacking a router, would people still use it?

Fucki= ng no.
  
A= 3 month reversal would be devastating, so the checkpoint isn't adding much e= xtra security.

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

I do= not care what do you think about the reasons why checkpoints were added, bu= t it is a fact that they make the attack scenario I describe above hard to i= mpossible.

Without checkpoints, you could perform t= his attack using a laptop.
With checkpoints, you need access to si= gnificant amounts of mining ASICs.

--------------------= ----------------------------------------------------------
O= ne dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications<= /span>
Performance metrics, stats and reports that give you Actiona= ble Insights
Deep dive visibility with transaction tracing u= sing APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567= 292;y
____= ___________________________________________
Bitcoin-developm= ent mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
= --Apple-Mail-1D350ADE-A483-4CFC-A151-4F92256CF5F9--