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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <apoelstra@wpsoftware.net>) id 1Wt3Th-0008Py-60
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 23:23:17 +0000
X-ACL-Warn:
Received: from s0106c0c1c0894c25.vs.shawcable.net ([70.70.46.218]
helo=mail.wpsoftware.net)
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Wt3Tf-0000iV-VM
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 23:23:17 +0000
Received: from shavo.dd-wrt (dd-wrt01 [192.168.0.1]) (authenticated bits=0)
by mail.wpsoftware.net (8.14.7/8.14.7) with ESMTP id s56MrP1n001275
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
verify=NO); Fri, 6 Jun 2014 15:53:26 -0700
Date: Fri, 6 Jun 2014 15:53:25 -0700
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: =?iso-8859-1?Q?Ra=FAl_Mart=EDnez?= <rme@i-rme.es>
Message-ID: <20140606225325.GF26152@shavo.dd-wrt>
References: <CA+8=xu+Bo5W+i__c-QMo+9sTTWzs4mi-wF9FFR1axPPRf5MO1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="aYDVKSzuImP48n7V"
Content-Disposition: inline
In-Reply-To: <CA+8=xu+Bo5W+i__c-QMo+9sTTWzs4mi-wF9FFR1axPPRf5MO1A@mail.gmail.com>
User-Agent: Mutt/1.5.22+19 (8f62001989cc) (2013-10-16)
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[70.70.46.218 listed in dnsbl.sorbs.net]
1.0 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
X-Headers-End: 1Wt3Tf-0000iV-VM
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Possible attack: Keeping unconfirmed
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: Fri, 06 Jun 2014 23:23:17 -0000
--aYDVKSzuImP48n7V
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 07, 2014 at 12:02:36AM +0200, Ra=FAl Mart=EDnez wrote:
> I dont know if this attack is even possible, it came to my mind and I will
> try to explain it as good as possible.
>=20
> Some transacions keep unconfirmed forever and finally they are purged by
> Bitcoin nodes, mostly due to the lack of fees.
>
It's definitely possible. As Pieter says it is important to always reuse
inputs if you are "resending" a transaction. If you don't reuse inputs,
you are creating a new transaction and you should think of it as
spending twice as much money.
Like any information on the Internet, once a signed transaction leaves
your system there is no way to undo this. (Though of course, you can
respend the inputs to ensure that if ever your transaction resurfaces it
will not confirm.) This is true even if the transaction has low fees, is
nonstandard, or is otherwise inhibited from relaying.
I would go so far as to say that any UI which suggests otherwise (e.g.
offering a "cancel" feature which does not involve respending inputs or
that makes any guarantees about being effective) is dangerously broken.
--=20
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
Web: http://www.wpsoftware.net/andrew
--aYDVKSzuImP48n7V
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJTkkZlAAoJEHrQqRxAvQCRsK0H/1s92NOzg4beiZp8zl7xUIoZ
+8cDZcszC6ZiI3pZEaPIqa9L5XYneIseGfk48OZM8leP7iKSPYgjjRskHrizOB+D
4j8gL/dm2USLoK3co6VIra9SV4W05d3NT3UocOIwakwzXlt6Yowkbi4/5/Gebixd
xIT2GvG/0MgubgwhP1Qv0Q+PbNZUGwCKjbgACBttjAv63F06CE7XfioizSbaOKHx
PI79jTCpdbeM/HUemeri6k7TSdSPk8Pscf764K0LOWG4HtNMrx0cJL/3w3Q4EYEs
bjJreTRVoplilQAtYsW+ZBwlSJO9oZS8u4seY++yzrYLsXCTmr3zVdHnAvDpmqY=
=U1l/
-----END PGP SIGNATURE-----
--aYDVKSzuImP48n7V--
|
