Hi

I have posted a paper on SSRN with the title:"Stochastic Model For The Price Of Bitcoin". It is available at this link: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3243011

The abstract of the paper:


Comments and suggestions are welcome.

@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.

@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.

@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.

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

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.

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

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

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.

@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 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

@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.

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.

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'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.

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.