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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EB3A5E85
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 06:12:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4D83E2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 06:12:31 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian))
id 1a9oHE-000437-LB for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 16:12:30 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 18 Dec 2015 16:12:23 +1000
Date: Fri, 18 Dec 2015 16:12:23 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151218061223.GA22650@sapphire.erisian.com.au>
References: <CAPg+sBjJcqeqGLHnPyWt23z3YoCRGozQupuMxy51J_-hdkKBSA@mail.gmail.com>
<E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] On the security of softforks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 18 Dec 2015 06:12:32 -0000
On Fri, Dec 18, 2015 at 10:47:14AM +0800, Jonathan Toomim via bitcoin-dev wrote:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 1) The risk of an old full node wallet accepting a transaction that is
> > invalid to the new rules.
> > The receiver wallet chooses what address/script to accept coins on.
> > They'll upgrade to the new softfork rules before creating an address
> > that depends on the softfork's features.
> > So, not a problem.
> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
> runs the old rules. Bob creates a p2pkh address for Mallory to
> use. Mallory takes 1 BTC, and creates an invalid SegWit transaction
> that Bob cannot properly validate and that pays into one of Mallory's
> wallets. [...]
> Clueless Carol is one of the 4.9% of miners who forgot to upgrade
> her mining node. Carol sees that Mallory included an enormous fee in
> his transactions, so Carol makes sure to include both transactions in
> her block.
For it to be a "safe" soft fork, the "invalid segwit transaction" should
look non-standard to Carol, and as such she should refuse to mine it.
I think the attack has to go like this:
* segwit activates; 5% of miners fail to upgrade however
* Mallory creates a transaction paying to a segwit script
(ie scriptPubKey is just a 33 byte push) [0]
* non-upgraded nodes and miners will refuse to forward or mine
this transaction (a non-p2sh scriptPubKey that just pushes data is
non-standard) but the upgraded nodes and miners will forward and mine
it. it will be included in the blockchain by upgraded miners fairly
soon, and will then be in the UTXO set of non-upgraded miners and
nodes too.
* Mallory creates a segwit-invalid spend back to himself (or directly
to Bob for the 1BTC), ie provides empty scriptSig, but no
witness data. Upgraded miners and nodes reject the transaction,
but non-upgraded nodes will relay and mine it afaics.
I *think* that transaction will fail the AreInputsStandard() test on
non-upgraded nodes, and thus still won't be accepted to the mempool
or mined by non-upgraded nodes, and thus no one will see it, or any
descendent transactions. (Upgraded nodes will reject it because it's
segwit invalid, of course)
If it is accepted by some old nodes, that transaction won't ever get many
confirmations -- if Carol mines it, her block will be orphaned by the
upgraded mining majority after the next two or three blocks are found.
With only 5% of hashpower, it will take around three hours for Carol
and friends to find a block in general.
Also, the fact that segwit outputs are "anyone can spend" maybe mitigates
this further -- you could have a vigilante node that creates invalid
segwit txns for every segwit output that just spends the entire thing
to fees. Even if the vigilante's transactions get rejected by nodes who
see Mallory's attempt first, that should still be enough to trigger any
sort of double-spend alerts I can think of, at least if anyone at all
is altruistic enough to run a vigilante node like that in the first place.
> Mallory gets free beer.
> Anything I'm missing?
So I think the only way Mallory gets free beer from you with segwit
soft-fork is if:
- you're running out of date software and you're ignoring warnings to
upgrade (block versions have bumped)
- you've turned off standardness checks
- you're accepting low-confirmation transactions
- you're not using any double-spend detection service
If you're not accepting zero-confirmation transactions straight from
the mempool, (ie you require 1 or 2 confirmations) you also need:
- some non-upgraded miners who have turned off standardness checks
- your business is setup that an attacker can happily wait hours for
the transaction to be included in a block before trying to get beer
from you
In general (IMO), just leaving standardness checks turned on (and waiting
for 6 confirmations before accepting any non-standard transaction) should
be enough to keep you safe from any attack a soft-fork might enable.
Upgrading your software regularly should also be enough to keep you safe
for any soft-fork, and also for any hard-fork, obviously.
Cheers,
aj
[0] Actually, for this attack Mallory could use *any* segwit payment, it
doesn't have to be his bitcoins to start with, he just has to make
it look like they finish up with him, which is trivial if segwit
looks like anyone can spend. Having it be his segwit payment in the
first place makes it a little easier to ensure his payment is seen
as the original and not the doublespend though.
|
