You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
dr-orlovsky
changed the title
Commit to public keys (C2PK): Generalized commitments based on public key tweaking
Commit to a value with public keys (C2VPK): Generalized commitments based on public key tweaking
Oct 10, 2019
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
changed the title
Commit to a value with public keys (C2VPK): Generalized commitments based on public key tweaking
Scheme for adding public key tweak commitments into transaction outputs
Oct 15, 2019
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:
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 keysP
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 keyTP
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.
The text was updated successfully, but these errors were encountered: