comit-network / comit-rs Goto Github PK
View Code? Open in Web Editor NEWReference implementation of COMIT, an open protocol facilitating trustless cross-blockchain applications.
License: GNU General Public License v3.0
Reference implementation of COMIT, an open protocol facilitating trustless cross-blockchain applications.
License: GNU General Public License v3.0
Ideally, we can achieve something similar as with the bitcoin-core zeromq integration where we are notified about every new block/transaction that makes it into the chain.
Defintion of done for this ticket:
As the trading client, when the trading service confirms the trade, I will:
DOD:
Scratches:
enum TradingSymbol {
ETH_BTC,
...
}
DoD:
As a trader, I want to be able to decline the offer, because I am cheap guy and don't want to spend so much money for trading.
DoD:
Update software to ensure that all steps support arbitrary amounts (float) and rates in safe manner.
Definition of Done:
Currently, most of the fields in the request/response structs are private because that is the default.
Where necessary during #5, I added the pub
keyword so that I can move along. This is not a long term solution.
We need to figure out a consistent approach for data that needs to be accessed from the outside.
We should only accept offers for trading BTC for ETH at the moment.
For this we need:
Implement the new route-structure for accepting offers:
POST /ETH-BTC/buy-offers
{
"amount": 1
}
This translates to the following:
Buy 1 ETH for x BTC.
The route should implemented in a 'hardcoded' manner. Means that the symbol is not(!) a path variable.
Todo:
As a trading client, I want to generate a trade request to the trading service.
Once the trade offer is received, I want to parse it and ask the trader whether they want to accept or decline the offer.
DoD:
As an exchange service, I want to request the current rate of trading BTC to ETH from the treasury service.
DoD:
Dependencies:
As a Trading client, I want to be able accept an offer. I do that by
and sending it to the trading-service.
Implementation hints:
For now, we only communicate with bitcoind via RPC. Needs unlocked wallet. CLI needs config for how to connect to the node (ENV variables). Ask user securely for password for unlocking the wallet.
exchange
folder to exchange-service
As a trading service, I can receive an accept offer. This includes a signed transaction.
Use an env variable/argument to set-up the rate that the fake-treasury returns.
DoD:
After accepting a trade and inputting their addresses, the user needs to send the addresses to the trading-service.
DOD:
As the exchange service, if I receive a trade offer request from the trading service, I will:
DoD:
Bitcoin Core offers a ZeroMQ endpoint (https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md) that can be used to subscribe to the following events:
Here is a working example that simply prints out every message to stdout:
I already put together some thoughts about how we could integrate this into the exchange and the trader application:
My suggestions would be to externalize this thing into a dedicated program that simply translates these messages to HTTP calls. As we already have an HTTP API in the trader and the exchange, we can easily deal with these messages as well.
interesting
transactions? We only care about transactions of current trades.Several possibilities:
Open questions:
Things that need to be configurable:
For option 2 and 3 we might consider embedding the trade-id into the URL, for example. A watcher could then be spawn like this:
./bitcoin-watcher --transactionhash=796d7a2dbb1213b65dc2f7170575755efdfae8340b2183e971ed5a89113bbedf --notificationurl=http://example.org/exchange/trades/7e641b0f-2f74-4a3b-a612-1aad89047203/transactions
A nice library for defining the parameters: https://github.com/TeXitoi/structopt
As the trading client, when the user wants to redeem his funds, I ask the trading service for the redeem transaction, so that the user can sign and broadcast it.
Note: The trading client does not sign by itself.
DOD:
We need the pubkey hash for creating the HTLC
Regarding the changes done to implement regtest in this 2 open source projects:
Currently, there seems to be a bug in the derivation of the address from the private key.
Somehow, it works fine using ganache but doesn't work with an address generated through meta mask.
The following private key should generate the followed address:
Private Key: dd0d193e94ad1deb5a45214645ac3793b4f1283d74f354c7849225a43e9cadc5
Address: 0x33DcA4Dfe91388307CF415537D659Fef2d13B71a
Create API documentation (Thomas mentioned OpenAPI) for each service. Need to be close to the code to avoid deprecation (in code? File at root?)
As a trading service, when the client accepts the offer I:
Find out what needs be changed to go to testnet in the code (hard coded addresses, etc).
Setup a testnet node (bitcoin and ethereum) and get the money.
Find out, start doing and document it!
Do not worry about making it dynamic at this stage.
Steps:
Definition of Done:
As the exchange service, I respond with the following information to the trading service, so that he can reconstruct the HTLC:
Note: The client already knows the secret and the success address.
DOD:
Document the timings
ie, 12 hours & 24 hours.
ETH:
BTC:
All amounts in our APIs should be represented as an object of the actual value and the associated currency. In the same step, we should default to serializing wei/satoshi. Regarding the JSON serialization, we should probably put the numbers in a string to avoid any kind of conversion/precision errors.
DoD:
As the trading service, I want to be notified about the deployment of the Ethereum HTLC with the contract address.
trading-service: implement secure call to be informed of the eth redeem contract address.
The trading-service will blindly trust this address as it will be provided by a blockchain watcher dedicated to the trading service.
re-order imports (or check why it's not working as reorder_import should be true by default)
see https://github.com/rust-lang-nursery/rustfmt/blob/effba718b4a46811d7baba185129b2eb34b3f126/Configurations.md
As the trading service, I'll forward an incoming request from the trading client to the exchange service within the same request.
As a result, I expect a trading offer from the exchange-service that contains an identifier along with the actual offer.
Upon receiving the offer from the exchange, I:
DoD:
Impl-Hints:
Probably gonna be a POST request.
As the trading service, when the trading client asks me for a redeem transaction, I will query my internal state to check if I have already received the contract address.
If there are enough confirmations (> 4) and there is still enough time to redeem the funds (> 1h), I will create a redeem transaction and send it back to the client.
In the case that there are not enough confirmations (or contract has not yet been created), we error to the user to wait.
In the case that there is not enough time to redeem securely, we tell the user.
As the trading service, I send the following data to the exchange service so it can compute the P2WSH address as well:
In addition, I include the ETH success address so that the exchange service can create the other HTLC.
DOD:
Things to note:
We have to use the nightly version of rust. We should install a dedicated one though
We need docker to run a bitcoin-core node for the integration tests
We should check the formatting
Properly setup caching so the builds are fast
Enable slack notifications instead of emails
Require green builds for pull requests
Use http://docs-rs.com/http-api-problem/0.5.1/http_api_problem/ to generate good error messages.
If we activate the feature with_rocket
, we can use HttpApiProblem
as the Err
type in Result
responses from our handlers.
Child of #408.
As a trading client, I can take the signed tx and forward to the trading service which will broadcast it.
DoD:
As a trading service I want to forward a decline offer request to the exchange service.
As an exchange service I want to process decline offer requests and delete them locally.
DoD:
DoD:
print out parameters
There should be a shell script that automates the setup of the project:
As the trading service, when the exchange service responds with the HTLC (ETH) information, I will
What should be in the HTLC info:
see: #53
Ensure all private keys are in an env variable
As the exchange service, after receiving the secret for the Bitcoin HTLC by an external service (being poked) I create a redeem transaction and send it to the blockchain.
Implementation hints:
In order to allow the exchange service to be decoupled from the blockchain, the exchange service itself does not literally watch it. Instead, it expects to be "poked" and thereby notified by an external service about this event.
This event needs to contain the transaction ID that funded the address, and the secret to redeem. At this point, we trust the external party to give us the correct data. As this is an "internal" endpoint, it needs to be secured later on.
To accept the trade the user execute a "trade accept" command on the cli
He has to provide two addresses:
For now, success is always an ETH address and refund is always an BTC address.
DOD:
As the trading service, when the client initiates a trade, I
DOD:
As the exchange service, after sending the HTLC-data to the trading service, I monitor the BTC blockchain for incoming deposits to the P2WSH address.
In order to be safe, I only watch for deposits to an address that I recomputed myself from the data the trading service sent me.
Upon a successful (proper amount & correct address) deposit, I will create an ETH-HTLC from the data I created earlier and deploy it to the chain.
Implementation hints:
In order to allow the exchange service to be decoupled from the blockchain, the exchange service itself does not literally watch it. Instead, it expects to be "poked" and thereby notified by an external service about this event.
This event needs to contain the transaction ID that funded the address. At this point, we trust the external party to give us the correct tx id. As this is an "internal" endpoint, it needs to be secured later on.
As the exchange service, when the trading service proposes a trade, I:
suggested:
ETH_HTLC_TIME = BTC_HTLC_TIME - EXCHANGE_BUFFER_TIME_NEEDED
Spike:
Notes:
Use cargo make
Add badge to readme
See https://testing.googleblog.com/2014/07/measuring-coverage-at-google.html?m=1
For the MVP we need a bunch of RPC methods.
createrawtransaction [{"txid":"id","vout":n},...] {"address":amount,"data":"hex",...} ( locktime ) ( replaceable )
validateaddress "address"
signrawtransaction "hexstring" ( [{"txid":"id","vout":n,"scriptPubKey":"hex","redeemScript":"hex"},...] ["privatekey1",...] sighashtype )
sendrawtransaction "hexstring" ( allowhighfees )
getblockcount
getrawtransaction "txid"
listunspent ( minconf maxconf ["addresses",...] [include_unsafe] [query_options])
fundrawtransaction "hexstring" ( options )
Branch: https://github.com/tenx-tech/swap/tree/feature/btc-rpc-client
RPC-Command documentation: https://bitcoin.org/en/developer-reference#rpcs
Add tests for all existing code
asx --buy BTC --sell ETH --sell-amount 42 # ETH:BTC (sell 42 eth, buy ?? btc)
asx --buy ETH --sell BTC --sell-amount 42 # ETH:BTC (sell 42 btc, buy ?? eth)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.