1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
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 <tier.nolan@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAE28kUR-0ozFg6D4Es7RCm1pA5xaW-E1R_YSTRRTj3z4XXiWxw@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
<5551F376.4050008@electrum.org>
<CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
<555210AF.3090705@electrum.org>
<CABsx9T3AxM3et7hgXx3+Rn3BvhQkF-Cn797sHcyztkMpD1UQmA@mail.gmail.com>
<55531E19.3090503@electrum.org>
<CAE-z3OXa8vk6Q1EBChoRYDOLKw--CXNXz4AokXCbVam_8LFFDg@mail.gmail.com>
<CAE28kURWFveC0B-WvFebMpGm1GY-8juxQ+UDpuYtOwVnbOgu-A@mail.gmail.com>
<CAE-z3OVBUu=6sqNc3RUJqFPuqhPdw1Ej0RZ-tSygoQ6LowhVXg@mail.gmail.com>
<CAE28kUR-0ozFg6D4Es7RCm1pA5xaW-E1R_YSTRRTj3z4XXiWxw@mail.gmail.com>
Date: Wed, 13 May 2015 14:28:44 +0100
Message-ID: <CAE-z3OWBVjUog7m9C4P4BHeZe6dy7Dt9f3+kSa6f3v3=oNQJmQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <alex.mizrahi@gmail.com>
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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 13, 2015 at 1:26 PM, Alex Mizrahi <span dir=3D"ltr"><<a href=3D"=
mailto:alex.mizrahi@gmail.com" target=3D"_blank">alex.mizrahi@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div>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.</div><div>Bitcoins he received were totally fa=
ke.</div><div><br></div><div>Bitcoin Core did a shitty job and confirmed so=
me fake transactions.</div></div></blockquote><div><br></div><div>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 <br><br></div><div>Even encrypted connections are pointless withou=
t authentication of who you are communicating with.=C2=A0 <br><br></div><di=
v>Again, it is part of the security model that you can connect to at least =
one honest node.<br></div><div><br></div><div></div><div>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.<br></div><div></di=
v></div><div class=3D"gmail_quote"><br><div><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><span class=3D"">> </span>WIthout checkpoints an =
attacker could prepare a fork for $10.<div>> With checkpoints, it would =
cost him at least $1000, but more likely upwards of $100000.</div><div>>=
That's quite a difference, no?<br><br></div><div>Headers first mean th=
at you can't knock a synced node off the main chain without winning the=
POW race.=C2=A0 <br><br>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.,<br></div></div></div></div></div></div></div>
--001a1139594e1dfb140515f697dd--
|
