Skip to main content

Chinilla vdf verification (wraps C++)

Project description

Chinilla VDF

Build PyPI PyPI - Format GitHub

Total alerts Language grade: Python Language grade: C/C++

Building a wheel

Compiling chinillavdf requires cmake, boost and GMP/MPIR.

python3 -m venv venv
source venv/bin/activate

pip install wheel setuptools_scm pybind11
pip wheel .

The primary build process for this repository is to use GitHub Actions to build binary wheels for MacOS, Linux (x64 and aarch64), and Windows and publish them with a source wheel on PyPi. See .github/workflows/build.yml. CMake uses FetchContent to download pybind11. Building is then managed by cibuildwheel. Further installation is then available via pip install chinillavdf e.g.

Building Timelord and related binaries

In addition to building the required binary and source wheels for Windows, MacOS and Linux, chinillavdf can be used to compile vdf_client and vdf_bench. vdf_client is the core VDF process that completes the Proof of Time submitted to it by the Timelord. The repo also includes a benchmarking tool to get a sense of the iterations per second of a given CPU called vdf_bench. Try ./vdf_bench square_asm 250000 for an ips estimate.

To build vdf_client set the environment variable BUILD_VDF_CLIENT to "Y". export BUILD_VDF_CLIENT=Y.

Similarly, to build vdf_bench set the environment variable BUILD_VDF_BENCH to "Y". export BUILD_VDF_BENCH=Y.

This is currently automated via pip in the install-timelord.sh script in the chinilla-blockchain repository which depends on this repository.

If you're running a timelord, the following tests are available, depending of which type of timelord you are running:

./1weso_test, in case you're running in sanitizer_mode.

./2weso_test, in case you're running a timelord that extends the chain and you're running the slow algorithm.

./prover_test, in case you're running a timelord that extends the chain and you're running the fast algorithm.

Those tests will simulate the vdf_client and verify for correctness the produced proofs.

Contributing and workflow

Contributions are welcome and more details are available in chinilla-blockchain's CONTRIBUTING.md.

The master branch is the currently released latest version on PyPI. Note that at times chinillavdf will be ahead of the release version that chinilla-blockchain requires in it's master/release version in preparation for a new chinilla-blockchain release. Please branch or fork master and then create a pull request to the master branch. Linear merging is enforced on master and merging requires a completed review. PRs will kick off a ci build and analysis of chinillavdf at lgtm.com. Please make sure your build is passing and that it does not increase alerts at lgtm.

Background from prior VDF competitions

Copyright 2018 Ilya Gorodetskov generic@sundersoft.com

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Our VDF construction is described in classgroup.pdf. The implementation details about squaring and proving phrases are described below.

Main VDF Loop

The main VDF loop produces repeated squarings of the generator form (i.e. calculates y(n) = g^(2^n)) as fast as possible, until the program is interrupted. Sundersoft's entry from Chinilla's 2nd VDF contest is used, together with the fast reducer used in Pulmark's entry. This approach is described below:

The NUDUPL algorithm is used. The equations are based on cryptoslava's equations from the 1st contest. They were modified slightly to increase the level of parallelism.

The GCD is a custom implementation with scalar integers. There are two base cases: one uses a lookup table with continued fractions and the other uses the euclidean algorithm with a division table. The division table algorithm is slightly faster even though it has about 2x as many iterations.

After the base case, there is a 128 bit GCD that generates 64 bit cofactor matricies with Lehmer's algorithm. This is required to make the long integer multiplications efficient (Flint's implementation doesn't do this).

The GCD also implements Flint's partial xgcd function, but the output is slightly different. This implementation will always return an A value which is > the threshold and a B value which is <= the threshold. For a normal GCD, the threshold is 0, B is 0, and A is the GCD. Also the interfaces are slightly different.

Scalar integers are used for the GCD. I don't expect any speedup for the SIMD integers that were used in the last implementation since the GCD only uses 64x1024 multiplications, which are too small and have too high of a carry overhead for the SIMD version to be faster. In either case, most of the time seems to be spent in the base case so it shouldn't matter too much.

If SIMD integers are used with AVX-512, doubles have to be used because the multiplier sizes for doubles are significantly larger than for integers. There is an AVX-512 extension to support larger integer multiplications but no processor implements it yet. It should be possible to do a 50 bit multiply-add into a 100 bit accumulator with 4 fused multiply-adds if the accumulators have a special nonzero initial value and the inputs are scaled before the multiplication. This would make AVX-512 about 2.5x faster than scalar code for 1024x1024 integer multiplications (assuming the scalar code is unrolled and uses ADOX/ADCX/MULX properly, and the CPU can execute this at 1 cycle per iteration which it probably can't).

The GCD is parallelized by calculating the cofactors in a separate slave thread. The master thread will calculate the cofactor matricies and send them to the slave thread. Other calculations are also parallelized.

The VDF implementation from the first contest is still used as a fallback and is called about once every 5000 iterations. The GCD will encounter large quotients about this often and these are not implemented. This has a negligible effect on performance. Also, the NUDUPL case where A<=L is not implemented; it will fall back to the old implementation in this case (this never happens outside of the first 20 or so iterations).

There is also corruption detection by calculating C with a non-exact division and making sure the remainder is 0. This detected all injected random corruptions that I tested. No corruptions caused by bugs were observed during testing. This cannot correct for the sign of B being wrong.

GCD continued fraction lookup table

The is implemented in gcd_base_continued_fractions.h and asm_gcd_base_continued_fractions.h. The division table implementation is the same as the previous entry and was discussed there. Currently the division table is only used if AVX2 is enabled but it could be ported to SSE or scalar code easily. Both implementations have about the same performance.

The initial quotient sequence of gcd(a,b) is the same as the initial quotient sequence of gcd(a*2^n/b, 2^n) for any n. This is because the GCD quotients are the same as the continued fraction quotients of a/b, and the initial continued fraction quotients only depend on the initial bits of a/b. This makes it feasible to have a lookup table since it now only has one input.

a*2^n/b is calculated by doing a double precision division of a/b, and then truncating the lower bits. Some of the exponent bits are used in the table in addition to the fraction bits; this makes each slot of the table vary in size depending on what the exponent is. If the result is outside the table bounds, then the division result is floored to fall back to the euclidean algorithm (this is very rare).

The table is calculated by iterating all of the possible continued fractions that have a certain initial quotient sequence. Iteration ends when all of these fractions are either outside the table or they don't fully contain at least one slot of the table. Each slot that is fully contained by such a fraction is updated so that its quotient sequence equals the fraction's initial quotient sequence. Once this is complete, the cofactor matricies are calculated from the quotient sequences. Each cofactor matrix is 4 doubles.

The resulting code seems to have too many instructions so it doesn't perform very well. There might be some way to optimize it. It was written for SSE so that it would run on both processors.

This might work better on an FPGA possibly with low latency DRAM or SRAM (compared to the euclidean algorithm with a division table). There is no limit to the size of the table but doubling the latency would require the number of bits in the table to also be doubled to have the same performance.

Other GCD code

The gcd_128 function calculates a 128 bit GCD using Lehmer's algorithm. It is pretty straightforward and uses only unsigned arithmetic. Each cofactor matrix can only have two possible signs: [+ -; - +] or [- +; + -]. The gcd_unsigned function uses unsigned arithmetic and a jump table to apply the 64-bit cofactor matricies to the A and B values. It uses ADOX/ADCX/MULX if they are available and falls back to ADC/MUL otherwise. It will track the last known size of A to speed up the bit shifts required to get the top 128 bits of A.

No attempt was made to try to do the A and B long integer multiplications on a separate thread; I wouldn't expect any performance improvement from this.

Threads

There is a master thread and a slave thread. The slave thread only exists for each batch of 5000 or so squarings and is then destroyed and recreated for the next batch (this has no measurable overhead). If the original VDF is used as a fallback, the batch ends and the slave thread is destroyed.

Each thread has a 64-bit counter that only it can write to. Also, during a squaring iteration, it will not overwrite any value that it has previously written and transmitted to the other thread. Each squaring is split up into phases. Each thread will update its counter at the start of the phase (the counter can only be increased, not decreased). It can then wait on the other thread's counter to reach a certain value as part of a spin loop. If the spin loop takes too long, an error condition is raised and the batch ends; this should prevent any deadlocks from happening.

No CPU fences or atomics are required since each value can only be written to by one thread and since x86 enforces acquire/release ordering on all memory operations. Compiler memory fences are still required to prevent the compiler from caching or reordering memory operations.

The GCD master thread will increment the counter when a new cofactor matrix has been outputted. The slave thread will spin on this counter and then apply the cofactor matrix to the U or V vector to get a new U or V vector.

It was attempted to use modular arithmetic to calculate k directly but this slowed down the program due to GMP's modulo or integer multiply operations not having enough performance. This also makes the integer multiplications bigger.

The speedup isn't very high since most of the time is spent in the GCD base case and these can't be parallelized.

Generating proofs

The nested wesolowski proofs (n-wesolowski) are used to check the correctness of a VDF result. (Simple) Wesolowski proofs are described in A Survey of Two Verifiable Delay Functions. In order to prove h = g^(2^T), a n-wesolowski proof uses n intermediate simple wesolowski proofs. Given h, g, T, t1, t2, ..., tn, h1, h2, ..., hn, a correct n-wesolowski proof will verify the following:

h1 = g^(2^t1)
h2 = h1^(2^t2)
h3 = h2^(2^t3)
...
hn = h(n-1)^(2^tn)

Additionally, we must have:

t1 + t2 + ... + tn = T
hn = h

The algorithm will generate at most 64-wesolowski proofs. Some intermediates wesolowski proofs are stored in parallel with the main VDF loop. The goal is to have a n-wesolowski proof almost ready as soon as the main VDF loop finishes computing h = g^(2^T), for a T that we're interested in. We'll call a segment a tuple (y, x, T) for which we're interested in a simple wesolowski proof that y = x^(2^T). We'll call a segment finished when we've finished computing its proof.

Segmenets stored

We'll store finished segments of length 2^x for x being multiples of 2 greater than or equal to 16. The current implementation limits the maximum segment size to 2^30, but this can be increased if needed. Let P = 16+2*l. After each 2^P steps calculated by the main VDF loop, we'll store a segment proving that we've correctly done the 2^P steps. Formally, let x be the form after k*2^P steps, y be the form after (k+1)*2^P steps, for each k >= 0, for each P = 16+2*l. Then, we'll store a segment (y, x, 2^P), together with a simple wesolowski proof.

Segment threads

In order to finish a segment of length T=2^P, the number of iterations to run for is T/k + l*2^(k+1) and the intermediate storage required is T/(k*l), for some parameters k and l, as described in the paper. The squarings used to finish a segment are about 2 times as slow as the ones used by the main VDF loop. Even so, finishing a segment is much faster than producing its y value by the main VDF loop. This allows, by the time the main VDF loop finishes 2^16 more steps, to perform work on finishing multiple segments.

The parameters used in finishing segments, for T=2^16, are k=10 and l=1. Above that, parameters are k=12 and l=2^(P-18). Note that, for P >= 18, the intermediate storage needed for a segment is constant (i.e. 2^18/12 forms stored in memory).

Prover class is responsible to finish a segment. It implements pause/resume functionality, so its work can be paused, and later resumed from the point it stopped. For each unfinished segment generated by the main VDF loop, a Prover instance is created, which will eventually finish the segment.

Segment threads are responsible for deciding which Prover instance is currently running. In the current implementation, there are 3 segment threads (however the number is configurable), so at most 3 Prover instances will run at once, at different threads (other Provers will be paused). The segment threads will always pick the segments with the shortest length to run. In case of a tie, the segments received the earliest will have priority. Every time a new segment arrives, or a segment gets finished, some pausing/resuming of Provers is done, if needed. Pausing is done to have at most 3 Provers running at any time, whilst resuming is done if less than 3 Provers are working, but some Provers are paused.

All the segments of lengths 2^16, 2^18 and 2^20 will be finished relatively soon after the main VDF worker produced them, while the segments of length 2^22 and upwards will lag behind the main VDF worker a little. Eventually, all the higher size segments will be finished, the work on them being done repeatedly via pausing (when a smaller size segment arrives) and resuming (when all smaller size segments are finished).

Currently, 4 more segment threads are added after the main VDF loop finishes 500 million iterations (after about 1 hour of running). This is done to be completely sure even the very big sized segments will be finished. This optimisation is only allowed on machines supporting at least 16 concurrent threads.

Generating n-wesolowski proof

Let T an iteration we are interested in. Firstly, the main VDF Loop will need to calculate at least T iterations. Then, in order to get fast a n-wesolowski proof, we'll concatenate finished segments. We want the proof to be as short as possible, so we'll always pick finished segments of the maximum length possible. If such segments aren't finished, we'll choose lower length segments. A segment of length 2^(16 + 2*p) can always be replaced with 4 segments of length 2^(16 + 2*p - 2). The proof will be created shortly after the main VDF loop produced the result, as the 2^16 length segments will always be up to date with the main VDF loop (and, at worst case, we can always concatenate 2^16 length segments, if bigger sizes are not finished yet). It's possible after the concatenation that we'll still need to prove up to 2^16 iterations (no segment is able to cover anything less than 2^16). This last work is done in parallel with the main VDF loop, as an optimisation.

The program limits the proof size to 64-wesolowski. If number of iterations is very large, it's possible the concatenation won't fit into this. In this case, the program will attempt again to prove every minute, until there are enough large segments to fit the 64-wesolowski limit. However, almost in all cases, the concatenation will fit the 64-wesolowski limit in the first try.

Since the maximum segment size is 2^30 and we can use at most 64 segments in a concatenation, the program will prove at most 2^36 iterations. This can be increased if needed.

Intermediates storage

In order to finish segments, some intermediate values need to be stored for each segment. For each different possible segment length, we use a sliding window of length 20 to store those. Hence, for each segment length, we'll store only the intermediates values needed for the last 20 segments produced by the main VDF loop. Since finishing segments is faster than producing them by the main VDF loop, we assume the segment threads won't be behind by more than 20 segments from the main VDF loop, for each segment length. Thanks to the sliding window technique, the memory used will always be constant.

Generally, the main VDF loop performs all the storing, after computing a form we're interested in. However, since storing is very frequent and expensive (GMP operations), this will slow down the main VDF loop.

For the machines having at least 16 concurrent threads, an optimization is provided: the main VDF loop does only repeated squaring, without storing any form. After each 2^15 steps are performed, a new thread starts redoing the work for 2^15 more steps, this time storing the intermediate values as well. All the intermediates threads and the main VDF loop will work in parallel. The only purpose of the main VDF loop becomes now to produce the starting values for the intermediate threads, as fast as possible. The squarings used in the intermediates threads will be 2 times slower than the ones used in the main VDF loop. It's expected the intermediates will only lag behind the main VDF loop by 2^15 iterations, at any point: after 2^16 iterations are done by the main VDF loop, the first thread doing the first 2^15 intermediate values is already finished. Also, at that point, half of the work of the second thread doing the last 2^15 intermediates values should be already done.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

chinillavdf-1.0.9.tar.gz (639.3 kB view details)

Uploaded Source

Built Distributions

chinillavdf-1.0.9-cp311-cp311-win_amd64.whl (1.9 MB view details)

Uploaded CPython 3.11 Windows x86-64

chinillavdf-1.0.9-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (474.7 kB view details)

Uploaded CPython 3.11 manylinux: glibc 2.17+ x86-64

chinillavdf-1.0.9-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (396.1 kB view details)

Uploaded CPython 3.11 manylinux: glibc 2.17+ ARM64

chinillavdf-1.0.9-cp311-cp311-macosx_11_0_arm64.whl (311.3 kB view details)

Uploaded CPython 3.11 macOS 11.0+ ARM64

chinillavdf-1.0.9-cp311-cp311-macosx_10_14_x86_64.whl (336.8 kB view details)

Uploaded CPython 3.11 macOS 10.14+ x86-64

chinillavdf-1.0.9-cp310-cp310-win_amd64.whl (1.9 MB view details)

Uploaded CPython 3.10 Windows x86-64

chinillavdf-1.0.9-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (396.1 kB view details)

Uploaded CPython 3.10 manylinux: glibc 2.17+ ARM64

chinillavdf-1.0.9-cp310-cp310-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (462.2 kB view details)

Uploaded CPython 3.10 manylinux: glibc 2.12+ x86-64

chinillavdf-1.0.9-cp310-cp310-macosx_11_0_arm64.whl (311.3 kB view details)

Uploaded CPython 3.10 macOS 11.0+ ARM64

chinillavdf-1.0.9-cp310-cp310-macosx_10_14_x86_64.whl (336.8 kB view details)

Uploaded CPython 3.10 macOS 10.14+ x86-64

chinillavdf-1.0.9-cp39-cp39-win_amd64.whl (1.9 MB view details)

Uploaded CPython 3.9 Windows x86-64

chinillavdf-1.0.9-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (396.5 kB view details)

Uploaded CPython 3.9 manylinux: glibc 2.17+ ARM64

chinillavdf-1.0.9-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (462.3 kB view details)

Uploaded CPython 3.9 manylinux: glibc 2.12+ x86-64

chinillavdf-1.0.9-cp39-cp39-macosx_11_0_arm64.whl (311.4 kB view details)

Uploaded CPython 3.9 macOS 11.0+ ARM64

chinillavdf-1.0.9-cp39-cp39-macosx_10_14_x86_64.whl (336.9 kB view details)

Uploaded CPython 3.9 macOS 10.14+ x86-64

chinillavdf-1.0.9-cp38-cp38-win_amd64.whl (1.9 MB view details)

Uploaded CPython 3.8 Windows x86-64

chinillavdf-1.0.9-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (396.1 kB view details)

Uploaded CPython 3.8 manylinux: glibc 2.17+ ARM64

chinillavdf-1.0.9-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (462.0 kB view details)

Uploaded CPython 3.8 manylinux: glibc 2.12+ x86-64

chinillavdf-1.0.9-cp38-cp38-macosx_10_14_x86_64.whl (336.9 kB view details)

Uploaded CPython 3.8 macOS 10.14+ x86-64

chinillavdf-1.0.9-cp37-cp37m-win_amd64.whl (1.9 MB view details)

Uploaded CPython 3.7m Windows x86-64

chinillavdf-1.0.9-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (398.8 kB view details)

Uploaded CPython 3.7m manylinux: glibc 2.17+ ARM64

chinillavdf-1.0.9-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (464.1 kB view details)

Uploaded CPython 3.7m manylinux: glibc 2.12+ x86-64

chinillavdf-1.0.9-cp37-cp37m-macosx_10_14_x86_64.whl (336.8 kB view details)

Uploaded CPython 3.7m macOS 10.14+ x86-64

File details

Details for the file chinillavdf-1.0.9.tar.gz.

File metadata

  • Download URL: chinillavdf-1.0.9.tar.gz
  • Upload date:
  • Size: 639.3 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.9.15

File hashes

Hashes for chinillavdf-1.0.9.tar.gz
Algorithm Hash digest
SHA256 5e226d827dce298c826bef718cec4a6af65164aaaf455752636807046a543f24
MD5 9a1bf7e45cd6ca1b02d727f5dc25dd10
BLAKE2b-256 aaa62fc76e7eb44e41e06b20b456b40b7e37a160a0afe391fd01f976f72c7a0c

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp311-cp311-win_amd64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp311-cp311-win_amd64.whl
Algorithm Hash digest
SHA256 7739b321d1065bf1c1cbf2d05a3cec802bc471845ced54187c09ac2fa17aadff
MD5 cc794d7be95575978b6bb33609a7041a
BLAKE2b-256 74e707759810c67428324b7a6366a6f88602f7323c139a636a75646ada9d5415

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 b18d0618bb4f144475fc978a45d16382fa4de26bb6a47d192a94a55fff0de03d
MD5 2d8a1902da19943d01fc94091960fdc9
BLAKE2b-256 8bfa945ee9ada8e84d5f789d029e804d14f09f678669b150c979509faf18602f

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 c4e5a1c3217d6524edb5183a38673975d35b542cd77cfd042145d68ec218a5f1
MD5 10c5a9f6bccd1830c8950eebc7e29929
BLAKE2b-256 e8609cd8999bca3c9d0afeb0109701558a85881f634a2d653a2081d9507d8aa4

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp311-cp311-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp311-cp311-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 7fcc844b3447fec904cd556dbf0581df01bb5f4b78cf21a14592406af910c098
MD5 5ca347946f5c797d75516b5a1fd3351b
BLAKE2b-256 f6b5cc5c209d476974914dc1ee1c01c08f5acde335caefcae3d65c771647286e

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp311-cp311-macosx_10_14_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp311-cp311-macosx_10_14_x86_64.whl
Algorithm Hash digest
SHA256 a44e8a3a9b0b92caccb704401a47e9de059e24599f86b1ad012f78712b6399a1
MD5 d993198195efb7a29c2c2598278097a9
BLAKE2b-256 9ddd1209d9d2e2699a5e1feb3d1f425df4b6af6c2ed248984df6dea1f7967927

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp310-cp310-win_amd64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp310-cp310-win_amd64.whl
Algorithm Hash digest
SHA256 7da4c8e946d351c0b4949a302e116228229a0ced1fe3b7cb21060cd3f4c93ebd
MD5 5167096dadd2a349771b13ed6e27ab64
BLAKE2b-256 683c45cffe7759eba87aebda8e7fcafa5c0a3ae3c22f4f83a49f373e9158f1ef

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 e9a9ed8bd3c0bca9b9e6f789c6a6bb486ed704f370d020d5c1eb3db7a51551fe
MD5 bace8b4135781250dc252ce2549c8cdd
BLAKE2b-256 887d99803e16edf99ca2f9983b3cd175dc3d4bc22cf4dd8830f188132eacde88

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp310-cp310-manylinux_2_12_x86_64.manylinux2010_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp310-cp310-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
Algorithm Hash digest
SHA256 1b0ca413fc2243b5ba01694bf2d8446cf7fc04c1c05342cda37383bd5d2dbff7
MD5 ae71e887b488e0385af54c3c080ef8bf
BLAKE2b-256 0cb75b33bc7618eaf59ee1daee75ff7d464c90c859392220463a192644536234

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp310-cp310-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp310-cp310-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 178f2496adf2a1dfabbe5b3d0f4e580911c351359f9ac8db5f20630a0c06942a
MD5 d83a4985c78883f7eedb5f2d311e2858
BLAKE2b-256 16b53e4ca06cd6eaf2e54c2ffd1507c783d5527ae5f338a8f788d5511126656f

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp310-cp310-macosx_10_14_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp310-cp310-macosx_10_14_x86_64.whl
Algorithm Hash digest
SHA256 cfe4bf661b6a0a9428a3ebbe0f48114bce879efad05c54f65969468a913b94e2
MD5 4c4c7e0e58b3df893d5592d82d4d942b
BLAKE2b-256 cc1c0636877d8fb380662aefb5301d72b6e46cf9e16fa8c7ba886b051e60a353

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp39-cp39-win_amd64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp39-cp39-win_amd64.whl
Algorithm Hash digest
SHA256 3aa3fcbdbeca9c6997298a44b95def27cb9d2d05f5335c73e5ac4648b4a6fc11
MD5 45a3610af9dd985ae0b7f95dd757e3a1
BLAKE2b-256 617bd1715089893fc1335ed6aff228c4d8f229bfb3a0ee9b09a2a29ba0cdb384

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 3c0920aa133d4d8578a2b02af13804158ca89032153c7134482ee329f1b11191
MD5 15a9293d1faa7c03db15feb23e116ba5
BLAKE2b-256 4f89c95e9846435f451e7479dc7c2ac4f81782e53b56386eb611098c600dd97c

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
Algorithm Hash digest
SHA256 b6d37168f4a19db758c110f9fd19d85d3d4c845e038045d785a7a098c2e1801e
MD5 d80dafcee032921de4400f10d5d68e58
BLAKE2b-256 ac7c40ec791bbb47f563b23b292bcd2e1c4edb1e84d53a806bc64cc30c75d0ad

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp39-cp39-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp39-cp39-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 ad4f612419c411214daa0ec8a3e0a9aac2ee1b4562827022121dd1f75735038a
MD5 0168650d099d94c04d08ffe7d566e51a
BLAKE2b-256 5fa2ff246e94f68d16279c4524d98f6fed621f54b0c7fc3dfc2060d28c538a1c

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp39-cp39-macosx_10_14_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp39-cp39-macosx_10_14_x86_64.whl
Algorithm Hash digest
SHA256 82d44cd11a1eaeff9a68c98f1f999f88e088b7a978860df935facdd96d2d54f3
MD5 bf38d2b401a20e0cf952df2c6c2a21fc
BLAKE2b-256 86e98d3f6002b2bd4c94c0f4d5e6c99ec7be7c185df80438d3be9c24ce68044d

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp38-cp38-win_amd64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp38-cp38-win_amd64.whl
Algorithm Hash digest
SHA256 2f89f2ab8df7a946556685ec611cc1d7c1623fd57de3f2fb28e42b7b2ec36899
MD5 e8d6a84c797504285ed3432cebcaac36
BLAKE2b-256 d0215bbfab309c63f1396a295809fa924b115606fc544809b3686f9c2023656f

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 454cc1d9c7613c52ae966f680712588802157e419991f2041ba6b9fd33506a16
MD5 e9fea7d64c6667161352d64fda3fa712
BLAKE2b-256 d31ca51a1ef23a36680a4f93bfe39ecfe43206fa03b21890dc1460152829ed1f

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
Algorithm Hash digest
SHA256 0f04c113428947236d6c4aa3f56944e82af3cc6d676b9e5b8bf07fad62094e02
MD5 423d0b2d7a2efb588078724814168ddb
BLAKE2b-256 a98f412e66e4871f779080d6c2d3ff5c51ea24717c0a2204385a15112595e4af

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp38-cp38-macosx_10_14_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp38-cp38-macosx_10_14_x86_64.whl
Algorithm Hash digest
SHA256 614419ad980ade989bd39fab10c8bba353b50e89e02e9600f82b48cfcfabba0b
MD5 8b7d791f8d7f3dad67e7df2beff5bb52
BLAKE2b-256 4d784eeaca0f4ad6c92a999ef60034cc63f07dc0ae2572cde0727ecba8a1913f

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp37-cp37m-win_amd64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp37-cp37m-win_amd64.whl
Algorithm Hash digest
SHA256 07f62c71cd8b15f4f24809a35c962156570c4c27810ecb37fb5a67eca7888a01
MD5 8d55f9ea4d879c64c0a8931b09b72c11
BLAKE2b-256 dc64396e1bd38a61fbecc2d2d0b627a02721717346b83edf14ebec3c70bcd67a

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 a8a0b8dc89a3f715e70f59e962007541c8ddb0e7f725b0cfb788d3605bf7c257
MD5 375677a8ca280861b88d96aeed02ee80
BLAKE2b-256 bde2d7aac4db25bb1f6bb8a836a77cdf98832601eec4ea166ebb7fee52170c35

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
Algorithm Hash digest
SHA256 c6ef1c20f56143d6515c9e706d9b2822f8e15421d57cf75dc8390ee3d7983466
MD5 9075243332223b4ad07b25fab43f1206
BLAKE2b-256 51d6e99bfc176cff1f81925a51dcc34d05b3f4f4b7cbe27f3f96251a4e75b36a

See more details on using hashes here.

File details

Details for the file chinillavdf-1.0.9-cp37-cp37m-macosx_10_14_x86_64.whl.

File metadata

File hashes

Hashes for chinillavdf-1.0.9-cp37-cp37m-macosx_10_14_x86_64.whl
Algorithm Hash digest
SHA256 19987b1d2982c18da8ab4ff04dea8d1e6bf6e65c1b158fead7e7bc2fee6b0da5
MD5 14c5f78bd9ae3c1c00e9c03a85f19872
BLAKE2b-256 2b605ec629e4989187bcf103be2793314184f207927bab59fa6f37e7fc7fb7e4

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page