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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <justusranvier@riseup.net>) id 1Z5ybP-0003ER-Qw
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:53:11 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129;
envelope-from=justusranvier@riseup.net; helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z5ybM-00060h-1D
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 15:53:11 +0000
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 1023641DBB;
Fri, 19 Jun 2015 15:53:02 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: justusranvier) with ESMTPSA id DF79C22BC1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Date: Fri, 19 Jun 2015 15:53:01 +0000
From: justusranvier@riseup.net
To: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
<c2a392703d02e1d674a029c60deb6d94@riseup.net>
<20150619151127.GA11263@savin.petertodd.org>
<04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
Message-ID: <812d8353e66637ec182da31bc0a9aac1@riseup.net>
X-Sender: justusranvier@riseup.net
User-Agent: Riseup mail
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.9 (-)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
-0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5ybM-00060h-1D
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
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: Fri, 19 Jun 2015 15:53:11 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015-06-19 15:37, Eric Lombrozo wrote:
> OK, a few things here:
>=20
> The Bitcoin network was designed (or should be designed) with the
> requirement that it can withstand deliberate double-spend attacks that
> can come from anywhere at any time=E2=80=A6and relaxing this assumption
> without adequately assessing the risk (i.e. I=E2=80=99ve never been hac=
ked
> before so I can assume it=E2=80=99s safe) is extremely dangerous at bes=
t and
> just horrid security practice at worst. Your users might not thank you
> for not getting hacked - but they surely will not like it when you DO
> get hacked=E2=80=A6and lack a proper recovery plan.
>=20
> Furthermore, the protocol itself makes no assumptions regarding the
> intentions behind someone signing two conflicting transactions. There
> are many potential use cases where doing so could make a lot of sense.
> Had the protocol been designed along the lines of, say,
> tendermint=E2=80=A6where signing multiple conflicting blocks results in=
loss
> of one=E2=80=99s funds=E2=80=A6then the protocol itself disincentivizes=
the behavior
> without requiring any sort of altruistic, moralistic assumptions. That
> would also mean we=E2=80=99d need a different mechanism for the use cas=
es that
> things like RBF address.
>=20
> Thirdly, taken to the extreme, the viewpoint of =E2=80=9Csigning a conf=
licting
> transaction is fraud and vandalism=E2=80=9D means that if for whatever =
reason
> you attempt to propagate a transaction and nobody mines it for a very
> long time, you=E2=80=99re not entitled to immediately reclaim those fun=
ds=E2=80=A6they
> must remain in limbo forever.
I'm not talking about changing the protocol - I'm talking about the=20
business relationships between users of Bitcoin.
I would expect a payment processor to inform the merchants of relevant=20
double spends that it observes on the network, even if the payment is=20
actually successful, so that the merchant can decide for themselves=20
whether or not to pursue it out of band.
Mining is a kind of technical fallback that allows the network to=20
resolve human misbehavior without human intervention. If nobody ever=20
attempted to make a fraudulent payment, we wouldn't need mining at all=20
because the signed transaction itself is proof of intention to pay. That=20
it exists doesn't suddenly make fraud less fraudulent and mean that=20
users who are in a position to pursue out of band recourse shouldn't do=20
so.
I agree that there are valid reasons for replacing transactions in the=20
mempool, I just think they should be implemented in a way that doesn't=20
facilitate fraud.
I'd also like to note that "prima facie" doesn't mean "always", it means=20
that "the default assumption, unless proven otherwise."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk
3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM
Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq
7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ
uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3
oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+
unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED
Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10
+oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46
4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo
i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle
eWvElyVQJsJHgAU8ygvn
=3D77NP
-----END PGP SIGNATURE-----
|
