From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F1DFF86D for ; Wed, 22 May 2019 02:47:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 206E47FB for ; Wed, 22 May 2019 02:47:46 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 457xrJ5G67z9sML; Wed, 22 May 2019 12:47:44 +1000 (AEST) From: Rusty Russell To: Anthony Towns , Bitcoin Protocol Discussion , bitcoin-dev@lists.linuxfoundation.org In-Reply-To: <20190510203804.554q333lw3l7qql4@erisian.com.au> References: <20190510203804.554q333lw3l7qql4@erisian.com.au> Date: Wed, 22 May 2019 12:17:31 +0930 Message-ID: <87d0kbkxx8.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: Wed, 22 May 2019 13:30:30 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 02:47:48 -0000 Anthony Towns via bitcoin-dev 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.