Scheme for adding public key tweak commitments into transaction outputs

[dr-orlovsky]

Commit to a value with public keys (C2VPK): Generalized commitments based on public key tweaking

Motivation

Lightning network channel construction already lacks non-P2WSH outputs in its HTLC-success and HTLC-timeout transactions, making it impossible to utilize modern RGB and single use seal data for both milti-hop and direct payments/state updates. The specifics of the protocol is that it does require creation of HTLC-based output and related HTLC-output spending transactions even for a direct payments, so the support of P2WSH commitments becomes required issue to operate RGB assets over Lightning Network.

Moreover, the next changes to BOTL's assumes that commitment transactions will also be left without P2PKH outputs, since to_remote output will require CSV script option in order to fix existing misalignment of incentives during the channel close. Thus, it is required to enable P2WSH pay-to-contract commitments.

This specification proposes a generalized way to make a cryptographic commitments bases on pay-to-contract-style public key tweaking for any kind of transaction output, namely:

• legacy P2PK
• OP_RETURN and non-standard P2S
• P2(W)PKH
• P2(W)SH
• P2WPKH and P2WSH wrapped into P2SH

Specification

To commit to a given message msg using elleptic-curve-based public key tweaking according to LNPBPS-0001 in a given transaction output a committing party MUST modify each of the public keys P withing all bitcoin scripts (scriptPubkey, redeemScript and witnessScript).

For OP_RETURN P2S variant, in a transaction output containing a OP_RETURN op-code the code must be followed by a 33 compressed tweaked public key TP computed with the algorithm described above. In this case the party can use any original public key for the tweaking procedure, which it can disclose lately to the parties to which it aims to reveal the commitment.

Rationale

Why we modify of all public keys

It is impossible to introduce a standard deterministic commitment for all possible output types and script variants that can be reliable used without the risk of multiple concurrent commitments placed into the same output.

Why the legacy P2PK and other non-standard script schemes are supported

The aim of this standard is to be as much universal as possible. While P2PK outputs are considered legacy due to a potential poor resistance to quantum computing attacks and arguably higher bitcoin blockchain footprint, we see no reason to create an exception from a standard for any legacy use case.

[dr-orlovsky]

Addition to the specification:

In order to demonstrate the fact of C2VPK a committing party must provide a proof of commitment, consisting of:

• Transaction OutPoint (txid and vout) containing the commitment
• Values for all public keys used in the scripts associated with that OutPoint
• Deterministic procedure of creation of the scriptPubKey and sigScript parts from the provided public keys (or the redeemScript themselve)
• Complete script (with all branches in case of MAST or Taproot)

This proof can be verified with the party exposing the original value v

[dr-orlovsky]

The spec was written, the issue is outdated