From a1706fab94ff1e34436466a039bfc0779fcb631d Mon Sep 17 00:00:00 2001 From: raulcano Date: Sun, 8 Feb 2026 23:26:00 +0100 Subject: [PATCH 01/10] adds scalar convenience type and completes description to ECDSA adaptor sigs and DLEQ proof types --- Messaging.md | 52 ++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 44 insertions(+), 8 deletions(-) diff --git a/Messaging.md b/Messaging.md index b31bf4b..73bea07 100644 --- a/Messaging.md +++ b/Messaging.md @@ -120,14 +120,15 @@ integers can be omitted: The following convenience types are also defined: -* `chain_hash`: a 32-byte chain identifier (see [BOLT #0](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md#chain_hash)) -* `contract_id`: a 32-byte contract_id (see [Protocol Specification](Protocol.md)) -* `sha256`: a 32-byte SHA2-256 hash -* `signature`: a 64-byte bitcoin Elliptic Curve signature -* `ecdsa_adaptor_signature`: a 65-byte ECDSA adaptor signature (TODO: link to doc once [#50](https://github.com/discreetlogcontracts/dlcspecs/issues/50) is done) -* `dleq_proof`: a 97-byte zero-knowledge proof of discrete log equality (TODO: link to doc once [#50](https://github.com/discreetlogcontracts/dlcspecs/issues/50) is done) -* `x_point`: a 32-byte x-only public key with implicit y-coordinate being even as in [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design) -* `point`: a 33-byte Elliptic Curve point (compressed encoding as per [SEC 1 standard](http://www.secg.org/sec1-v2.pdf#subsubsection.2.3.3)) +* `chain_hash`: a 32-byte chain identifier (see [BOLT #0](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md#chain_hash)). +* `contract_id`: a 32-byte contract_id (see [Protocol Specification](Protocol.md)). +* `sha256`: a 32-byte SHA2-256 hash. +* `signature`: a 64-byte bitcoin Elliptic Curve signature. +* `ecdsa_adaptor_signature`: a 65-byte ECDSA adaptor signature (TODO: link to doc once [#50](https://github.com/discreetlogcontracts/dlcspecs/issues/50) is done). +* `dleq_proof`: a 97-byte zero-knowledge proof of discrete log equality (TODO: link to doc once [#50](https://github.com/discreetlogcontracts/dlcspecs/issues/50) is done). +* `x_point`: a 32-byte x-only public key with implicit y-coordinate being even as in [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design). +* `point`: a 33-byte Elliptic Curve point (compressed encoding as per [SEC 1 standard](http://www.secg.org/sec1-v2.pdf#subsubsection.2.3.3)). +* `scalar`: a 32-byte big-endian encoded integer as per [this description](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#notation-and-conventions). * `spk`: A bitcoin script public key encoded as ASM prefixed with a `u16` value indicating its length. * `short_contract_id`: an 8 byte value identifying a contract funding transaction on-chain (see [BOLT #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#definition-of-short-channel-id)) * `bigsize`: a variable-length, unsigned integer similar to Bitcoin's CompactSize encoding, but big-endian. Described in [BigSize](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#appendix-a-bigsize-test-vectors). @@ -335,6 +336,41 @@ This type contains CET signatures and any necessary information linking the sign * [`ecdsa_adaptor_signature`:`signature_n`] * [`dleq_proof`:`dleq_prf_n`] +### The `ecdsa_adaptor_signature` Type +This type contains an ECDSA adaptor signature, represented as a 65-byte stream that contains the following: + +`R`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). +- The point `R` is calculated by multiplying the random value `r` by `G`, as described [here](https://note.com/crypto_garage/n/na1ef06177b27). + +`s'`: a 32-byte encrypted signature scalar. This is calculated as ```s' = r^-1(H(m) + rTp)``` as explained [here](https://note.com/crypto_garage/n/na1ef06177b27). +- Note that `H(m)` is the 32-byte transaction id `txid` (not to confuse with the `m_o` in the Tweak points, where `m_o` is the outcome value published by the oracle, such as `heads` or `tails`, etc.) +- To calculate the adaptor signature scalar for numeric decomposition, one needs to calculate one tweak point `T_i` per digit and then obtain `T = T_0 + T_1 + ... + T_(i-1)` as described [here](https://medium.com/crypto-garage/optimizing-numeric-outcome-dlc-creation-6d6091ac0e47). + +#### `ecdsa_adaptor_signature` +1. data: + * [`point`:`R`] + * [`scalar`:`s'`] + +### The `dleq_proof` Type +This type contains a 97-byte zero-knowledge proof of discrete log equality. The values here presented are built as described in [this article by Ichiro Kuwahara](https://medium.com/crypto-garage/adaptor-signature-in-discreet-log-contracts-on-ecdsa-c8c04197e11f). + +`R'`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). +- The point `R'` is derived as `R' = rT`, where `T` is the tweak point (or adaptor point). +- The tweak point `T` is calculated as `T = R_o + H(R_o|P_o|m_o)`, where: + - `R_o` is the nonce point published by the oracle, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). + - `P_o` is the oracle public key, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). + - `m_o` is the outcome that the oracle commits to publish. + +`e`: a 32-byte sha256 outcome representing a challenge calculated as `e = H(R|R'|R_2|R_2')` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). + +`s`: a 32-byte signature verification scalar calculated as `s = r_2 + re` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). + +#### `dleq_proof` +1. data: + * [`point`:`R'`] + * [`sha256`:`e`] + * [`scalar`:`s`] + ### The `funding_signatures` Type This type contains signatures of the funding transaction and any necessary information linking the signatures to their inputs. From 655d8dfe23446e65015d239ff13a833fc8c54be8 Mon Sep 17 00:00:00 2001 From: raulcano Date: Mon, 9 Feb 2026 08:24:18 +0100 Subject: [PATCH 02/10] adds a bit more clarity in the explanations. --- Messaging.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/Messaging.md b/Messaging.md index 73bea07..a754dc2 100644 --- a/Messaging.md +++ b/Messaging.md @@ -337,14 +337,19 @@ This type contains CET signatures and any necessary information linking the sign * [`dleq_proof`:`dleq_prf_n`] ### The `ecdsa_adaptor_signature` Type -This type contains an ECDSA adaptor signature, represented as a 65-byte stream that contains the following: +This type contains an ECDSA adaptor signature, represented as a 65-byte stream as follows: `R`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). -- The point `R` is calculated by multiplying the random value `r` by `G`, as described [here](https://note.com/crypto_garage/n/na1ef06177b27). +- The point `R` is calculated by multiplying a random value `r` by `G`, as described [here](https://note.com/crypto_garage/n/na1ef06177b27). `s'`: a 32-byte encrypted signature scalar. This is calculated as ```s' = r^-1(H(m) + rTp)``` as explained [here](https://note.com/crypto_garage/n/na1ef06177b27). -- Note that `H(m)` is the 32-byte transaction id `txid` (not to confuse with the `m_o` in the Tweak points, where `m_o` is the outcome value published by the oracle, such as `heads` or `tails`, etc.) -- To calculate the adaptor signature scalar for numeric decomposition, one needs to calculate one tweak point `T_i` per digit and then obtain `T = T_0 + T_1 + ... + T_(i-1)` as described [here](https://medium.com/crypto-garage/optimizing-numeric-outcome-dlc-creation-6d6091ac0e47). +- `r` is the same random value used for `R`. +- `T` is a tweak point (or adaptor point) and is calculated as `T = R_o + H(R_o|P_o|m_o)`, where: + - `R_o` is the nonce point published by the oracle, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). + - `P_o` is the oracle public key, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). + - `m_o` is the outcome that the oracle commits to publish. +- `H(m)` is the 32-byte transaction id `txid` (not to confuse with the `m_o` in the Tweak points, where `m_o` is the outcome value published by the oracle, such as `heads` or `tails`, etc.) +- In numeric decomposition, one needs to calculate one tweak point `T_i` per digit and then obtain `T = T_0 + T_1 + ... + T_(i-1)` as described [here](https://medium.com/crypto-garage/optimizing-numeric-outcome-dlc-creation-6d6091ac0e47). #### `ecdsa_adaptor_signature` 1. data: @@ -355,13 +360,9 @@ This type contains an ECDSA adaptor signature, represented as a 65-byte stream t This type contains a 97-byte zero-knowledge proof of discrete log equality. The values here presented are built as described in [this article by Ichiro Kuwahara](https://medium.com/crypto-garage/adaptor-signature-in-discreet-log-contracts-on-ecdsa-c8c04197e11f). `R'`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). -- The point `R'` is derived as `R' = rT`, where `T` is the tweak point (or adaptor point). -- The tweak point `T` is calculated as `T = R_o + H(R_o|P_o|m_o)`, where: - - `R_o` is the nonce point published by the oracle, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). - - `P_o` is the oracle public key, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). - - `m_o` is the outcome that the oracle commits to publish. +- The point `R'` is derived as `R' = rT`, where `T` is the tweak point (or adaptor point) and `r` is the same random value used to calculate `R`. -`e`: a 32-byte sha256 outcome representing a challenge calculated as `e = H(R|R'|R_2|R_2')` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). +`e`: a 32-byte sha256 outcome representing a challenge calculated as `e = H(R|R'|R_2|R_2')` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). Also, the hash function needs to use a tag as specified [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality). `s`: a 32-byte signature verification scalar calculated as `s = r_2 + re` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). From 46187431cf52b3d1673e39d836303fbc1864b60c Mon Sep 17 00:00:00 2001 From: raulcano Date: Mon, 9 Feb 2026 08:34:53 +0100 Subject: [PATCH 03/10] minor editorial changes --- Messaging.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Messaging.md b/Messaging.md index a754dc2..7b619b7 100644 --- a/Messaging.md +++ b/Messaging.md @@ -360,11 +360,16 @@ This type contains an ECDSA adaptor signature, represented as a 65-byte stream a This type contains a 97-byte zero-knowledge proof of discrete log equality. The values here presented are built as described in [this article by Ichiro Kuwahara](https://medium.com/crypto-garage/adaptor-signature-in-discreet-log-contracts-on-ecdsa-c8c04197e11f). `R'`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). -- The point `R'` is derived as `R' = rT`, where `T` is the tweak point (or adaptor point) and `r` is the same random value used to calculate `R`. +- The point `R'` is derived as `R' = r * T`, where `T` is the tweak point (or adaptor point) and `r` is the same random value used to calculate `R`. -`e`: a 32-byte sha256 outcome representing a challenge calculated as `e = H(R|R'|R_2|R_2')` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). Also, the hash function needs to use a tag as specified [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality). +`e`: a 32-byte sha256 outcome representing a challenge calculated as `e = H(R|R'|R_2|R_2')` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). Also, the hash function needs to use a tag as specified [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality). The points `R_2` and `R_2'` are defined as follows: + + - `R_2 = r_2 * G` + - `R_2' = r_2 * T` -`s`: a 32-byte signature verification scalar calculated as `s = r_2 + re` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). +`s`: a 32-byte signature verification scalar calculated as `s = r_2 + re` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)), where: + + - `r_2` is a random value, used to generate `R_2` and `R_2'`. #### `dleq_proof` 1. data: From 68c960b625e2c9432a5ad67c369a7167222f7008 Mon Sep 17 00:00:00 2001 From: raulcano Date: Mon, 9 Feb 2026 22:21:42 +0100 Subject: [PATCH 04/10] minor updates --- Messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Messaging.md b/Messaging.md index 7b619b7..65e55c9 100644 --- a/Messaging.md +++ b/Messaging.md @@ -342,7 +342,7 @@ This type contains an ECDSA adaptor signature, represented as a 65-byte stream a `R`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). - The point `R` is calculated by multiplying a random value `r` by `G`, as described [here](https://note.com/crypto_garage/n/na1ef06177b27). -`s'`: a 32-byte encrypted signature scalar. This is calculated as ```s' = r^-1(H(m) + rTp)``` as explained [here](https://note.com/crypto_garage/n/na1ef06177b27). +`s'`: a 32-byte encrypted signature scalar. This is calculated as `s' = r^-1 * (H(m) + r * T * p)` as explained [here](https://note.com/crypto_garage/n/na1ef06177b27). - `r` is the same random value used for `R`. - `T` is a tweak point (or adaptor point) and is calculated as `T = R_o + H(R_o|P_o|m_o)`, where: - `R_o` is the nonce point published by the oracle, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). From c8dd6024b35a6d1624ec2c56d5824245fa34e2d8 Mon Sep 17 00:00:00 2001 From: raulcano Date: Fri, 20 Mar 2026 09:21:15 +0100 Subject: [PATCH 05/10] change order of parameters in the Hash function for the adaptor point --- Messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Messaging.md b/Messaging.md index 65e55c9..b42fc45 100644 --- a/Messaging.md +++ b/Messaging.md @@ -344,7 +344,7 @@ This type contains an ECDSA adaptor signature, represented as a 65-byte stream a `s'`: a 32-byte encrypted signature scalar. This is calculated as `s' = r^-1 * (H(m) + r * T * p)` as explained [here](https://note.com/crypto_garage/n/na1ef06177b27). - `r` is the same random value used for `R`. -- `T` is a tweak point (or adaptor point) and is calculated as `T = R_o + H(R_o|P_o|m_o)`, where: +- `T` is a tweak point (or adaptor point) and is calculated as `T = R_o + H(P_o|R_o|m_o)`, where: - `R_o` is the nonce point published by the oracle, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). - `P_o` is the oracle public key, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). - `m_o` is the outcome that the oracle commits to publish. From ff22180d8cdc49485a69564e9f698538761a56f6 Mon Sep 17 00:00:00 2001 From: raulcano Date: Fri, 20 Mar 2026 12:09:30 +0100 Subject: [PATCH 06/10] aligns variables in description to the ones used in ECDSA-adaptor.md --- Messaging.md | 44 +++++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/Messaging.md b/Messaging.md index b42fc45..3c9c0c0 100644 --- a/Messaging.md +++ b/Messaging.md @@ -340,42 +340,44 @@ This type contains CET signatures and any necessary information linking the sign This type contains an ECDSA adaptor signature, represented as a 65-byte stream as follows: `R`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). -- The point `R` is calculated by multiplying a random value `r` by `G`, as described [here](https://note.com/crypto_garage/n/na1ef06177b27). +- The point `R` is calculated by multiplying a random value `k` by the adaptor point `Y`, as described [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#encrypted-signing). +- `Y` is an adaptor point calculated as defined [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Introduction.md#signature-point). + +`s_a`: a 32-byte encrypted signature scalar. This is calculated as `s_a = k⁻¹ (m + r * x)` as explained [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#encrypted-signing). +- `k` is the same random value used to obtain `R`. +- `m` is the 32-byte transaction digest. +- `x` is the signer's private key. -`s'`: a 32-byte encrypted signature scalar. This is calculated as `s' = r^-1 * (H(m) + r * T * p)` as explained [here](https://note.com/crypto_garage/n/na1ef06177b27). -- `r` is the same random value used for `R`. -- `T` is a tweak point (or adaptor point) and is calculated as `T = R_o + H(P_o|R_o|m_o)`, where: - - `R_o` is the nonce point published by the oracle, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). - - `P_o` is the oracle public key, encoded as `x_point` (see [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types)). - - `m_o` is the outcome that the oracle commits to publish. -- `H(m)` is the 32-byte transaction id `txid` (not to confuse with the `m_o` in the Tweak points, where `m_o` is the outcome value published by the oracle, such as `heads` or `tails`, etc.) -- In numeric decomposition, one needs to calculate one tweak point `T_i` per digit and then obtain `T = T_0 + T_1 + ... + T_(i-1)` as described [here](https://medium.com/crypto-garage/optimizing-numeric-outcome-dlc-creation-6d6091ac0e47). #### `ecdsa_adaptor_signature` 1. data: * [`point`:`R`] - * [`scalar`:`s'`] + * [`scalar`:`s_a`] ### The `dleq_proof` Type -This type contains a 97-byte zero-knowledge proof of discrete log equality. The values here presented are built as described in [this article by Ichiro Kuwahara](https://medium.com/crypto-garage/adaptor-signature-in-discreet-log-contracts-on-ecdsa-c8c04197e11f). +This type contains a 97-byte zero-knowledge proof of discrete log equality. -`R'`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). -- The point `R'` is derived as `R' = r * T`, where `T` is the tweak point (or adaptor point) and `r` is the same random value used to calculate `R`. +`R_a`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). +- The point `R_a` is derived as `R_a = k * G`, where `G` is the generator point in the curve, and `k` is the same random value used to calculate `R` in the `ecdsa_adaptor_signature` type. -`e`: a 32-byte sha256 outcome representing a challenge calculated as `e = H(R|R'|R_2|R_2')` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)). Also, the hash function needs to use a tag as specified [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality). The points `R_2` and `R_2'` are defined as follows: +`b`: a 32-byte sha256 outcome representing a challenge calculated as `b = H(R_a || Y || R || A_G || A_Y)` (see [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proving)). Note that the hash function needs to use a tag as specified [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality). The points `A_G` and `A_Y` are defined as follows: - - `R_2 = r_2 * G` - - `R_2' = r_2 * T` + - `A_G = a * G` + - `A_Y = a * Y` + - `a` is a random value (see [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proving)). + - `R`, `Y` are the same values used in the `ecdsa_adaptor_signature` related to this proof. -`s`: a 32-byte signature verification scalar calculated as `s = r_2 + re` (see [here](https://note.com/crypto_garage/n/na1ef06177b27)), where: +`c`: a 32-byte signature verification scalar calculated as `c = a + b * k` (see [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proving)), where: - - `r_2` is a random value, used to generate `R_2` and `R_2'`. + - `a` is the random value described above. + - `b` is the challenge as described above. + - `k` is the secret random number used for calculating points `R` and `R_a` #### `dleq_proof` 1. data: - * [`point`:`R'`] - * [`sha256`:`e`] - * [`scalar`:`s`] + * [`point`:`R_a`] + * [`sha256`:`b`] + * [`scalar`:`c`] ### The `funding_signatures` Type From 3b7b67e2752805354d0883d3f30dda24e9f9ffe4 Mon Sep 17 00:00:00 2001 From: raulcano Date: Fri, 20 Mar 2026 12:11:08 +0100 Subject: [PATCH 07/10] updates authors --- Messaging.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Messaging.md b/Messaging.md index 3c9c0c0..bbf34f3 100644 --- a/Messaging.md +++ b/Messaging.md @@ -500,6 +500,8 @@ Nadav Kohen Ben Carman +Raúl Cano + ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). From fa5bb7cc65d8fde77d92c83d9dd0d585b65f7b21 Mon Sep 17 00:00:00 2001 From: raulcano Date: Fri, 20 Mar 2026 12:19:15 +0100 Subject: [PATCH 08/10] replace 'x' by 'k' for clarity and consistency ('x' used for a different purpose in a very close section) --- ECDSA-adaptor.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ECDSA-adaptor.md b/ECDSA-adaptor.md index 0fe46c9..f9a7218 100644 --- a/ECDSA-adaptor.md +++ b/ECDSA-adaptor.md @@ -67,9 +67,9 @@ The challenge hash `H` below is defined as `H(x) = scalar(SHA256(tag || x))`. ### Proving -The `DLEQ_prove(x, (X, Y, Z))` algorithm takes the following inputs: +The `DLEQ_prove(k, (X, Y, Z))` algorithm takes the following inputs: -- `x`: A **non-zero** scalar representing the witness for the proof. +- `k`: A **non-zero** scalar representing the witness for the proof. - `(X, Y, Z)`: Three **non-zero** secp256k1 points which define the statement to be verified. and is defined as: @@ -78,7 +78,7 @@ and is defined as: - Set `A_G` to `a * G` - Set `A_Y` to `a * Y` - Set `b` to `H(X || Y || Z || A_G || A_Y)` -- Set `c` to `a + b * x` +- Set `c` to `a + b * k` - Set `proof` to `b || c` - Return `proof` From 4b0e03227e65aacaf1ff4f51ad9d496d4f136b87 Mon Sep 17 00:00:00 2001 From: raulcano Date: Fri, 20 Mar 2026 22:01:08 +0100 Subject: [PATCH 09/10] removes a description that wrongly defined R as an adaptor point --- Messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Messaging.md b/Messaging.md index bbf34f3..58a01b8 100644 --- a/Messaging.md +++ b/Messaging.md @@ -339,7 +339,7 @@ This type contains CET signatures and any necessary information linking the sign ### The `ecdsa_adaptor_signature` Type This type contains an ECDSA adaptor signature, represented as a 65-byte stream as follows: -`R`: a 33-byte compressed elliptic-curve adaptor point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). +`R`: a 33-byte compressed elliptic-curve point as described in [Fundamental Types](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#fundamental-types). - The point `R` is calculated by multiplying a random value `k` by the adaptor point `Y`, as described [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#encrypted-signing). - `Y` is an adaptor point calculated as defined [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Introduction.md#signature-point). From f204d073e95a51370342768b764797ee1f91c9c3 Mon Sep 17 00:00:00 2001 From: raulcano Date: Fri, 20 Mar 2026 22:03:41 +0100 Subject: [PATCH 10/10] adds description of r --- Messaging.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Messaging.md b/Messaging.md index 58a01b8..1d06926 100644 --- a/Messaging.md +++ b/Messaging.md @@ -346,6 +346,7 @@ This type contains an ECDSA adaptor signature, represented as a 65-byte stream a `s_a`: a 32-byte encrypted signature scalar. This is calculated as `s_a = k⁻¹ (m + r * x)` as explained [here](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#encrypted-signing). - `k` is the same random value used to obtain `R`. - `m` is the 32-byte transaction digest. +- `r` is the x-coordinate of `R` (mod `n`) - `x` is the signer's private key.