summaryrefslogtreecommitdiff
path: root/8f/b9a5a2a8a014e3453cf98bf132d8d280075b78
blob: 40310aaf2335c66671efae978a2a1c85ec28aae8 (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
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 1UFLoA-0008Cc-RM
	for bitcoin-development@lists.sourceforge.net;
	Tue, 12 Mar 2013 09:47:46 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.78 as permitted sender)
	client-ip=62.13.149.78; envelope-from=pete@petertodd.org;
	helo=outmail149078.authsmtp.net; 
Received: from outmail149078.authsmtp.net ([62.13.149.78])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UFLo8-0004e0-Fo for bitcoin-development@lists.sourceforge.net;
	Tue, 12 Mar 2013 09:47:46 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r2C9lbjD093802
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 12 Mar 2013 09:47:37 GMT
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 r2C9lUd8047432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 12 Mar 2013 09:47:32 GMT
Date: Tue, 12 Mar 2013 05:47:00 -0400
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130312094700.GA8130@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: dd020541-8af9-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
	P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgd1
	LRkLXVBSFQZ4ARUL AhkUURo8cANYeX5u ZEFqQHFbVVt/fUFi
	QwAWFx4POQI0YGAb V0RbdU1ScQVCMEsR alJ/UXcMfG1WMHN9
	RlY+ZXU7ZG1VbXwN GFxcdQlJHhsGRCgX RxkEEjQpEgUZRyh7
	IRErYlkaVE8VKEg7 PUppQl8eL1cOEARY BEhGHC5eIUJp
X-Authentic-SMTP: 61633532353630.1019: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: -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: 1UFLo8-0004e0-Fo
Subject: [Bitcoin-development] Changing the fee on already sent transactions
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: Tue, 12 Mar 2013 09:47:47 -0000


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

We can allow for transaction replacement for the purpose of adding fees
to existing transactions safely, and while not increasing the risk of
double-spends by taking advantage of the stubbed out replacement code.

Specifically the replacement code allows for the replacement of a
transaction if a transaction spending the tx that is being replaced is
not in the mempool. Specifically:

664     // Check for conflicts with in-memory transactions
665     CTransaction* ptxOld =3D NULL;
666     for (unsigned int i =3D 0; i < tx.vin.size(); i++)
667     {
668         COutPoint outpoint =3D tx.vin[i].prevout;
669         if (mapNextTx.count(outpoint)){

Followed by the actual replacement logic. We could change this logic to
instead evaluate if the candidate replacement does not remove or
decrease the value of any existing outputs. Adding outputs is ok.
Changing the set of inputs is also ok, provided that there are no
conflicts with other spent transactions. DoS attacks would be prevented
by only forwarding/accepting into the mempool replacements that increase
the fees paid by at least MIN_RELAY_TX_FEE * size - essentially the same
decision to allow the broadcast of the transaction in the first place.

Because a transaction can not be replaced if another transaction already
depends on it the change would not increse double-spend risks for
unconfirmed transactions.

Along with this change code can be added to clients to examine the
mempool and recent blocks to determine what fee would be required to get
a transaction confirmed in what time.


Of course, considering our recent "fun" last night, I'll be the first to
admit that this change needs a lot of testing and careful thought.
However the ability to increase fees on already broadcast transactions
would be very valuable to users as competition for blockchain space
increases.

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

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

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

iQEcBAEBAgAGBQJRPvmTAAoJEH+rEUJn5PoEJpYH/3ekZmzdKeOPhbbJrZK4MVSJ
SYlt7XW2Q7uK/K5F/gNE3Wog/SUhSK3Q2soLZc3CvY96rGNfHr1mwPDhwMz0z1Wj
yRPseU0u4ZnfZqHj3Dr8rjvEicDN3CtmvH+ptKmmpXdWpWDmZICsM/Uh/vWSo2nq
9AlZLvNryIC/ji4+rWBLGjyvCiZCowmU/LsVKcbGNhsrWA3aJLWSqubXAfRn2fCd
GqBAkD1EhN/CN3Rp9XPlfXWG1wLBlSlFIk29gSXoWL0g39i7hdIm/2jOhIUY6sB1
mYg5PEpuopNVFoH3XLiHD6TO4hojz3eEMyQy7/YLL2Jpy2rcF6NMhXPMk1ZM3zQ=
=CjfM
-----END PGP SIGNATURE-----

--BXVAT5kNtrzKuDFl--