GithubHelp home page GithubHelp logo

decred / atomicswap Goto Github PK

View Code? Open in Web Editor NEW
507.0 63.0 230.0 188 KB

On-chain atomic swaps for Decred and other cryptocurrencies.

Home Page: https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/

License: ISC License

Go 100.00%
cryptocurrencies cryptocurrency decred exchange go

atomicswap's Introduction

NOTICE Mar 1 2018: The atomic swap contract has been updated to specify the secret sizes to prevent fraudulent swaps between two cryptocurrencies with different maximum data sizes. Old contracts will not be usable by the new tools and vice-versa. Please rebuild all tools before conducting new atomic swaps.

Decred-compatible cross-chain atomic swapping

This repository contains utilities to manually perform cross-chain atomic swaps between various supported pairs of cryptocurrencies. At the moment, support exists for the following coins and wallets:

External support exists for the following coins and wallets:

Pull requests implementing support for additional cryptocurrencies and wallets are encouraged. See GitHub project 1 for the status of coins being considered. Implementing support for a new cryptocurrency provides atomic swap compatibility between all current and future supported coins.

These tools do not operate solely on-chain. A side-channel is required between each party performing the swap in order to exchange additional data. This side-channel could be as simple as a text chat and copying data. Until a more streamlined implementation of the side channel exists, such as the Lightning Network, these tools suffice as a proof-of-concept for cross-chain atomic swaps and a way for early adopters to try out the technology.

Due to the requirements of manually exchanging data and creating, sending, and watching for the relevant transactions, it is highly recommended to read this README in its entirety before attempting to use these tools. The sections below explain the principles on which the tools operate, the instructions for how to use them safely, and an example swap between Decred and Bitcoin.

Build instructions

Requires Go 1.11 or later

  • Clone atomicswap somewhere outside $GOPATH:

    $ git clone https://github.com/decred/atomicswap && cd atomicswap
    
  • To install a single tool:

    $ cd cmd/dcratomicswap && go install
    

Theory

A cross-chain swap is a trade between two users of different cryptocurrencies. For example, one party may send Decred to a second party's Decred address, while the second party would send Bitcoin to the first party's Bitcoin address. However, as the blockchains are unrelated and transactions can not be reversed, this provides no protection against one of the parties never honoring their end of the trade. One common solution to this problem is to introduce a mutually-trusted third party for escrow. An atomic cross-chain swap solves this problem without the need for a third party.

Atomic swaps involve each party paying into a contract transaction, one contract for each blockchain. The contracts contain an output that is spendable by either party, but the rules required for redemption are different for each party involved.

One party (called counterparty 1 or the initiator) generates a secret and pays the intended trade amount into a contract transaction. The contract output can be redeemed by the second party (called counterparty 2 or the participant) as long as the secret is known. If a period of time (typically 48 hours) expires after the contract transaction has been mined but has not been redeemed by the participant, the contract output can be refunded back to the initiator's wallet.

For simplicity, we assume the initiator wishes to trade Bitcoin for Decred with the participant. The initiator can also trade Decred for Bitcoin and the steps will be the same, but with each step performed on the other blockchain.

The participant is unable to spend from the initiator's Bitcoin contract at this point because the secret is unknown by them. If the initiator revealed their secret at this point, the participant could spend from the contract without ever honoring their end of the trade.

The participant creates a similar contract transaction to the initiator's but on the Decred blockchain and pays the intended Decred amount into the contract. However, for the initiator to redeem the output, their own secret must be revealed. For the participant to create their contract, the initiator must reveal not the secret, but a cryptographic hash of the secret to the participant. The participant's contract can also be refunded by the participant, but only after half the period of time that the initiator is required to wait before their contract can be refunded (typically 24 hours).

With each side paying into a contract on each blockchain, and each party unable to perform their refund until the allotted time expires, the initiator redeems the participant's Decred contract, thereby revealing the secret to the participant. The secret is then extracted from the initiator's redeeming Decred transaction providing the participant with the ability to redeem the initiator's Bitcoin contract.

This procedure is atomic (with timeout) as it gives each party at least 24 hours to redeem their coins on the other blockchain before a refund can be performed.

The image below provides a visual of the steps each party performs and the transfer of data between each party.

Command line

Separate command line utilities are provided to handle the transactions required to perform a cross-chain atomic swap for each supported blockchain. For a swap between Bitcoin and Decred, the two utilities btcatomicswap and dcratomicswap are used. Both tools must be used by both parties performing the swap.

Different tools may require different flags to use them with the supported wallet. For example, btcatomicswap includes flags for the RPC username and password while dcratomicswap requires flags for TLS client authentication. Running a tool without any parameters will show the full usage help.

All of the tools support the same six commands. These commands are:

Commands:
  initiate <participant address> <amount>
  participate <initiator address> <amount> <secret hash>
  redeem <contract> <contract transaction> <secret>
  refund <contract> <contract transaction>
  extractsecret <redemption transaction> <secret hash>
  auditcontract <contract> <contract transaction>

initiate <participant address> <amount>

The initiate command is performed by the initiator to create the first contract. The contract is created with a locktime of 48 hours in the future. This command returns the secret, the secret hash, the contract script, the contract transaction, and a refund transaction that can be sent after 48 hours if necessary.

Running this command will prompt for whether to publish the contract transaction. If everything looks correct, the transaction should be published. The refund transaction should be saved in case a refund is required to be made later.

For dcratomicswap, this step prompts for the wallet passphrase. For the btcatomicswap and ltcatomicswap tools the wallet must already be unlocked.

participate <initiator address> <amount> <secret hash>

The participate command is performed by the participant to create a contract on the second blockchain. It operates similarly to initiate but requires using the secret hash from the initiator's contract and creates the contract with a locktime of 24 hours.

Running this command will prompt for whether to publish the contract transaction. If everything looks correct, the transaction should be published. The refund transaction should be saved in case a refund is required to be made later.

For dcratomicswap, this step prompts for the wallet passphrase. For the btcatomicswap and ltcatomicswap tools the wallet must already be unlocked.

redeem <contract> <contract transaction> <secret>

The redeem command is performed by both parties to redeem coins paid into the contract created by the other party. Redeeming requires the secret and must be performed by the initiator first. Once the initiator's redemption has been published, the secret may be extracted from the transaction and the participant may also redeem their coins.

Running this command will prompt for whether to publish the redemption transaction. If everything looks correct, the transaction should be published.

For dcratomicswap, this step prompts for the wallet passphrase. For the btcatomicswap and ltcatomicswap tools the wallet must already be unlocked.

refund <contract> <contract transaction>

The refund command is used to create and send a refund of a contract transaction. While the refund transaction is created and displayed during contract creation in the initiate and participate steps, the refund can also be created after the fact in case there was any issue sending the transaction (e.g. the contract transaction was malleated or the refund fee is now too low).

Running this command will prompt for whether to publish the redemption transaction. If everything looks correct, the transaction should be published.

extractsecret <redemption transaction> <secret hash>

The extractsecret command is used by the participant to extract the secret from the initiator's redemption transaction. With the secret known, the participant may claim the coins paid into the initiator's contract.

The secret hash is a required parameter so that "nonstandard" redemption transactions won't confuse the tool and the secret can still be discovered.

auditcontract <contract> <contract transaction>

The auditcontract command inspects a contract script and parses out the addresses that may claim the output, the locktime, and the secret hash. It also validates that the contract transaction pays to the contract and reports the contract output amount. Each party should audit the contract provided by the other to verify that their address is the recipient address, the output value is correct, and that the locktime is sensible.

Example

The first step is for both parties to exchange addresses on both blockchains. If party A (the initiator) wishes to trade Bitcoin for Decred, party B (the participant) must provide their Bitcoin address and the initiator must provide the participant their Decred address.

Party A runs:

$ dcrctl --testnet --wallet getnewaddress
TsfWDVTAcsLaHUhHnLLKkGnZuJz2vkmM6Vr

Party B runs:

$ bitcoin-cli -testnet getnewaddress "" "legacy"
n31og5QGuS28dmHpDH6PQD5wmVQ2K2spAG

Note: It is normal for neither of these addresses to show any activity on block explorers. They are only used in nonstandard scripts that the block explorers do not recognize.

A initiates the process by using btcatomicswap to pay 1.0 BTC into the Bitcoin contract using B's Bitcoin address, sending the contract transaction, and sharing the secret hash (not the secret), contract, and contract transaction with B. The refund transaction can not be sent until the locktime expires, but should be saved in case a refund is necessary.

Party A runs:

$ btcatomicswap --testnet --rpcuser=user --rpcpass=pass initiate n31og5QGuS28dmHpDH6PQD5wmVQ2K2spAG 1.0
Secret:      3e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16
Secret hash: 29c36b8dd380e0426bdc1d834e74a630bfd5d111

Contract fee: 0.0000744 BTC (0.00020000 BTC/kB)
Refund fee:   0.00000281 BTC (0.00001018 BTC/kB)

Contract (2MwQAMPeRGdCzFzPy7DmCnQudDVGNBFJK8S):
63a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a914ebcf822c4a2cdb5f6a6b9c4a59b74d66461da5816704d728bd59b17576a91406fb26221375b1cbe2c17c14f1bc2510b9f8f8ff6888ac

Contract transaction (346f4901dff1d69197850289b481f4331913126a8886861e7d5f27e837e0fe88):
010000000267864c7145e43c84d13b514518cfdc7ca5cf2b04764ed2672caa9c8f6338a3e3010000006b483045022100901602e523f25e9659951d186eec7e8b9df9d194e8013fb6d7a05e4eafdbb61602207b66e0179a42c54d4fcfca2b1ccd89d56253cc83724593187713f6befb37866201210288ef714849ce7735b64ed886d056b80d0a384ca299090f684820d31e7682825afeffffff3ac58ce49bcef3d047ea80281659a78cd7ef8537ca2bfce336abdce41450d2d7000000006b483045022100bd1246fc18d26a9cc85c14fb60655da2f2e845af906504b8ba3acbb1b0ebf08202201ec2cd5a0c94e9e6b971ec3198be0ff57e91115342cd98ccece98d8b18294d86012103406e35c37b3b85481db7b7f7807315720dd6486c25e4f3af93d5d5f21e743881feffffff0248957e01000000001976a914c1925e7398d325820bba18726c387e9d80047ef588ac00e1f5050000000017a9142d913627b881255c417787cc255ccad9a33ce48d8700000000

Refund transaction (45c7c175f333981508229f6fa637410fbbf4f086b657035c07adda6a49207e03):
000000000188fee037e8275f7d1e8686886a12131933f481b48902859791d6f1df01496f3401000000bf4830450221009344b17316054eae5d293b34683177fa5e7c7ba9b0001ebb2b3deca83bef552e022067088b7342bed0155b2ccef69d97cd293faa687f589d2a351aa6e154953c0c65012103a3a9f2c0492a40b134363e82959fa6132b86e0969e0b25109beb53b1debc4324004c5163a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a914ebcf822c4a2cdb5f6a6b9c4a59b74d66461da5816704d728bd59b17576a91406fb26221375b1cbe2c17c14f1bc2510b9f8f8ff6888ac0000000001e7dff505000000001976a914f5261c9e58aaa9461923c3f78f8f12f0eec22ed388acd728bd59

Publish contract transaction? [y/N] y
Published contract transaction (346f4901dff1d69197850289b481f4331913126a8886861e7d5f27e837e0fe88)

Once A has initialized the swap, B must audit the contract and contract transaction to verify:

  1. The recipient address was the BTC address that was provided to A
  2. The contract value is the expected amount of BTC to receive
  3. The locktime was set to 48 hours in the future

Party B runs:

$ btcatomicswap --testnet auditcontract 63a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a914ebcf822c4a2cdb5f6a6b9c4a59b74d66461da5816704d728bd59b17576a91406fb26221375b1cbe2c17c14f1bc2510b9f8f8ff6888ac 010000000267864c7145e43c84d13b514518cfdc7ca5cf2b04764ed2672caa9c8f6338a3e3010000006b483045022100901602e523f25e9659951d186eec7e8b9df9d194e8013fb6d7a05e4eafdbb61602207b66e0179a42c54d4fcfca2b1ccd89d56253cc83724593187713f6befb37866201210288ef714849ce7735b64ed886d056b80d0a384ca299090f684820d31e7682825afeffffff3ac58ce49bcef3d047ea80281659a78cd7ef8537ca2bfce336abdce41450d2d7000000006b483045022100bd1246fc18d26a9cc85c14fb60655da2f2e845af906504b8ba3acbb1b0ebf08202201ec2cd5a0c94e9e6b971ec3198be0ff57e91115342cd98ccece98d8b18294d86012103406e35c37b3b85481db7b7f7807315720dd6486c25e4f3af93d5d5f21e743881feffffff0248957e01000000001976a914c1925e7398d325820bba18726c387e9d80047ef588ac00e1f5050000000017a9142d913627b881255c417787cc255ccad9a33ce48d8700000000
Contract address:        2MwQAMPeRGdCzFzPy7DmCnQudDVGNBFJK8S
Contract value:          1 BTC
Recipient address:       n31og5QGuS28dmHpDH6PQD5wmVQ2K2spAG
Author's refund address: mg9sDLhfByfAWFo4zq3JZ7nsLfsN59XPue

Secret hash: 29c36b8dd380e0426bdc1d834e74a630bfd5d111

Locktime: 2017-09-16 13:36:23 +0000 UTC
Locktime reached in 47h56m54s

Auditing the contract also reveals the hash of the secret, which is needed for the next step.

Once B trusts the contract, they may participate in the cross-chain atomic swap by paying the intended Decred amount (1.0 in this example) into a Decred contract using the same secret hash. The contract transaction may be published at this point. The refund transaction can not be sent until the locktime expires, but should be saved in case a refund is necessary.

Party B runs:

$ dcratomicswap --testnet --clientcert=client.cert --clientkey=client.key participate TsfWDVTAcsLaHUhHnLLKkGnZuJz2vkmM6Vr 1.0 29c36b8dd380e0426bdc1d834e74a630bfd5d111
Passphrase:

Contract fee: 0.000251 DCR (0.00100400 DCR/kB)
Refund fee:   0.000301 DCR (0.00100669 DCR/kB)

Contract (TcZpybEVDVTuoE3TCBxW3ui12YEZWrw5ccS):
63a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a9149ee19833332a04d2be97b5c99c970191221c070c6704e6dabb59b17576a914b0ec0640c89cf803b8fdbd6e0183c354f71748c46888ac

Contract transaction (a51a7ebc178731016f897684e8e6fbbd65798a84d0a0bd78fe2b53b8384fd918):
010000000137afc6c25b027cb0a1db19a7aac365854796260c4c1077e3e8accae5e4c300e90300000001ffffffff02441455980100000000001976a9144d7c96b6d2360e48a07528332e537d81e068f8ba88ac00e1f50500000000000017a914195fb53333e61a415e9fda21bb991b38b5a4e1c387000000000000000001ffffffffffffffff00000000ffffffff6b483045022100b30971448c93be84c28b98ae159963e9521a84d0c3849821b6e8897d59cf4e6c0220228785cb8d1dba40752e4bd09d99b92b27bc3837b1c547f8b4ee8aba1dfec9310121035a12a086ecd1397f7f68146f4f251253b7c0092e167a1c92ff9e89cf96c68b5f

Refund transaction (836288fa26bbce52342c8569ca4e0db7dec81b2187eb453c1fd5c5d06838f60a):
000000000118d94f38b8532bfe78bda0d0848a7965bdfbe6e88476896f01318717bc7e1aa5010000000000000000016c6bf5050000000000001976a9140b4dae42b84dbad7b7e35f61602cb6a2393f0ae088ace6dabb590000000001ffffffffffffffff00000000ffffffffbe47304402201bd55803eae6de4ea19c618060f82c38e9ca04047c346dc7025f54d8276f13f602205cdf104db74563559e570f186cbc68549d623618b96c7ec971d1a996dab78fbd01210244e4e75a9318ac06656d145c3d3205b2f4f25615698f458e80233c4bb78c91ac004c5163a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a9149ee19833332a04d2be97b5c99c970191221c070c6704e6dabb59b17576a914b0ec0640c89cf803b8fdbd6e0183c354f71748c46888ac

Publish contract transaction? [y/N] y
Published contract transaction (a51a7ebc178731016f897684e8e6fbbd65798a84d0a0bd78fe2b53b8384fd918)

B now informs A that the Decred contract transaction has been created and published, and provides the contract details to A.

Just as B needed to audit A's contract before locking their coins in a contract, A must do the same with B's contract before withdrawing from the contract. A audits the contract and contract transaction to verify:

  1. The recipient address was the DCR address that was provided to B
  2. The contract value is the expected amount of DCR to receive
  3. The locktime was set to 24 hours in the future
  4. The secret hash matches the value previously known

Party A runs:

$ dcratomicswap --testnet auditcontract 63a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a9149ee19833332a04d2be97b5c99c970191221c070c6704e6dabb59b17576a914b0ec0640c89cf803b8fdbd6e0183c354f71748c46888ac 010000000137afc6c25b027cb0a1db19a7aac365854796260c4c1077e3e8accae5e4c300e90300000001ffffffff02441455980100000000001976a9144d7c96b6d2360e48a07528332e537d81e068f8ba88ac00e1f50500000000000017a914195fb53333e61a415e9fda21bb991b38b5a4e1c387000000000000000001ffffffffffffffff00000000ffffffff6b483045022100b30971448c93be84c28b98ae159963e9521a84d0c3849821b6e8897d59cf4e6c0220228785cb8d1dba40752e4bd09d99b92b27bc3837b1c547f8b4ee8aba1dfec9310121035a12a086ecd1397f7f68146f4f251253b7c0092e167a1c92ff9e89cf96c68b5f
Contract address:        TcZpybEVDVTuoE3TCBxW3ui12YEZWrw5ccS
Contract value:          1 DCR
Recipient address:       TsfWDVTAcsLaHUhHnLLKkGnZuJz2vkmM6Vr
Author's refund address: Tsh9c9aytRaDcbLLxDRcQDRx66aXATh28R3

Secret hash: 29c36b8dd380e0426bdc1d834e74a630bfd5d111

Locktime: 2017-09-15 13:51:34 +0000 UTC
Locktime reached in 23h58m10s

Now that both parties have paid into their respective contracts, A may withdraw from the Decred contract. This step involves publishing a transaction which reveals the secret to B, allowing B to withdraw from the Bitcoin contract.

Party A runs:

$ dcratomicswap --testnet --clientcert=client.cert --clientkey=client.key redeem 63a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a9149ee19833332a04d2be97b5c99c970191221c070c6704e6dabb59b17576a914b0ec0640c89cf803b8fdbd6e0183c354f71748c46888ac 010000000137afc6c25b027cb0a1db19a7aac365854796260c4c1077e3e8accae5e4c300e90300000001ffffffff02441455980100000000001976a9144d7c96b6d2360e48a07528332e537d81e068f8ba88ac00e1f50500000000000017a914195fb53333e61a415e9fda21bb991b38b5a4e1c387000000000000000001ffffffffffffffff00000000ffffffff6b483045022100b30971448c93be84c28b98ae159963e9521a84d0c3849821b6e8897d59cf4e6c0220228785cb8d1dba40752e4bd09d99b92b27bc3837b1c547f8b4ee8aba1dfec9310121035a12a086ecd1397f7f68146f4f251253b7c0092e167a1c92ff9e89cf96c68b5f 3e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16
Passphrase:

Redeem fee: 0.000334 DCR (0.00100300 DCR/kB)

Redeem transaction (53c2e8bafb8fe36d54bbb1884141a39ea4da83db30bdf3c98ef420cdb332b0e7):
000000000118d94f38b8532bfe78bda0d0848a7965bdfbe6e88476896f01318717bc7e1aa50100000000ffffffff01885ef5050000000000001976a9149551ab760ba64b7e573f54d34c53506676e8145888ace6dabb590000000001ffffffffffffffff00000000ffffffffe0483045022100a1a3b37a67f3ed5d6445a0312e825299b54d91a09e0d1b59b5c0a8baa7c0642102201a0d53e9efe7db8dc47210b446fde6425be82761252ff0ebe620efc183788d86012103395a4a3c8c96ef5e5af6fd80ae42486b5d3d860bf3b41dafc415354de8c7ad80203e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16514c5163a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a9149ee19833332a04d2be97b5c99c970191221c070c6704e6dabb59b17576a914b0ec0640c89cf803b8fdbd6e0183c354f71748c46888ac

Publish redeem transaction? [y/N] y
Published redeem transaction (53c2e8bafb8fe36d54bbb1884141a39ea4da83db30bdf3c98ef420cdb332b0e7)

Now that A has withdrawn from the Decred contract and revealed the secret, B must extract the secret from this redemption transaction. B may watch a block explorer to see when the Decred contract output was spent and look up the redeeming transaction.

Party B runs:

$ dcratomicswap --testnet extractsecret 000000000118d94f38b8532bfe78bda0d0848a7965bdfbe6e88476896f01318717bc7e1aa50100000000ffffffff01885ef5050000000000001976a9149551ab760ba64b7e573f54d34c53506676e8145888ace6dabb590000000001ffffffffffffffff00000000ffffffffe0483045022100a1a3b37a67f3ed5d6445a0312e825299b54d91a09e0d1b59b5c0a8baa7c0642102201a0d53e9efe7db8dc47210b446fde6425be82761252ff0ebe620efc183788d86012103395a4a3c8c96ef5e5af6fd80ae42486b5d3d860bf3b41dafc415354de8c7ad80203e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16514c5163a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a9149ee19833332a04d2be97b5c99c970191221c070c6704e6dabb59b17576a914b0ec0640c89cf803b8fdbd6e0183c354f71748c46888ac 29c36b8dd380e0426bdc1d834e74a630bfd5d111
Secret: 3e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16

With the secret known, B may redeem from A's Bitcoin contract.

Party B runs:

$ btcatomicswap --testnet --rpcuser=user --rpcpass=pass redeem 63a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a914ebcf822c4a2cdb5f6a6b9c4a59b74d66461da5816704d728bd59b17576a91406fb26221375b1cbe2c17c14f1bc2510b9f8f8ff6888ac 010000000267864c7145e43c84d13b514518cfdc7ca5cf2b04764ed2672caa9c8f6338a3e3010000006b483045022100901602e523f25e9659951d186eec7e8b9df9d194e8013fb6d7a05e4eafdbb61602207b66e0179a42c54d4fcfca2b1ccd89d56253cc83724593187713f6befb37866201210288ef714849ce7735b64ed886d056b80d0a384ca299090f684820d31e7682825afeffffff3ac58ce49bcef3d047ea80281659a78cd7ef8537ca2bfce336abdce41450d2d7000000006b483045022100bd1246fc18d26a9cc85c14fb60655da2f2e845af906504b8ba3acbb1b0ebf08202201ec2cd5a0c94e9e6b971ec3198be0ff57e91115342cd98ccece98d8b18294d86012103406e35c37b3b85481db7b7f7807315720dd6486c25e4f3af93d5d5f21e743881feffffff0248957e01000000001976a914c1925e7398d325820bba18726c387e9d80047ef588ac00e1f5050000000017a9142d913627b881255c417787cc255ccad9a33ce48d8700000000 3e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16
Redeem fee: 0.00000314 BTC (0.00001016 BTC/kB)

Redeem transaction (c49e6fd0057b601dbb8856ad7b3fcb45df626696772f6901482b08df0333e5a0):
000000000188fee037e8275f7d1e8686886a12131933f481b48902859791d6f1df01496f3401000000e0483045022100f43430384ca5ecfc9ca31dd074d223836cef4801b3644c651c3a30d80fbf63b8022017dae9e7ec6f3f5ee0e0b60d146963ba85d9b31003d7f60852126f2a35492759012103b10e3690bcaf0eae7098ec794666963803bcec5acfbe6a112bc8cdc93797f002203e0b064c97247732a3b345ce7b2a835d928623cb2871c26db4c2539a38e61a16514c5163a61429c36b8dd380e0426bdc1d834e74a630bfd5d1118876a914ebcf822c4a2cdb5f6a6b9c4a59b74d66461da5816704d728bd59b17576a91406fb26221375b1cbe2c17c14f1bc2510b9f8f8ff6888acffffffff01c6dff505000000001976a914e1fce397007bad3ce051f0b1c3c7587f016cd76a88acd728bd59

Publish redeem transaction? [y/N] y
Published redeem transaction (c49e6fd0057b601dbb8856ad7b3fcb45df626696772f6901482b08df0333e5a0)

The cross-chain atomic swap is now completed and successful. This example was performed on the public Bitcoin and Decred testnet blockchains. For reference, here are the four transactions involved:

Description Transaction
Bitcoin contract created by A 346f4901dff1d69197850289b481f4331913126a8886861e7d5f27e837e0fe88
Decred contract created by B a51a7ebc178731016f897684e8e6fbbd65798a84d0a0bd78fe2b53b8384fd918
(Decred testnet has been reset, link no longer available)
A's Decred redemption 53c2e8bafb8fe36d54bbb1884141a39ea4da83db30bdf3c98ef420cdb332b0e7
(Decred testnet has been reset, link no longer available)
B's Bitcoin redemption c49e6fd0057b601dbb8856ad7b3fcb45df626696772f6901482b08df0333e5a0

If at any point either party attempts to fraud (e.g. creating an invalid contract, not revealing the secret and refunding, etc.) both parties have the ability to issue the refund transaction created in the initiate/participate step and refund the contract.

Discovering raw transactions

Several steps require working with a raw transaction published by the other party. While the transactions can sometimes be looked up from a local node using the getrawtransaction JSON-RPC, this method can be unreliable since the set of queryable transactions depends on the current UTXO set or may require a transaction index to be enabled.

Another method of discovering these transactions is to use a public blockchain explorer. Not all explorers expose this info through the main user interface so the API endpoints may need to be used instead.

For Insight-based block explorers, such as the Bitcoin block explorer on [test-]insight.bitpay.com, the Litecoin block explorer on {insight,testnet}.litecore.io, and the Decred block explorer on {mainnet,testnet}.decred.org, the API endpoint /api/rawtx/<txhash> can be used to return a JSON object containing the raw transaction. For example, here are links to the four raw transactions published in the example:

Description Link to raw transaction
Bitcoin contract created by A 346f4901dff1d69197850289b481f4331913126a8886861e7d5f27e837e0fe88
Decred contract created by B a51a7ebc178731016f897684e8e6fbbd65798a84d0a0bd78fe2b53b8384fd918
(Decred testnet has been reset, link no longer available)
A's Decred redemption 53c2e8bafb8fe36d54bbb1884141a39ea4da83db30bdf3c98ef420cdb332b0e7
(Decred testnet has been reset, link no longer available)
B's Bitcoin redemption c49e6fd0057b601dbb8856ad7b3fcb45df626696772f6901482b08df0333e5a0

First mainnet DCR-LTC atomic swap

Description Link to raw transaction
Decred contract created by A fdd72f5841414a9c8b4a188a98a4d484df98f84e1c120e1ed59a66e51e8ae90c
Litecoin contract created by B 550d1b2851f6f104e380aa3c2810ac272f8b6918140547c9717a78b1f4ff3469
A's Litecoin redemption 6c27cffab8a86f1b3be1ebe7acfbbbdcb82542c5cfe7880fcca60eab36747037
B's Decred redemption 49245425967b7e39c1eb27d261c7fe972675cccacff19ae9cc21f434ccddd986

License

These tools are licensed under the copyfree ISC License.

atomicswap's People

Contributors

alexlyp avatar dajohi avatar dasource avatar deannolan avatar deswurstes avatar devwarrior-cool avatar devwarrior777 avatar eabz avatar glendc avatar hypernoob avatar jholdstock avatar jrick avatar litebit avatar luoshang722 avatar metalicjames avatar pprudhvi avatar romanornr avatar tecnovert avatar vctt94 avatar wakiyamap avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

atomicswap's Issues

btcatomicswap: error from RPC server

Hi!
I tried to run AS between DCR and BTC, but btcatomicswap returns this error:

warning: falling back to mempool relay fee policy
fundrawtransaction: -3: Expected type bool, got object

with any commands initiate or participate.

Bitcoin node version:
"bitcore-lib": "^v0.13.19",
"bitcore-node": "^3.1.3",
"bitcore-wallet-service": "^2.1.0",
"insight-api": "^0.4.3"

Be more explicit regarding expired locktimes

Currently if a contract contains a locktime that has already been reached it will display the same "Locktime expires in..." message but with a negative duration. This can be handled better by explicitly stating that the locktime has been reached.

New coin want to be swaped

�Now i want to add support of Qtum for atomicswap, but Qtum does not have a Go implement. Should i write an alternative full node by GO for qtum first? If it is, which xxxd should i fork if want it easier. btcd or ltc or which one ?

AS between BTC and LTC

Hi, with the help of your utility it is possible to make a atomic swap between BTC and LTC?

DRY Implementation

Description

As it stands. A lot of code is rewritten in each folder. Each separate chain has its own module and checksums, but, we could have the commands be refactored into separate folders and the modules for each chain are used instead.

Example

Main source code is in.

src/initiate.go
src/participate.go
# etc...

Chain specific source code is in

btc/go.mod
btc/sum.mod
btc/btcatomicswap.go

And so forth.

Suggestions

  • Refactor source code in this way in order to reduce SLOC and make it easier to review code.

  • Ensure that standards are consistent across all chains.

  • Ensure that test cases and documentation for each chain works properly.

Verify all getrawchangeaddress addresses are P2PKH.

The code only checks that the address has a Hash160 method, which is true of both P2PKH and P2SH addresses. If the wallet being queried by any of these tools has added segwit support, and the optional parameter has not been added to request a "legacy" P2PKH address, the wallet may return a P2SH-witness address that will not be usable and may lead to unspendable/lost coins if a refund must be made.

Monero (XMR) Atomic Swap with BTC or BCH

This is possible even though Monero (XMR) has neither hashing nor timelocks.
Only one chain must have sufficient scripting capabilities, while the other one does not.
All that's needed of the non-scriptable chain is that it uses elliptic curve signatures and that transactions are immutable after some time. The scheme doesn't have to be used only to swap with XMR, it can be used for any such non-scriptable chain.
More details:

How does it work?

Novel thing is that parties can use their one-time keys from a different curve on the scriptable chain to interactively construct an encrypted one-time key on the non-scriptable chain, such key that signing something on the scriptable chain allows the other party to decrypt the one-time key on the non-scriptable chain.

This means that on scriptable chain the swap contract will be a HTLC multisig (BTC) or a HTLC covenant (BCH), while on the other chain (XMR) it will be just a normal UTXO.

Say Bob has BTC or BCH and wants XMR
Alice has XMR and wants BTC or BCH

  1. A&B generate their one-time keys for the scriptable chain, and then cooperate to construct the XMR pubkey
  2. Bob funds the contract on BTC or BCH chain
  3. Alice observes the transaction has been mined, funds the XMR output
  4. Bob releases the secret to open the hashlock on the scriptable chain
  5. Alice uses the hashlock secret + her one-time key to take the BTC or BCH; in doing so she reveals the other half of the XMR key
  6. Bob learns the missing piece of info from Alice's signature, decrypts the XMR secret key, and takes the XMR

Refund

The contract on the scriptable chain is a 2-transaction contract.
Regular swap uses only one transaction, but if 1st timelock expires, funds can be forwarded to the 2nd contract: the refund HTLC contract.

There, the roles are reversed.
In refund contract it is Bob who uses the revealing signature to take his BTC or BCH back, and in doing so reveals the missing piece for Alice to take back her XMR.

If Bob is missing in action and doesn't claim the refund on time, the 2nd timelock opens a recovery path where Alice can just take his BCH after a grace period (and XMR is stuck/lost). Instead of XMR refund, Alice gets BCH as if trade went through, while Bob gets nothing.

If Bob cooperates on refund (exercises his option), then he can take the BTC or BCH back, and in doing so reveal his half of the key for Alice to take her XMR back.

Note on Signature Malleability

The original paper claimed that SegWit is needed due to malleability because there the involved parties have to pre-sign the refund spending path, and malleating the parent TXID would invalidate the signatures.
This is true for chains that have pre-2017 version of Bitcoin ScriptVM.

However, since then, BCH has seen 2 upgrades that allow an alternative method:

  • OP_CHECKDATASIG (2018) - this allows for contracts checking a signature for a message from stack, message which can be hardcoded into the contract
  • Introspection opcodes (2022) - together with OP_CAT and OP_SPLIT (2018) - this allows the Script to generate a custom SIGHASH to sign, emulating ANYPREVOUT, or, just directly verifying parts of the transactions without having to emulate it using checksig.

Using this we can construct a proper covenant, and if parent gets malleated then the other party can just update the child TX's prevout refs by themselves without breaking any signature - so malleability problem is removed by making the descendant TX malleable, too, and the resulting contracts are much smaller, since relatively big multisig signatures are replaced with simple covenant code.
More details here:

https://bitcoincashresearch.org/t/monero-bch-atomic-swaps/545/14

Note that there's a 10.5 XMR bounty for the first XMR-BCH swap: https://bounties.monero.social/posts/37/10-500m-bch-xmr-atomic-swaps

gRPC Implementation

Description

Currently, the atomic swap configuration can only be used via command line. It might be a good idea to implement it via gRPC in a way that can also be accessed via HTTP. As it currently stands, the project is very difficult to use in a real-world scenario. Being able to provision this project as a remote procedure call not only ensures consistency with the Bitcoin Core source but also allows the project to be accessed via HTTP as well too.

Suggestions

  • .proto files to define endpoints for each respective CLI tool.

  • Converting existing examples and documentation to use gRPC standard.

  • Test cases for running testing contracts via HTTP.

What if A doesn't reveal contract after redeeming the transaction?

In the example given in the README, once A has redeemed - he need to publish the redemption transaction so that B can extract secret and redeem her contract. What if A doesn't publish the redemption transaction? I am guessing that B then can't redeem her contract. What is the recourse for B in this scenario?

I'd like to use this as a library

Hey there,

I would like to use this code in my own proejct, with a few changes that allows to use this code as a go plugin. I propose the following changes:

func getSettingsKeys() []string {}
func setSettings(settings map[string]string) err {}

settings would entail rpc connection details, or anything required for the plugin to run correctly.

Is this interesting for you too, or shall I fork the repo for myself?

obfuscated secrets: basic extractsecret can fail for non-push-only scriptsig

I was thinking some more about atomic swaps today and how Alice might try to obfuscate her secret when redeeming Bob's contract, in order to confuse him long enough to refund her side as well. For example, consider the extraction code here:

https://github.com/decred/atomicswap/blob/master/cmd/bchatomicswap/main.go#L984-L1003

On most bitcoin-based blockchains, Alice can collude with a miner to create a convoluted scriptsig, such as one including the fragment PUSH(<pre-secret>) SHA256 in place of PUSH(<secret>). Here Alice has chosen a random pre-secret ahead of time and used it to calculate secret=SHA256(pre-secret). She needs to collude with a miner to include her strange transaction since it's non-standard (but valid). When the extractSecretCmd() is run on this script, it finds only pre-secret which does not hash to the expected value, and thus it fails.

In general it seems that a full script interpreter would be required to evaluate scriptsig and find out exactly what is on the stack, before the redeemscript starts executing. Only then do you know for sure what the actual secret value is.

(In Bitcoin Cash, starting in November the scriptsig-push-only rule will change from being a relay policy to being a consensus rule, so at least then it will be easy to extract the secret when Alice is on BCH.)

golint errors

commit : 897d4c1

$ golint ./...
cmd/bchatomicswap/main.go:159:1: error should be the last type when returning multiple items
cmd/bchatomicswap/main.go:440:6: func fundTransactionJsonParser should be fundTransactionJSONParser
cmd/btcatomicswap/main.go:157:1: error should be the last type when returning multiple items
cmd/dcratomicswap/main.go:172:1: error should be the last type when returning multiple items
cmd/ltcatomicswap/main.go:157:1: error should be the last type when returning multiple items
cmd/monaatomicswap/main.go:158:1: error should be the last type when returning multiple items
cmd/partatomicswap/main.go:159:1: error should be the last type when returning multiple items
cmd/partatomicswap/sizeest.go:41:7: don't use ALL_CAPS in Go names; use CamelCase
cmd/partatomicswap/sizeest.go:41:7: exported const WITNESS_SCALE_FACTOR should have comment or be unexported
cmd/polisatomicswap/main.go:157:1: error should be the last type when returning multiple items
cmd/viaatomicswap/main.go:158:1: error should be the last type when returning multiple items
cmd/vtcatomicswap/main.go:159:1: error should be the last type when returning multiple items
cmd/xzcatomicswap/main.go:158:1: error should be the last type when returning multiple items

Building on top of decred/atomic swaps code - Next Steps

Thoughts about building on top of decred/atomic swaps code:

The tools are great as a PoC but difficult to use from other code

  • Standalone executables is fine for PoC
  • Trying to use them in new code means making unwieldy child processes from them .. awkward!
  • The current tools from individual coins need to be in non-main packages
    can wrap command line around that if wanted
  • It is then ok to import those packages into new code such as sequencer for an atomic swap
  • The new individual coin packages should be emitting json later have gRPC/protocol buffer support
  • They should not have the decision to broadcast txs, rather that should be for higher level code
  • @jrick Your idea for go 1.11 module use is a great idea to manage the individual coin packages
    Cheers 😉

ltcatomicswap fails to compile

Deps needs to be sorted out, hopefully after the various ltcsuite PRs land. Currently it is failing to compile due to some package naming mismatches (trying to mix and match btcsuite and ltcsuite).

getrawchangeaddres: status code: 401, response: ""

Going through your readme file but instead of using btcatomicswap with dcratomicswap, I am using btcatomicswap with ltcatomicswap.

When I get to the command:

dcratomicswap --testnet redeem

Or in my case

ltcatomicswap --testnet redeem

I get the following error:

getrawchangeaddres: status code: 401, response: ""

Any idea why?

Why is auditcontract an offline Command?

According to the readme, after party A "Initiates" the swap, Party B audits the contract and the contract transaction.

What i understand is.. Party A will pass on the entire contract and the contract transaction to party B.
Party B checks the contract contents offline (i.e.) not consulting the block chain.

My question is : What if the party A gives a malicious contract and have a different one on the blockchain? How is this situation avoided?

[btcatomicswap] sendrawtransaction wrong param

after commit bitcoin/bitcoin@c033c4b bitcoin switched sendrawtransaction to use maxFeeRate instead of allowHighFees.

This will trhow an error on btcatomicswap: Second argument must be numeric (maxfeerate) and no longer supports a boolean. To allow a transaction with high fees, set maxfeerate to 0.

How can A receive the DCR and B receive BTC?

Description

A only has the bitcoin address n1Sp6GY2CWVy51EHtBoeSNPYHB7zfXoHAd and B only has the DCR address TsRTbDbF8eHKQZgSLRoQJfrH2hv6U66w4WU ,and the last two steps are "A redeem the 0.1DCR from B, B redeem the 0.1BTC from A",
How can they receive other's coin??

Bitcoin Core forks: use estimatesmartfee

Since Bitcoin Core 0.14.2, estimatefee has been deprecated and clients are encouraged to use estimatesmartfee instead. Any atomicswap tools working with wallets that are synced with this Bitcoin Core change should be using estimatesmartfee instead of estimatefee.

Switch to go modules

Repo still uses dep and README recommends very old go. This needs to updated to go modules.

per-project vendoring

Currently, a single dep ensure pulls the vendored deps for all of the go tools. This is a lot of dependencies, and that number is only increasing as more projects add support. Instead, split the dep files for each project and move them to that package. This reduces the number of deps that must be fetched as well as allowing each contributor to make changes to the dep files without stepping over changes made by other projects.

OP_SHA256

Now that the new OP_SHA256 rules have been activated in Decred, all of the atomic swap tools should switch over to this more secure hash function. They are currently using OP_RIPEMD160 due to the sha256 opcode not having been available in the Decred scripting vm.

Before this can be completed, all of the txscript packages must be updated to recognize the OP_SHA256 version of the atomic swap contract:

@dasource @metalicjames heads up, I'll be creating some PRs for your projects for this change.

Transaction fees

Hi! Having a question about transaction fee. Can a dev set it up as desired or is it a fixed amount?

participant address is not P2PKH

Description

when I use bitcoin-cli -testnet getnewaddress to get an address 2N5ioPyiLdGDhHDXDwLj3XzeLvfmE156dgc,
and use this bitcoin address to do the autoswap,

ubuntu@ip-172-31-15-69:~$ btcatomicswap --testnet --rpcuser=eigen --rpcpass=eigencapital initiate 2N5ioPyiLdGDhHDXDwLj3XzeLvfmE156dgc 1.0
participant address is not P2PKH

what should I do ?

support requirements

Hi, I am interested in adding atomicswap capability to a Bitcoin-based altcoin. Is there a checklist of required capabilities?

Update. I found https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/

In order to perform an on-chain atomic swap between 2 cryptocurrencies, there are several prerequisites. Both chains must support:

  • branched transaction scripts
  • the same hash algorithm in both chains’ transaction scripts
  • signature checks in transaction scripts
  • CheckLockTimeVerify or CheckSequenceVerify (“CLTV” and “CSV” for short) in transaction scripts

Since Decred and Litecoin are forks of Bitcoin, the first 3 conditions are trivially satisfied. Further, both Decred and Litecoin have been tracking updates from Bitcoin, so they both support CLTV. The CLTV/CSV support is used to effect a refund, in the cases where either party does not complete part of the process. With some further work on part of other Bitcoin-based cryptocurrency projects, this on-chain atomic swap can occur between any pair of cryptocurrencies that satisfy the above constraints.

Some of these items, I can add in, but is it truly necessary for the same hash algorithm in both chains? Why is this needed?

btcatomicswap auditcontract from output address (redeem address)

The btcatomicswap utility takes in a contract and contract transaction as the arguments in a format of long hexstrings.

Example:
btcatomicswap --testnet auditcontract 6382012088a820dca04d3bb2332d9441964798c846d00d892d8d7dcf8a0cd02ede232dcf12a0298876a9141205a71bca338c827ab7e983fa877d0df4ea068e670423b8065bb17576a914d4cad03b36abd5e2e890dce6d7902abba06d28dc6888ac 020000000001019f3388b5ab5853b0c456e0da1391f5f5c476495e9d4f58c31f760481f52e8f1e0000000017160014504058af6af2ead87d4e347f51ec09263f7f2bfbfeffffff02a08601000000000017a914c1adc9411f7b87353459b2f2b4d2c5fcccb4528e878850f6000000000017a914c7068e75c1e873181d66e538ad5e9b779294be748702473044022024c94c68e6a8bb35bfa74a1563e148bfb751dc52d7cde2853c67d6b82e26aa79022068ee09f68d36ca53507a85fa0ab4b7067db60a5839bc2996a089e23d3bfce1b90121028e7966a869b77aa7da4254779317ce8a4ac5c824c605fea2aec0aaa814e8250b00000000

For an automation of atomicswaps we are implementing we'd like to be able to perform an audit given a simple output address, that we can find in a confirmed contract transaction via block explorer.

Example:
btcatomicswap --testnet auditcontract 2N1y1Jh5pv7uY5atXYpvV4quqLZuFkjJ37C

tls: transport connection broken

Hello,
I am trying to implement atomicswaps to Polis a cryptocurrency with a X11 Algorith. The go version of the full node is ready, also the wallet rpc and the command line.

I am testing with btcatomicswap but when I try to participate on the initiated contract I get a response:

getrawchangeaddress: Post http://localhost:24128: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02\x16"

On the btcwallet side I get other error:

http: TLS handshake error from [::1]:53060: tls: oversized record received with length 21536

Any help from were to start solving this issue?

Thanks!

specification for the atomic swap communications side-channel?

I am thinking for the non-lightning crypto swaps, it would be great if the wider community could settle on some kind of standard for the side channel protocol. I'm not sure if there is any movement in this direction so I'm just leaving an issue post here to inquire.

One reason I ask is that I hope at some point there is a plugin for Electrum / Electron Cash that lets users make atomic swaps, and ideally it would interoperate with decred, and with swap tools that may appear for other wallets. I may even write such a plugin myself.

There is perhaps not any need to freeze a protocol yet but I hope that with your practical experience, something elegant could be settled on.

At the risk of self-promoting too much, I would hope the protocol also supported other variants of atomic swap contract, too. And maybe even to permit swaps carrying OP_RETURN data like the colored coins token system we just implemented. :-D

Cheers!

Refund Transaction Not Being Confirmed

Hi,

Thanks very much for the amazing work you are doing here to make swaps available. The consequences can only be imagined.

For once in my life I decided to be cautious and exercise the failure option first. To that end I created and initiated a contract (using ltcatomicswap) then waited the 48 hours for the refund to be available.

I submitted the refund transaction via https://live.blockcypher.com/ltc/pushtx/ but it still hasn't confirmed, and as far as I can tell it hasn't been relayed, other Litecoin block explorers can't find the transaction.

Publishing the refund transaction using litecoin 0.14.2 sendrawtransaction "failed: 64: version (code -26)"

( getinfo returns in part: "version": 140200,
"protocolversion": 70015,
"walletversion": 60000)

The current situation is: https://live.blockcypher.com/ltc/address/3CH9sjVpApvQR31U8niMyrYg3MzR9466uS/

Suggestions to remedy the situation or help me understand what I've done wrong would be appreciated.

In case it's significant, the refund address used in the initiate below is from the wallet that the local litecoin instance controls.

ltcatomicswap -rpcuser user -rpcpass atomic initiate LiYeAuZHCYUDxe6zpRSthneYew98My7meB 0.5
warning: falling back to mempool relay fee policy
Secret:      [REDACTED]
Secret hash: 80add26acbcd57e618a77573e5fe1696e85d9793

Contract fee: 0.000224 LTC (0.00100000 LTC/kB)
Refund fee:   0.000281 LTC (0.00102182 LTC/kB)

Contract (ZNdPisrRRMg7kYTxyFhGMFxgFCKAT4VUKU):
63a61480add26acbcd57e618a77573e5fe1696e85d97938876a914ffd3b1bd0c5a94762f41b155697e2d267a28c57e67046b17cb59b17576a9145a238ba258c2ec0bc3076038d8f3f97cd65b095a6888ac

Contract transaction (9948ad4738aba10ba57171ff2703fd41bbb6e09fd058fdac95c9fa4d0c27e108):
0200000001bf922f652c3ab84d233840a010e5e38ddc175de9cd0aaf015d1271d759ac1d95000000006b4830450221008208604bd6119c65a2fa7ea4a268f0831129fda31f0dd22f90b5138fc4d55d8102206933d1ab5d8476f401e26be7aca63a34d6e63fb1eaf893cc6238170640fc8f02012103bc62efac4d28be76d073e21bd924ce2a294a7dada17cfab7c186925e3f576b8ffeffffff0282d8464f020000001976a914da4cd7aac092d0acb20488f816214778171e39e488ac80f0fa020000000017a914742609c49d65ae0ed34416284f56773ecef240078700000000

Refund transaction (35452de16c7856c97214bbfc5f64978dcd263180db35ceb9c85f5ef32b88a181):
000000000108e1270c4dfac995acfd58d09fe0b6bb41fd0327ff7171a50ba1ab3847ad489901000000be47304402205838b0907d8819277909355cfbe72642cc3501fc976b4f8d1aa71292071fabde0220105692802184ec8176052654b74dd4db438637c9609398e02931a884314808a901210371b18eeab61b58d22e3c92ef0826e619dfa110a588d7db312421085e71a7b97d004c5163a61480add26acbcd57e618a77573e5fe1696e85d97938876a914ffd3b1bd0c5a94762f41b155697e2d267a28c57e67046b17cb59b17576a9145a238ba258c2ec0bc3076038d8f3f97cd65b095a6888ac0000000001bc82fa02000000001976a914da4cd7aac092d0acb20488f816214778171e39e488ac6b17cb59

Publish contract transaction? [y/N] y
Published contract transaction (9948ad4738aba10ba57171ff2703fd41bbb6e09fd058fdac95c9fa4d0c27e108)

Panic: OP_EQUALVERIFY failed

Hello, is me again.
I have been testing for a while, and everything works, except for when running redeem function.
I run polisatomicswap -rpcuser test -rpcpass test -s localhost:24127 participate PRZ5CR6cEwgMj7nGYKVyNdbaUsFR7fRJc6 0.333 e725d18c2ddecae6838f6b33b503c9d794fafcc0603eb61261ed623a014e25bf

And receive a err: Panic: OP_EQUALVERIFY failed.

Any idea on what is this issue related? I think it might be on hashing algorithm or BIP141 implementation.

[btcamoticswap] deprecated signrawtransaction command

If running btcatomicswap with bitcoin core and, bitcoin core on master, we will receive the following error message:

signrawtransaction: -32: signrawtransaction was removed in v0.18.
Clients should transition to using signrawtransactionwithkey and signrawtransactionwithwallet

When trying to do an atomic swap, as signrawtransaction is deprecated.

Adding Ethereum support

I'm sure Ethereum doesn't need an introduction, but here are some links anyhow:

Would be implemented using a smart contract, not sure which high level language is preferred, but Solidity seems to be the recommended one since a long time.

I'm willing to put engineering time into this myself in order to make this happen, somewhere next month. However I'm confused to why this chain is not yet supported? Are there strong reasons not to support it? Would be a great addition to this repo I would think.

make locktime configurable

locktime is currently hardcoded. it would be nice to specify locktime.

./cmd/btcatomicswap/main.go:    locktime := time.Now().Add(48 * time.Hour).Unix()
./cmd/btcatomicswap/main.go:    locktime := time.Now().Add(24 * time.Hour).Unix()
./cmd/dcratomicswap/main.go:    locktime := time.Now().Add(48 * time.Hour).Unix()
./cmd/dcratomicswap/main.go:    locktime := time.Now().Add(24 * time.Hour).Unix()
./cmd/ltcatomicswap/main.go:    locktime := time.Now().Add(48 * time.Hour).Unix()
./cmd/ltcatomicswap/main.go:    locktime := time.Now().Add(24 * time.Hour).Unix()

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.