Add a new endpoint on the MIGP server for the client to retrieve the MIGP configuration parameters.

Print a warning if the client's MIGP library version does not match the server version.

Use byte slices instead of strings where applicable to reduce the amount of type casting. The BenchmarkRdasMutator100 benchmark test shows a ~30% reduction in ns/op and 43% reduction in B/op with these changes.

Add unit tests for utility functions in common_test.go.

Hi, I tried implementing the time-lock-puzzle in Go. But there is a problem which. I did not face the problem with the python implementation. When the T (# of squaring) is around 1024 the Go implementation works. But when I increase T to around 2048 it crashes.

The problem is in line # 110 as you can see in the attached code snippet. Line # 110 is the following.

// k = c_k - a^ (2^t) mod n equation (5) from paper https://people.csail.mit.edu/rivest/pubs/RSW96.pdf
K := new(big.Int).Sub(c_k, b) // this line should decrease the size of K to 32 bytes.

The line should decrease the size of K to 32 bytes. But when T >= 2048 it remains 256 bytes. Hence K can not be used as a key to unlock the puzzle as it only accepts keys of size 32, 24, or 12.

My guess is this is caused by integer overflow when calculating b = a^(2^T) mod n as big int is unsigned and when the most significant bit comes 1 this causes the problem. I have been using Go’s Exp library for the exponentiations. Here is the code snippet.

b := a
p := new(big.Int).Exp(big.NewInt(2), T, nil) // p = 2^T
b.Exp(b, p , N)

I have been trying to debug it but haven’t been successful. I have attached comments to the code following the convention from the paper but not sure how helpful it would Do you have ideas on how to fix it?