assembly
assembly
Recent Posts  
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Ardor Client: Ardor 2.2.5

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: September 18, 2019, 05:01:00 pm 
Started by tre - Last post by tre
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.

 22 
 on: September 18, 2019, 11:38:19 am 
Started by tre - Last post by petko
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.

 23 
 on: September 18, 2019, 08:17:46 am 
Started by capodieci - Last post by capodieci
My name is Roberto (read about me here: https://medium.com/@capodieci/i-am-was-an-it-artisan-cdf56f3831d3 )



Cheers to everyone in this forum!

R

 24 
 on: September 16, 2019, 02:37:49 pm 
Started by jhonnyplay - Last post by jhonnyplay
NEW MONTHLY 2 BTC COMPETITION IS NOW ACTIVE!
Don't miss the chance to participate in our monthly competition!
Play and battle your way to the top of the leaderboard to WIN PRIZES in BTC!



 25 
 on: September 16, 2019, 07:24:37 am 
Started by Jose - Last post by Jose
Weekly Wins - 16th of September, 2019
https://twitter.com/Jelurida/status/1173492304985935872
https://www.jelurida.com/news/weekly-update-2019-09-16

 26 
 on: September 15, 2019, 03:54:48 pm 
Started by tre - Last post by Right.Here
Hi  :D

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

thank you and good continuation  ;)

 27 
 on: September 11, 2019, 01:46:52 am 
Started by tre - Last post by tre
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.

 28 
 on: September 07, 2019, 03:35:48 pm 
Started by Jose - Last post by Jose
It seems it's coming... soon
https://www.youtube.com/watch?v=AuNi-yNhHY8

 29 
 on: September 07, 2019, 03:32:16 pm 
Started by Jose - Last post by Jose
Weekly Wins - 6th of September, 2019
https://twitter.com/Jelurida/status/1169963323531698176
https://www.jelurida.com/news/weekly-update-2019-09-06

 30 
 on: September 05, 2019, 07:21:17 am 
Started by Jose - Last post by Jose
https://twitter.com/coinexcom/status/1169118705898414082
https://announcement.coinex.com/hc/en-us/articles/360032913352-Ardor-Online-Blockchain-Equals-Services-Platform

Pages: 1 2 [3] 4 5 ... 10
elective-stereophonic
elective-stereophonic
assembly
assembly