● Proposed anyprevout sighash modes: two weeks ago, Anthony Towns posted a proposed BIP to the Bitcoin-Dev and Lightning-Dev mailing lists for consideration. The idea, bip-anyprevout, provides two new signature hashing (sighash) modes that allow a signature to commit to fewer details about the funds being spent than the default bip-taproot and bip-tapscript sighash mode. This enables the functionality previously described by BIP118 with modification so that it works with Taproot and reduces the risk of accidental misuse. One of the new sighash modes is directly compatible with the proposed Eltoo layer for LN, requiring only modifications for Taproot and the addition of a chaperone signature (described later). A second sighash mode commits to more data than necessary for Eltoo in a way that may make it useful for atypical commitments in Eltoo or for use in other protocols.

A significant advantage of this proposal over BIP118 noinput is that it can make use of Taproot cooperative spends, allowing the two or more parties to an LN channel or other contract protocol to optionally spend their funds without revealing any of the contract terms (including that anyprevout was in use).

For a quick look at anyprevout, we consider it in the context of a two-party Eltoo-based LN channel. As a reminder, the key feature of Eltoo is that each balance change in a channel (state update) can be spent by any later state update, so there’s no risk of publishing an old state to the block chain like there is with the current penalty-based LN channels. Eltoo calls this capability rebinding and BIP118 proposed to make rebinding available by allowing signatures to skip committing to the input part of the spending transaction—allowing anyone to modify that part of the transaction to bind any later state they knew about.

The SIGHASH_ANYPREVOUTANYSCRIPT mode (any previous output, any script) defined by bip-anyprevout works similarly to BIP118 noinput, with the following changes. To use anyprevoutanyscript, the public key to which a signature is compared will need to use a special prefix (0x00 or 0x01; not to be confused with the pubkeys used for bip-taproot’s output key that uses the same prefix in a different context). Additionally, the script being evaluated will need to contain at least one signature that doesn’t use anyprevoutanyscript or the other new sighash mode described later. This non-anyprevout signature is called the chaperone signature because, under reasonable assumptions, it prevents an anyprevout signature from being misused. (See Newsletter #34 for details about the replay problem.) With the correct prefix and a chaperone signature, anyprevoutanyscript allows the signature to skip committing to the identifier for output being spent (the outpoint), that previous output’s scriptPubKey, and the hash of the executed taproot leaf (tapleaf). The transaction digest to which the signature commits still includes some details about the prevout, such as its bitcoin value.

Additionally, bip-anyprevout also defines another sighash mode: SIGHASH_ANYPREVOUT that also requires the same special pubkey prefix and chaperone signature, but it includes the prevout’s scriptPubKey and tapleaf hash in the signature. Whereas anyprevoutanyscript can allow Eltoo-like rebinding where any later state can bind to any earlier state (but earlier states can’t bind to later states), there may be alternative protocols (and times within the Eltoo protocol) where the participants want to ensure that state n can only bind to state n-1 and not any other state.

The proposal has begun receiving feedback on the mailing lists, so we’ll provide updates in subsequent newsletters summarizing any significant discussions.