$1000
1stPrize
$500
2ndPrize
$500
2ndPrize
$500
2ndPrize
$500
2ndPrize
ARCHIVE

The competition and voting have completed. Winners were determined by the citizens of Lykke City.

  • Days of the project

    Dec 27, 2016 - Feb 24, 2017 (58 days)

  • Registration

    Dec 27, 2016 - Feb 17, 2017

  • Submissions

    Jan 17 - Feb 17, 2017

  • Voting

    Feb 17 - Feb 24, 2017

Atomic crosschain swap transactions

Lykke is semi-centralized exchange that means that a matched trade is settled on a blockchain as an atomic transaction. A single trade between two parties is calles "swap" of two kinds of assets between those two parties. Proof of concept for atomic crosschain swaps BTC<>ETH is required to be implemented: 

Crosschain atomic swap assumes that Alice transfers BTC to Bob on the Bitcoin blockchain and at the same time Bob transfers ETH to Alice on the Ethereum blockchain. Such two transfers should be made in trustless way – swap must be atomic operation (see more Atomic cross-chain trading).

There are the following 2 scenarios must be covered:

Scenario I. Bob pays first

1. Bob transfers to Alice ETH using a smart contract with hash H calculated from Bob’s secret preimage R H=hash(R). Alice can redeem Bob’s ETH payment only by providing secret R to the smart contract. Bob’s transfer to Alice can be canceled if it is not redeemed by Alice during 48 hours.

2. Alice transfers BTC using bitcoin HTLC transaction that has the following output:

  • Bob’s signature and secret preimage R which hashes to revocation hash H

OR

  • Alice’s signature and OP_CHECKSEQUENCEVERIFY <24 hours>

3. Bob redeems the HLTC during 24 hours and reveals his secret R. Otherwise Alice can get her coins back.

4. Alice should redeem Bob’s payment with providing revealed secret R into smart contract. Otherwise Bob can cancel his smart contract payment.

Scenario II. Alice pays first

1. Alice generates a secret preimage R and calculates public hash H=hash(R). Alice transfers assets BTC using bitcoin HTLC transaction that has the following output:

  • Bob’s signature and secret preimage R which hashes to revocation hash H

OR

  • Alice’s signature and OP_CHECKSEQUENCEVERIFY <48 hours>

2. Bob transfers assets to Alice using Ethereum smart contract protected with an Alice’s public hash H. Bob can cancel the smart contract transfer if it is not redeemed by Alice during 24 hours.

3. Alice can redeem Bob’s payment by providing secret R into contract. Bob gets smart contract event notification revealing Alice’s secret R to Bob.

4. Bob should redeem Alice’s bitcoin HTLC payment with revealed R during 24 hours. Otherwise Alice can get her coins back.

Platform preference

Highly recommended that Bitcoin part would be implemented on C# using NBitcoin. Ethereum part would be implemented on C# using Nethereum.

Why not to use BTC Relay?

BTC Relay is a smart contract that allows to lock ETH until BTC would be provided on the requested bitcoin address. The smart contract is needed to be feeded up with the bitcoin blockchain information to be able unlock ETH payments.

Anyone can be a Relayer who provides bitcoin blockchain hashes to the smart contract. But the major issue is that the BTC Relay solution is not scalable. It would not not work for the offchain micropayment channels. It is entirely based on the onchain information.

What we want to achieve is to build a similar to BTC Relay smart contract which would also provide locking of ETH until BTC transfered to the requested address. But the main difference is that the smart contract should not hold chain of bitcoin block hashes. To unlock funds a preimage R of hash H=hash(R) must be revealed on both Ethereum and Bitcoin blockchains. The same hash locks mechanism will be used for the micropayment channels on the further projects. Currently the proof-of-concept for the onchain ETH-BTC atomic swap is only required based on hash locks.

 

Please login using a user with KYC to see this info
Username Registration date Result
February 09, 2017 09:57
Please login to leave a comment
Username reg. and Subm. Date Result Vote

For this project, none of the submitted results matched our experts expectations, so we decided not to award the first prize.

Your Feedback