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
|
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 <jrn@jrn.me.uk>) id 1Y7osf-0001Bw-OA
for bitcoin-development@lists.sourceforge.net;
Sun, 04 Jan 2015 17:22:21 +0000
X-ACL-Warn:
Received: from s3.neomailbox.net ([178.209.62.157])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Y7osb-00081r-QU for bitcoin-development@lists.sourceforge.net;
Sun, 04 Jan 2015 17:22:21 +0000
Message-ID: <54A976C3.1030805@jrn.me.uk>
Date: Sun, 04 Jan 2015 17:22:11 +0000
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <54A95179.2070200@jrn.me.uk>
<CAAS2fgSw=Goibe2LkXsEH5xjyftjQq4FxJh-dhaP_N5ea21ugQ@mail.gmail.com>
In-Reply-To: <CAAS2fgSw=Goibe2LkXsEH5xjyftjQq4FxJh-dhaP_N5ea21ugQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Y7osb-00081r-QU
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Re-enabling simple tx replacement
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, 04 Jan 2015 17:22:21 -0000
On 04/01/15 17:04, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll <jrn@jrn.me.uk> wrote:
>> Dear all,
>>
>> I've been looking at atomic cross-chain trading (
>> https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
>> Bitcoin and Dogecoin blockchains, and have a mostly functional
>> prototype. However as it stands if the refund transaction is relayed
>> before the actual spend transaction, it "blocks" the legitimate spend
>> transaction from being accepted into the memory pool.
>
> Unless there is a serious bug that I am not aware of this is not the
> case. The unlocked transaction is not relayable and will not be
> mempooled (well, until right before it locks).
Grabbing a simple test case:
https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
- that won't lock until 0028 UTC on the 5th.
I've tried closing the wallet, moving the wallet.dat file out of the
way, and then attempting the spend transaction (which can be locked
immediately), and it either rejects it on acceptance to mempool, or it
is never included in a block.
Compare with
https://chain.so/tx/BTCTEST/0b96eb0c9bf8a6ca08bb9d75e44970889db77779c6d3122296c0169959f979cc
where the refund was not sent first, and the transaction has succeeded.
>> I've drafted a patch for this
>> https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
>> but have not yet raised a PR, as historically this has lead to a lot of
>> discussion in Github which is better suited to this mailing list.
>>
>> I'm therefore looking for feedback while I continue testing that patch,
>> and any comments would be welcomed.
>
> This appears to have absolutely no protection against denial of
> service, it seems to me that a single user can rapidly update their
> transaction and exhaust the relay bandwidth of the entire network.
>
They can only replace a non-final transaction with a final transaction,
so the replacement can happen at most once (any later replacement would
be attempting to replace a final transaction, and therefore fails). So,
while they can expend twice the bandwidth compared to a non-replacement,
I don't think that's a major issue?
|
