bitcoin-teleport / teleport-transactions

CoinSwap implementation
Other
233 stars 62 forks source link

Using BDK (Bitcoin Development Kit) #12

Open chris-belcher opened 3 years ago

chris-belcher commented 3 years ago

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.

notmandatory commented 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

mojoX911 commented 3 years ago

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.

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.

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.

moneyball commented 3 years ago

How about:

  1. Use BDK's coin selection and fee estimation for spending
  2. Use BDK's descriptor and PSBT functionality for multi-sig support
  3. Use BDK support of Tor for privacy

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 .

mojoX911 commented 3 years ago

How about:

  1. Use BDK's coin selection and fee estimation for spending
  2. 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.

  1. 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.

Makes Sense Situation

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.

Possible Challenges

I dont think major changes in the protocol will be needed for that. But few things might help

Architecture of deployment

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.