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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E7995D8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Jun 2018 01:20:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [203.11.71.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 288866B7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Jun 2018 01:20:50 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 40xmjr0YPMz9ryk; Fri, 1 Jun 2018 11:20:47 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"Christian Decker" <decker.christian@gmail.com>
In-Reply-To: <87muwhvozr.fsf@rustcorp.com.au>
References: <87po25lmzs.fsf@rustcorp.com.au>
<201805100227.42217.luke@dashjr.org>
<87vabnq9ui.fsf@rustcorp.com.au>
<CADZtCShwOV+GuJ5__GMi9hd2_X=BztASPBihDXakU3Mjb39wcQ@mail.gmail.com>
<87zi0tisft.fsf@rustcorp.com.au>
<20180521035658.vfo4wx6ifum2s2o5@petertodd.org>
<87muwhvozr.fsf@rustcorp.com.au>
Date: Thu, 31 May 2018 12:17:58 +0930
Message-ID: <87h8mov8v5.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Matt Corallo <matt@chaincode.com>
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 01 Jun 2018 01:20:51 -0000
Rusty Russell <rusty@rustcorp.com.au> writes:
> AFAICT the optimal DoS is where:
>
> 1. Attacker sends a 100,000 vbyte tx @1sat/vbyte.
> 2. Replaces it with a 108 vbyte tx @2sat/vbyte which spends one of
> those inputs.
> 3. Replaces that spent input in the 100k tx and does it again.
>
> It takes 3.5 seconds to propagate to 50% of network[1] (probably much worse
> given 100k txs), so they can only do this about 86 times per block.
>
> That means they send 86 * (100000 + 108) = 8609288 vbytes for a cost of
> 86 * 2 * 108 + 100000 / 2 = 68576 satoshi (assuming 50% chance 100k tx
> gets mined).
This 50% chance assumption is wrong; it's almost 0% for a low enough
fee. Thus the cost is only 18576, making the cost for the transactions
463x lower than just sending 1sat/vbyte txs under optimal conditions.
That's a bit ouch.[1]
I think a better solution is to address the DoS potential directly:
if a replacement doesn't meet #3 or #4, but *does* increase the feerate
by at least minrelayfee, processing should be delayed by 30-60 seconds.
That means that eventually you will RBF a larger tx, but it'll take
much longer. Should be easy to implement, too, since similar timers
will be needed for dandelion.
Cheers,
Rusty.
[1] Christian grabbed some more detailed propagation stats for me: larger
txs do propagate slower, but only by a factor of 2.5 or so.
|
