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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
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 0D5DCBB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 00:52:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f47.google.com (mail-la0-f47.google.com
[209.85.215.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAAB9F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 00:52:00 +0000 (UTC)
Received: by lagc2 with SMTP id c2so29466682lag.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jun 2015 17:51:59 -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=TzaE61dp2NJtQdO5J+bGZw68wKFiOeWCxe3/ZZ3P3VE=;
b=cJDsIy9OY6c49d301tAJVMzGwecyBoMOxAOAKUKikbOsJNlh2ycl4nGT0OyePAlnyt
NSjuNm4uikxz1UQzGadryDscGaWsLXCDVwP8h+nkja3PapJRJ+j5o/3kyA5oFCv+QUxI
+XkxQE9Np4urgAdr63FlVq++2YIVIgI1qB0/4dy8cugvE5IH1opizXiaMTsTPajbdPUY
e+O5WlHDVa8gKgbcuGtNq6QpuLWKcPEOHFRqOD/qg3aU3HUBRBF54blDNyCsIspyrb1O
FayNXPf/VQltU9D/A6ieQBRf11Z4924i7rG7QbwUHYmOSmfoeu9tJrskfC9Bl6JQ8nbZ
kXLA==
MIME-Version: 1.0
X-Received: by 10.152.43.134 with SMTP id w6mr15261770lal.120.1435625518881;
Mon, 29 Jun 2015 17:51:58 -0700 (PDT)
Received: by 10.114.184.175 with HTTP; Mon, 29 Jun 2015 17:51:58 -0700 (PDT)
Received: by 10.114.184.175 with HTTP; Mon, 29 Jun 2015 17:51:58 -0700 (PDT)
In-Reply-To: <5591E10F.9000008@thinlink.com>
References: <20150629050726.GA502@savin.petertodd.org>
<5591E10F.9000008@thinlink.com>
Date: Tue, 30 Jun 2015 02:51:58 +0200
Message-ID: <CAAt2M1_yiN8ouaTdiyx8n8CkaT=e-pdUqqtde-bC32enqLfHog@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=001a11c1a8081564cc0519b19d3b
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 00:52:02 -0000
--001a11c1a8081564cc0519b19d3b
Content-Type: text/plain; charset=UTF-8
Den 30 jun 2015 02:21 skrev "Tom Harding" <tomh@thinlink.com>:
>
> On 6/28/2015 10:07 PM, Peter Todd wrote:
>>
>> Worryingly large payment providers have shown
>> willingness(4) to consider extreme measures such as entering into legal
>> contracts directly with large miners to ensure their transactions get
mined.
>> This is a significant centralization risk and it is not practical or even
>> possible for small miners to enter into these contracts, leading to a
situation
>> where moving your hashing power to a larger pool will result in higher
profits
>> from hashing power contracts; if these payment providers secure a
majority of
>> hashing power with these contracts inevitably there will be a temptation
to
>> kick non-compliant miners off the network entirely with a 51% attack.
>>
>
> Your incomprehensible meddling with successful usage patterns threatens
to have unintended consequences directly in opposition to your own stated
goal of decentralization. And yet you persist.
>
> As we deliberately break things and turn the P2P network into a
completely unpredictable hodge-podge of relay policies, we should expect
many more participants to bypass the P2P network entirely.
What you are asking for is TSA style reactive security and unverifiable and
fundamentally untrustable security mechanisms, rejecting proactive security
on the grounds that it is inconvenient.
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.
You want verifiable behavior? Incentives to tell the truth? Incentives to
be consistent? Multisignature notaries (Greenaddress.it), payment channel
based hub-and-spokes (LN, Stroem), etc... Trusting the P2P network is
futile. You need one accountable party that is actually capable of
enforcing the behavior you ask for, one that can build a reputation over
time - the P2P nodes you wish to hold accountable are on the other hand
powerless to stop an actual attack, their reputations are therefore
meaningless and irrelevant. Multisignature notaries aren't, as they can
stop an attack, and they can be sued for breach of contract if they don't -
neither of those applies to P2P nodes.
--001a11c1a8081564cc0519b19d3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 30 jun 2015 02:21 skrev "Tom Harding" <<a href=3D"mailto:t=
omh@thinlink.com">tomh@thinlink.com</a>>:<br>
><br>
> On 6/28/2015 10:07 PM, Peter Todd wrote:<br>
>><br>
>> Worryingly large payment providers have shown<br>
>> willingness(4) to consider extreme measures such as entering into =
legal<br>
>> contracts directly with large miners to ensure their transactions =
get mined.<br>
>> This is a significant centralization risk and it is not practical =
or even<br>
>> possible for small miners to enter into these contracts, leading t=
o a situation<br>
>> where moving your hashing power to a larger pool will result in hi=
gher profits<br>
>> from hashing power contracts; if these payment providers secure a =
majority of<br>
>> hashing power with these contracts inevitably there will be a temp=
tation to<br>
>> kick non-compliant miners off the network entirely with a 51% atta=
ck.<br>
>><br>
><br>
> Your incomprehensible meddling with successful usage patterns threaten=
s to have unintended consequences directly in opposition to your own stated=
goal of decentralization.=C2=A0 And yet you persist.<br>
><br>
> As we deliberately break things and turn the P2P network into a comple=
tely unpredictable hodge-podge of relay policies, we should expect many mor=
e participants to bypass the P2P network entirely.</p>
<p dir=3D"ltr">What you are asking for is TSA style reactive security and u=
nverifiable and fundamentally untrustable security mechanisms, rejecting pr=
oactive security on the grounds that it is inconvenient. </p>
<p dir=3D"ltr">What you ask to see implemented will trivially fall to a syb=
il attack. It isn't securable. It is running on the honor system exclus=
ively. It will be attacked, it will fail, losses will be had, the attackers=
will walk away with embarrassingly large sums. </p>
<p dir=3D"ltr">You want verifiable behavior? Incentives to tell the truth? =
Incentives to be consistent? Multisignature notaries (Greenaddress.it), pay=
ment channel based hub-and-spokes (LN,=C2=A0 Stroem), etc... Trusting the P=
2P network is futile. You need one accountable party that is actually capab=
le of enforcing the behavior you ask for, one that can build a reputation o=
ver time - the P2P nodes you wish to hold accountable are on the other hand=
powerless to stop an actual attack, their reputations are therefore meanin=
gless and irrelevant. Multisignature notaries aren't, as they can stop =
an attack, and they can be sued for breach of contract if they don't - =
neither of those applies to P2P nodes. </p>
--001a11c1a8081564cc0519b19d3b--
|
