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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4795EAC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 16:05:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk
[62.13.149.55])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 45689118
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 16:05:34 +0000 (UTC)
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 t5UG5UI7098763;
Tue, 30 Jun 2015 17:05:30 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5UG5OpZ025950
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 30 Jun 2015 17:05:26 +0100 (BST)
Date: Tue, 30 Jun 2015 12:05:24 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20150630160523.GG17984@savin.petertodd.org>
References: <20150629050726.GA502@savin.petertodd.org>
<5591E10F.9000008@thinlink.com>
<20150630013736.GA11508@savin.petertodd.org>
<CALqxMTH_5rtOs=aSNiVrfsG_sqQDCnTr-8qBH3Qji+8g_dAMcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="Zrag5V6pnZGjLKiw"
Content-Disposition: inline
In-Reply-To: <CALqxMTH_5rtOs=aSNiVrfsG_sqQDCnTr-8qBH3Qji+8g_dAMcQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: d2cf2722-1f41-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdQIUEkAaAgsB AmMbWlNeUFh7W2Q7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRlk cRthEnNydQBPfX4+ Z0JjXnAVCEYpI0R6
QExJFDsCZHphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
FQ4vNDcwO3BTJTpg CissFQBab1sPGnYG SggGFD4iWEcUAgs+
IlQqJ0YYG1cUP0Mu eUAqWV8ULhsfYgAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 16:05:35 -0000
--Zrag5V6pnZGjLKiw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote:
> It is correct to view first-seen miner and relay policy as
> honour-based, though it is the current default.
>=20
> I think it would be better to deploy full-RBF in an opt-in way and
> leave the current default miner & relay policies as is. So for
> example a new signature flag or transaction type that is marked as
> opting-in waiving the first-seen policy.
>=20
> In this way we can get a smoother transition for people away from the
> first-seen assumption, towards greenaddress (trust based) and
> lightning / payment channel solutions. Mid-term the channel and hub
> model can provide fast secure 0-confirm transactions, which are
> generically not known to be directly and robustly securable via miner
> consensus.
>=20
> As we've seen abruptly stopping the first-seen miner & relay policy is
> risky and unpopular and causes people to seek contracts with miners to
> retain first-seen. This is itself a bad trend for fungibility for
> obvious reasons.
Well, as you know I have good reason to believe those contracts are
being actively worked on right now. I've been talking about this issue
for something like two years now, and rather than seeing a shift away
=66rom use of zeroconf, we're seeing new services adopting it, always
large, centralized, startups in the payment space. Meanwhile the story
for decentralized wallets is if anything even worse, and most such
wallets don't even have code to detect double-spends at all.
=46rom the point of view of large companies like Coinbase, getting hashing
power contracts and sybil attacking the network is relatively easy. Why
would they invest in genuine improvements when they can take the easy
way out? Especially when the easy way is something their smaller
competitors simply have no access too? Working on those contracts now
only makes sense, especially as the reliability of the P2P network in
providing zeroconf guarantees continues to decline as transaction volume
increases, and uniformity of nodes decreases.
By acting sooner rather than later in adopting full-RBF I think we have
a shot at changing the direction of the industry; if we wait I think we
stand a real chance of that dangerous infrastructure being put into
place. Equally, when you ask who is benefiting from the status quo, it
isn't decentralized wallets, but a small number of centralized startups
who have an advantage that the former can't match.
> We shouldn't prejudge people's and segment's of business weak-reliance
> on first-seen. Some types of payments are generally high trust (known
> relationships) or physical stores or very low marginal cost (coffee
> marginal cost <10c, sale price > $2 or lower ebook, audio stream etc
> as embodied by fremium model). It is not ours to prejudge and kill
> their business. It our job to help improve network security however,
> so that they do not have to eat a fraud cost. And that is do able
> with trust via greenaddress, or without trust (other than
> time-preference) via the hub & channel model.
You know, if the status quo didn't have the downsides I mention above,
I'd probably agree with you on that point. But the risks outweigh it
IMO.
> Security maybe incrementally improvable via non-spendable relaying of
> proof of double-spent status, and services that try to measure % of
> miners by hashrate with assumption of first-seen that have have seen a
> given transaction first, though I am not sure such approaches are
> robust enough to invest time in vs greenaddress or hub & channel.
Note how relaying proof of double-spent status is only useful if you can
do something about it; the only method available without a scripting
language soft-fork is the scorched earth concept, which ironically
relies on full-RBF.
> Any thoughts on the simplest way to support an opt-in version of full-RBF?
I'd suggest using nSequence for that purpose by defining non-maxint
nSequence as allowing RBF. (as well as non-maxint - 1 for nLockTime
usage to discourage fee sniping) Mark Friedenbach's sequence number BIP
is going to make use of transaction replacement anyway after all, so
doing that would be forward-compatible with it.
--=20
'peter'[:-1]@petertodd.org
0000000000000000129dec64f63611dc737b87331bb165740fb5552a92833a12
--Zrag5V6pnZGjLKiw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVkr5AXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNmY5MGVhZmI3MTExZjRjYWVhMWY3OTJmZTUzNWZkYzFj
MjI1MWJjNDUxNDc4N2MvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftYiggAs9iqm/BOETt6H+AzCaMbPUby
oWJeXHrGw6YcoQj5b5kROb2DeNuJJlEE+SsfgqwLjqUL2t0b4hXha0Kd7Dhc+Ux2
VsDi/++XMJkUgYoi3qAjzWIM9RtyMxeI93jVW1MF3ibcEgIpUMEAIljf0Dv8TzCM
rbEsKPp0OsrignWoBJwPdIBv0LF0JwLnD9XsfY2vRgX4a6fCds1CLKNzDtfm+MYs
S6p3KGSuDorAgQ3OdVeAWOzm/JSok3fHv9G9DlEZFXwcu1HXMJ8EEWTF0mOY+M8Q
ua44aH6JEsTRxMEzSgodPMOjgOrIvcl+hO8XXTXOpKQACUky6xio1nKgX/XyDw==
=PfJE
-----END PGP SIGNATURE-----
--Zrag5V6pnZGjLKiw--
|
