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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1Z6Scc-0008CJ-Mg
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 23:56:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.176 as permitted sender)
client-ip=209.85.192.176; envelope-from=elombrozo@gmail.com;
helo=mail-pd0-f176.google.com;
Received: from mail-pd0-f176.google.com ([209.85.192.176])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6Sca-00008W-PC
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 23:56:26 +0000
Received: by pdjn11 with SMTP id n11so114317433pdj.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 16:56:19 -0700 (PDT)
X-Received: by 10.70.54.7 with SMTP id f7mr44669874pdp.75.1434844579125;
Sat, 20 Jun 2015 16:56:19 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by mx.google.com with ESMTPSA id
ff10sm15368126pab.13.2015.06.20.16.56.16
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 20 Jun 2015 16:56:17 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_424FB76F-7675-4F34-9C54-4E4D658C6871";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <17636B68-7A3A-4412-96D7-38CCA7C44E27@gmail.com>
Date: Sat, 20 Jun 2015 16:56:14 -0700
Message-Id: <8C9DD3A9-05EF-4F92-89D3-4F72B39B7D8D@gmail.com>
References: <20150619103959.GA32315@savin.petertodd.org>
<c2a392703d02e1d674a029c60deb6d94@riseup.net>
<20150619151127.GA11263@savin.petertodd.org>
<04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com>
<CABm2gDqsMtUdDZ+fWPZVUnoLTv-ziVM0hPs10L=9f3ZnRXD0fQ@mail.gmail.com>
<17636B68-7A3A-4412-96D7-38CCA7C44E27@gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -1.3 (-)
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
(elombrozo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.3 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z6Sca-00008W-PC
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Justus Ranvier <justusranvier@riseup.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: Sat, 20 Jun 2015 23:56:26 -0000
--Apple-Mail=_424FB76F-7675-4F34-9C54-4E4D658C6871
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>=20
>=20
>> On Jun 20, 2015, at 4:16 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> =
wrote:
>>=20
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>>> 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=A6
>>=20
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>>=20
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>>=20
>> I can't say for sure what was meant by "attacking the network" in =
this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work =
in
>> the first place.
>>=20
>> Alternative policies are NOT attacks on the network.
>=20
> Just to be clear, Jorge, I wasn=E2=80=99t suggesting that unconfirmed =
transactions are part of any sort of global consensus. In fact, they =
very much AREN=E2=80=99T. Which is exactly why it is extremely dangerous =
to accept unconfirmed transactions as final unless you clearly have =
assessed the risks and it makes sense for the particular business use =
case.
>=20
> - Eric Lombrozo
I think the misunderstanding was in perhaps my earlier statement seemed =
like I was suggesting that it=E2=80=99s the protocol=E2=80=99s =
responsibility to protect merchants from double-spends. On the contrary =
- I think we agree - the protocol CANNOT make any guarantees to ANYONE =
until we do converge on a history. The =E2=80=9Cdesign=E2=80=9D I speak =
of here is more on the merchant side.
- Eric Lombrozo
--Apple-Mail=_424FB76F-7675-4F34-9C54-4E4D658C6871
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVhf2eAAoJEJNAI64YFENU7o0QAJVxRZ7EQIyk4/FhdiK0aESj
XHTMX1G556ugiucvVS6W4tmNPCiVArFZJOGhw7lx3SdmxKw1Dfo6iLJN2bN3j9rb
7C7tfZ1wfRIUQjetpk/T12hRj7MSKsPfEJXj7hdqZ0mi2/uQILT+9vg5vzRoD+mF
CajD3DV5aWUudhN9w2fHwStPQx4wLo1dgARknIuOxL21WDg7iB40NXv6qexSMBlE
IXnRMi6PpPlrA3PHHIwqoqICl6Ch7rmHpSASrhub1sRlQ+eTahW4czHCPdxcU1DA
bBdMOTlgG4P5DkYq18ti/qszmaCzBxiQ4iM6tH/pb/xjgdUVQU4G6dbv6O5DWcr7
Y7Xab4ftJPC+IrqAYQNVk21ei2YpYSSZPlpCJgK8lHEsjci9SYM2Qj9ebWI5B4LY
/mOdHgFW/3wiMOkjRkXeH8XtiPsFNMCP3M5MEjBDV13CjVkdRG0L15+RG0a6tPc5
JaHg3j73P7yln8sfr2r1md63aEodSyYD3Cq97ZyAzD9DpxeQdhI1i11wcNy3/H5K
gE1EQnhD38SshEaWArbXNzIdEm9eMqPqImRAWqoZxJ9Xdvb73XRkAulSdRmGQXeS
ZGbaZYhaE4a2OQEsNszQTqCbO+Qr/xJNF1hzblvM9RJf7AR2sg0rR0iR5aHFTxrp
JiESYtorZU2aB64DAqq9
=VPxh
-----END PGP SIGNATURE-----
--Apple-Mail=_424FB76F-7675-4F34-9C54-4E4D658C6871--
|
