Skip to content

Remove tunable threshold in g1_lincomb_fast #601

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jtraglia merged 1 commit into from
Sep 16, 2025
+0 −15
Merged

Remove tunable threshold in g1_lincomb_fast #601

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 0 additions & 15 deletions src/common/lincomb.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,11 +50,6 @@ void g1_lincomb_naive(g1_t *out, const g1_t *p, const fr_t *coeffs, size_t len)
* @param[in] coeffs Array of field elements, length `len`
* @param[in] len The number of group/field elements
*
* @remark This function CAN be called with the point at infinity in `p`.
Copy link
Contributor

@b-wagn b-wagn Sep 16, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we remove this remark, does it mean that we can no longer input the point at infinity?
If so, we should say that. If we still can, then why does removing the remark make sense?
Keeping the remark then would not hurt and would be more explicit.

Copy link
Member Author

@jtraglia jtraglia Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah thanks for bringing this up. I removed this because I did not think it made sense to state anymore. No remark means no restrictions. For example, we do not state that g1_lincomb_naive can be used with points at infinity either.

* @remark While this function is significantly faster than g1_lincomb_naive(), we refrain from
* using it in security-critical places (like verification) because the blst Pippenger code has not
* been audited. In those critical places, we prefer using g1_lincomb_naive() which is much simpler.
*
* For the benefit of future generations (since blst has no documentation to speak of), there are
* two ways to pass the arrays of scalars and points into blst_p1s_mult_pippenger().
*
Expand All @@ -71,16 +66,6 @@ C_KZG_RET g1_lincomb_fast(g1_t *out, const g1_t *p, const fr_t *coeffs, size_t l
blst_p1_affine *p_affine = NULL;
blst_scalar *scalars = NULL;

/* Tunable parameter: must be at least 2 since blst fails for 0 or 1 */
const size_t min_length_threshold = 8;

/* Use naive method if it's less than the threshold */
if (len < min_length_threshold) {
g1_lincomb_naive(out, p, coeffs, len);
ret = C_KZG_OK;
goto out;
}

/* Allocate space for arrays */
ret = c_kzg_calloc((void **)&p_affine, len, sizeof(blst_p1_affine));
if (ret != C_KZG_OK) goto out;
Expand Down
Loading