Bitcoin Forum
May 02, 2024, 08:22:03 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Jamming issue in Atomic Cross Chain Transfers..  (Read 626 times)
spartacusrex (OP)
Hero Member
*****
Offline Offline

Activity: 718
Merit: 545



View Profile
January 31, 2017, 12:49:19 PM
Last edit: January 31, 2017, 02:15:20 PM by spartacusrex
Merited by ABCbits (1)
 #1

(please excuse the length of this post..)

Currently there is an issue with ACCT.

You can't lose your coins, but it is very easy for a user to pull out of a trade, before it is complete, and just have both users keep their original coins. The 'Jamming'..

Many of us have come to the conclusion that some kind of central server, that still cannot steal your coins, could be used to help in the transaction.

..

Alex has 1 BTC, and wants to trade with BOB who has 100 LTC. (or whatever)

The Current Method :

2) Alex create a TXN that pays out 1 BTC to BOB, if he can provide the pre-image of a hash, that currently only Alex knows. There is also a refund element that allows Alex to reclaim the coins at some point in the future, lets say 24hrs later.

3) Alex posts this TXN, and BOB now has to wait for it to be 'fully' confirmed. He cannot publish his txn until this has happened.

4) Once the previous txn has cleared, Bob knows that if he knows the pre-image of a certain hash, he -AND ONLY HE- can claim the BTC. (until 24 hrs is up)

5) Bob creates a txn that pays out 100 LTC to Alex, if he can provide the pre-image of the same hash as his txn. This way when Alex claims his LTC, Bob can claim his BTC. (with refund bits etc..)

6) Bob posts his txn, and Alex now has to wait until it is fully confirmed, before he claims his prize, the LTC. Thus revealing the pre-image, and allowing Bob to claim his BTC.

There is no guarantee that Bob will publish his txn, as the price may have gone down, and if that happens both parties just get their coins back.

There is no guarantee that Alex will infact claim the LTC, by revealing the pre-image, as the price may have shot up!, and if that happens both parties just get their coins back.

..

To force Alex to reveal his pre-image I propose another txn be published.

Alex creates a txn that pays Alex say 5% of the original trade value, if he reveals the pre-image. And if he does not, after X amount of time, Bob can claim these coins. Lets call this the 'Hash-Force' (HF) txn.

SO in this case Alex would create a txn that pays 0.05 BTC to Alex(himself) if he reveals the pre-image, and using CLTV, after a few hours Bob can also claim those funds, if they have not been claimed already.

This would force Alex to either publish the pre-image, by claiming the coins, or not publishing and letting Bob take the 5% fee. An adequate recompense for not going through with the whole trade.

..

Now the tricky bit.

Alex of course CANNOT publish the HF txn until he is sure that Bob's txn has cleared, as otherwise he would have his original txn and his HF txn out in the wild and Bob would be able to either claim the original 1 BTC, or the 5% HF txn, without paying any LTC. Also there is little point to having the HF txn if he does wait as he may aswell just claim the original LTC coins, thus revealing the preimge that way, or not publishing anything anyway.

..

Let's bring in a central server. SERV.

New Method :

1) SERV, Alex and Bob, all generate a random string, S, A, B, and then hash it. These are H(S), H(A), and H(B). The pre-images are kept secret.

2) SERV asks BOTH Alex and Bob to send it a very specific txn.

Alex sends a BTC txn:

<txn>
    <1 BTC output>
           <PAYOUT If signed by Bob and A in H(A) and B in H(B)>
                            OR
           <PAYOUT If CLTV is 24hrs in the future and signed by Alex>
    </output>
    <0.05 BTC output>
            <PAYOUT if signed by Alex and A in H(A)>
                     OR
            <PAYOUT If CLTV 2 hours in the future and signed by Bob and S in H(S)>
    </output>
</txn>

Bob sends an LTC txn:

<txn>
    <100 LTC output>
           <PAYOUT If signed by Alex and A in H(A) and B in H(B)>
                            OR
           <PAYOUT If CLTV is 24hrs in the future and signed by Bob>
    </output>
    <5 LTC output>
            <PAYOUT if signed by Bob and B in H(B)>
                     OR
            <PAYOUT If CLTV 2 hours in the future and signed by Alex and S in H(S)>
    </output>
</txn>

Notice that the HF txn cannot be claimed by the other party, unless they know S in H(S). Which only the server knows.

3) Once the server has received BOTH txns, it publishes them. Both.

4) Once BOTH txns have cleared and are confirmed, the server shares the preimage of H(S), S, with both parties. Now both users HAVE to claim their HF txn, or lose the coins, and thus enable the whole trade to go through.

If BOTH txns do not clear the server does not reveal the S in H(S). Deletes it. This way noone can claim the HF, except the original author, and both parties just get their coins back.

If both txns clear, then the first one to claim their HF txn, reveals the preimage they know and allows the other party to claim their prize, aswell as their HF txn, and thus allow them both to claim their coins.

The 'Jamming' issue has now been relegated to one point, only at the very beginning, where one party could try and double spend their coins before they clear. In this case, and not knowing S in H(S), both parties would just get their coins back.

If either party does not provide their txn at the beginning, then neither txn is published, and no coins are jammed. It would be almost instant for the users to provide these TXNs, so if someone fails to do it, the server can just kick them out and move to the next user.

..

The Issue :

Everything works, EXCEPT if the server gets hacked. Then it is possible for one party to claim the HF txn, as they will know the S in H(S), and make sure that their txn is not published.

It is still not possible to steal the actual trade funds.

..

I am not sure if this can ever be made 100% atomic/safe.. can anyone think of anything (S in H(S) done differently)?

Making the HF txn 1% may make it less annoying (the server would have to be hacked after all, so I don't see this as a common occurrence..), but it's still not right..

Anyone ?

 Undecided

Life is Code.
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714638123
Hero Member
*
Offline Offline

Posts: 1714638123

View Profile Personal Message (Offline)

Ignore
1714638123
Reply with quote  #2

1714638123
Report to moderator
watashi-kokoto
Sr. Member
****
Offline Offline

Activity: 682
Merit: 268



View Profile
February 05, 2017, 02:54:28 PM
 #2

You can have two servers. Each server knows different random number S1, S2.

  S = S1 + S2

server 1 calculates and publishes H(S) using Yao's garbled circuit protocol.  (without knowing S2)

So the transaction can be jammed only if both servers are hacked (otherwise attacker doesn't know S)

In the end both servers publish S1, S2 , clients do the addition S1+ S2 and calculate H(S) normally.
spartacusrex (OP)
Hero Member
*****
Offline Offline

Activity: 718
Merit: 545



View Profile
February 06, 2017, 09:39:56 AM
 #3

hmmm.. nice Watashi! (watashi-wa-spartacus-des-ka..) 

Would that not be the same as having a slightly more complicated HF txn that just requires BOTH preimages ?

So the payout bit of the HF txn (for Alex) would now be..

..
<PAYOUT If CLTV 2 hours in the future and signed by Bob and S1 in H(S1) AND S2 in H(S2)>
..


Both servers would release their preimages once the initial txns had cleared. I could keep adding servers.. maybe require 3 or 4 servers. Although only 1 of the servers would need to be hacked to 'jam'. So..

It's safer.. but still not nuclear atomic.. !

Life is Code.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!