LNP/BP stands for "Bitcoin Protocol / Lightning Network Protocol". This repository covers standards & best practices for Layer 2+ in cases when they do not require soft- or hard-forks of the Bitcoin blockchain level and are not directly related to issues covered in Lightning Network RFCs (BOLTs).

LNPBP sstandards cover client-side validation protocols, which can be anchored or build on top of to Bitcoin. It includes primitives for L2+ solution design and describes complex use cases which can be built from some primitives. This allows such solutions as financial assets, storage, messaging, computing and different forms of secondary markets leveraging Bitcoin security model and Bitcoin as a method of payment/medium of exchange.

Criteria for a LNP/BP specification proposal:

• Should not be covered by existing or proposed BIPs

• Should not cause soft- or hard-fork in Bitcoin blockchain (but may depend on soft-forks from an existing BIP proposals)

• Should not distort Bitcoin miner's economic incentives

• Should not pollute Bitcoin blockchain with unnecessary non-transaction related data or have to maintain such pollution as low as possible

• Must not require a utility or security tokens to function (but may enable creation of digital assets or tokenized physical goods)

• Must not depend on non-bitcoin blockchains (but may be applicable to other blockchains)

Verticals for LNP/BP proposals:

List of LNP/BP standards and proposals

Invited or planned proposals to join LNP/BP standards family

1. Discreet log contracts:

2. Different

• Abstract

• Background

• Motivation

Abstract

Background

Motivation

Problems with modern merkle trees:

• Depth extension attack: no commitment to the tree depth

Design

Based on bitcoin merklization with following modifications:

• Tagged hashing for source data

• Tagged hashing of each tree object

• Commitments to depth, width and height of the tree

• Custom placeholders for empty objects

Specification

Merkle node is represented by a single SHA256 hash over the following data, serialized as a byte stream without any separators:

• branch type (byte)

• tag (128-bit number)

• depth (byte)

• width (4 bytes, little-endian)

If one or both of the child nodes are absent, a constant consisting of 16 0xFF bytes is used.

The root is produced via CommitmentId procedure

Compatibility

Rationale

Reference implementation

Acknowledgements

References

Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Test vectors

• Abstract

• Background

• Motivation

Abstract

Cryptographic commitments embedded into bitcoin transactions is a widely-used practice. It's application include timestamping [1], single-use seals [2], pay-to-contract settlement schemes [3], sidechains [4], blockchain anchoring [5], Taproot, Graftroot proposals [6, 7, 8], Scriptless scripts [9] and many others. Nevertheless, existing ways of creating commitments have never been standardized with best practices and do not commit to the exact protocol or commitment scheme used. They are also inapplicable to situations where multiple public keys are present in some output: how to deterministically detect which key is holding the commitment.

This work proposes a standardization for cryptographic commitments that utilize the homomorphic properties of the Secp256k1 elliptic curve (EC) and allows to commit to arbitrary data using an EC public key or a set of EC public keys from the Secp256k1 curve in a deterministic and safe way.

Background

Cryptographic commitments represent a way to commit to some message without revealing it. The procedure consists of two phases, commit and reveal. In the commit phase, a party (committer), willing to prove its knowledge of some message, computes a cryptographic hash function over that message producing a message digest, which can be provided to other party(ies). In the reveal phase, the committer reveals the actual message and each party accessing it may check that its hash is equal to the originally provided digest.

Key tweaking is a procedure for creation of a cryptographic commitment to some message using elliptic curve properties. The procedure uses the discrete log problem (DLP) as a proof of existence & knowledge of certain information about the message by some party (Alice) without exposing the original message. This is done by adding to a public key, for which Alice knows the corresponding private key, a hash of the message multiplied on the generator point G of the elliptic curve. This produces a tweaked public key, containing the commitment. At a later time Alice may prove her past knowledge of the original message (at the time when the commitment was created) by providing a signature corresponding to the original public key and the message itself.

The main advantage of the public key tweak procedure is the fact that a tweaked key, or a corresponding signature, can't be distinguished from any other public keys or signatures; this property allows to hide the actual commitment in such a way that it can only be known to those parties which have knowledge of the secrets: the original public and/or key pair and a message.

This type of commitment was originally proposed as a part of the pay to contract concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity Wall [2] for the same purpose. However, these proposals were arguably vulnerable to length-extension attacks and, more importantly, were not applicable to scenarios when multiple public keys are used (for instance, multi-signature bitcoin transaction outputs). These problems were fixed as a part of the sidechain-design efforts by Blockstream [3], which proposed to utilize a HMAC function and also introduced a nonce in the concept.

Here we propose a standardization of the algorithm based on the original Eternity Wall and Blockstream work, enhanced with Pieter Wuille's Tagged Hashes procedure, coming from a specification on Schnorr signatures in Bitcoin [4], also used in the Taproot proposal [5]. This procedure prevents cross-protocol collisions, such that the original message's byte sequence can't be reinterpreted under another protocol.

Motivation

Publication of cryptographic commitments to the Bitcoin blockchain is a widely used mechanism, allowing timestamping of the commitment: it can be used to prove the fact that some information was known before a certain period in time without revealing the actual information. Use of elliptic curve homomorphic properties allows to perform such commitments without increasing the size of the transaction, by leveraging existing transaction outputs and not polluting blockchain space with excessive OP_RETURNs. However, as of today, there is no single standard for such commitments. While different practices for that purpose exist (see [1, 2, 3]), they contain multiple collision risks, such as the possibility of length-extension attacks and cross-protocol replay attacks. Or they can't be applied in situations where multiple public keys are used ( multi-signature or custom bitcoin scripts). This standard combines existing best practices into a single algorithm, that avoids all of those issues.

Specification

Commitment procedure

For a given message msg, a list of public keys from the Secp256k1 curve P* := {P1, P2, ..., Pn}, n > 0, with a selected original public key Po from this list (Po ∈ P*), and a protocol-specific tag known to both parties, the commit procedure runs as follows:

1. Reduce list P* to a set of unique public keys P, by removing all duplicate public keys from the list.

2. Compute sum S of all unique public keys in set P; fail the protocol if an overflow over elliptic curve generator point order happens during the procedure.

The final formula for the commitment is: T = Po + G * HMAC-SHA256(SHA256("LNPBP1") || SHA256(tag) || msg, S*)

Verification procedure

Verification procedure for the commitment (i.e. tweaked public key T) can be performed with the provision of the list of public keys P*, the original public key Po and the message msg (assuming that the verifying party is aware of the protocol-specific tag and LNPBP1 tag) and runs as follows:

1. Make sure that the provided tweaked public key T lies on the elliptic curve and is not equal to the point at infinity.

2. Compute T' = Po + G * HMAC-SHA256(SHA256("LNPBP1") || SHA256(tag) || msg, S*) repeating the commitment procedure according to the rules above.

3. Make sure that T' = T and report verification success; otherwise report verification failure.

Reveal procedure

Thus, reveal data required for the commitment verification constists of:

1. Original message msg

2. Tweaked public key value T

3. Original set of public keys P and a key Po from that set.

The used protocol tag tag must be known to all parties participating in the protocol.

Compatibility

The proposed procedure should be compatible with previously-created pay-to-contract-style commitments based on SHA256 hashes under the assumption of SHA256 collision resistance. Utilization of a double tagged hash protocol prefix guarantees randomness in the first 64 bytes of the resulting tweaking string lnpbp1_msg, reducing probability for these bytes to be interpreted as a correct message under any of the previous standards.

The procedure is well compliant with Taproot SegWit v1, since it operates with a sum of the original public keys, and the Taproot intermediate key is a sum of all used public keys, so it can represent a correct input for the protocol.

The tweaked procedure may result in a public key that may, or may not have its y coordinate being a quadratic residue (in terms of BIP-340 [4]). This may present a compatibility issue for using this scheme in Taproot/Schnorr-enabled outputs and protocols. Nevertheless, this issue may be mitigated by running the procedure a second time and replacing the original public key with its own negation, if the resulting tweaked version was not square.

The proposal relies on a tagged hash prefix similar to the one used in BIP-340, [4], which helps to prevent protocol collisions.

Rationale

Commitments with a set of public keys, not a single key

The protocol was designed to support commitments to multiple public keys in order to be usable with non-P2(W)PK outputs. For instance, with Lightning network all outputs in the commitment transaction are non-P2WPK, so all existing key tweaking schemes are not usable within LN structure.

Use of HMAC insead of simple hash

Reason: prevention of length-extension attacks

As this protocol aims to be a generic scheme, the message msg can be of any length. If we would just use a simple hash (e.g. SHA256), users of LNPBP-1 could potentially be vulnerable to length-extension attacks, if they are not careful. To be on the safe side, we use HMAC-SHA256, which is resistant to length-extension attacks, but computationally more expensive. However, this protocol aims to be used in client-side validation applications primarily and should therefore run many orders of magnitude less often then complete validatation of all public blockchain data. The computational overhead of HMAC on a client node is therefore considered negligible, for the targeted use cases.

Public key serialization to 64 byte uncompressed form

Reason: HMAC needs a byte array as input

HMAC requires a byte array as input for the key argument to authenticate a message. This key is not intended to be an EC key, it can be anything. Its purpose is to add entropy to the resulting hash value to counter length attacks on the underlying message.

We use HMAC's key argument for two purposes:

1. Commit the message msg to a specific public key S.

2. As entropy for the security of HMAC-SHA256 against length extension attacks.

For the serialization of the public key S, we rely on the de facto standard format for uncompressed public keys in Bitcoin, which is followed by libraries like . However, this results in a 65 byte array with the first byte being the prefix having the value 0x04, denoting an uncompressed public key. However, the first byte doesn't add any entropy and a key larger than 64 byte causes HMAC-SH256 to do an additional round of hashing. Therefore, we use rust-secp256k1' s key.serialize_uncompressed() function, but strip the first byte from the resulting value, so we end up with a 64 byte array of:

• 32 bytes representing the x coordinate in big-endian order,

• followed by 32 bytes representing the y coordinate in big-endian order.

Use of protocol tags

Reason: prevention of cross-protocol collision attacks

The use of protocol-specific, double tagged hashes was originally proposed by Peter Wuille in [4] and [5] in order to prevent potential replay-attacks for interpreting messages under different protocols. The choice of a duplicate SHA256 prefix hash was made according to Peter Wuille because it is not yet used in any existing bitcoin protocol, which increases compatibility and reduces chances of collisions with existing protocols.

Protocol failures

The protocol may fail during some of the commitment procedure steps:

• when the tweaking factor f exceeds the order n of the generator point G for the selected elliptic curve.

• when the multiplication of the Secp256k1 generator point G on the tweaking factor f results in F being equal to the point at infinity.

The probabilities of these failures are infinitesimal; for instance the probability of the SHA256 hash value of a random message exceeding G order n is (2^256 - n) / n, which is many orders of magnitude less than the probability of a CPU failure. The probability of the second or third failure is even lower, since the point at infinity may be obtained only if F is equal to -G or -P, i.e. the probability of private key collision, equal to the inverse of Secp256k1 curve generator point order n. The only reason why this kind of failure may happen is when the original public key set was forged in a way that some of its keys are equivalent to the negation of other keys.

These cases may be ignored by a protocol user -- or, alternatively, in case of the protocol failure the user may change P's value(s) and re-run the protocol.

Protocol failures during the verification procedure may happen only during its repetition of the original commitment. This means that the original commitment is invalid, since it was not possible to create a commitment with the given original data. Thus, such failure will simply indicate a negative result of the verification procedure.

Choice of elliptic curve generator point order n over field order p

While it is possible to ignore elliptic curve overflow over its order n during public key addition, since it does not provide a security risk for the commitment, it was chosen to stick to this scheme because of the following:

• Current implementation of Secp256k1 library (libsecp256k1) fails on overflow during key tweaking procedure. Since this library is widely used in the Bitcoin ecosystem (and Bitcoin Core), it is desirable to maintain LNPBP-1 compatible with this functionality.

• Probability of an overflow is still infinissimal, being comparable to probability of 3.7*10^-66, for a tweaking factor not fitting into the elliptic curve field order p.

No nonce

In certain circumstances a simple hash based commitment might be vulnerable to brute force vocabulary attacks, if the syntax and semantics of the invoking protocol are known to the attacker. This is usually countered with adding additional entropy (e.g. a nonce) to each hash. In our case the public key S already provides enough entropy, which - when added via HMAC-SHA256 to the whole msg – sufficiently counters such vocabulary attacks, preventing an attacker from successfully guessing the original message, even for short and standard messages.

Reference implementation

Acknowledgements

Authors would like to thank:

• Alekos Filini for his initial work on the commitment schemes as a part of early RGB effort [6];

• ZmnSCPxj for bringing attention to possible Taproot-compatibility issues [7];

• Peter Wuille for a proposal on the tagged hashes, preventing reply-type of attacks [5];

• Authors of Sidechains whitepaper for paying attention to the potential length-extension attacks and the introduction of HMAC-based commitments to the original public key [3];

References

1. Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the Pay-to-Contract Protocol. arXiv:1212.3257 [cs.CR]

3. Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain Innovations with Pegged Sidechains (commit5620e43). Appenxix A. .

License

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Appendix A. Test vectors

All tests done with protocol-specific tag value equal to ProtoTag. Values for public keys are given in standard compressed pre-Shorr's Bitcoin encoding format; values for tweaking factors are given in little-endian byte order.

1. Correct test vectors

1.1. Zero-length message

1. Single public key #1

• Original public key: 03ab1ac1872a38a2f196bed5a6047f0da2c8130fe8de49fc4d5dfb201f7611d8e2

• Tweaked public key with the commitment: 025d69da2890f85928cb492545a13bd6782168b39d52e69fadd1d3fcb3b1bf9268

• Tweaking factor value: 9ff4c975950ec102b5eb39df2f976948b2c1a6e3f92ef5bf5af0e1241380dbcf

1. Single public key #2

• Original public key: 039729247032c0dfcf45b4841fcd72f6e9a2422631fc3466cf863e87154754dd40

• Tweaked public key with the commitment: 032fdf6c4023453b869294ddd28684f98fcaca604c2cd734c8dd64b8520547b0b4

• Tweaking factor value: 11db141cfe0143f60e9e9f9db478630033fc65eb4f682905e9044c87869459a5

1. Set of five public keys

• Original public key: 02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e

• Key set:

  • 02383b24fbea14253ac37b0d421263b716a34192516ea0837021a40b5966a06f5e

1.2. Message consisting of a single zero byte

1. Single public key #1

   • Original public key: 032564fe9b5beef82d3703a607253f31ef8ea1b365772df434226aee642651b3fa

   • Tweaked public key with the commitment: 0285f7e0a8cdd801e5fbf84602e84de46a036ba47230b2c37f7767a496aeb4e4c5

1.3. Message of text string test

1. Single public key #1

   • Original public key: 0271efa4e26a4179e112860b88fc98658a4bdbc59c7ab6d4f8057c35330c7a89ee

   • Tweaked public key with the commitment: 02605b2400618ca83f563e997da456c7ae99df9b38a7939ead5bc8e5b8b29f5d45

1.4. Binary messsage, hex encoding (little-endian byte order)

Original message for the all cases in this section: [0xde, 0xad, 0xbe, 0xef]

1. Single public key #1

   • Original public key: 0352045bcc58e07124a375ea004b3508ac80e625da2106c74f5cb023498de0545f

   • Tweaked public key with the commitment: 0357f2619c2805794ef65ab7ea7a349f4c1be4cc3f576584f8270f06e830f33e36

1.5. Keyset changes

Commitment creation and validation filters repeated keys and does not depend on the key order (since elliptic curve addition is commutative)

1. Set of five public keys containing duplicated keys

   • Message (binary string, little-endian byte order): [0x00, 0xde, 0xad, 0xbe, 0xef]

   • Original public key: 025d9e055d7e7a85f097e981779c6e1c40d74b0563e631128c06623609b99a8f87

2. Invalid test vectors

All these cases are cases for validation procedure, which must fail.

1. Case #1: commitment key created with a different original public key

   • Message: zero-length

   • Original public key: 03ab1ac1872a38a2f196bed5a6047f0da2c8130fe8de49fc4d5dfb201f7611d8e2

3. Edge cases: protocol failures

Keyset constructed of a key and it's own negation.

• Expected result: must fail commitment procedure with error indicating that the operation resulted at the point-at-infinity.

• Message: test

• Original public key: 0218845781f631c48f1c9709e23092067d06837f30aa0cd0544ac887fe91ddd166

Abstract

The proposal provides standard mechanism for creating, structuring & verifying deterministic bitcoin commitments ("anchoring") to multiple extra-transaction data (client-side-validated etc).

Background

Motivation

Design

Miltiple protocols may commit to external (non-transaction and non-blockchain) data by constructing a special data structure called anchor and committing to its content inside transaction input or output.

Specification

Commitment procedure

A party needing to commit to multiple data coming from distinct protocols MUST follow the algorithm:

1. Construct LNPBP-4 multi-message commitment;

2. Deterministically define transaction input or output which will contain the final commitment. This algorithm is not a part of the current specification and must be defined at upper protocol level (see for instance LNPBP-10).

3. Run commitment embedding procedure:

If algorithm failed the party creating commitment MAY change the structure of the transaction and try to repeat the commitment procedure.

Verification procedure

The verification process runs by repeating steps of the commitment protocol using the information provided during the reveal phase and verifying the result is equal to the provided proofs. If the commitment procedure fails at any of the steps, the verification procedure MUST also fail.

Anchor structure and serialization

Anchor consists of the following fields, serialized according to the strict serialization rules (see LNPBP-7):

1. txid: 32-byte transaction id

2. commitment: a commutment block structure from LNPBP-4

3. proof: a deterministic commitment proof which has the same structure for both LNPBP-2 and LNPBP-92 commitment:

The list of script_info variants is non-exhaustive. If a future version of script info variant byte is met the deserialization of anchor data MUST fail with explicit error and the anchor MUST not be verified.

If the anchor data does not match the provided script pubkey (for instance, being encoded as P2WSH-in-P2SH instead of P2WSH) the verifying party MUST fail verification even if other option is satisfied with other (non-specified) encoding.

Concealment of the anchor data

Anchor data contain extra information which is not required for the DBC validation and represents additional proofs for non-DBC validation procedures. This information is contained in commitment field of the anchor data structure containing LNPBP-4 multi-message commitment entrypy value, used for proving the absence of some specific protocol within the commitment tree. This information MAY be discarded for privacy reasons when the anchor data are passed to a third-party with a special conceal procedure as described in LNPBP-4 and LNPBP-9 standards.

Compatibility

Rationale

Why not to use 0x03 variant for keeping key spend path-only Taproot info

Using 0x03 variant (TaprootScript) for Taproot outputs having no script path spending conditions (i.e. self-tweaked keys) instead of 0x00 (SinglePubkey) will result in storing additional 32 bytes on the client side per each output of this type, while providing no privacy gains: a user hacing access to the anchor data can always make sure that the value of the script tweak is equal to the self-tweak and still acquire knowledge that the output does not contain a script path spending condition.

Why not to use single 0x01 variant for all types of scripts

P2WSH-in-P2SH require its own script info variant (0x02, WrappedWitnessScript) since this allows to simplify verification algorithm by avoiding trying multiple script encodings (native P2SH and legacy P2WSH-in-P2SH). This does not reduce forward compatibility: we may have 252 more variants for script info value, which is exceeds a possible number of future bitcoin script pubkey encoding (15 possible future witness values).

Reference implementation

The reference implementation is version 1.0 of , which is a part of the developed and maintained by LNP/BP Strandards Association.

If the implementation differs from the spec, the spec has a higher priority.

Acknowledgements

References

Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Test vectors

• Abstract

• Background

• Motivation

Abstract

A single-use-seal is an abstract mechanism to prevent double-spends. The current proposal defines core single-use-seal terminology and procedures which must be supported and implemented according to this guidelines by any specific single-use-seal implementation.

Background

Concept of single-use-seal was developed as a result of research work on cryptographic commitments, consensus protocols in distributed systems and client-side-validation [1, 2, 3, 4].

Motivation

Existing cryptographic commitment primitives does not allow to create "two-level" commitments, whether at initial stage a commiter commits to commit to a certain (potentially yet unknown) message in the future, once and only once. Given a trustless way of performing verification of such commitments the primitive may be a basic building block for creating decentralized, private and censorship-resistant state machines and smart contracting systems which will be protected from "double-spend" attacks.

Design

Analogous to the real-world, physical, single-use-seals used to secure shipping containers, a single-use-seal primitive is a unique object that can be closed over a message exactly once. In short, a single-use-seal is an abstract mechanism to prevent double-spends.

Specification

For a given data structure $l$ providing single-use-seal definition and a message $m$ single-use-seal implementation MUST support two fundamental operations:

• Close seal $l$ over message $m$, producing a witness $w_l$:

  Close($l$,$m$)→$w_l$

• Verify that the seal $l$ was closed over message $m$:

  Verify($l$,$w_l$,$m$)

A single-use-seal implementation is secure if it is impossible for an attacker to cause the Verify function to return true for two distinct messages $m1$, $m2$, when applied to the same seal (it is acceptable, although non-ideal, for there to exist multiple witnesses for the same seal/message pair).

Practical single-use-seal implementations will also obviously require some way of generating new single-use-seals. Secondly, authentication is generally useful. Thus we have:

• Generate a new seal bound to pubkey p:

  Gen($p$)→$l$

• Close seal $l$ over message $m$, authenticated by signature $s$ valid for pubkey $p$:

  Close($l$,$m$,$s$)→$w_l$

Trust

An obvious single-use-seal implementation is to simply have a trusted notary, with each seal committing to that notary’s identity, and witnesses being cryptographic signatures produced by that notary. A further obvious refinement is to use disposable keys, with a unique private key being generated by the notary for each seal, and the private key being securely destroyed when the seal is closed.

For a scalable, trust-minimized, single-use-seal implementation we can use a proof-of-publication ledger, where consensus over the state of the ledger is achieved in a trust-minimized manner (i.e. Bitcoin blockchain).

Reference implementation

The reference implementation is version 1.0 of , which is a part of the developed and maintained Dr Maxim Orlovsky at LNP/BP Strandards Association.

If the implementation differs from the spec, the spec has a higher priority.

References

1. Peter Todd. Preventing Consensus Fraud with Commitments and Single-Use-Seals

2. Peter Todd. Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication.

3. Peter Todd. Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance.

Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Abstract

This specification proposes a batch of improvements for lightning payment channels: (1) generalization of channels to have an arbitrary number of participants (multi-peer channels), (2) abstraction from specific peyment routing syncrhronization algorithm (HTLC, PTLC), (3) ability to extend and change channel parameters and structure on-the-go, (4) use of Schnorr signatures, MuSig, Taproot and miniscript-based descriptors. It achieves this properties by leveraging Bifrost protocol, specifically LNPBP-50 and LNPBP-51 standards.

• Abstract

• Background

• Motivation

Abstract

The standard defines an algorithm for deterministic embedding and verification of cryptographic commitments based on elliptic-curve public key tweaking procedure defined in inside scriptPubkey script for existing types of Bitcoin transaction output.

Background

Cryptographic commitments embedded into bitcoin transactions is a widely-used practice. Its application include timestamping [1], single-use seals [2], pay-to-contract settlement schemes [3], sidechains [4], blockchain anchoring [5], Taproot, Graftroot proposals [6, 7, 8], Scriptless scripts [9] and many others.

Motivation

A number of cryptographic commitment (CC) use cases require the commitment to be present within non-P2(W)PK(H) outputs,which may contain multiple public keys and need a clear definition of how the public key that contain the commitment can be found within the bitcoin script itself. For instance, embedding CC into Lightning Network (LN) payment channel state updates in the current version requires the modification of an offered HTLC and received HTLC transaction outputs[10], and these transactions contain only a single P2WSH output. With the use of option_anchor_outputs [11] all outputs in the LN commitment transaction becomes P2WSH outputs, also leading to a requirement for a standard and secure way of making CC inside P2(W)SH outputs.

At the same time, P2(W)SH and other non-standard outputs (like explicit bare script outputs, including OP_RETURN type) are not trivial to use for CC, since CC requires deterministic definition of the actual commitment case. Normally, one of the most secure and standard CC scheme uses homomorphic properties of the public keys [12]; however multiple public keys may be used within non-P2(W)PK(H) output. Generally, these outputs present a hash of the actual script, hiding the used public keys or their hashes. Moreover, it raises the question of how the public key within Bitcoin Script may be defined/detected, since it is possible to represent the public key in a number of different ways within bitcoin script itself (explicitly or by a hash, and it's not trivial to understand where some hash stands for a public key or other type of preimage data). All this raises a requirement to define a standard way and some best practices for CC in non-P2(W) PK(H) outputs. This proposal tries to address the issue by proposing a common standard on the use of public-key based CC [12] within all possible transaction output types.

Design

The protocol requires that exactly one public key of all keys present or referenced in scriptPubkey and redeemScript must contain the commitment (made with LNPBP-1 procedure) to a given message. This commitment is deterministically singular, i.e. it can be proven that there is no other alternative message that the given transaction output commits to under this protocol. The singularity is achieved by committing to the sum of all original (i.e. before the message commitment procedure) public keys controlling the spending of a given transaction output. Thus, the given protocol covers all possible options for scriptPubkey transaction output types.

The commitment consists of the updated scriptPubkey value, which may be embed into the transaction output, and an extra-transaction proof (ETP), required for the verification of the commitment. The structure and information in the proof depends on the actual scriptPubkey type.

The protocol includes an algorithm for deterministic extraction of public keys from a given Bitcoin script, based on Miniscript [16].

Specification

Commitment procedure

The committing party, having a message msg, must:

1. Collect all public keys instances (named original public key set) related to the given transaction output, defined as:

   • a single public key for P2PK, P2PKH, P2WPK, P2WPK/WSH-in-P2SH type of outputs;

   • If OP_RETURN scriptPubkey is used, it must contain a single public key serialized in BIP-340 xcoordonly form right after OP_RETURN

Reveal procedure

The reveal protocol is usually run between the committing and verifying parties; however it may be used by the committing party to make the proofs of the commitment public. These proofs include:

• scriptPubkey from the transaction output containing the commitment;

• original message msg to which the committing party has committed;

• extra-transaction proof (ETP), constructed at the 5th step of the ;

Verification procedure

The verification process runs by repeating steps of the commitment protocol using the information provided during the reveal phase and verifying the results for their internal consistency; specifically:

1. Original public key set reconstruction:

   • if extra-transaction proof (ETP) provides script data (pt. 5.b from the commitment procedure) parse it according to deterministic key collection and collect all the original public keys from it; fail the verification procedure if parsing fails;

   • otherwise use an original public key provided as a part of ETP as a single- element set

Deterministic public key extraction from Bitcoin Script

1. The provided script MUST be parsed with Miniscript [16] parser; if the parser fails the procedure MUST fail.

2. Iterate over all branches of the abstract syntax tree generated by the Miniscript parser, running the following algorithm for each node:

   • if a public key hash is met (pk_h Miniscript command) and it can't be resolved against known public keys or other public keys extracted from the script, fail the procedure;

By "miniscript" we mean usage of rust-miniscript library v2.0.0 (commit 463fc1eadac2b46de1cd5ae93e8255a2ab34b906) which may be found at

Compatibility

The proposed cryptographic commitment scheme is fully compatible, and works with LNPBP-1 standard [12] for constructing cryptographic commitments with a set of public keys.

The standard is not compliant with previously used OP_RETURN-based cryptographic commitments, like OpenTimestamps [1], since it utilises plain value of the public key with the commitment for the OP_RETURN push data.

The author is not aware of any P2(W)SH or non-OP_RETURN cryptographic commitment schemes existing before this proposal, and it is highly probable that the standard is not compatible with ones if they were existing.

The proposed standard is compliant with current Taproot proposal [14], since it can use intermediate Taproot key to store the commitment.

Standard also should be interoperable with Schnorr's signature proposal [15], since it uses miniscript supporting detection of public keys serialized with new BIP-340 rules.

Rationale

Continuing support for P2PK outputs

While P2PK outputs are considered obsolete and are vulnerable to a potential quantum computing attacks, it was decided to include them into the specification for unification purposes.

Support OP_RETURN type of outputs

OP_RETURN was originally designed to reduce the size of memory-kept UTXO data; however it is not recommended to use it since it bloats blockchain space usage. This protocol provides support for this type of outputs only because some hardware (like HSM modules or hardware wallets) can't tweak public keys inside outputs and produce a correct signature after for their spending, and keeping the commitment in OP_RETURN's can be an only option. For all other cases it is highly recommended not to use OP_RETURN outputs for the commitments and use tweaking of other types of outputs instead.

Unification with OP_RETURN-based commitments

While it is possible to put a deterministic CC commitments into OP_RETURN-based outputs like with [1], their format was modified for unification purposes with the rest of the standard. This will help to reduce the verification and commitment code branching, preventing potential bugs in the implementations.

Custom serialization of public keys in OP_RETURN

This saves one byte of data per output, which is important in case of blockchain space.

While we could pick a new BIP340-based rules for public key serialization [15], this will require software to support new versions of the secp256k1 libraries and language-specific wrappers, which may be a big issue for legacy software usually used by hardware secure modules, which require presence of OP_RETURN's (see rationale points above).

Support for pre-SegWit outputs

These types of outputs are still widely used in the industry and it was decided to continue their support, which may be dropped in a higher-level requirements by protocols operating on top of LNPBP-2.

Committing to the sum of all public keys present in the script

Having some of the public keys tweaked with the message digest, and some left intact will make it impossible to define a simple and deterministic commitment scheme for an arbitrary script and output type that will prevent any potential double-commitments.

Deterministic public key extraction for a Bitcoin script

We use determinism of the proposed Miniscript standard to parse the Bitcoin script in an implementation-idependet way and in order to avoid the requirement of the full-fledged Bitcoin Script interpreter for the commitment verification.

The procedure fails on any public key hash present in the script, which prevents multiple commitment vulnerability, when different parties may be provided with different extra-transaction proof (ETP) data, such that they will use different value for the S public key matching two partial set of the public keys (containing and not containing public keys for the hashed values).

The algorithm does not require that all of the public keys will be used in signature verification for spending the given transaction output (i.e. public keys may not be prefixed with [v]c: code in Miniscript [16]), so the committing parties may have a special public key shared across them for embedding the commitment, without requiring to know the corresponding private key to spend the output.

Use of Taproot intermediate public key

With Taproot we can't tweak the public key contained in the scriptPubkey directly since it will invalidate its commitment to the Tapscript and to the intermediate key, rendering output unspendable. Thus, we put tweak into the underlying intermediate public key as the only available option.

Reference implementation

Acknowledgements

Authors would like to thank:

• Giacomo Zucco and Alekos Filini for their initial work on the commitment schemes as a part of early RGB effort [13];

• Dr Christian Decker for pointing out on Lightning Network incompatibility with all existing cryptographic commitment schemes.

References

1. Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin.

2. Peter Todd. Preventing Consensus Fraud with Commitments and Single-Use-Seals.

License

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Appendix A. Test vectors

1. Correct test vectors

TBD

2. Invalid test vectors

TBD

3. Edge cases: protocol failures

TBD

Abstract

This document specifies upgrade of BOLT-1, 3, 4 and 5-based routed payments in legacy network and covers payment routing via HTLC-based channel synchronization in Bifrost using Taproot, TapScript and miniscript-based bitcoin output descriptors.

Background

HTLC (hash-time-locked contracts) are used for coordination of state update between multiple UTXO-based channels. This was the first mechanism proposed for payment routing in the original lightning network.

Motivation

Legacy lightning network uses pre-Taproot scripts and non-Schnorr signatures, which reduces its privacy and requires more onchain space, especially in cases of non- cooperative channel closings.

Design

Specification

Messaging

HTLC-based payment coordination is performed by using onion message transport from LNPBP-52. This specification defines the following message types embedded as onion payloads:

HTLC_ADD

HTLC_EXPIRE

HTLC_FULFILL

HTLC_MALFORMED

It also re-uses SIG_UPDATE and REVOKE messages from the core Bifrost protocol (LNPBP-50).

Transactions

Each HTLC contract adds an output to the commitment transaction. The output depends on whether this is an offered HTLC or received one.

Offered HTLC outputs

Received HTLC outputs

These outputs are constructed after BOLT-3 with option_anchors (see rationale).

HTLC spending transactions

The input of HTLC spending transactions spends offered HTLC (for HTLC timeout transaction) or received HTLC (for HTLC success transaction) output from the commitment transaction.

• nLockTime:

  • 0 for HTLC-success

  • CLTV_EXPIRY for HTLC-timeout

On-chain protocol

TBD

Compatibility

Rationale

Use of OP_CHECKSIGADD

There are multiple ways to create multisig scheme in Taproot & TapScript [1]. In script-path spending leafs we choose to use OP_CHECKSIGADD-based scripts, defined by miniscript multi_a descriptors. This allows to avoid multiple interactive communications required for composinng aggregated MuSig signatures. The downside of this approach is a large witness stack size (and higher transaction cost), which may be mitigated by adopting PTLC-based scriptless- script contracts [2].

Use of option_anchors

HTLC construction in Bifrost always requires use of equivalent of legacy BOLT-9 "anchored outputs" option. This addresses a vulnerability caused by the absence of self-delay seqnence lock, where local party had an incentive to non-cooperatively close the channel in order to instantly get access to the local funds.

Reference implementation

Acknowledgements

References

2. LNPBP-0056

Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Test vectors

• Abstract

• Background

• Motivation

Abstract

The proposal standardizes derivation paths used by lightning nodes, for both BOLT-compatible and Bifrost networks.

Background

BOLT-3 define a number of "basepoints" - public and private keys used in channel transaction construction and the rules for derivation of the specific keys for each of the transactions out of the basepoint set.

This proposal fills in the gap of how these basepoints may be deterministically derived from a single extended key.

Motivation

A standard for deterministic derivation of keys used in channel transaction construction will allow users to always recover the whole information out of a seed phrase independently from a specific node implementation used for channel creation.

Design

We define a extended lightning key as an extended master private key used for all derivations of channel basepoints, funding wallet and node key. This key is derivable from the extended master key / seed phrase using a specific derivation path purpose value 9735'.

Specification

Extended lightning key should be derived from a extended master key using the following derivation path:

m/9735'/

where 9735' is a BIP-43 purpose field reserved for this standard.

Node key is derived from the extended lightning key using /chain'/0'/node_index' derivation, where chain' is a hardened index specifying blockchain operated by the node, and node_index' is a hardened incremental index for the node among all nodes managed by a seed owner.

Channel basepoint is derived from the extended lightning key using /chain'/1'/ln_ver'/channel' derivation, where:

• channel' is a hardened index constructed from the initial channel id most significant bits starting from 1 to 32 using zero-based indexing. For BOLT-defined lightning channels initial channel id is the temporary channel id value; for Bifrost channel it is the channel id value.

• ln_ver' is a hardened index set to 0' for BOLT-defined lightning channels and 1' for Bifrost channels.

Derivation paths for the base points are the following:

Basepoint name | Derivation suffix | Full derivation path -------------- | ------------------------------------------- Funding | /0 | m/9735'/chain'/1'/ln_ver'/channel'/0 Payment | /1 | m/9735'/chain'/1'/ln_ver'/channel'/1 Delayed | /2 | m/9735'/chain'/1'/ln_ver'/channel'/2 Revocation | /3 | m/9735'/chain'/1'/ln_ver'/channel'/3 Per-commitment | /4/* | m/9735'/chain'/1'/ln_ver'/channel'/4/0 HTLC | /5 | m/9735'/chain'/1'/ln_ver'/channel'/5 PTLC | /6

Funding wallet used for keeping funds by a lightning node for constructing funding transactions is derived with /chain'/2'/case/index path, where case is an equivalent of change field with RGB extensions (see ___) and index is a sequential index number.

Example of extended keys used by lightning node #0 on bitcoin network for a BOLT-defined channel with temporary channel id 2938ce5c0cae4b2af072065dc7dcea68de5e3de0c936742e27e045c8650c6a79:

Please note that the channel shutdown key is derived from a funding wallet - and not from a channel basepoint.

Compatibility

TBD: investigate derivation paths used by specific lightning nodes

c-Lightning

LND

Eclair

LNP Node

LNP Node is fully compatible with the standard

Electrum

Rationale

Choice of 9735h for BIP-43 purpose

BIP-43 defines that new purposes must be created with new BIPs and their hardened index representations must match that BIP number. Since we this standard is created before BIP proposal for a new purpose, we need to choose some large number which will not be used by BIPs in a foreseable future. 9735 is the unicode character value for lightning (☇) also used as a port number in lightning network.

Use of channel ids for channel basepoint derivation

Channels may be created asynchronously and it is hard to get sequential numbering within the lightning node. Also, if the node data are lost, it will be hard to guess which channel had which sequence index. Thus, the only way to get a channel-specific derivation index is to use some of channel id bits.

We can't use channel funding transaction id since it will be known only upon key derivation.

Selection of bits for channel basepoint

We can use only 31 bits, since the most significant bit of derivation index is occupied by hardering flag (see BIP-32). We start with the second most significant channel bit to make it easy visually compare index with channel id without any bit shifts.

Use of unhardeded derivation between basepoints

Each channel is derived with hardened derivation, which allows to separate node from channels: if a node-level extended public – or even extended private key is leaked, it still be impossible to guess from the key information which channels ere created or closed with that node. From the other hand, if one needs to disclose the full information about the channel transaction it will be sufficient to have a single extended public key for channel basepoint to derive all other public keys any channel transaction.

Shutdown key derived from funding wallet

Funding wallet may be a separate process - or separate cold wallet, isolated from the rest of the lightning node. Deriving shutdown key from funding wallet allows it to use funds from closed channels for funding new channels without the need for additional interactivity with the lightning node.

Using unhardened indexes for per-commitment points

This allows user to reconstruct channel history without the need to access channel extended private key.

Reference implementation

The reference implementation of this derivation standard is done in a as a part of legacy::channel::Keyset, bifrost::channel::Keyset and NodeAccount structures.

Acknowledgements

References

Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Test vectors

Note: This standard has been superseded by due to incompatibility with Lightning, Coinjoin, and consignment metadata.

• Abstract

• Background

• Motivation

Abstract

Background

Motivation

Design

Specification

Bifrost transaction requirements

Bifrost requires all off-chain transactions always be of version 2. Transaction outputs which are internal to the channel (i.e. spend by other offchain transactions participating in channel) MUST use v1 witness P2TR outputs (or later witness versions). The scripts in taproot key path spends MUST be miniscript-compatible.

For on-chain funding transactions and funding outputs of channel level 1 this requirement is released to witness v0 or above. The reason for lower requirement is the interoperability with the legacy lightning network, allowing migration of existing channels opened in legacy network to Bifrost.

There is no specific requirements for outputs which are not internal for the channel.

Channel coordination

For channel operations we assume that any channel may be a multi-peer channel. Thus, for channel updates it is required that all parties cooperate and sign the latest version of updated channel transactions. This is achieved by introducing concept of channel coordinator. Channel coordinator is the lightning node that has originally proposed channel. It is responsible for orchestrating message flow between all nodes which are the parts of the channel and keeping them up-to-date. Also, the channel coordinator is the only party required to have direct connections with other channel participants – and each of channel participants is required to be connected at least to the channel coordinator.

If a multiple nested channels are present, for all higher-level channels channel coordinator MUST be the same as channel coordinator for the base (level 1) channel; the list of participants for the nested channels MUST be a subset of the participants of the topmost level 1 channel.

Channel workflows

There are following workflows affecting channel status / existence. Each of these workflows represent a set of P2P messages exchanged by channel peers.

• Channel creation

• Moving channel from legacy to Bifrost LN

• Removing channel from Bifrost to legacy LN

• Changing channel status (pausing etc)

Workflow can be initiated only by a channel coordinator, and specific P2P messages inside the workflow can be sent either from the channel coordinator to a peer – or, in response, from a peer to the channel coordinator.

Normal channel operations are covered by application-specific business logic and messages and are not part of any listed channel workflow. Unlike workflows, they may be initiated by any of the channel peers sending message to the channel coordinator, however whenever they involve other peers or external channels, after being initiated they must be coordinated by the channel coordinator.

Channel creation workflow

Considering generic case of multi-peer channel setup channel creation workflow is organized with the following algorithm:

1. First, all parties agree on the structure of the funding transaction and overall transaction graph within the channel – simultaneously signing refund transaction (which, upon channel creation, will become first version of the channel commitment transaction). This is done using ProposeChannel requests sent by the channel coordinator to each of the peers, replying with either AcceptChannel (containing updated transaction graph with signed refund transaction) or Error. peers must wait for CHANNEL_CREATION_TIMEOUT period and discard all provisional channel data from their memory.

2. Once the refund transaction is fully signed – implying that the transaction graph if agreed between participants – channel coordinator starts next phase, where the funding transaction gets fully signed. Coordinator sends

During channel construction workflow channels are identified by ChannelId, which is constructed as a tagged SHA-256 hash (using bifrost:channel-proposal as tag) of the strict-serialized ChannelParams data and coordinator node public key.

Compatibility

Rationale

Reference implementation

Acknowledgements

References

Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Test vectors