Quote from: viljy on June 01, 2022, 06:49:49 PM

Что-то это не совсем то, что я имел в виду. А именно - полностью убрать операции удвоений из расчета. Таким образом изначально вычисляем 255 фиксированных открытых ключей, начиная от одного удвоения G и заканчивая точкой из 255 удвоений. Эти точки можно вычислить просто в эллиптическом калькуляторе и готовые значения взять. Уж много памяти не должны занять. Значит имеем всего 256 точек (откр. ключей) включая саму точку G. Затем на основании приватника в двоичном формате суммируем только те точки, которым соответствует 1 в соответствующем разряде. Так у нас полностью убраны из расчета удвоения. Значит используются только формулы для суммирования. Должно ли это быть быстрее?

Именно то, о чём Вы говорите, и реализуется в первой программе, если в качестве основания для разложения по степеням ввести двойку.
В этом случае создаётся база из 256 элементов (пуб. ключи, соответствующие 2^0, 2^1, 2^2, ..., 2^254, 2^255). МЕста в памяти такая база займёт совсем немного, почти ничего. Далее, при вычислении любого пуб. ключа никаких удвоений уже не происходит. Число (приватный ключ) представляется в виде суммы степеней двойки с соответствующими коэффициентами (0 или 1), и пуб. ключ вычисляется в соответствии с этими коэффициентами как сумма элементов базы.
При раскладывании на степени другого числа больше двойки число слагаемых уменьшается, что приводит к росту скорости вычисления пуб. ключа, но в таком случае растёт и размер базы.
Для относительно больших значений приватника библиотека работает быстрее. Для "маленьких" ключей библиотека отстаёт.
Возможны три причины "тормоза". 1-я: медленное разложение приватника в сумму степеней (во второй программе этот шаг отсутствует!). 2-я: использование словаря не самый эффективный способ хранения элементов базы. 3-я: медленно работает функция сложения пуб. ключей. Что скажут программисты?