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) = sn%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.