assembly
assembly
Proposal for consensus-enforced atomic swaps between NXT, ARDOR and all clones
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Ardor Client: Ardor 2.2.5

Author Topic: Proposal for consensus-enforced atomic swaps between NXT, ARDOR and all clones  (Read 87 times)

tre

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 3
    • View Profile

Proposal for consensus-enforced atomic swaps between NXT, ARDOR and all clones. Implemented with two new transaction types and logic to verify signed sendMoney transactions from the other platforms and introduced simultaneously on all participating clones.

The motivation is to allow trust-less, consensus-enforced, simultaneous (locked step) trading of the tokens between accounts on the different platforms. The tokens do not, of course, actually leave the platforms but they are exchanged between the trader's accounts in such a way that the transfer of tokens on the one platform is also the key to enabling the opposing trade transfer transaction to occur on the other.

The implementation is in three parts and requires two new phased transactions that must have an equivalent implementation on each platform.

1. Reserve-Balance. A new phased transaction type. This transaction guarantees that the balance is available to complete the trade.

This transaction is similar to the sendMoney transaction except that nothing is transferred and that the amountNQT is only locked until a specified block height. This balanced is unreserved in one of two cases: If a sendMoney transaction with otherwise identical fields (amountNQT recipient senderPublicKey) is attempted then this reserved value is used to complete the attempted sendMoney transaction. OR by a transaction (2) that is unlocked.

2. Template-Lock. A new phased transaction type. This transaction is unlocked by a signed sendMoney transaction from the opposing platform which is being traded with.

This transaction is also similar to a sendMoney transaction but contains an attachment with a valid unsigned sendMoney transaction that is valid on the opposing platform which is being traded with. The amountNQT field corresponds with the native token to be exchanged and the attachment's amountNQT field corresponds with opposing platform's token that is being traded for the native token.

This transaction is unlocked by (3). The idea will be illustrated with an example below.

3. Each platform must understand how to verify ordinary signed sendMoney transactionBytes of each other. So NXT should understand ARDOR's and vice versa. (2) is unlocked when the sending account of (2) receives a message with a binary attachment that corresponds with the signed attachment in (2) and that is valid on the opposing platform i.e. that is a signed sendMoney transactionBytes. The reserved balance of (1) is used to complete the transaction of (2).

The choice to use a message trigger to unlock (2) has the disadvantage of requiring that the verifying nodes compute messages while the phasing in (2) is active. Perhaps a purpose-specific new transaction would be more efficient. Or perhaps a new message attachment indicator (to compliment messageIsText) type that indicates that it is a trigger for type transaction (2).

Example of a trade between NXT and IGNIS.

Alice wants to trade 150 NXT for 100 IGNIS. Bob accepts the trade. Alice and Bob exchange the publickeys that they control on each other's platform i.e. Bob creates a NXT account and gives their publickey to Alice and Alice does the same for their IGNIS account.

Alice creates a phased transaction (1) that contains amountNQT 150 NXT and Bob's recipient account-ID and commits the transaction on the NXT blockchain.

Bob makes a similar phased transaction (1) that contains amountNQT 100 IGNIS and Alice's recipient account-ID and commits the transaction on the ARDOR blockchain.

Alice has locked 150 NXT from their account for a certain number of blocks and Bob has locked 100 IGNIS for a comparable number of blocks.

Alice confirms that Bob's transaction (1) has been committed on the blockchain and maybe waits for a number of confirmations. Bob does the same and confirms that Alice's transaction (1) has been committed. They are both reassured that they each will have the required tokens to complete the trade.

To continue the trade either Alice or Bob can create a transaction (2) with the agreed parameters for the trade amountNQT. It is not necessary that both create the opposing transaction. Only one is necessary to guarantee the trade. Let us say that Alice creates a transaction (2) with a template for an ARDOR platform IGNIS sendMoney transaction for amountNQT 100 IGNIS and Alice's recipient and Bob's senderPublicKey (and appropriate feeNQT ecBlockId ecBlockHeight ...).

To continue the trade Bob can unlock Alice's phased NXT transaction (2) by sending the correct signed transactionBytes as a NXT message using Alice's senderPublicKey from transaction (2) This same transactionBytes sent to Alice from Bob can be committed by Alice to the ARDOR blockchain to also unlock Bob's transaction (1)'s reserved balance and complete the trade.

The trade has a consensus guarantee once either Alice or Bob create a valid transaction (2). It is up to both parties to take into consideration the phased block height and deadline limits committed by transactions (1) and (2).

If neither Alice nor Bob continues the trade by supplying (2) then the locked values (1) will be returned to their respective accounts at the specified block height limit.

The exchange can be automated with an application that is connected to each platform and matches offers off-chain and creates the phased transactions (1) and (2) for each trader and waits for and sends the unlock (3) for the opposing platform.
Logged

Right.Here

  • Sr. Member
  • ****
  • Karma: +22/-4
  • Offline Offline
  • Posts: 269
    • View Profile

Hi  :D

nice idea , there is already something like this in BTCPay...
https://docs.btcpayserver.org/

thank you and good continuation  ;)
Logged
NXT-LJV5-YSF4-MXXX-438D5

petko

  • Full Member
  • ***
  • Karma: +24/-0
  • Offline Offline
  • Posts: 100
    • View Profile
    • My blog

Quote
Each platform must understand how to verify ordinary signed sendMoney transactionBytes of each other. So NXT should understand ARDOR's and vice versa

This is not applicable. We don't want the Ardor nodes to be forced to process the NXT chain and vice versa.

But why do you avoid the standard atomic swap protocol, based on hashed secret? It doesn't require the trading blockchains to understand each-other. And we already have the tools for that - phasing by hashed secret. Actually the Migrator project already worked on atomic swaps between Ardor child chains, NXT, BTC, ETH, etc.
Logged

tre

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 3
    • View Profile

Quote
This is not applicable. We don't want the Ardor nodes to be forced to process the NXT chain and vice versa.

petko, I believe that your comment is based on a misunderstanding of the proposed protocol, I must not have explained this point adequately - ARDOR would not need to be connected to NXT nor vice-versa. The idea would not have much merit if it was so unwieldy.

It is only necessary that each platform understand how to interpret (and verify the signature of) one extra-platform transaction type - when submitted as an attachment of a native transaction (as described) to unlock a phased transaction. This is the key to guaranteeing that unlocking the funds on one platform can also can unlock the funds on the other (and that the keys are simultaneously accessible to both participants).

I am very interested to learn how Migretor implemented their atomic swap protocol. Would you kindly provide a link to this information, or if you have the patience to explain, even if briefly, the protocol?

Perhaps it is as simple as a phased transaction on each platform locked by two hashed secrets - only one is known to each. Both transaction's phased block height limits (approximated to time) are staggered so that one expires much sooner than the other and the protocol requires that the trader who has the later limit be the first to broadcast their secret. This will allow a safe margin of time for the trader with the first limit to decide if there is enough time to broadcast both secrets on the opposing platform. Something like this?

Is it possible, without a code change, to phase a single transaction against two (both required) hashed secrets?

A couple of small advantages versus using hashed secrets (although at the cost of a change of the code). The proposed protocol only requires that one trader post their key and then both transactions are guaranteed (before the deadline) and also that either trader can decide to unlock both transactions.
« Last Edit: September 18, 2019, 08:33:53 pm by tre »
Logged

petko

  • Full Member
  • ***
  • Karma: +24/-0
  • Offline Offline
  • Posts: 100
    • View Profile
    • My blog

Quote
It is only necessary that each platform understand how to interpret (and verify the signature of) one extra-platform transaction type - when submitted as an attachment of a native transaction (as described) to unlock a phased transaction. This is the key to guaranteeing that unlocking the funds on one platform can also can unlock the funds on the other (and that the keys are simultaneously accessible to both participants).

This is not enough to guarantee that Bob cannot immediately unlock and claim Alice funds right after she locked the 150 NXT. Bob can submit a valid Ardor transaction (valid bytes, validly signed) on the NXT blockchain, but his account may be already empty on the Ardor blockchain. Which the NXT nodes cannot know because they are not processing the Ardor blockchain, they only check the bytes and signature (right?).

Quote
I am very interested to learn how Migretor implemented their atomic swap protocol. Would you kindly provide a link to this information, or if you have the patience to explain, even if briefly, the protocol?
I think they used the good old atomic swap protocol: https://en.bitcoin.it/wiki/Atomic_swap

Quote
Perhaps it is as simple as a phased transaction on each platform locked by two hashed secrets - only one is known to each. Both transaction's phased block height limits (approximated to time) are staggered so that one expires much sooner than the other and the protocol requires that the trader who has the later limit be the first to broadcast their secret. This will allow a safe margin of time for the trader with the first limit to decide if there is enough time to broadcast both secrets on the opposing platform. Something like this?
Generally yes, but there is only one secret. Something like this:

1. Alice generates a secret and hash-locks her funds for very long time tA > 4 confirmations_periods. Bob can claim the coins during this period if he knows the secret. But only the hash of the secret is known here.
2. Bob waits for 1 confirmations_period and locks his funds on his blockchain with the same hash which Alice used, for a period of tB < tA - 2 confirmations_periods
3. Alice waits for 1 confirmations_periods and claims Bob's funds. This shows the secret. Notice that she can wait almost until Bob's lock period ends. So Bob's period must end before Alice's period, or else she can get back her coins and also claim Bob's coins.
4. Bob now knows the secret and has at least 1 confirmation_time to claim Alice coins.
Logged

tre

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 3
    • View Profile

Quote
This is not enough to guarantee that Bob cannot immediately unlock and claim Alice funds right after she locked the 150 NXT. Bob can submit a valid Ardor transaction (valid bytes, validly signed) on the NXT blockchain, but his account may be already empty on the Ardor blockchain. Which the NXT nodes cannot know because they are not processing the Ardor blockchain, they only check the bytes and signature (right?).

petko, again a misunderstanding of the proposed protocol. I blame myself as I have been too brief with the description and with explaining the rationale behind each protocol part - in this case (1).

Transactions (1) can only be unlocked by other native transactions that are also signed by the sender of (1). Regarding Alice's (1), Bob cannot unlock this transaction without a native sendMoney transaction signed by Alice as described or, alternatively, by Alice's transaction (2) - also signed by Alice. Again, these are native transactions - the proposed protocol does not otherwise require sharing of information.

The setup of transactions (1) and (2) are further illustrated in the section Example of a trade between NXT and IGNIS. It does require that Alice and Bob are able to observe the opposing platform - naturally they will be creating a transaction on the opposing platform for the purpose of receiving their part of the trade.

I did not appreciate that phased-by-hashed-secret also guarantee funds which was the rationale behind transaction (1) and the reason for attempting this protocol. Your protocol example using the already existing phased-by-hashed-secret help me understand this fact. And by needing only one hashed secret my proposal no longer has any purpose.
Logged
 

elective-stereophonic
elective-stereophonic
assembly
assembly