[Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[ZmnSCPxj]

Good morning lists,

Let me summarize concerns brought up:

* Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_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 any 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 outputs, 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 Taproot 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 commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it.
* If a UTXO used for an offchain protocol ends up in a cooperative-resolution 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 special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy.
But if this fact is kept secret *unless* the very specific case of unilateral 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 introduce another footgun into the bitcoin protocol with address reuse. It's common practice for bitcoin businesses to re-use addresses. Many exchanges [1] reuse addresses for cold storage with very large sums of money that is stored 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 changing the hash reference to the previous output, without invalidating the signatures. This allows transactions to be bound to any output that matches 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 storage address with a SIGHASH_NOINPUT signature, that signature can be replayed again and again on the blockchain until their wallet is drained. This might 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 transaction 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 offchain protocols like Lightning. This gives us the building blocks for enforcing 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 adoption 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_NOINPUT -- does NOT get mixed up with the first signing path that controls an exchanges onchain funds. If this were to happen, fund lost could occur if the 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 unintentionally 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 possible 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 transactions that the input may not bind to. For example an application SHOULD generate a new key-pair for the application instance using NOINPUT signatures and 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 introduces more complexity for key management (two keychains).
>
> One (of the few) upsides of the current Lightning penalty mechanism is that fund loss can be contained to balance of the channel. You cannot do something in the current protocol that will effect your funds outside of that channel. With SIGHASH_NOINPUT, that property changes.
>
> ### A side note
> In general, i think we should start disallowing uses of the SIGHASH protocols 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 big one.
>
> [1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
> [2] - https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
> [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016048.html
>
> On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > With the recently renewed interest in eltoo, a proof-of-concept implementation
> > [1], and the discussions regarding clean abstractions for off-chain protocols
> > [2,3], I thought it might be time to revisit the `sighash_noinput` proposal
> > (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
> >
> > (sorry for the long e-mail. I wanted to give enough context and describe the
> > various tradeoffs so people don't have to stitch them together from memory. 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 outputs, by
> > adding a sighash flag that excludes the output when signing. This allows 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 signature
> > 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-phase
> > currently, and to allow deployment alongside the next version of segwit
> > script. `bip-anyprevout` builds on top of BIP-118, adding integration with
> > `bip-taproot`, chaperone signatures, limits the use of the sighash flag to
> > script path spends, as well as a new pubkey serialization which uses the first
> > byte to signal opt-in.
> >
> > I'd like to stress that both proposals are complementary and not competing,
> > 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 tool in
> > our toolbox soon(ish).
> >
> > In the following I will quote a couple of things that were discussed during
> > the CoreDev meeting earlier this year, but not everybody could join, and 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 complex
> > 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 least
> > one developer proposing to use noinput for all transactions to discourage
> > address reuse.
> >
> > This was also mentioned at CoreDev [6]:
> >
> > > When [...] said he wanted to write a wallet that only used SIGHASH\_NOINPUT,
> > > that was pause for concern. Some people might want to use SIGHASH\_NOINPUT 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 hashing
> > > 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 shooting
> > > 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-level
> > protocol. This leads to those funds becoming inaccessible unless you gather
> > 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 signature,
> > that doesn't use noinput, or any of its variants, and therefore needs to 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 instance, 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 need 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 privkey 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 the
> >     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 malleability first
> >     and foremost. My counterparty has the incentive to trick me, a third-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 awesome work
> > by the way), there was no strong support for chaperone signatures during 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 problem, 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 easier to
> > > bypass it than to use it. Whereas for tagged outputs, it's that if you 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 outputs 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 supported for
> > > taproot v1 outputs, instead we have a segwit version 16 v16 that supports
> > > 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 exchange and
> > > receive a bech32 address, you declare it invalid. You make it less user
> > > friendly here; and there shouldn't be an address anyway. You might want to see
> > > it on a block explorer, but you don't want to pass it around to anyone.
> >
> > We don't need addresses in our contract constructions because we deal directly
> > with the scripts. This would also have the desired effect of no allowing
> > generic wallets to send to these addresses, or users accidentally sending
> > funds to what was supposed to be a one-off script used internally in the
> > off-chain contract.
> >
> > Notice that this idea was already used by Russell O'Connor when performing a
> > transaction on elements using his new scripting language simplicity
> > [7]:
> >
> > > For this experimental development, we created an improper segwit version,
> > > "version 31" for Simplicity addresses. The payload of this segwit version 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 outputs
> > used in a contract as such and making them identifiable. But maybe it would be
> > a good idea to create two domains anyway: one for user-addressable
> > destinations which users can use with their general purpose wallets, and 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 participants,
> > > 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 address I can
> > > give to someone else or not? It's all scripts, no real addresses. There 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 additional 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 / anyprevoutanyscript /
> >     anyprevout. While at the CoreDev meeting I think everybody agreed that
> >     these proposals a useful, also beyond eltoo, not everybody could be
> >     there. I'd therefore like to elicit some feedback from the wider community.
> > 2.  Is there strong support or opposition to the chaperone signatures
> >     introduced in anyprevout / anyprevoutanyscript? I think it'd be best to
> >     formulate a concrete set of pros and contras, rather than talk about
> >     abstract dangers or advantages.
> > 3.  The same for output tagging / explicit opt-in. What are the advantages 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] <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002131.html>
> > [2] <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017285.html>
> > [3] <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html>
> > [4] <https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki>
> > [5] <https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki>
> > [6] <http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/>
> > [7] <https://lists.ozlabs.org/pipermail/simplicity/2019/000018.html>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev