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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YKhti-00030B-Nt
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Feb 2015 06:32:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.55 as permitted sender)
client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
helo=outmail149055.authsmtp.co.uk;
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YKhte-0005Jp-UP for bitcoin-development@lists.sourceforge.net;
Mon, 09 Feb 2015 06:32:42 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t196WWdP065755;
Mon, 9 Feb 2015 06:32:32 GMT
Received: from [10.205.129.65] ([209.226.201.243]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t196WVRf052584
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 9 Feb 2015 06:32:32 GMT
User-Agent: K-9 Mail for Android
In-Reply-To: <54D82BCF.1090200@thinlink.com>
References: <54D82BCF.1090200@thinlink.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Mon, 09 Feb 2015 00:32:24 -0600
To: Tom Harding <tomh@thinlink.com>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <A2F3F5F0-29EF-412E-A170-6E9B064F2ACE@petertodd.org>
X-Server-Quench: 6d7d2cd4-b025-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgsUHlAWAgsB AmMbW1JeU197WmE7 aQpYcwdfZFRMXwR0
UkxKXVZUERppT1gA Dxh5NHskdwBEfXZ0 K0dmWXJcEkIuchJ/
ERpQCD8GZ2J9aWFK VF1RIQRQbQNKfBpM agF+V3ZZYitlM3Bw
LCUyIzs2PDMaJClL TwUKNVcfR1o+VgMk SxkeEH0zGgUpQDg5
KxFjEUYRGkpZHkgq K1YqUE4ZNBlaNQxY E0ZSYRdDIEEGXCMv ZQAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 209.226.201.243/465
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YKhte-0005Jp-UP
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 06:32:42 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is an incredibly dangerous and foolish proposal that opens up the Bitcoin network to serious vulnerabilities, both from attackers outside the network, as well as miners trying to gain an advantage over their competition.
Ultimately it's flawed for the same root problem that proof-of-stake proposals suffer from: the p2p network just isn't a reliable broadcast medium. 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.
You can measure "propagation times" and other metrics all you want, but 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. 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.
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.
Frankly if this idea gets traction it should serve as a warning to all miners that it's time they adopt replace-by-fee to set a clear precedent that they have no obligations other than the same economic self-interest- not vague notions of "honesty" - that makes Bitcoin work in the first place.
BTW you quote Hal Finney and Satoshi in your proposal to try to lend support to it. Don't do that - appealing to authority is a surefire way to get people to ignore you. Its particularly bad when the authorities being appealed too haven't participated in consensus research for years; you're referencing stuff from a time when Bitcoin was barely understood.
On 8 February 2015 21:38:55 GMT-06:00, Tom Harding <tomh@thinlink.com> wrote:
>
>This update strengthens the incentive not to confirm double-spends
>after
>time T (30 seconds). To grow and stabilize adoption, it is necessary
>to
>influence the miner of the block after a deprecated block, who in turn
>is concerned with the block after that. Accordingly, the disincentive
>is
>changed from a simple delay to a temporary chain work penalty, which
>can
>be negative. Hal Finney first suggested this in 2011.
>
>The penalty is graduated in two steps based on the respend gap, for
>reasons explained within. I believe it is the minimum required to
>achieve the intended result.
>
>Double-Spend Deprecation Window
>https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
>
>
>------------------------------------------------------------------------------
>Dive into the World of Parallel Programming. The Go Parallel Website,
>sponsored by Intel and developed in partnership with Slashdot Media, is
>your
>hub for all things parallel software development, from weekly thought
>leadership blogs to news, videos, case studies, tutorials and more.
>Take a
>look and join the conversation now. http://goparallel.sourceforge.net/
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJU2FR4MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTd/B/9CG8fiJIZWnyxTsvnK
InGRfFMef8yvbALEt4/Io75Iv6Y6xYw0TbkLdk8r38/iFD5RlE6edYQe90QKA903
D6nxKQU0b1vW53cTptetzpvR6utkFogw3nqPRAy5SrDAdjJrg2Z78QrUQv+pSeYs
U9Mlw/22Z34vRI4VHpY9jeEtyj2lKNZvlBj/BtOeSHYsXB3R4tVmtp4DRiXc5FVr
i9NcOSBqKSzvG5bgx1S6QmMakSD/9LaoBrBWFiU2FZV/jX9x+dR31OdrVWr06OJU
zlR2Xyn3P+KwG8IeJR0K3sk72/vvEN+pntG+SMhtfrwjCgDKYGvULbcELR41EcmA
/X0i
=hGv0
-----END PGP SIGNATURE-----
|
