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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1YKoX6-0004Ky-18
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Feb 2015 13:37:48 +0000
X-ACL-Warn:
Received: from mail-pa0-f54.google.com ([209.85.220.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YKoX5-00065m-3v
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Feb 2015 13:37:48 +0000
Received: by mail-pa0-f54.google.com with SMTP id kx10so18804626pab.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Feb 2015 05:37:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=m/qiap5H0QaULwLgzBZ667YTNuJz1v8lGiLmSxN8Pp0=;
b=MibaeQeOrWAepKeUZ6HarGcx2rHAV/2SFOdA2JI+KoHzUljdMeQQv6sdrSWsG3Yd2H
skWdHOPthqlNPBlWqqSWYrxJRdENiF65jEzBsqWgNfQWO7SaDg3WrkU5lgijevkxLatp
DUQPf8cXO7v8s+URfryBuBF6bLLOckIsW0Mrpo6objwR+FgGcSi2EW+y6+nVlK1v7l8S
DVDof7d0SrCc+VgWnfAsGohPHbZlfO/H7jeGkV4/VUobzbvtMuf99FKcOPbMBt7hbQTk
ynnNCkXbijFGPeNDfTNrKYSTBhiyVGZCoSfpxLEyfVq0gK+fHXSG2gXjLUC/1tcyaNoK
WUpg==
X-Gm-Message-State: ALoCoQnwk3yDc2tJP1aKS0xo5CBhDzH/sl0qaikcEW3Z+4MNEBvJqemgwBlFmSov25+n2abfq+uQ
X-Received: by 10.70.130.69 with SMTP id oc5mr5333363pdb.160.1423489061332;
Mon, 09 Feb 2015 05:37:41 -0800 (PST)
Received: from [192.168.1.89] (99-6-44-248.lightspeed.sntcca.sbcglobal.net.
[99.6.44.248])
by mx.google.com with ESMTPSA id n2sm16475307pdo.0.2015.02.09.05.37.40
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 09 Feb 2015 05:37:40 -0800 (PST)
Message-ID: <54D8B823.7000300@thinlink.com>
Date: Mon, 09 Feb 2015 05:37:39 -0800
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <54D82BCF.1090200@thinlink.com>
<A2F3F5F0-29EF-412E-A170-6E9B064F2ACE@petertodd.org>
In-Reply-To: <A2F3F5F0-29EF-412E-A170-6E9B064F2ACE@petertodd.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YKoX5-00065m-3v
Subject: Re: [Bitcoin-development] Update to Double-Spend Deprecation Window
Proposal
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: Mon, 09 Feb 2015 13:37:48 -0000
Many thanks for the feedback Peter. Please if you would, see below
On 2/8/2015 10:32 PM, Peter Todd wrote:
> Seeing a transaction is not a guarantee that any other node has seen it; not seeing a transaction is not a guarantee other nodes have not seen a spend.
In no way does proposal rely on such assumptions. It develops local
rules which result in a desirable outcome for the network as a whole,
under the applicable statistics.
> you're measuring a network that isn't under attack; Bitcoin must be robust against attacks, and it must not create incentives to launch them.
Two specific attacks are addressed at some length. No one is keener
than I to learn of new ones, or flaws in those treatments.
> Institutionalising the punishment of miners being they did not have perfect connectivity - an unattainable goal in a trust less, decentralised system - is athema to the goals of having a decentralised systmem and will only lead to smaller mining operations being punished for being the victim of attacks on their network connectivity that are only made profitable by this proposal.
Building from unavoidable imperfections is the necessary spirit when
interfacing with physical reality. I would defer to miners whether
these specific worries outweigh the benefits of helping to achieve a 30
second network, rather than a 10±10 minute network.
> Equally your proposal actually makes it *easier* to pull off apparently single-confirm double-spend attacks - any miner who ignores a block containing the apparent double-spend is just as likely to be aiding an attacker trying to get a 1-conf transaction double-spent. This forces *everyone* to waiting *longer* before accepting a transaction because now even a single-confirmation is no longer good evidence of an accepted transaction. In an ecosystem where hardly anyone relies on zeroconf anyway your putting a much larger group of people at risk who weren't at risk before.
I agree on one point -- it is necessary to let transactions mature for
something on the order of 15 to 30 seconds before mining them, as
discussed in proposal. I quite disagree regarding Finney (1-conf)
attacks. In fact this proposal is the only one I've seen that actually
stops most Finney attacks -- all those where the block comes more than
30 seconds after tx1.
|
