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@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@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
