summaryrefslogtreecommitdiff
path: root/d6/1f7effa2ac9a2d379b166922abd36fdd3ad246
blob: 33d5648d3ffda9239fd7e59f5e4ff6ad277d8d67 (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1WekGc-0006xe-6x
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Apr 2014 12:02:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.161 as permitted sender)
	client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
	helo=outmail148161.authsmtp.com; 
Received: from outmail148161.authsmtp.com ([62.13.148.161])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WekGZ-0007Fo-Ri for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Apr 2014 12:02:38 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3SC2TXp037148
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 28 Apr 2014 13:02:29 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3SC2Ox3070083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 28 Apr 2014 13:02:26 +0100 (BST)
Date: Mon, 28 Apr 2014 08:02:09 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20140428120209.GJ20078@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="zOcTNEe3AzgCmdo9"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: f790a756-cecc-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
	P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQ11
	IQgLXVBSFQF4AB8L BhwUUB48cANYeX5u ZEFqQHFbVVt/fUFi
	QwAXFg51Zxgoa2AY UEBQdE1ccQJMMElC Y1AuU3YLfDZSNSl9
	RlY+ZHVgYTtWbXwN GFxcdVtLGhsHRSgG SggGFD4iWEcUAis+
	IlQ9IVkGF0YcPgA/ OEE9WRoHMgMSDRBC V0pNAStVYkEIVjFu
	AwRAGFYXCjBbXU9N 
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -0.4 (/)
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
	1.1 TRACKER_ID             BODY: Incorporates a tracking ID number
X-Headers-End: 1WekGZ-0007Fo-Ri
Subject: [Bitcoin-development] Replace-by-fee scorched-earth without
	child-pays-for-parent
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, 28 Apr 2014 12:02:38 -0000


--zOcTNEe3AzgCmdo9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Someone who wanted to remain anonymous sent me in this idea, which I'll
admit I'm kicking myself for not having thought of earlier. They sent
me this hash so they can claim credit for it later should they choose to
reveal their identity:

bb0de552f81fa356b99fbeef65fa532bb58111184efee2cbe92f66509af8d151


When Alice wants to pay Bob x bitcoins, rather than creating a single
transaction, tx1, that does that, she creates a pair of transactions,
with the second, tx2, spending the same inputs and an input provided by
Bob, but paying x*k bitcoins to fees. Should Bob detect a double-spend
he simply signs the extra input, making it clear that he intended for
the countermeasure to be deployed, and broadcasts tx2.

This mechanism has two advantages: 1) child-pays-for-parent isn't
required at avoiding changes to the relaying code and letting the
counter-transaction propagate quickly. 2) k can be adjusted such that
Alice is guaranteed to be worse off for attempting a double-spend even
taking into account the probability of getting away with it. For
instance, right now if just, say, Eligius adopted replace-by-fee a k
value of 20 would still make double-spends unprofitable.

However it does require payment protocol support. This lead me to
realize that if Alice signs all her inputs with the ANYONECANPAY sighash
bit set Bob can get the same effect by adding his own inputs to bump the
effective fee. While of course the funds to do so come out of his own
pocket, they are balanced out by the payment to him, with the net effect
being the same as the child-pays-for-parent version. Additionally in the
common case of "Bob would like Alice's transaction to go through sooner"
this also gives Bob the flexibility to add small sized inputs at will to
bump fees. (or for that matter Alice, giving a small privacy boost)

Using ANYONECANPAY does have one disadvantage in that transactions using
it are always malleable. However an "attacker" doing so is forced to
spend funds to do that. Secondly after the recent malleability attacks
wallet handling of malleability-related problems has greatly improved.


Finally it's worth noting how the k-overpaying version of scorched-earth
gives Finney attacking(1) miners - such as BitUndo - incentives to
defect knowing that they can earn significantly more fees by publishing
their supposedly secret transactions to the p2p network. Equally even in
the ANYONECANPAY version merchants may decide that discouraging fraud is
worth an overpayment.

1) https://bitcointalk.org/index.php?topic=3D3441.msg48384#msg48384

--=20
'peter'[:-1]@petertodd.org
0000000000000000603b189f99cf2a95ce01835596b5d5fbd8c5725c11f504ee

--zOcTNEe3AzgCmdo9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTXkM8XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA0YzI4NTFiNmEwYTYzNTY1ZTRlYzQzYTU2YTk5ZjRlMTky
MTk1YjI0YzM2NGJhZWYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsseAgAgBpsLaY9SMq3y9HAQE5Dqq1w
sYZi2QvOQjYgubO6zdWHbCumBRQ4HIjwYgBOj0boMgPj8VJD1JuXKiRzDz4O76KJ
dm493++liYBgDmjRxz+EGvW2XKaUl8YlgXvVcD8TVGaNYKt0Ox9D37D7q/00RIGd
blwzCAf80Qt1FLx/iDs6fDoJ4UzmCksRzl/V5j47yrYm3Bcz26dEf23fDNFzGbz1
WgIOS28Nrg5gz6oZsczWRneGEOYXQp9KGOscoE2bB/OKRXkf5HMN7EpyvRJwmQNG
FPygtwDOFn3N0S6dmrioEwOeHnPjOhOk/M7FC4rXGTid+LRWLbGd5BEVXdHV7g==
=ClXw
-----END PGP SIGNATURE-----

--zOcTNEe3AzgCmdo9--