Topic: Anonymous Atomic Swaps Using Homomorphic Hashing - page 2. (Read 1120 times)

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.

 

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.

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

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.

Relevant related things:

CoinSwap: https://bitcointalksearch.org/topic/coinswap-transaction-graph-disjoint-trustless-trading-321228  (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?

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

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

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.