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
Copy file name to clipboardExpand all lines: secp256k1-sys/depend/secp256k1/CONTRIBUTING.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,11 +44,11 @@ The Contributor Workflow & Peer Review in libsecp256k1 are similar to Bitcoin Co
44
44
45
45
In addition, libsecp256k1 tries to maintain the following coding conventions:
46
46
47
-
* No runtime heap allocation (e.g., no `malloc`) unless explicitly requested by the caller (via `rustsecp256k1_v0_11_context_create` or `rustsecp256k1_v0_11_scratch_space_create`, for example). Moreover, it should be possible to use the library without any heap allocations.
47
+
* No runtime heap allocation (e.g., no `malloc`) unless explicitly requested by the caller (via `rustsecp256k1_v0_12_context_create` or `rustsecp256k1_v0_12_scratch_space_create`, for example). Moreover, it should be possible to use the library without any heap allocations.
48
48
* The tests should cover all lines and branches of the library (see [Test coverage](#coverage)).
49
49
* Operations involving secret data should be tested for being constant time with respect to the secrets (see [src/ctime_tests.c](src/ctime_tests.c)).
50
50
* Local variables containing secret data should be cleared explicitly to try to delete secrets from memory.
51
-
* Use `rustsecp256k1_v0_11_memcmp_var` instead of `memcmp` (see [#823](https://github.com/bitcoin-core/secp256k1/issues/823)).
51
+
* Use `rustsecp256k1_v0_12_memcmp_var` instead of `memcmp` (see [#823](https://github.com/bitcoin-core/secp256k1/issues/823)).
52
52
* As a rule of thumb, the default values for configuration options should target standard desktop machines and align with Bitcoin Core's defaults, and the tests should mostly exercise the default configuration (see [#1549](https://github.com/bitcoin-core/secp256k1/issues/1549#issuecomment-2200559257)).
53
53
54
54
#### Style conventions
@@ -72,7 +72,7 @@ In addition, libsecp256k1 tries to maintain the following coding conventions:
72
72
* Use `void *ptr` instead of `void* ptr`.
73
73
* Arguments of the publicly-facing API must have a specific order defined in [include/secp256k1.h](include/secp256k1.h).
74
74
* User-facing comment lines in headers should be limited to 80 chars if possible.
75
-
* All identifiers in file scope should start with `rustsecp256k1_v0_11_`.
75
+
* All identifiers in file scope should start with `rustsecp256k1_v0_12_`.
This is implemented in `rustsecp256k1_v0_11_ellswift_swiftec_var`. The used $sign(x)$ function is the parity of $x$ when represented as in integer in $[0,q).$
474
+
This is implemented in `rustsecp256k1_v0_12_ellswift_swiftec_var`. The used $sign(x)$ function is the parity of $x$ when represented as in integer in $[0,q).$
475
475
476
476
The corresponding encoder would invoke the x-only one, but negating the output $t$ if $sign(t) \neq sign(y).$
477
477
478
-
This is implemented in `rustsecp256k1_v0_11_ellswift_elligatorswift_var`.
478
+
This is implemented in `rustsecp256k1_v0_12_ellswift_elligatorswift_var`.
479
479
480
480
Note that this is only intended for encoding points where both the x-coordinate and y-coordinate are unpredictable. When encoding x-only points
481
481
where the y-coordinate is implicitly even (or implicitly square, or implicitly in $[0,q/2]$), the encoder in
0 commit comments