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 3D828120F for ; Tue, 1 Oct 2019 13:31:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B21D8B1 for ; Tue, 1 Oct 2019 13:31:54 +0000 (UTC) Date: Tue, 01 Oct 2019 13:31:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1569936710; bh=oxcnbxOkYoQRQcplJGG2RDuszfI6gggojYewyBM//WA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=pEZ6VxCdr7on/G+Uu7qSlHRIsPreOvDrwSnRumI3EzSyFp+0ioHdO1CHWTJGZ1k9b cJ9tudrmfq+DO1yqH8ddVoKrsxzrjGgpqFQyzcu4AiWZF9J4OpEmDj6L7s3zttI1aX g0A9olbGuBnKUU43En03PUDg/hsU1Vqec4vpuFa8= To: Chris Stewart From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <87wodp7w9f.fsf@gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Christian Decker via bitcoin-dev , "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout 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: Tue, 01 Oct 2019 13:31:56 -0000 Good morning lists, Let me summarize concerns brought up: * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHAS= H_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`. * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is= *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as an= y other SegWit v1 output. I propose the below instead: * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`. * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`. Then, on usage: * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 ou= tputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP= _CHECKSIG_ADD` sequence. * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Tapro= ot internal point, with a MAST branch containing a Tapscript v16 with `OP_1= OP_CHECKSIG`. This solves both concerns: * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not comm= it to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPU= T` is unuseable to claim it. * If a UTXO used for an offchain protocol ends up in a cooperative-resoluti= on state, nobody has to know that a Tapscript v16 branch existed that could= have used `SIGHASH_NOINPUT`. Again, my objection to output tagging is that it is **publicly visible** as= soon as the funding transaction is confirmed onchain that this is a specia= l output used for a Decker-Russell-Osuntokun construction, greatly damaging= privacy. But if this fact is kept secret *unless* the very specific case of unilater= al uncooperative enforcement, then it is quite fine with me. Would this alternate proposal hold better muster? Regards, ZmnSCPxj > I do have some concerns about SIGHASH_NOINPUT, mainly that it does introd= uce another footgun into the bitcoin protocol with address reuse. It's comm= on practice for bitcoin businesses to re-use addresses. Many exchanges [1] = reuse addresses for cold storage with very large sums of money that is stor= ed in these addreses. > > It is my understanding with this part of BIP118 > > >Using NOINPUT the input containing the signature no longer references a = specific output. Any participant can take a transaction and rewrite it by c= hanging the hash reference to the previous output, without invalidating the= signatures. This allows transactions to be bound to any output that matche= s the value committed to in the witness and whose witnessProgram, combined = with the spending transaction's witness returns true. > > if an exchange were to once produce a digital signature from that cold st= orage address with a SIGHASH_NOINPUT signature, that signature can be repla= yed again and again on the blockchain until their wallet is drained. This m= ight be able to mitigated since the signatures commit to outputs, which may= be small in value for the transaction that SIGHASH_NOINPUT was used. This = means that an exchange could move coins from the address with a larger tran= saction that spends money to a new output (and presumably pays a higher fee= than the smaller transactions). > > ### Why does this matter? > > It seems that SIGHASH_NOINPUT will be an extremely useful tool for offcha= in protocols like Lightning. This gives us the building blocks for enforcin= g specific offchain states to end up onchain [2]. > > Since this tool is useful, we can presume that it will be integrated into= the signing path of large economic entities in bitcoin -- namely exchanges= . Many exchanges have specific signing procedures for transactions that are= leaving an exchange that is custom software. Now -- presuming wide adoptio= n of off chain protocols -- they will need to have a _second unique signing= path that uses SIGHASH_NOINPUT_. > > It is imperative that this second signing path -- which uses SIGHASH_NOIN= PUT -- does NOT get mixed up with the first signing path that controls an e= xchanges onchain funds. If this were to happen, fund lost could occur if th= e exchange is reusing address, which seems to be common practice. > > This is stated here in BIP118: > > >This also means that particular care has to be taken in order to avoid u= nintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be used,= unless it is explicitly needed for the application, e.g., it MUST NOT be a= default signing flag in a wallet implementation. Rebinding is only possibl= e when the outputs the transaction may bind to all use the same public keys= . Any public key that is used in a NOINPUT signature MUST only be used for = outputs that the input may bind to, and they MUST NOT be used for transacti= ons that the input may not bind to. For example an application SHOULD gener= ate a new key-pair for the application instance using NOINPUT signatures an= d MUST NOT reuse them afterwards. > > This means we need to encourage onchain hot wallet signing procedures to = be kept separate from offchain hot wallet signing procedures, which introdu= ces more complexity for key management (two keychains). > > One (of the few) upsides of the current Lightning penalty mechanism is th= at fund loss can be contained to balance of the channel. You cannot do some= thing in the current protocol that will effect your funds outside of that c= hannel. With SIGHASH_NOINPUT, that property changes. > > ### A side note > In general, i think we should start disallowing uses of the SIGHASH proto= cols that have unexpected behavior. The classic example of this is SIGHASH_= SINGLE [3]. I get uneasy about adding more footguns to the protocol, which = with current network behavior (address re-use) SIGHASH_NOINPUT would be a b= ig one. > > [1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html > [2] - https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Sept= ember/002136.html > [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/01= 6048.html > > On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev wrote: > > > With the recently renewed interest in eltoo, a proof-of-concept impleme= ntation > > [1], and the discussions regarding clean abstractions for off-chain pro= tocols > > [2,3], I thought it might be time to revisit the `sighash_noinput` prop= osal > > (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5]. > > > > (sorry for the long e-mail. I wanted to give enough context and describ= e the > > various tradeoffs so people don't have to stitch them together from mem= ory. If > > you're impatient there are a couple of open questions at the bottom) > > > > Both proposals are ways to allow rebinding of transactions to new outpu= ts, by > > adding a sighash flag that excludes the output when signing. This allow= s the > > transaction to be bound to any output, without needing a new signature,= as > > long as output script and input script are compatible, e.g., the signat= ure > > matches the public key specified in the output. > > > > BIP-118 is limited to explaining the details of signature verification,= and > > omits anything related to deployment and dependency on other proposals.= This > > was done in order not to depend on bip-taproot which is also in draft-p= hase > > currently, and to allow deployment alongside the next version of segwit > > script. `bip-anyprevout` builds on top of BIP-118, adding integration w= ith > > `bip-taproot`, chaperone signatures, limits the use of the sighash flag= to > > script path spends, as well as a new pubkey serialization which uses th= e first > > byte to signal opt-in. > > > > I'd like to stress that both proposals are complementary and not compet= ing, > > which is something that I've heard a couple of times. > > > > There remain a couple of unclear points which I hope we can address in = the > > coming days, to get this thing moving again, and hopefully get a new to= ol in > > our toolbox soon(ish). > > > > In the following I will quote a couple of things that were discussed du= ring > > the CoreDev meeting earlier this year, but not everybody could join, an= d it is > > important that we engage the wider community, to get a better picture, = and I > > think not everybody is up-to-date about the current state. > > > > ## Dangers of `sighash_noinput` > > > > An argument I have heard against noinput is that it is slightly less co= mplex > > or compute intensive than `sighash_all` signatures, which may encourage= wallet > > creators to only implement the noinput variant, and use it indiscrimi- > > nately. This is certainly a good argument, and indeed we have seen at l= east > > one developer proposing to use noinput for all transactions to discoura= ge > > address reuse. > > > > This was also mentioned at CoreDev [6]: > > > > > When [...] said he wanted to write a wallet that only used SIGHASH\_N= OINPUT, > > > that was pause for concern. Some people might want to use SIGHASH\_NO= INPUT as a > > > way to cheapen or reduce the complexity of making a wallet > > > implementation. SIGHASH\_NOINPUT is from a purely procedural point of= view > > > easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're ha= shing > > > less. It's way faster. That concern has been brought to my attention = and it's > > > something I can see. Do we want to avoid people being stupid and shoo= ting > > > themselves and their customers in the foot? Or do we treat this as a = special > > > case where you mark we're aware of how it should be used and we just = try to > > > get that awareness out? > > > > Another issue that is sometimes brought up is that an external user may > > attempt to send funds to a script that was really part of a higher-leve= l > > protocol. This leads to those funds becoming inaccessible unless you ga= ther > > all the participants and sign off on those funds. I don't believe this = is > > anything new, and if users really want to shoot themselves in the foot = and > > send funds to random addresses they fish out of a blockexplorer there's= little > > we can do. What we could do is make the scripts used internally in our > > protocols unaddressable (see output tagging below), removing this issue > > altogether. > > > > ## Chaperone signatures > > > > Chaperone signatures are signatures that ensure that there is no third-= party > > malleability of transactions. The idea is to have an additional signatu= re, > > that doesn't use noinput, or any of its variants, and therefore needs t= o be > > authored by one of the pubkeys in the output script, i.e., one or more = of the > > participants of the contract the transaction belongs to. Concretely in = eltoo > > we'd be using a shared key known to all participants in the eltoo insta= nce, so > > any participant can sign an update to rebind it to the desired output. > > > > Chaperone signatures have a number of downsides however: > > > > - Additional size: both the public key and the signature actually nee= d to be > > stored along with the real noinput signature, resulting in transfer= , > > computational and storage overhead. We can't reuse the same pubkey = from the > > noinput signature since that'd require access to the matching privk= ey which > > is what we want to get rid of using noinput in the first place. > > - Protocols can still simply use a globally known privkey, voiding th= e > > benefit of chaperone signatures, since third-parties can sign again= . I > > argue that third-party malleability is a subset of first-party > > malleability, and we should protect against first-party malleabilit= y first > > and foremost. My counterparty has the incentive to trick me, a thir= d-party > > may not. > > > > On the plus side chaperone signatures certainly address the lazy-wallet= -dev > > scenario, and as AJ points out in [bip-anyprevout] we get back the same > > security guarantees as we had without noinput. > > > > From what I remember and the transcript (thanks Kanzure for your awesom= e work > > by the way), there was no strong support for chaperone signatures durin= g the > > meeting [6], but feedback from people that were not present is needed: > > > > > if everyone who wanted to use NOINPUT was convinced there was a probl= em, then > > > they would pick the right thing, but clearly people aren't. It's not = a > > > foot-gun defense mechanism because it's easily bypassed, and it's eas= ier to > > > bypass it than to use it. Whereas for tagged outputs, it's that if yo= u want > > > any NOINPUT then you must tag. > > > > ## Output tagging > > > > One proposal that I found rather fascinating during the discussion in > > Amsterdam was that we could achieve the same disincentive to use on > > non-smart-contract cases by simply making the output scripts > > unaddressable. This can be done by specifying a version of taproot outp= uts for > > which the bech32 addressing scheme simply doesn't have a representation= [6]: > > > > > The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT supp= orted for > > > taproot v1 outputs, instead we have a segwit version 16 v16 that supp= orts > > > taproot. The reason for v16 is that we redefine bech32 to not cover > > > v16. There's no addresses for this type of output. If you're an excha= nge and > > > receive a bech32 address, you declare it invalid. You make it less us= er > > > friendly here; and there shouldn't be an address anyway. You might wa= nt to see > > > it on a block explorer, but you don't want to pass it around to anyon= e. > > > > We don't need addresses in our contract constructions because we deal d= irectly > > with the scripts. This would also have the desired effect of no allowin= g > > generic wallets to send to these addresses, or users accidentally sendi= ng > > funds to what was supposed to be a one-off script used internally in th= e > > off-chain contract. > > > > Notice that this idea was already used by Russell O'Connor when perform= ing a > > transaction on elements using his new scripting language simplicity > > [7]: > > > > > For this experimental development, we created an improper segwit vers= ion, > > > "version 31" for Simplicity addresses. The payload of this segwit ver= sion 31 > > > address contains a commitment Merkle root of a Simplicity program to = control > > > the UTXO. > > > > The concern with output tagging is that it hurts fungibility, marking o= utputs > > used in a contract as such and making them identifiable. But maybe it w= ould be > > a good idea to create two domains anyway: one for user-addressable > > destinations which users can use with their general purpose wallets, an= d one > > domain for contracts, which users cannot send to directly. > > > > This also came up during the CoreDev meeting [ams-coredev]: > > > > > these sort of NOINPUT signatures are only things that are within some > > > application or within some protocol that gets negotiated between part= icipants, > > > but they don't cross-independent domains where you see a wallet or a = protocol > > > as a kind of domain. You can't tell the difference, is this an addres= s I can > > > give to someone else or not? It's all scripts, no real addresses. The= re are > > > types of outputs that are completely insecure unconditionally; there = are > > > things that are protected and I can give to anyone, you don't want to= reuse > > > it, but there's no security issue from doing so. This is an additiona= l class > > > that is secure perfectly but only when used in the right way. > > > > ## Open questions > > > > The questions that remain to be addressed are the following: > > > > 1. General agreement on the usefulness of noinput / anyprevoutanyscrip= t / > > anyprevout. While at the CoreDev meeting I think everybody agreed t= hat > > these proposals a useful, also beyond eltoo, not everybody could be > > there. I'd therefore like to elicit some feedback from the wider co= mmunity. > > 2. Is there strong support or opposition to the chaperone signatures > > introduced in anyprevout / anyprevoutanyscript? I think it'd be bes= t to > > formulate a concrete set of pros and contras, rather than talk abou= t > > abstract dangers or advantages. > > 3. The same for output tagging / explicit opt-in. What are the advanta= ges and > > disadvantages? > > 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce= the > > confusion and make for simpler discussions in the end. > > 5. Anything I forgot to mention :-) > > > > Cheers, > > Christian > > > > [1] > > [2] > > [3] > > [4] > > [5] > > [6] > > [7] > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev