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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C86F2AAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 01:10:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com
[209.85.215.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A21932
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 01:10:25 +0000 (UTC)
Received: by lagc2 with SMTP id c2so29805597lag.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jun 2015 18:10:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=RX0DoVi6X9TYoiVglml/iQHB2C/6vuyAlp8HQtS/BYc=;
b=coXOSVxrUbz3qORS+Xden+TKx+d4rlkArKb3gpiqf2RIBi7MU8crT8sFgwoLGF2Ram
+TAkWTKphl/p7TIr2XzUO7ZbRHxh4WWenCw5vmZ0RZ0WB7qLsrWwisiUmJUzC/aE7LaT
nVlVJwWBM47oN1LVOTnNcsDBI2bkzSTsflH4RoSL5R4/t3EHZ69ThPKFiGb3AHzeGzoN
6Dd7NXSkX4QteVSeXC5B39qXI9Y/ewQVi9/6aNGxYRk1cjknfQwHeTRXLbAxLVtmLCoh
x8WJ83eDOqfZE3K9SSir4pn+7So4bLo/VOXc5V2Cnp4iLM3M4cDiTL01S+51vGxdqCxQ
qUFw==
MIME-Version: 1.0
X-Received: by 10.152.43.134 with SMTP id w6mr15313059lal.120.1435626623634;
Mon, 29 Jun 2015 18:10:23 -0700 (PDT)
Received: by 10.114.184.175 with HTTP; Mon, 29 Jun 2015 18:10:23 -0700 (PDT)
Received: by 10.114.184.175 with HTTP; Mon, 29 Jun 2015 18:10:23 -0700 (PDT)
In-Reply-To: <5591EA1B.1050709@thinlink.com>
References: <20150629050726.GA502@savin.petertodd.org>
<5591E10F.9000008@thinlink.com>
<CAAt2M1_yiN8ouaTdiyx8n8CkaT=e-pdUqqtde-bC32enqLfHog@mail.gmail.com>
<5591EA1B.1050709@thinlink.com>
Date: Tue, 30 Jun 2015 03:10:23 +0200
Message-ID: <CAAt2M18Bbcp8-saF7FbkY1vp9rUihStaTXawB9JjafX=+ZasFw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=001a11c1a808ee97620519b1de36
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 01:10:25 -0000
--001a11c1a808ee97620519b1de36
Content-Type: text/plain; charset=UTF-8
Den 30 jun 2015 03:00 skrev "Tom Harding" <tomh@thinlink.com>:
>
> On 6/29/2015 5:51 PM, Natanael wrote:
>>
>> What you ask to see implemented will trivially fall to a sybil attack.
It isn't securable. It is running on the honor system exclusively. It will
be attacked, it will fail, losses will be had, the attackers will walk away
with embarrassingly large sums.
>
>
> Oh please. Checking that a node does relay something is not much
different than banning it for relaying garbage.
>
> It just happens to require that you have two nodes and coordinate them
somehow. I didn't offer a complete design, don't claim magical properties,
and certainly didn't mean to imply that nodes passing a test could be
trusted (as you suggest with your "accountable parties").
But the check means nothing at all to you since no information which you
can learn from doing so can be trusted for use in decision making of any
kind, so why do it? Unless you pay for hosting of that particular node
which you test, you have no reason to care for any reason other than simple
statistics.
The claims I made is based on simple economic analysis - if *to be able to
attack* first requires effort and risk that exceed the payoff, you're
unlikely to try. Being legally accountable and identified in advance and
having to build reputation before being trusted with attack-worthy sums is
strongly discouraging.
--001a11c1a808ee97620519b1de36
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 30 jun 2015 03:00 skrev "Tom Harding" <<a href=3D"mailto:t=
omh@thinlink.com">tomh@thinlink.com</a>>:<br>
><br>
> On 6/29/2015 5:51 PM, Natanael wrote:<br>
>><br>
>> What you ask to see implemented will trivially fall to a sybil att=
ack. It isn't securable. It is running on the honor system exclusively.=
It will be attacked, it will fail, losses will be had, the attackers will =
walk away with embarrassingly large sums. <br>
><br>
><br>
> Oh please.=C2=A0 Checking that a node does relay something is not much=
different than banning it for relaying garbage.<br>
><br>
> It just happens to require that you have two nodes and coordinate them=
somehow.=C2=A0 I didn't offer a complete design, don't claim magic=
al properties, and certainly didn't mean to imply that nodes passing a =
test could be trusted (as you suggest with your "accountable parties&q=
uot;).</p>
<p dir=3D"ltr">But the check means nothing at all to you since no informati=
on which you can learn from doing so can be trusted for use in decision mak=
ing of any kind, so why do it? Unless you pay for hosting of that particula=
r node which you test, you have no reason to care for any reason other than=
simple statistics. </p>
<p dir=3D"ltr">The claims I made is based on simple economic analysis - if =
*to be able to attack* first requires effort and risk that exceed the payof=
f, you're unlikely to try. Being legally accountable and identified in =
advance and having to build reputation before being trusted with attack-wor=
thy sums is strongly discouraging. </p>
--001a11c1a808ee97620519b1de36--
|
