Using BDK (Bitcoin Development Kit)

[chris-belcher]

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:

• BDK supports RBF, that could be useful later then Teleport ends up supporting multiple pre-signed RBF transactions.
• If we ever create a taker Teleport app then BDK's implementation of client side block filters would help for private wallet sync. On the other hand this still requires downloading many GB, so not really an option for a limited-data mobile wallet.
• BDK supports miniscript. Right now teleport builds up scripts from rust-bitcoin's library see example. Miniscript might be a bit cleaner, also it might be useful if/when scriptless scripts get added to bitcoin if miniscript supports them in a cleaner way.
• Using BDK's wallet struct would be a bit cleaner.

So a useful thing to do one day might be to have Teleport use BDK.

[notmandatory]

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]

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.

[moneyball]

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 <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACPUA2DJRMMH45LPZNKGITTPEZW5ANCNFSM42WTQSHQ> .

[mojoX911]

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.

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

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

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.