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

Relevant related things:

CoinSwap: https://bt.irlbtc.com/view/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?

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

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

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.

@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

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
i think it is still wrong  

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