decred / atomicswap Goto Github PK

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()

@eabz I'll need the polissuite repos reinstated or we will need to remove the polisatomicswap tool. It is currently causing build errors on our CI infrastructure.

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.

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?

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"

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.

It must use the mempool relay fee, not the higher fee/kB used to increase confirmation time.

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:

• Gugger, J., Bitcoin–Monero Cross-chain Atomic Swap
• Fournier, L., One-Time Verifiably Encrypted Signatures (VES)

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

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

• website: http://ethereum.org
• reference implementation: https://github.com/ethereum/go-ethereum

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.

�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 ?

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?

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!

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!

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

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.

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

Due to the removal of the depracated RPC call "getinfo", btcatomicswap fails when calling the "redeem" command.

Use of getinfo:
https://github.com/decred/atomicswap/blob/master/cmd/btcatomicswap/main.go#L460

From the BitcoinCore release notes:

The deprecated RPC getinfo was removed. It is recommended that the more specific RPCs are used:
getblockchaininfo
getnetworkinfo
getwalletinfo
getmininginfo

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.

(Because Non-segwit transactions can be malleated)

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?

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

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.

Your cross-chain atomic swaps appear to be using the canonical form of smart contracts, which can make them vulnerable to an attack that I describe here:

https://gist.github.com/markblundeberg/7a932c98179de2190049f5823907c016

If Alice is providing the secret, then the smart contract created by Bob must verify the size of the secret or else he is vulnerable to having his money stolen.

Datacoin (DTC) is a Primecoin fork: https://bitcointalk.org/index.php?topic=2188160.0

But SCRIPT is all there so this should be doable. Go tool should be portable.

Little bit confused, everything here seems to be in Go, including the clients. Surely C++ Qt clients are fine to use?

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

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 ?

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).

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??

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.

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?

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.

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 😉

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

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.

We can handle this by using the max of the two values.

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?

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)

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:

• btcd/txscript (btcsuite/btcd#1085)
• dcrd/txscript (decred/dcrd#930)
• ltcd/txscript (jrick/btcd@07a02d6)
• partd/txscript (particl/partsuite_partd#1)
• vtcd/txscript (vertcoin-project/vtcd#2)

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

The account parameter was removed. also see btcsuite/btcd#1058.

This can be worked around in the tool itself by using the raw requests.

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.

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.)