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
5080c9c build: adapt Windows builds for libsecp256k1 build changes (fanquake)
ff061fd Squashed 'src/secp256k1/' changes from 705ce7ed8c..c545fdc374 (fanquake)
Pull request description:
Includes bitcoin-core/secp256k1#1378. Which fixes #28079.
Adapts Windows build for bitcoin-core/secp256k1#1367.
ACKs for top commit:
hebasto:
ACK 5080c9c, I've made the `src/secp256k1` subtree update locally and got zero diff with this PR branch.
jonasnick:
ACK 5080c9c
Tree-SHA512: 37915d420ebacefc6bc82c2511bff3d6884e01d5c92795f19cd61862f96b30aa1fe768aeabec128c9d25c1d8bc62b46b46969626067266074b39566ad9e2f5ba
Copy file name to clipboardexpand all lines: src/secp256k1/CHANGELOG.md
+10
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,16 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
8
8
## [Unreleased]
9
9
10
+
#### Added
11
+
- New module `ellswift` implements ElligatorSwift encoding for public keys and x-only Diffie-Hellman key exchange for them.
12
+
ElligatorSwift permits representing secp256k1 public keys as 64-byte arrays which cannot be distinguished from uniformly random. See:
13
+
- Header file `include/secp256k1_ellswift.h` which defines the new API.
14
+
- Document `doc/ellswift.md` which explains the mathematical background of the scheme.
15
+
- The [paper](https://eprint.iacr.org/2022/759) on which the scheme is based.
16
+
17
+
#### Changed
18
+
- When consuming libsecp256k1 as a static library on Windows, the user must now define the `SECP256K1_STATIC` macro before including `secp256k1.h`.
19
+
10
20
## [0.3.2] - 2023-05-13
11
21
We strongly recommend updating to 0.3.2 if you use or plan to use GCC >=13 to compile libsecp256k1. When in doubt, check the GCC version using `gcc -v`.
@@ -329,7 +329,7 @@ $t$ value for multiple $c$ inputs (thereby biasing that encoding):
329
329
it requires $g(u)=0$ which is already outlawed on even-ordered curves and impossible on others; in the second it would trigger division by zero.
330
330
* Curve-specific special cases also exist that need to be rejected, because they result in $(u,t)$ which is invalid to the decoder, or because of division by zero in the encoder:
331
331
* For $a=0$ curves, when $u=0$ or when $t=0$. The latter can only be reached by the encoder when $g(u)=0$, which requires an even-ordered curve.
332
-
* For $a \neq 0$ curves, when $X_0(u)=0$, when $h(u)t^2 = -1$, or when $2w(u + 2v) = 2X_0(u)$ while also either $w \neq 2Y_0(u)$ or $h(u)=0$.
332
+
* For $a \neq 0$ curves, when $X_0(u)=0$, when $h(u)t^2 = -1$, or when $w(u + 2v) = 2X_0(u)$ while also either $w \neq 2Y_0(u)$ or $h(u)=0$.
333
333
334
334
**Define** a version of $G_{c,u}(x)$ which deals with all these cases:
0 commit comments