This software is not meant to be used on mainnet. Doing so may lead to fund loss.
- Accept or decline swap requests depending on a configurable rate
- Action the steps to proceed with a swap: fund & redeem HTLCs
- A standalone Bitcoin wallet that uses bitcoind RPC (do not use this as an example of how to write your own Bitcoin Wallet, see known limitations)
- An Ethereum wallet that uses web3
- Support Bitcoin <-> Ether swaps
- Use fee/gas services to calculate appropriate transaction fees/gas
- ERC20 support (maybe)
- Automatically refund when expiry is reached
- Testnet support
Feature we will not do:
- Mainnet support
- Ethereum node of your choice
- comit-rs suite:
btsieveconfigured and running
Install, configure & run
- Clone this repo:
git clone https://github.com/coblox/bobtimus.git
- Install dependencies:
- Create a config file in the working dir of bobtimus (have a look at
- Let's go:
yarn run start
- Fund Bitcoin and Ethereum wallets (addresses are printed at the start of the logs)
seedWords present in the config file are used to generate both Bitcoin and Ethereum HD wallets. Hence, Bobtimus will retain its balance even after a restart.
The Bitcoin Wallet is a Hierarchical Deterministic wallet that uses
bitcoind RPC command
This commands returns unspent outputs found in the blockchain for given
scanobjects used by Bobtimus are extended public keys, that are derived 1000 times.
bitcoind scans the blockchain to find UTXOs for any of these 2000 keys (there are 2 pubkeys).
Moreover, a HD wallet is supposed to only use addresses once.
Also, all data storage for Bobtimus is done in memory.
This leads to the following limitations:
- At boot time, Bobtimus needs to wait for the first
scantxoutsetcall to be finished to know its Bitcoin balance
- The scanning may be long on mainnet
- After more that ~1000 swaps (buying Bitcoin), Bobtimus will not see new incoming Bitcoin funds
- Even if we were to increase the search range, it would only delay the problem and make the
scantxoutsetcall longer and longer
- If the output related to the last address used is already spent, at reboot, Bobtimus cannot guess such that such address were used (spent output are not returned by
scantxoutset) and hence will re-use it
scantxoutset only returns unspent outputs, it is not straightforward (or possible?) to create an algorithm that would progressively scan a limited range of keys at a given time.
If within a given range, let's say scanning key 2000 to 3000, no UTXO is found does it mean that, either:
- None of the keys from 2000 to 3000 were used and scanning can stop?
- Keys from 2000 to 3000 were used and scanning should proceed to 3000-4000 range?
Because of this uncertainty, it is not possible to create an algorithm only using
bitcoind that can certify that all Bitcoin funds are use by Bobtimus.