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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YPL8t-00028r-Im
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 01:15:31 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.101 as permitted sender)
client-ip=62.13.148.101; envelope-from=pete@petertodd.org;
helo=outmail148101.authsmtp.com;
Received: from outmail148101.authsmtp.com ([62.13.148.101])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YPL8r-0001To-MS for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 01:15:31 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1M1FHnm063111;
Sun, 22 Feb 2015 01:15:17 GMT
Received: from [25.108.40.159] ([24.114.71.166]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1M1FDZk035478
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 22 Feb 2015 01:15:14 GMT
In-Reply-To: <CAJHLa0M4Tc7kiQVNmBfMBvSqFyrmHXdaNh7mF+crAdME5FUWHg@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
<20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com>
<20150219085604.GT14804@nl.grid.coop>
<CABm2gDorEFNzzHH2bxpo6miv1H0RUhL9uAYX6gg2aW0wB1QDbw@mail.gmail.com>
<CAOG=w-uJFobZtkd8OoPnOJC3uqCOwjsqyfNWJTg3j3sJQn+wXQ@mail.gmail.com>
<CAJHLa0M4Tc7kiQVNmBfMBvSqFyrmHXdaNh7mF+crAdME5FUWHg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Sun, 22 Feb 2015 01:15:02 +0000
To: Jeff Garzik <jgarzik@bitpay.com>, Mark Friedenbach <mark@friedenbach.org>,
=?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@blockstream.io>
Message-ID: <1A8F9DE6-14AF-429D-9C1D-4BE66E917D90@petertodd.org>
X-Server-Quench: 42042db6-ba30-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdAAUHlAWAgsB AmMbW1VeUVh7WGY7 aQ5PbARZfE1PQQRs
VldNRFdNFUssAGEA cGp0CRlxcgFBcDBx bE9gXj5fXkR+dxIv
RFMGRG4GeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4REyY4 ThsPWD8+WEMISm0t
d1p/chhEBk1NWgAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.114.71.166/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: 1YPL8r-0001To-MS
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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: Sun, 22 Feb 2015 01:15:31 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik <jgarzik@bitpay.com> wrote:
>"scorched earth" refers to the _real world_ impact such policies would
>have on present-day 0-conf usage within the bitcoin community.
I think you guys are reading too much into the name... Replace-by-fee is called "replace-by-fee" because it considers whether to replace or not based on fee; the idea came about in an discussion about replacement based on nSequence.
I forget whether it was myself or John Dillon who came up with the name "scorched earth", but it just refers to the game theory behind the *specific* idea of the receiver combating a zeroconf double-spend by sending all the funds to fees. Scorched earth as in "You're trying to defraud me, so I'm not going yo play this game or negotiate, I'm just going to immediately do what is most likely to make you lose the maximum amount of money to punish you for your vandalism."
>All payment processors AFAIK process transactions through some scoring
>system, then accept 0-conf transactions for payments.
>
>This isn't some theoretical exercise. Like it or not many use
>insecure 0-conf transactions for rapid payments. Deploying something
>that makes 0-conf transactions unusable would have a wide, negative
>impact on present day bitcoin payments, thus "scorched earth"
I'm not so convinced, precisely because we've seen zeroconf fail in pretty bad ways; the people most vulnerable to losses have generally changed the way they operate. (e.g. ATM's that no longer rely on zeroconf security, instead waiting for confirmations, installing cameras, etc.)
My #1 concern right now is person-to-person trading, and people doing that tend to wait for confirmations or otherwise protect themselves. (e.g. reputation systems)
>Without adequate decentralized solutions for instant payments,
>deploying replace-by-fee widely would simply push instant transactions
>even more into the realm of centralized, walled-garden services.
Agreed. Deploying it has been something I've made into a long, drawn out, protracted process for precisely that reason. OTOH I sometimes wonder if I've gone too far with that - the services that themselves try to guarantee zeroconf right now through metrics are themselves highly centralised, and there's a big risk of them driving mining centralisation itself when they fail.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6S2N
AAoJEMCF8hzn9LncrFUH/1xhuPhYJnjTCxhpv2h5ZJOT3wLsrU1oEDmD5fWy/4wG
7ppr3EiHNX7nB42fgeSGZF8fW1VuBjivJa9ra3IvFysFfaD40Kyre2FTnN03+vTC
Upa5ykPzOMqZIHkSf8N1xMbz4SXHHPWu8wPMzj/QGvUpllNiOWn/6Vooqrcp7f6Y
NJFykSq+vDNMOUWCiJG8hhoKiOcZhTH0Aj9qPcGs9WhgsF7wDAX7pg6iO6Y5qmt5
LdFcut2caL6mIxpExm0F9V+lyeam/3gvAU3eecHY77KOxRxFTO1xfQXEJFTWN92h
+M9BXQZ1UifjTZWMzK0kp3SRJuVSXg4KOAapQFBLTzU=
=3Mmw
-----END PGP SIGNATURE-----
|
