* [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
@ 2019-05-10 20:38 Anthony Towns
2019-05-22 2:47 ` Rusty Russell
0 siblings, 1 reply; 4+ messages in thread
From: Anthony Towns @ 2019-05-10 20:38 UTC (permalink / raw)
To: bitcoin-dev
Hi everybody!
Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and
SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT,
despite the name change)
I don't think we are (or should be) as confident that ANYPREVOUT is
ready for implementation and deployment as we are that taproot is.
In particular, we were still coming up with surprising ways that these
style of signatures could maybe cause problems over the past few months,
despite "NOINPUT" having been around for years, and having been thinking
seriously about it for most of the last year. In comparison we've had
a roughed out security proof for taproot [0] for over a year now.
So far, the best approach (in my opinion) that we've come up with to
limit the possible negative impacts of these types of signatures is to
require an additional regular signature to accompany every ANYPREVOUT
signature. As such, it's included in the BIP draft.
In theory this ensures that no ANYPREVOUT tx can cause any more problems
than some existing tx could; but in practice this assumes that the private
key for that signature is maintained in a similar way to the private keys
currently securing transactions are. After passing this around privately,
I'm not convinced the theory will survive meeting adversarial reality,
in which case I don't think this draft will be suitable for adoption.
But maybe I'm too pessimistic, or maybe we can come up with either
a proof that ANYPREVOUT is already safe without any other measures,
or maybe we can come up with some better measures to ensure it's safe.
So in any case I'm still hopeful that publishing the best we've got is
helpful, even if that still isn't good enough.
The BIP draft can be found here:
https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki
A sample implementation based on the taproot branch is here:
https://github.com/ajtowns/bitcoin/commits/anyprevout
Some interesting features:
* This demonstrates how to upgrade tapscript's existing CHECKSIG,
CHECKSIGADD and CHECKSIGVERIFY opcodes for new SIGHASH methods or
potentially a new signature scheme, a new elliptic curve or other
public key scheme
* This demonstrates a cheap way of using the taproot internal key
as the public key for CHECKSIG operations in script
* There are two variants, ANYPREVOUT and ANYPREVOUTANYSCRIPT, which
seems helpful for eltoo
* The BIP attempts to describe the security implications of ANYPREVOUT-style
signatures
Cheers,
aj
[0] https://github.com/apoelstra/taproot/blob/master/main.tex
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
2019-05-10 20:38 [bitcoin-dev] SIGHASH_ANYPREVOUT proposal Anthony Towns
@ 2019-05-22 2:47 ` Rusty Russell
2019-05-22 20:11 ` Anthony Towns
0 siblings, 1 reply; 4+ messages in thread
From: Rusty Russell @ 2019-05-22 2:47 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion, bitcoin-dev
Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
> Hi everybody!
>
> Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and
> SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT,
> despite the name change)
I really like this proposal, and am impressed with how cleanly it
separated from taproot/tapscript.
I believe the chaparone signature requirement should be eliminated: I am
aware of four suggested benefits, which I don't believe are addressed
adaquately enough by chaparones to justify enshrining this complexity
into the protocol.
1. "These features could be used dangerously, and chaparone signatures make
them harder to use, thus less likely to be adopted by random wallet
authors."
This change is already hard to implement, even once you're on v1
segwit; you can't just use it with existing outputs. 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.
2. "Accidental key reuse can make this unsafe."
This is true, but chaparones don't seem to help. The main purpose of
ANYPREV is where you can't re-sign; in particular, in lightning you
are co-signing with an untrusted party up-front. So you have to
share the chaparone privkeys with one untrusted party.
The BIP says "SHOULD limit the distribution of those private keys".
That seems ridiculously optimistic: don't tell the secret to more
than *one* untrusted party?
In fact, lightning will also need to hand chaparone keys to
watchtowers, so we'll probably end up using some fixed known secret.
3. "Miners can reorg and invalidate downstream txs".
There's a principle (ISTR reading it years ago from Greg Maxwell?)
that if no spender is malicious, a transaction should generally not
become invalid. With ANYPREV, a miner could reattach a transaction
during a reorg, changing its txid and invalidating normal spends from
it.
In practice, I believe this principle will remain just as generally
true with ANYPREV:
1. For lightning the locktime will be fairly high before these txs are
generally spendable.
2. Doing this would require special software, since I don't see bitcoin
core indexing outputs to enable this kind of rewriting.
3. We already added such a common possibility with RBF, but before I
brought it up I don't believe anyone realized. We certainly
haven't seen any problems in practice, for similar practical
reasons.
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. If we do understand it, we should be able to point out
real problems.
Finally, it seems to me that chaparones can be opt-in, and don't need to
burden the protocol.
Cheers,
Rusty.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
2019-05-22 2:47 ` Rusty Russell
@ 2019-05-22 20:11 ` Anthony Towns
2019-05-27 1:26 ` Rusty Russell
0 siblings, 1 reply; 4+ messages in thread
From: Anthony Towns @ 2019-05-22 20:11 UTC (permalink / raw)
To: Rusty Russell; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
2019-05-22 20:11 ` Anthony Towns
@ 2019-05-27 1:26 ` Rusty Russell
0 siblings, 0 replies; 4+ messages in thread
From: Rusty Russell @ 2019-05-27 1:26 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-05-27 1:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-10 20:38 [bitcoin-dev] SIGHASH_ANYPREVOUT proposal Anthony Towns
2019-05-22 2:47 ` Rusty Russell
2019-05-22 20:11 ` Anthony Towns
2019-05-27 1:26 ` Rusty Russell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox