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
|
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 9F1A213DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 May 2019 01:28:49 +0000 (UTC)
X-Greylist: domain 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 5A51313A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 May 2019 01:28:48 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 45Bzrs4jq3z9sB8; Mon, 27 May 2019 11:28:45 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Anthony Towns <aj@erisian.com.au>
In-Reply-To: <20190522201131.tfbfldddvkkktcc6@erisian.com.au>
References: <20190510203804.554q333lw3l7qql4@erisian.com.au>
<87d0kbkxx8.fsf@rustcorp.com.au>
<20190522201131.tfbfldddvkkktcc6@erisian.com.au>
Date: Mon, 27 May 2019 10:56:01 +0930
Message-ID: <87ef4k3cye.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 27 May 2019 14:25:27 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
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: Mon, 27 May 2019 01:28:49 -0000
Anthony Towns <aj@erisian.com.au> writes:
> On Wed, May 22, 2019 at 12:17:31PM +0930, Rusty Russell wrote:
>> I prefer to
>> change the bip introduction to expliclty shout "THESE SIGNATURE
>> HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it
>> SIGHASH_UNSAFE_ANYPREVOUT.
>
>> 4. "Rebinding is a new power in bitcoin, and it makes me uncomfortable".
>> I have a degree of sympathy for this view, but objections must be
>> backed in facts. If we don't understand it well enough, we should
>> not do it.
>
> Yeah, that's where I'm at: if we think something is UNSAFE enough to
> need a warning, then I think it's too unsafe to include in the consensus
> layer. I would like to find a way of making ANYPREVOUT safe enough that
> it doesn't need scary warnings; a week or two ago, chaperone sigs were
> my best idea for that.
The DO_NOT_WANT naming is to prevent people who *don't* want to use it
from using it because it's the "new hotness".
It cannot both be powerful enough to do what we need (rebinding) and
safe enough for general use (no rebinding).
> So here's something I almost think is an argument that ANYPREVOUT is safe
> (without chaperone sigs or output tagging, etc).
>
> #1. I'm assuming funds are "safe" in Bitcoin if they're (a) held in
> a cryptographically secured UTXO, (b) under "enough" proof of work
> that a reorg is "sufficiently" unlikely. If you don't have both those
> assumptions, your money is not safe in obvious ways; if you do have them
> both, your money is safe.
>
> #2. My theory is that as long as you, personally, only use ANYPREVOUT
> to sign transactions that are paying the money back to yourself, your
> funds will remain safe.
>
> If you follow this rule, then other people replaying your signature is
> not a problem -- the funds will just move from one of your addresses, to
> a different address.
...
> Eltoo naturally meets this requirement, as long as you consider "paying
> to yourself" to cover both "paying to same multisig address" (for update
> transactions)
I disagree? Paying to share with an untrusted party is *insecure*
without further, complex arrangements. Those arrangements (already a
requirement for lightning) worry me far more than the bitcoin-level
rebinding, TBH.
Lightning relies on #1, not #2. I don't know of any use for #2 in fact;
in practice if you have control of keys you can generally sign a new tx,
not requiring ANYPREVOUT. If you're trying to blindly spend a tx which
may be RBF'd, ANYPREVOUT won't generally help you (amount changes).
> #5. It's probably not compatible with luke's "malleability proof" wallet
> idea [0]. Malleability is only a concern for funds that aren't already
> "sufficiently" buried, and if you're only spending it to yourself that
> doesn't help with burying, and if you're spending it to someone else
> immediately after, doesn't help with making that transaction less
> malleable. But if the line of argument above's correct, that just
> recognises that a wallet like that risks losing funds if someone else
> reuses its addresses; it doesn't add any systemic risk. And "wallet X
> isn't safe" is a risk category we already deal with.
Yes, I think our primary concern is risk to non-ANYPREVOUT using txs.
That would make ANYPREVOUT a bad idea, but seems we're concluding that's
not the case.
Secondary, is the accidentally-using-ANYPREVOUT scenario, which I
consider unlikely (like accidentally-using-SIGHASHNONE), especially
since you need to actually mark your keys now, so you can't do it
post-hoc to existing outputs.
Final concern is the using-correctly-but-nasty-gotchas. This seems to
be inherent in rebinding, and is fully addressed by Don't Reuse
Addresses. That is already a requirement for lightning (reusing
revocation keys is fatal). Others reusing your addresses is already a
thing we have to deal with in bitcoin (Enjoy/Sochi).
Cheers,
Rusty.
|
