Bitcoin Forum

Hi

I've written a paper entitled: "Anonymous Atomic Swaps Using Homomorphic Hashing". It is available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3235955 (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3235955).

Briefly, an atomic swap is the exchange of crypto between two parties using two transactions. Each transaction uses a hashed-time-lock-contract (HTLC) to lock the coins being sent to the other party. The hash used in both transactions are the same, linking the transactions. The paper describes how homomorphic hashing can be used to set up the HTLC's but each with a different hash, thus breaking the public link between the two transactions. The two hashes are related by a secret shared between the two parties, enabling the swap to proceed as per normal. As soon as the first party claims their coins using their pre-hash, the second party can use the shared secret and the pre-hash used by the first party to determine the pre-hash they have to use to claim their coins.

Any comments are welcome. I would like to hear thoughts on this.

Very impressive work.

Atomic swap is an important field and sooner or later it will disruptively change the scene of crypto exchange. Using this technology to reach anonymity is of urgent importance as well. Thank you for sharing. :)

I checked your paper carefully and other than one issue I found no weakness or any ambiguity in it, very elegant and straightforward.

But the issue I encountered:
Using  ℎ(s) = sⁿ mod p  as a hash function is suspected to correlativity, although you have calculated it for small spaces by simulation, for larger spaces it remains unsolved.

Generally the basic idea of having a homomorphic hash function, e.g. h(a+b) = h(a)+h(b)  is suspected to correlativity problem as far as I can understand.

Suppose we are trying to have a hash near to a value.
We primarily generate a large number of hashes for a series of random numbers.
Then we would be able to find a combination of calculated hashes that sum up to a desired proximity to our target and use the sum of their secrets.

I would suggest using a large enough set of primary hashes makes it possible to find an exact match.

Am I missing something?

Hi aliashraf

Firstly, thank you very much for your feedback. It is very insightfull.

You have mentioned a weakness that I have not considered and that I would like to address.

You are correct in that an attacker could try to guess the two secrets using the sum provided.

There are actually two attacks that I see possible. The first you have mentioned, but I also realised there is another possibility.

If the sum t is very low or very high, very few secrets will be candidates to generate that sum. For example, if we use n = 3 and 8 bit representation with p = 257 and the sum is 2, then the secrets must be 1 and 1. The same for very high sums. If the sum is 33162750 and the secrets are limited to max 255 then the secrets must both be 255.

This attack can easily be solved by limiting the sums we find acceptable to the range (2/3*p)³ < t < p³.

The second attack is the one you mentioned. To analyse this attack it is necessary to determine the effective search space that will result from using the equation s₁³ + s₂³ = t, for a given t.

Suppose the attacker launches a brute force attack on this equation, what will the effective search space be?

The attacker will have to start with s₁ = 1 and solve for f = floor((t - s₁³)^1/3) and c = ceil((t - s₁³)^1/3).

If f = c they would have solved the problem with s₂ = f = c for a given s₁.

The error in t is (s₁³ + c³) - t or (s₁³ + f³) - t.

The attacker can 'ride the curve' closer to t by starting from a point to search for (s₁³ + c³) - t = 0. But there is no guarantee that it will end in a solution. (s₁³ + c³) - t has many jump discontinuities. As soon as it gets close to 0 it jumps. According to estimates on a small space, there are approximately 40% * t^1/3 discontinuities. The attacker will therefore still have to search about 40% * t^1/3 of the space.

Using the limits for t previously set, I hypothesize the search space would therefore be between 25% * p and 40% * p.

Assuming a bit space of 256 bits is used in the hash, this would still be a large space.

I understand from your description of the attack, that you would look for values near the total. And that if you have enough randomly selected hashes, you would find an exact match by moving in on the exact match. But (s₁³ + c³) - t has many jump discontinuities. And any starting point could lead to a solution, but most starting points wouldn't.

So even a random attack would be faced with the same search space. And it has to be an exact match, or the secrets would be slightly out and not match the required hashes.

Again, thank you for your feedback and insights. They are greatly appreciated.

Please feel free to provide further comment. If I have not explained myself correctly, please ask for clarrification.

If I have made reasoning errors, please bring them to my attention

Regards

Johan

Hi

I think I can prove the difficulty of finding e = 0 for e = s₁³ + c³ - t [where c = ceil((t - s₁³)^1/3) ] scales with increasing size of space. (e is the error) (please refer to previous post)

First define b = ceil(a, d) where b is the number greater than a with d decimal places, e.g. b = ceil(a,0) wil give the integer larger than a and b=ceil(a,1) will give the number larger than a and divisible by 0.1

Then observe that b = ceil(10 * a, 0) = 10 * ceil(a, 1). That is, we can multiply a by 10 and then ceil to closest integer, or we can ceil to closest 0.1 and then multiply by 10.

Then scale space with m so that s₁^' = 10^m * s₁, t^' = 10^3*m * t,

e = (s₁^')³ + (ceil((t^' - (s₁^')³)^1/3,0))³ - t^'

e = (10^m * s₁)³ + (ceil((10^3*m*t - (10^m*s₁)³)^1/3,0))³ - 10^3*m*t

e = (10^m * s₁)³ + (ceil(10^m*(t - (s₁)³)^1/3,0))³ - 10^3*m*t

e = (10^m * s₁)³ + (10^m*ceil((t - (s₁)³)^1/3,m))³ - 10^3*m*t

e = 10^3*m * (s₁³ + (ceil((t - (s₁)³)^1/3,m))³ - t)

If we now increase m, the ceil can be approximated by removing it and this then reduces to

e = 10^3*m * (s₁³ + (t - (s₁)³) - t)

e = 10^3*m * 0

Therefore e reduces to 0 for all values of s₁ and t if m becomes large enough.

Effectively as m increases the search space changes from integer space to rational space.

Thus the search for a unique solution to (s₁³ + c³) - t becomes intractable.

As before comments and questions are welcome.

Relevant related things:

CoinSwap: https://bitcointalk.org/index.php?topic=321228.0  (now that the network has CSV and/or fixed malleability a somewhat simpler protocol can be used; see also https://github.com/AdamISZ/CoinSwapCS)

Swapping with adaptor signatures: https://github.com/apoelstra/scriptless-scripts/blob/master/md/atomic-swap.md


The simple power sums looks like deanonyizing them is a  solvable modular lattice problem but I haven't looked carefully,  I'd be interested in knowing how you think your approach compares to the coinswap and adaptor signature approaches?

OP,
I've just finished reading your latest posts, meanwhile I was (and still I am) independently investigating your proposed hash function being secure enough against a range of heuristic/brute force attacks like the one I've suggested previously.

I've to admit (somewhat intuitively for now) you are in the right direction and for s1 and s2 being mutually coprimes with p, where p is a large enough number and n a small odd integer like 3, a good security against reverse hash attacks seems to be provable.

I'll compare my results with yours and will keep you informed  ;)

----------------------------------------------------------------------------------------------------------------------------------------------------

@gmaxwell,
I afraid your CoinSwap proposal is not atomic swap because of its use of escrow (not trusted tho). Its advantage (which is so common for your works) is its compatibility with bitcoin machine language that is not the case with Op's proposal.

Obviously, implementing this proposal (given it would be approved both mathematically and computationally) needs extending bitcoin machine to support the homomorphic hash under consideration (MUL and ADD opcodes are both disabled and useless because of overflow problem).

Greg, if this hash function h(s,n,p) = sⁿ%p could provably resist against complicated  brute force/heuristic attacks that take advantage of its homomorphism, when s,n and p are selected properly, this proposal would be a game changer in crypto-anonymity domain.

I would like to take advantage of this case as an exemplary to prove myself right about the infinite possibilities for improving bitcoin and the unacceptable consequences of extreme conservatism.

@gmaxwell,

Thank you for making me aware of the CoinSwap and the Adaptor signatures. I was not aware of this work and will update my paper to reference and discuss how it compares to my work. I will also discuss this here as you asked how they compare.

As I understand from what I have read on the CoinSwap method it has the following features relevant to your question:
1) It runs on current cryptocurrencies without them needing modification and no novel cryptography is needed;
2) It uses scripts that are frequently used, so that it can blend in with the environment;
3) It uses between 4 and 6 transactions to execute, of which the first two are 2-of-2 multisignature transactions; and
4) All the coins that are being swapped are swapped together.

From my understanding of the Adaptor signature it has the following features relevant to your question
1) It would require a soft fork to implement Schnorr signatures;
2) It will use Schnorr signatures to release coins;
3) It uses 4 transactions to execute; and
4) All the coins that are being swapped are swapped together.

If there is something I do not understand correctly, please bring this to my attention.

The main features of my proposal that are relevant to your question are:
1) It would require a soft fork to implement the needed homomorphic hash opcode;
2) It will use the created homomorphic hash code to release coins;
3) It uses a minimum of 2 transactions to execute; and
4) The coins can be swapped in a variety of combinations.

Let me explain at the hand of the items above what the differences therefore are.

The CoinSwap does not require modification; the Adaptor signature does but it seems a BIP is in the process. My proposal will require due investigation to make sure it is secure and would then require a BIP.

The CoinSwap blends in much more with the environment than the other two which require special opcodes. But this might not be as safe as it sounds. It is true that the CoinSwap multisig transactions would not be found among all the other multisigs, but what would happen in practice is that someone would investigate a person by following the history of their coins. If they encounter a multisig transaction they would as a matter of course search for another multisig transaction for the same amount around the same block height. If they found such a multisig they would fork their investigation to follow both coin histories.

In my opinion any anonymous swap of coins will leave some sort of fingerprint. That cannot be eliminated. What needs to happen is for that the anonymous swap must be the standard method of swapping crypto assets and it must be possible for the swap to be broken up into smaller transactions with different amounts. That way if an investigation is following coins and it finds a swap has occurred, it must search for an unknown number of transactions in a sea of similar transactions.

That brings me to the last point. To my understanding the CoinSwap and Adaptor signature methods swap coin for coin in a fixed set of  transactions. In other words A gives 1 BTC to B in TX1 and B gives 1 BTC to A in TX2. In my proposal I make the point that implies the following is possible:
1) A creates 3 transactions with amounts 0.2 BTC, 0.3 BTC and 0.5 BTC to send to B; and
2) B creates 2 transactions with amounts 0.4 BTC and 0.6 BTC to send to A.

The amounts all add to 1 BTC, each transaction will have a different hash, all hashes are related by a set of shared secrets, and if A claims a single transaction in (2) B will be able to claim all transactions in (1). These transactions can also happen in different blocks. This is a very important point that is not made in any of the literature that I read on the CoinSwap and Adaptor signature methods. I suspect it is possible for the Adaptor signature methods but not for CoinSwap.

But to hide the swap with the homomorphic opcode that flags it as a swap, these swaps would need to be the standard method of crypto asset swapping. I believe this is true no matter which of these three methods are used, even for the CoinSwap method for reasons mentioned above.

On a side note, a homomorphic hash might also have applications other than atomic swaps. For example:
1) Alice generates a secret s1 and Bob generates a secret s2;
2) they both hash their secrets to generate h1 and h2;
3) they sum the hashes to generate ht
4) They can now use this ht in a transaction
5) If either s1 or s2 is revealed the other party can determine st which is the pre-image of ht.
At this time this transaction is a bit of a hammer looking for a nail. I mention it because someone might be able to use it and it helps you to understand the possible value of the proposed homomorphic hash.

I hope this answers your question to your satisfaction. If you have any further questions on this, please let me know.

---------------------------------------------------------------------------------------------------------------------------------------

@aliashraf

I look forward to hearing from you regarding any results your investigation produces.

You can do adaptor-signature based atomic swaps in Bitcoin without Schnorr; see https://eprint.iacr.org/2018/472 which has a full security proof (and security model, which is a nontrivial thing to define for transitive atomic swaps). Adaptor signatures can be used to make arbitrary sets of transactions atomic; and to even add transactions to these sets after the protocol has started. They are definitely not restricted to pairwise exchange, though in practice I expect you'll find it's hard to coordinate much else.

It is not possible to do a cross-chain atomic swap with only two transactions because you need at least one transaction on each chain, and the first transaction on each chain can be invalidated by publishing a conflicting transaction alongside it.

Interestingly, the idea of your referenced source, multi-hop locks, shares the concept of employing homomorphic hash functions with this proposal.

I doubt it. Using this proposal:

Alice issues tx1 on aliceChain sending m aliceCoins to Bob hash-locked with H(s1) after privately handing Bob (t, H(s1), H(s2))  

Bob does the same by issuing tx2 on bobCahin hash-locked with H(s2), AFTER tx1 is confirmed on aliceChain.

Now Alice should wait for tx2 to get confirmed before spending its outpoint and Bob should wait for Alice spending tx2 (and revealing s2) to be able to calculate s1 = t-s2 and spend tx1's outpoint.

 

Hi johank!

I really like the idea.
So you're talking about the homomorphic hashing functions. But why not just use the elliptic-curve arithmetics? Indeed this is what it is - one-way homomorphic transformation.

Am I misunderstanding something?
Thanks in advance.

Hi vlad.gelfer

You are correct, you can use EC. Specifically the proposal by Andrew Poelstra is a manner to use Schnorr signatures on EC curves to achieve this. From what I have learnt they approaches achieves something very similar. The main differences are that this proposal would use 2 transactions and Andrew's would use 4 and that there is already a BIP in the works to make Schnorr signatures part of Bitcoin.

What I am interested in seeing is what else the Scriptless Script's of Andrew can achieve. As for this proposal, the following example is another type of transaction that it could be applied to (as discussed in previous post):

Hope this answers your question

I count four transactions in what you described.

Actually, the spend transactions are not part of the protocol itself because both parties would be able to do it as regular transactions for other purposes but if you feel more comfortable counting this way, I've no objections.

Hi,
I have read the paper several times and after so much thinking about it i still can't understand your proof of 'no collisions', and i can't see a reason for proofing it, i think if we don't have a high chance of collisions that would be enough.
About the proof its self; as i see it, you can't use rule of signs when you are using modular math.
s₁ⁿ-s₂ⁿ=0 (mod p) means s₁ⁿ-s₂ⁿ=kp where k is a member of Integers numbers, so for a fixed s₁ not only s₂ but k would be a variable.
also the board of the function is limited from 0 to P-1 and as a result, the talk of no collisions is meaningless out of a limited range for s, and you have mentioned s<p in the paper but i see no use for it in the part 4 of 'no collisions'.
maybe i'm just wrong, please tell me if i am.

@empty[g]

I understand the point you are trying to make. I had not considered that issue. That is why I prefer sharing work on these forums
as you get people  looking at your work which you do not come across in daily life. Your input is much appreciated.

I will consider the point you made and will see if I can find a solution. If you do find a solution I would appreciate if you share it.

Regards

Johan

Hi

Hopefully this expanded proof of no collisions works. Please let me know if I have made any mistakes.

I use the following theorem

Theorem 9.5 Let p be a prime. The non-congruent numbers a₁; a₂; : : : ; a_k are
roots of the polynomial congruence f(x) = 0 (mod p) if and only if there exist
two integral polynomials q(x) and r(x) such that
f(x) = (x - a₁).(x - a₂) . . . (x - a_k).q(x) + p.r(x)
and deg r(x) < k.

The proof is available at www2.math.uu.se/~astrombe/talteori2016/lindahl2002.pdf (http://www2.math.uu.se/~astrombe/talteori2016/lindahl2002.pdf)

h₁ = s₁ⁿ mod p
h₂ = s₂ⁿ mod p

For collisions h₁ = h₂ and s₁ != s₂

Therefore determine roots of

(s₁ⁿ - s₂ⁿ) = 0 (mod p)

This is equivalent to

s₁ⁿ - s₂ⁿ = t.p

So for completeness sake we can find the roots of

(s₁ⁿ - s₂ⁿ - t.p) = 0 (mod p)

Applying the above theorem, we can set r(s₁) = t

Then we have to find the roots of s₁ⁿ - s₂ⁿ

There are three possibilities:

1) n is odd
2) n is even and has no odd factors
3) n is even and has odd factors

-------------------------

(1)

if n is odd

= (s₁ - s₂).(s₁^(n-1) + s₁^(n-2).s₂ + ... + s₁.s₂^(n-2) + s₂^(n-1))

= (s₁ - s₂).q(s₁)

=> 1 root s₁ = s₂

=> no collisions

-------------------------

(2)

n is even

= (s₁^(n/2) - s₂^(n/2)).(s₁^(n/2) + s₂^(n/2))

n/2 is even

= (s₁^(n/4) - s₂^(n/4)).(s₁^(n/4) + s₂^(n/4)).(s₁^(n/2) + s₂^(n/2))

n/m is 2

= (s₁² - s₂²).q(s1)

= (s₁ - s₂).(s₁ + s₂).q(s₁)

=> 2 roots s₁ = s₂ and s₁ = -s₂

=> has collisions

-------------------------

(3)

n is even

= (s₁^(n/2) - s₂^(n/2)).(s₁^(n/2) + s₂^(n/2))

n/2 is even

= (s₁^(n/4) - s₂^(n/4)).(s₁^(n/4) + s₂^(n/4)).(s₁^(n/2) + s₂^(n/2))

n/m is odd

= (s₁^(n/m) - s₂^(n/m)).(s₁^(n/m) + s₂^(n/m)).q'(s1)

= (s₁ - s₂).(s₁^(n/m-1) + ... + s₂^(n/m-1)).(s₁ + s₂).(s₁^(n/m-1) - s₁^(n/m-2).s₂ + ... - s₁.s₂^(n/m-2) + s₂^(n/m-1)).q'(s₁)

=> at least 2 roots s₁ = s₂ and s₁ = -s₂

=> has collisions

-------------------------

Therefore to assure no collisions, n has to be odd and p must be a prime.

As soon as I have a chance I will update the paper with these details.

as soon as i got the time i have something to share with you, but for now let me say i think there should be more conditions on P.
i would try to update this post and tell you more in next 24 hours.

Hi

Just thought I might share this. It is a simple attack, that the following proof shows will not work

h = sⁿ mod p

Assume an attacker want to find a power m such that

h^m mod p = s

=> s = s^(n.m) mod p

=> s^(n.m) - s = 0 (mod p)

The attacker would have to solve the above congruence.

Using the theorem from my previous post, this implies that the congruence can be factorized to yield

s.(s^(n.m-1) - 1)

This yields roots s = 0, s = 1 and possibly s = -1 for all values of n and m

Therefore for s > 1 there are no values of m that can be used to determine the pre-image s from the hash h.

hi
i think it is still wrong  ;D

i can't find out what did you do wrong exactly in math, so i just say why i think the result is wrong.
about the math: i think you did a mistake that you get here : "Then we have to find the roots of s₁ⁿ - s₂ⁿ"

i repeat what i said before once : "the board of the function is limited from 0 to P-1 and as a result, the talk of no collisions is meaningless out of a limited range for s, and you have mentioned s<p in the paper but i see no use for it in the part 4 of 'no collisions' "

in general when a function is modulating it would have collisions unless we set a range on the input (here 's')
any argue with no declaration on range of s for no collisions should be false.

also i have written a simple c program that with brute force checks if there is collisions(i can share it if you ask me nice ;)   )

for every prime number less than 10,000 as P
for every number less than the P is being tested as S

for n=3 the largest number as p with no collisions was "1289"
for n=5 the largest number as p with no collisions was "73"

it shows that there are prime numbers that will give you collisions and there are ones that would not.
-------------------------------------------------------
also sorry for not being on time as i promised in previous post

Hi

I agree with your assessment. I verified that there are collisions for n=3 and p = 1291. My mistake lies in assuming

(s₁^(n-1) + s₁^(n-2).s₂ + ... + s₁.s₂^(n-2) + s₂^(n-1))

in

has no roots mod p.

This is incorrect.

For example

s₁² + s₁.s₂ + s₂² mod 1291

has roots.

Therefore you are correct that p would have to have a specific value to allow/disallow collisions.

The problem is my previous proof regarding an attack on the system

h^m mod p = s

where

h = sⁿ mod p

is also incorrect.

Specifically an attack could succeed if there are no collisions for a specific value of m

Basically by raising the hash to the correct power, the secret can be discovered.

From limited numerical simulation it seems that if there are no collisions, then a specific value om m exist for all s

If collisions are possible, then this attack is not possible. The downside is then that it might make a brute force
attack easier

I am therefore going to remove the paper from SSRN, as this is a major problem.

i think your answer to this attack is right, maybe not complete but right.
it is not possible to determine a 'm' that works regardless of 's' with only having h(s)
i don't see how collisions effect this.

-----------

also don't be disappointed with collisions problem, i have found 46337 as a prime number without collisions for n=3 with brute force
i suggest that if you can find a way to determine if a prime number has collisions or not WITHOUT brute force the problem is solved.(as we need a large number that denies the possibility of brute force and it is not wise to determine itself with brute force  ;D )

Hi

For those following this thread, here is a proof that this hash can be broken

Using Eulers totient function it is known that

s^phi(p) = 1 (mod p)

Raising to a power t using modular arithmetic yields

s^phi(p).t = 1 (mod p)

Multiplying by s

s^{(phi(p).t + 1)} = s (mod p)

Therefore if a secret s was raised to a power n to hash, then the hash can be undone by raising to such a power m so that

phi(p).t + 1 = n.m

(phi(p).t + 1)/n = m

Examples:

p = 11
n = 3

phi(p) = 10
t = 2

phi(p).t + 1 = 21

m = 7

s²¹ mod 11 = s mod 11 (you can easily verify this numerically)

for example

s = 9

s³ mod 11 = 3 = h

h⁷ mod 11 = 9 = s

This proof is holds for s < p. If s > p then it does not hold, but then collisions become unavoidable as k.p + 1 and (k+1).p + 1 will result in the same hash.

At this point one probably will have to change the hash function to h = g^s mod p ( where g is some fixed generator number)

(The problem with this hash function is that it can be computationally intensive)

This would change this attack to a brute force attack that has to solve

h^m = 1 (mod p)

which would mean

g^s.m = 1 (mod p)

And then they would have to use brute force to solve

s = phi(p).t/m

with no remainder

ie phi(p).t mod m = 0

I am not sure how hard this would be

@johank
I think we are not done with your proposal yet, despite your suggested inverse attack which is based on finding at least one pair of (t,m) such that (p-1)*t+1=n.m or m = ((p-1)*t + 1)/n and using m to find s=h(s)^m mod p.

You can note that the equation has no integer roots if p-1 mod n = 0  or (p-1)/n = k
((p-1)*t+1)/n = m    ==>   (p-1)*t/n + 1/n = m    ==>   m= kt+1/n
so if we choose p and n such that n divides p-1 the hash function h(s) = sⁿ mod p is irreversible.

Now here is another interesting  problem:
For a prime number p and an odd number n, when such a number m can not be found to commit an inverse attack on h it seems that we have a hash function with collision! For example with n= 3 and p = 13 there is no m and inverse function but we have collision!

I suggest that analysing the collision rate may still imply good enough security for large prime numbers.

@aliashraf

I agree with what you said. Yes, if (p-1) mod n = 0, it will not be reversible, and I agree that it seems if it is not reversible there are collisions.
We therefore want something with collisions, but as little as possible. This also means that n can be even.

It terms of the collision rate, I think I can help with that.

For h₁ = h₂

s₁ⁿ - s₂ⁿ mod p = 0

If p is prime then it has at most n roots

=> for a hash h, there are at most n secrets that create that hash.

=> brute force search space is reduced to 1/n of its original size

for n = 2

all primes will yield (p-1) mod 2 = 0, it will be reversible and I suspect have collisions (at most 2 per hash)

and the search space will only halve.

@johank

If you are right about the number of collisions having an upper bound of n, choosing n slightly bigger is more appropriate to have more discontinuities and jumps hence more resistance to heuristic attacks  like what I suggested primarily up-thread.

For example putting n = 6 with a search space of 2²⁵⁵/3 height, is practically the same as ²⁵⁵ for n=2, both being computationally hard and won't be broken in real time.

I think it is time for you (or @empty[g]) to put everything together once again and give a solid mathematical presentation and proof of the homomorphic hash function:   h(s)=sⁿ mod p

I'm not convinced about the collision rate to be n by the way.

@aliashraf

I have updated the paper that I wrote with all the details we have discussed. It summarizes it all together. I will be uploading it soon. As you and empty[g] have provided valuable insights I wish to add you as authors. If you wish to allow this please email me your names and the email I should include and I will update the paper to reflect this.

Regarding the impact of collisions on the homomorphic hashing I included the following in the paper to discuss this:


A large search space is required, but also when choosing n and p to have collisions there should be no obvious double roots to a collision, e.g n = 2, p = 13, s₁ = 4, h₁ = 3, s₂ = 9, h₂ = 3 where -4 mod 13 = 9 => -s₁ mod p = s₂ when n = 2

If you want to find out more about the upper bound of the collisions, please look at Lagrange's Theorem on congruence of polynomials under modulo a prime. I also discuss this in the paper.

@johank
From my side, all the credits go to you though @empty[g]'s contribution was very helpful  , thanks anyway.  :)

And you are right Lagrange's theorem definitively proves the rate of collisions being bounded by n and choosing a properly small n (I suggest 6) with a large prime p will make it computationally infeasible to find a collision.

I have to emphasis on using n>>2 to mitigate heuristic attacks. Once you have finished  the final version, please keep me informed, we should take care of implementation issues next.

nice,
we are almost there...

if xⁿ=P (x is not integer)
i suggest to put x < S < P-x to be sure about the unpredictability of the hash function

also i have read and investigated the subjects have been said in last posts from @johank and @aliashraf , i'm very excited about them and agree with the solution that have been proposed.

johank , you may want choose a 512 bits prime number as p instead of 256 bits for making sure that the reduction of search space needed for brute force attack due the collisions is not that important, but i think even a 256 bits would do for this date we are in.

i also like to hear from you about the operation stage and if you are gonna code the program and etc. i would love to help the coding as much as i can.

about your honorable offer, unlike aliashraf i am new and searching for a name and i would be glad to be mentioned on the paper but i think the credit mainly is for you.
you can contact me at hamun.davarpanah@gmail.com

@aliashraf

The paper is ready with the updates. I have uploaded it to SSRN, but the review can take anything from 1 to 14 days. If you require a copy sooner, please contact myself on the email on the original paper or empty[g] on the email provided above. I have sent him a copy of the paper that I have uploaded.