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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Z6S00-0002w9-Bf
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 23:16:32 +0000
Received: from mail-wi0-f171.google.com ([209.85.212.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6Rzu-0001vd-HS
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 23:16:32 +0000
Received: by wiga1 with SMTP id a1so46989768wig.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 16:16:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=p9qKBFJzX1QLrIFji9cN0RohWz5hbid/gMLybK3EvOA=;
b=dWl9wRPqSs6gL/Kvbwa20Y1Pel7sk97SABz8dep5ixR5PnZG/t8UNJdwvjGamhLeTE
UelH05BbjNMqwzuCkTUdh7dytTgZ6DL2JWigwkepODuQV9EU/8lfkazzilZCyWhUp1eZ
Vlf7RvebpamML3bhBnIj/e3LBjhMTb+o3chjqit63KQwzVfGDhEOF1obVTk6ldNixCD+
7g6YWSR8laW7+J7f3JUjO9mdt7FfUXlhYJNQyJLIXNGSOTwYbVvcKlQcqBevjHvqKRY1
Q1MwXoEZ92pafNHyW5dzCQY8Jmxw1N9ZBj0n93+3P59BZ6rCyKCuaRymjcqHg8R9cyrd
As0w==
X-Gm-Message-State: ALoCoQlfo1IcXs+AAjLGFz8YMTVmyJBG8F9wW/uZK3sbcjDqwCaCOJBG0R+6SMXeue2VJ0Y5ucs+
MIME-Version: 1.0
X-Received: by 10.194.58.7 with SMTP id m7mr36319295wjq.109.1434842180449;
Sat, 20 Jun 2015 16:16:20 -0700 (PDT)
Received: by 10.194.139.235 with HTTP; Sat, 20 Jun 2015 16:16:20 -0700 (PDT)
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>
Date: Sun, 21 Jun 2015 01:16:20 +0200
Message-ID: <CABm2gDqsMtUdDZ+fWPZVUnoLTv-ziVM0hPs10L=9f3ZnRXD0fQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z6Rzu-0001vd-HS
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:16:32 -0000
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 require=
ment that it can withstand deliberate double-spend attacks that can come fr=
om anywhere at any time=E2=80=A6
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:
"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."
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.
Alternative policies are NOT attacks on the network.
|
