Open chris-belcher opened 3 years ago
I'm happy to help anyone who wants to work on this one.
Another project you might find interesting (and also from @afilini) is https://github.com/MagicalBitcoin/libtor
I have spent some time exploring and thinking about BDK-CoinSwap integration.
Listing my thoughts below here, for future reference and others to evaluate on.
BDK provides three basic functionalities of a wallet system. A Database
(by default a sled
type key-value pair), Descriptors
and a Blockchain
backend.
Coinswap currently implements all of them in straight forwards ways.
So it seems there are certain responsibilities coinswap can offload to BDK to handle.
The benefits I think will come from using the DB
and Blockchain
parts of the BDK.
I am not sure if the default sled
DB provided in the BDK can add custom coinswap data and logic. If not, we need to implement the relevant public DB traits to make our custom Database BDK compatible.
But the biggest benefit I think comes from compact_filter
feature of BDK. Which makes the wallet essentially into a Neutrino light client which can be pointed to a full node. This can be very useful for privacy in mobile apps. And as BDK does all the heavy lifting in the background, with very simple API, it is almost trivial to turn maker/taker wallet into a Neutrino using it.
This will essentially replace the core RPC communication that coinswap uses right now.
One possible problem is BDK is primarily a Descriptor based wallet. So coinswap protocol has to be transformed in descriptor language. And some core logic around the protocol might needs to be refactored. But should not be too hard.
Here's my preliminary thought on how the integration might look like.
Maker
will be divided in a demon-client
architecture.
makerd
running tokio loop, syncing the lightclient backend, storing wallet data, processing incoming requests, and handling coinswap logic. A bulk of this task can be offloaded to BDK. maker-cli
will make RPC communication with makerd
and provide control and information query to end user.Taker
can be a REPL based command line tool wrapping over BDK and taker protocol logic. It will also have its own neutrino backend, wallet db, and sync with a pointed core node, again most of it can be offloaded to BDK.
It will make communication with makers, show offers, configure and execute coinswaps. These will be coniswap specific logic.
So far this looks to me like a possible path of integration.
Along with this the state of coinswap implementation itself has to be considered. As it might make sense to first complete the coinswap specific functions here before shifting to a more complex wallet backend.
How about:
On Sun, May 23, 2021 at 10:14 AM Mojo @.***> wrote:
I have spent some time exploring and thinking about BDK-CoinSwap integration.
Listing my thoughts below here, for future reference and others to evaluate on. Basic infos
BDK provides three basic functionalities of a wallet system. A Database (by default a sled type key-value pair), Descriptors and a Blockchain backend.
Coinswap currently implements all of them in straight forwards ways.
- Database - Simple file storage
- Blockchain - Talk to core via RPC.
- Descriptors - Scripts are simple, made by hand.
So it seems there are certain responsibilities coinswap can offload to BDK to handle. Benefits
The benefits I think will come from using the DB and Blockchain parts of the BDK.
I am not sure if the default sled DB provided in the BDK can add custom coinswap data and logic. If not, we need to implement the relevant public DB traits to make our custom Database BDK compatible.
But the biggest benefit I think comes from compact_filter feature of BDK. Which makes the wallet essentially into a Neutrino light client which can be pointed to a full node. This can be very useful for privacy in mobile apps. And as BDK does all the heavy lifting in the background, with very simple API, it is almost trivial to turn maker/taker wallet into a Neutrino using it.
This will essentially replace the core RPC communication that coinswap uses right now. Problems
One possible problem is BDK is primarily a Descriptor based wallet. So coinswap protocol has to be transformed in descriptor language. And some core logic around the protocol might needs to be refactored. But should not be too hard. Possible Approach
Here's my preliminary thought on how the integration might look like.
Maker will be divided in a demon-client architecture.
- makerd running tokio loop, syncing the lightclient backend, storing wallet data, processing incoming requests, and handling coinswap logic. A bulk of this task can be offloaded to BDK.
- maker-cli will make RPC communication with makerd and provide control and information query to end user.
Taker can be a REPL based command line tool wrapping over BDK and taker protocol logic. It will also have its own neutrino backend, wallet db, and sync with a pointed core node, again most of it can be offloaded to BDK. It will make communication with makers, show offers, configure and execute coinswaps. These will be coniswap specific logic. Thoughts
So far this looks to me like a possible path of integration.
Along with this the state of coinswap implementation itself has to be considered. As it might make sense to first complete the coinswap specific functions here before shifting to a more complex wallet backend.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin-teleport/teleport-transactions/issues/12#issuecomment-846595657, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPUA2DJRMMH45LPZNKGITTPEZW5ANCNFSM42WTQSHQ .
How about:
- Use BDK's coin selection and fee estimation for spending
- Use BDK's descriptor and PSBT functionality for multi-sig support
@moneyball yes, all of them will be used by default i think when using the BDK wallet.
- Use BDK support of Tor for privacy
That sounds like cherry on top. I haven't looked into the Tor part of BDK yet, thanks for mentioning.
Below are some further thoughts on summarising both my and @chris-belcher 's comments above.
I think the integration makes sense after the first iteration of coinswap protocol, once the basic functionalities are done. As @chris-belcher also mentioned, we might wanna deploy some kind of coinswap binaries with wallet support for people to start using it.
In such case, it makes sense offload major wallet tasks to BDK.
I dont think major changes in the protocol will be needed for that. But few things might help
A miniscript description of the protocol will be needed. Agree with @chris-belcher here, it would be a more cleaner approach than bare scripts.
A DB implementation compatible with BDK traits here
Possibility of light client depends on the amount of storage required. As per my current understanding light client storage size is small, but not trivial. This might need some R&D.
I think a simple Maker
type server-cli
binary pair, and a Taker
type cli
binary will be the easiest thing to cook. I do have some thoughts over them. But we can do that on another thread later.
I studied this library (https://github.com/bitcoindevkit/bdk) to see if it could be useful to Teleport.
Right now Teleport uses rust-bitcoin, bitcoincore-rpc and Bitcoin Core's RPC for almost everything it does. Moving to BDK would be done by using it's Wallet struct. It could help in a few ways:
So a useful thing to do one day might be to have Teleport use BDK.