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
|
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 3871DA7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 20:11:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D7B66C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 20:11:41 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1hTXaJ-00007V-Et; Thu, 23 May 2019 06:11:37 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 23 May 2019 06:11:31 +1000
Date: Thu, 23 May 2019 06:11:31 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>
Message-ID: <20190522201131.tfbfldddvkkktcc6@erisian.com.au>
References: <20190510203804.554q333lw3l7qql4@erisian.com.au>
<87d0kbkxx8.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87d0kbkxx8.fsf@rustcorp.com.au>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
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: Thu, 23 May 2019 13:31:42 +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: Wed, 22 May 2019 20:11:42 -0000
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.
> Finally, it seems to me that chaparones can be opt-in, and don't need to
> burden the protocol.
Eltoo (and perhaps lightning more generally) seem like the most obvious
use case for ANYPREVOUT, so if it isn't going to opt-in (or is going
to opt-out in any way it can, as you suggest) then they're not a good
solution.
I'm not going to argue about any of that here, though I do reserve the
right to do so later. :)
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.
If other people *fail* to follow this rule, you might receive funds
directly authorised by an ANYPREVOUT signature. But those funds are only
secure if they're "sufficiently" buried in confirmations anyway, and
once they are, they won't disappear. You might be able to reuse that
signature against some different UTXO, but that's only to your benefit:
they lose funds after violating the rule, but you gain funds.
Eltoo naturally meets this requirement, as long as you consider "paying
to yourself" to cover both "paying to same multisig address" (for update
transactions) and "splitting funds between members of a group who owned
the funds". If you consider the "split" to be "you get 50% of our funds,
you get 20%, you get 30%", even if the signature gets replayed later
against a different utxo, the percentage split remains true it just
unexpectedly applies to more funds.
#3. Making ANYPREVOUT only available via script is aligned with this;
if you'repaying to yourself you probably want complicated rules that
you have to encode in script, and there's a mild economic incentive to
try to avoid that because the key path is cheaper.
#4. I think this covers the major security property for bitcoin (your
funds are yours to decide what to do with), but maybe there are other
ways in which ANYPREVOUT is scary that could be formalised and addressed?
#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.
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012463.html
Cheers,
aj
|
