It's not supported because

1. I don't have the technical experience to write solidity contracts

2. Nobody else has stepped up

You're welcome to take this on. Ideally the contract would be reviewed by 3rd parties who have more experience with solidity than I do.

Well it has already been implemented in solidity by several teams such as altcoin.io (https://github.com/AltCoinExchange/ethatomicswap/blob/master/cmd/ethatomicswap.js ) and republic protocol ( https://github.com/republicprotocol/eth-atomic-swap/blob/master/contracts/AtomicSwapEther.sol ), don't know if it might help. Would be happy to help but I don't use go

@leoloco not every tool need be written in Go. Each tool is its own program and can be implemented in any language.

I was planning to write it in Golang, but feel free to help to review the solidity part and high-level logic of ethereum @leoloco once I have a PR available.

I've performed some tests with a solidity contract mostly inspired by the republic protocol's one. I was using the mist wallet and it appears to work fine (on the rinkeby testnet though).
I'll help with pleasure

Could be useful:

• chatch/hashed-timelock-contract-ethereum
• chatch/xcat for Ethereum-Stellar swaps
• Ethereum Cross Chain Atomic Swaps (links to contract code)

A heads-up before you get started: a lot of the code in the ethereum ecosystem is GPL and the code linked above is no exception. I'd however prefer to keep all of the tooling in this repo permissively licensed if at all possible.

Sure, that is not a problem. Have implemented the atomic swap logic in another chain already, as to support decred for it. So I don't think there is much need, if any at all, to look at the code linked above.

I am also interested in helping .. especially if Decred are interested ..

There is a contract at:
https://github.com/AltCoinExchange/ethatomicswap/blob/master/contracts/AtomicSwap.sol

. . . which can perhaps be used.

The work would be taking jrick's golang front end CLI api and making those work (in golang) with the ethereum client(s) geth, etc. over RPC. As 'low hanging fruit' maybe use Infuria.io first

That is implementing:
- 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>

These calls would interact with the ethereum contract referenced above through transactions signed by the user's wallet.

Then any Atomic Swap GUI implementer can use the same calls for ethereum from something like electron

What do you guys think?

I agree. I think we should update the contract to solidity 4.18 though.

Maybe 4.21 as that is the start of many new solc safety features

"The work would be taking jrick's golang front end CLI api and making those work (in golang) with the ethereum client(s) geth, etc. over RPC."

@jrick - any thoughts on my proposal above please ...

For me all look good. If needed I can start working on this by the end of this week, as I'll start to have time for it. If someone else can do it faster, feel free to go for it. Just please make sure if you take it instead of me, that you can deliver it within the next week, as I would like to start playing with it by than. But its free for grabs if you can start working on it already now, and can deliver it within he next few days :)

No I have no plans to spend time on this at the moment - was asking jrick opinion on which way might be optimal is all .. cheers

Ah yes! That is very good. The more input the better!

@devwarrior777 yes, as described in project 1, any tools added should adhere to the same interface.

I started working on this today, will try to post some results ASAP:

• (1) First I will try to get the smart contract right, implement it using SOL 4.21 or higher, as well as unit testing it if possible;
  • Question for people with more experience with Ethereum than I have: would it be fair to just create this smart contract each time again, new, each time an atomic swap is created? Or would the same contract be reused if possible?
• (2) Once the contract works, I would need to get an ethereum daemon up and running, so that I can start working on the CLI interface, adhering the same interface as the other tools;

Will already post an intermediate result once I finished (1), as that will be a big part of the core logic for this tool, having someone review it ASAP will help hopefully with the quality.

For me ; reuse the same contract, but make the functions restricted to withdrawer and sender address.

If reusing I suppose we should allow an optional flag to reference contract if desired, or not?

Well, if you want a decentralized matching engine system, then I wouldn’t allow not to reference the contract, so that you can have a decentralized list of open trades for people to find a pair. To my mind liquidity and decentralization comes before a relative anonymity.

Any thoughts here about formal verification of the smart contract we'll write for this feature in Solidity, using why3? I can't find much up-to-date information about it, so not sure if it is still actively being worked on?

I know the solidity ecosystem supports unit tests, using javascript, but I would prefer a formal verification of the to be used contract if possible. Any people who can give some guidance here or have thoughts about this?

Here are some insights https://github.com/pirapira/ethereum-formal-verification-overview/blob/master/README.md#formal-verification-of-ethereum-contracts-yoichis-attempts

The folks at https://zeppelin.solutions/ do vetting of contracts -- and I have read one of their analyses -- they caught a few errors including an overflow error that was a potential attack vector. It may not be free .. so perhaps Decred would be willing to put up a reasonable bounty for this @jrick once the contract has been updated to solc 4.21 and informally looked at by us here.

Great to see many people here

Added the smart contract, including unit tests, in the following (WIP) PR: #76

• It uses solc 4.23;
• I think it follows all the (security) advices (not an EVM/Solidity expert though, so might need some proper auditing to know for sure);
• I think it follows the Solidity style guide (again, not an expert, but used the official documentation and its style guide as a reference);
• It unit tests all reasonable cases I could think off (travis also runs these tests since my PR);

the ethatomicswap tool is finished:

• it respects the decred atomic swap tools, with some exceptions where ethereum works a bit too different for it to make sense otherwise (will provide a full example later, as to illustrate, you can already read more about it in the API differences section below);
• it provides also 2 extra commands: one to deploy the smart contract, and one to audit a transaction used to deploy a contract against the expected contract;

Please review the ethatomicswap tool on all levels. Also please audit the Solidity smart contract used, as I am by no means an Ethereum expert.

API differences

All commands require a running node (with its RPC accessible) except for the extractsecret command. This means that the auditcontract also requires a daemon (cannot be used offline), as we need the daemon in order to get the timestamp from the block of a transaction, as well as to get the sender for a given transaction.

The ethatomicswap tool takes an account flag:

• (a) a hex-encoded account address can be given:
  • this has to be an address known by the daemon;
  • that account has to be unlocked;
  • this results in the transactions being signed on the daemon signed (using eth_signTransaction): as far as I learned from the community, this is a pretty dangerous approach to desire, but it is available should you want/need it;
• (b) this can be left empty (=default), in which the case the first account (found using eth_accounts) is used, further it is the same approach as described in (a);
• (c) you can give the file path of a key (within the key storage dir of your daemon):
  • this does require STDIN in ordere to get the passphrase, needed to decrypt that file;
  • it means signing will be done directly in the CLI tool;

The redeem, refund and auditcontract commands do not take a <contract> (pos) argument, as I do not really see the value in it for Ethereum, given that the contract is a "central" one registered on the address used (and customisable using the -contract flag). Therefore my reasoning is, you know (and hopefully validated) the contract registered on that chain, hence you already know how the contract looks like.

The ethatomicswap provides also the -s <endpoint> flag, just as the other atomic swap tools do. I have tested it, and can confirm that you can use your (geth) daemon's HTTP address as well as the IPC path.

I used the ethatomicswap tool also to make a first TFT-ETH (testnet) atomic swap, as to be able to document a full walkthrough. You can find that documentation and referenced (testnet) transactions in the open PR which closes this issue: #76

I request anyone interested in this feature to either review or get some Solidity/Ethereum experts to review this PR as soon as you can. It would be greatly appreciated.

@GlenDC I am trying to do an atomicswap between BTC and ETH.

1. Initiate from btc worked fine.
2. auditcontract worked fine
3. Participate from eth shows this error.

ethatomicswap -testnet -account 0xc33c7453fb06c9b19ea4eca55cf29f09214958f6  -s http://localhost:8545 participate 0xc33c7453fb06c9b19ea4eca55cf29f09214958f6 1.0 0b8aeb23474fecd2ace555a82bf93ee5bc792458b41e019322b3489793e5b09d

failed to create participate TX: unexpected error while checking for an existing contract: failed to get swap contract from smart contract (at 2661cbaa149721f7c5fab3fa88c1ea564a683631): abi: unmarshalling empty output