Open GlenDC opened 6 years ago
It's not supported because
I don't have the technical experience to write solidity contracts
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:
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:
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:
SOL 4.21 or higher
, as well as unit testing it if possible;
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?
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: https://github.com/decred/atomicswap/pull/76
solc 4.23
;the ethatomicswap
tool is finished:
API differences
section below);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.
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:
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;eth_accounts
) is used, further it is the same approach as described in (a);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: https://github.com/decred/atomicswap/pull/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
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.