Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Good morning list, To elucidate further --- Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`. This new opcode ignores any `SIGHASH` flags, if present, on a signature, but instead hashes the current transaction without the input references, then checks that hash to the signature. This is equivalent to `SIGHASH_NOINPUT`. Yet as an opcode, it would be possible to embed in a Taproot script. For example, a Decker-Russell-Osuntokun would have an internal Taproot point be a 2-of-2, then have a script `OP_1 OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden script, but cooperative closes would use the 2-of-2 directly. Of note, is that any special SCRIPT would already be supportable by Taproot. This includes SCRIPTs that may potentially lose funds for the user. Yet such SCRIPTs are already targetable by a Taproot address. If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not so concerned about Taproot abuse? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Good morning Christian, > 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. I rather strongly oppose output tagging. The entire point of for example Taproot was to reduce the variability of how outputs look like, so that unspent Taproot outputs look exactly like other unspent Taproot outputs regardless of the SCRIPT (or lack of SCRIPT) used to protect the outputs. That is the reason why we would prefer to not support P2SH-wrapped Taproot even though P2SH-wrapping was intended to cover all future uses of SegWit, including SegWit v1 that Taproot will eventually get. Indeed, if it is output tagging that gets into Bitcoin base layer, I would strongly suggest the below for all Decker-Russell-Osuntokun implementations: * A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, confirmed onchain * A "translator transaction" spending the above and paying out to a SegWit v16 output-tagged output, kept offchain. * Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` spending the translator transaction output. * Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` spending the update transaction output. The point regarding use of a commonly-known privkey to work around chaperone signatures is appropriate to the above, incidentally. In short: this is a workaround, plain and simple, and one wonders the point of adding *either* chaperones *or* output tagging if we will, in practice, just work around them anyway. Again, the *more* important point is that special blockchain constructions should only be used in the "bad" unilateral close case. In the cooperative case, we want to use simple plain bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot SegWit v1 addresses, to increase the anonymity set of all uses of Decker-Russell-Osuntokun and other applications that might use `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple bip-schnorr-signed n-of-n cases when the protocol is completed successfully by all participants). We already have the issue in current Lightning where the blockchain-explorer-revealed address for current, existing Poon-Dryja channels is unsafe to send any amount to. Granted, we should work to make things safer; but I suggest that we should be willing to sacrifice some amount of safety against arguably-stupid decisions in order to have better privacy for larger sets of users. > > 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. I submit that a Taproot whose internal Taproot point is a NUMS point (thus nobody knows its scalar) is similarly "secure perfectly but only when used in the right way". Yet the point of Taproot is to hide these outputs until they are spent, improving their privacy while unspent. I submit also that a Taproot whose internal Taproot point is an n-of-n of all participants, with script branches enforcing particular modes, are similarly "secure perfectly but only when used in the right way", and again the point of Taproot is to allow the n-of-n "everybody agrees" path to hide among the 1-of-1 whale HODLers. In short: I do not see how you can coherently argue for "we should separate `SIGHASH_NOINPUT` types to a new script type" while simultaneously arguing "we should merge all kinds of SCRIPT usage (and non-usage) together into a single script type". If we will separate `SIGHASH_NOINPUT`-enabled outputs, we should not implement Taproot, as the existing separation of P2WSH and P2WPKH is congruent to the proposed separation of `SIGHASH_NOINPUT`-enablement. > > 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
[Lightning-dev] Continuing the discussion about noinput / anyprevout
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
