Wallet constructor, builder or standard constuctor. What arguments to add to the constructors? Single-descriptor wallets (Wallet::create_single) Wallet::peek_address Wallet::cancel_tx Wallet::next_derivation_index Wallet::derivation_of_spk Wallet::descriptor_checksum Wallet::finalize_psbt? Jurvis' request for get_tx on the clients

The ticket: https://github.com/bitcoindevkit/bdk/issues/980 Goals Do Electrum properly. Check PoW of the chain, find the best chain. Check tx is part of the block (merkle-proofing). Do Electrum checkpointing (minimize headers to download). The Architecture The new ChainOracleTo construct: Initial blocks (Vec<{Height, BlockHash, Difficulty}>) with difficulty.

Attendees Steve Myers https://github.com/notmandatory Tobin Harding https://github.com/tcharding Andrew Poelstra https://github.com/apoelstra Ben Carman https://github.com/benthecarman Matt Corallo https://github.com/TheBlueMatt Christian Lewe https://github.com/uncomputable Dawid Ciezarkiewicz https://github.com/dpc Rob Netzke https://github.com/rustaceanrob Dan Gould https://github.com/DanGould

Day 1: Rust Bitcoin Day 2: Bitcoin Dev Kit Day 3: Lightning Dev Kit Day 4: Fedi Attendees

July 30, 2024 Nashville, TN <br> Presentations 10am: Steve on BDK 1.0 11am: ValuedMammal on What to expect when upgrading to 1.0 2pm: thunderbiscuit on the BDK Documentation Landscape Feature requests for 1.X and 2.0

#lookingforhelp Support for cha-cha and bitcoin hashes Write a simple, async http client RPC types Bitcoin HPKE + OHTTP

# **Day 4: Fedi**

# **Day 3: Lightning Dev Kit**

Talk: Dev Tools That Helps Wallet Users Summary Bitcoin is meant to be decentralized. However, many Bitcoin wallets rely on trusted sources to fetch transaction data. This sacrifices privacy and security for users. Furthermore, technologies such as Compact Block Filters are readily served in the network. Why aren’t more wallets making use of such features? Topics discussed in this talk include simple payment verification, Electrum, compact block filters, and developer incentives. In addition, a new standard will be proposed… are you ready to meet Neutrum? Sections Who Am IEvan BDK (Bitcoin Dev Kit) Contributor BDK is a bitcoin wallet library Who uses BDK?Key management, miniscript, generating addresses, fetching transactions, creating transactions, signing transactions

The problem PR#1203 at commit 94b9751841b935969bc6031f612cd10d5e872512 has a bug where the KeychainTxOutIndex constructed from individual changesets may be different than what would be constructed from the aggregate of those ChangeSets. This problem is shown in a test of commit 0401c9b79f9a00b65770bc3562aa2d3e7a4b916e. /// The index as of commit `94b9751841b935969bc6031f612cd10d5e872512`. pub struct KeychainTxOutIndex<K> { keychains_to_descriptor_ids: BTreeMap<K, DescriptorId>, descriptor_ids_to_keychain: BTreeMap<DescriptorId, K>, // ... other fields excluded ... }

Agenda Evan's pitch (shoutout to @LLFourn for these ideas).Problems with the current chain src APIs.Esplora: need to lock wallet again to fetch missing checkpoints. Electrum: need to refer back to wallet to fetch full transactions. Not efficient. We should use electrum with pub/sub model. The TxGraph::missing_heights API is also problematic in general: https://github.com/bitcoindevkit/bdk/issues/1354 Solution(s). Change checkpoints from linked-list to skip-list. Checkpoints were linked-list so we can cheaply share the LocalChain's state to chain-sources. This is very good for block-by-block chain sources where we only need to worry whether the update connects with the original state (to do so we iterate backwards from the tip). However, for spk-based chain-sources, we may be introducing transactions from way back. We need a quick way to determine which new checkpoints to fetch when we introduce these transactions. The old solution was to maintain an index of the linked-list (as a height->hash map in LocalChain). This means we need to refer back to the LocalChain to determine which checkpoints we need to fetch. Enter skip lists. Skip list makes querying from a checkpoint tip efficient so instead of maintaining a separate index, we can just query from a checkpoint. Now we can determine which new checkpoints to fetch without refering back to the LocalChain. Wrap transactions with Arc. This allows us to have the chain-src cheaply have a view of all transactions fetched. Electrum chain source will not have to refer back to the receiving TxGraph and just always send Arc<Transaction> as an update. The additional benefits of this is more memory savings since ChangeSets can also be of Arc<Transaction>s.

BDK is a Rust library with the goal of making it easier for devs to build Bitcoin wallets The BDK project is a Rust workspace, composed of various crates. There are two types of crates: the ones that contain logic (crates) and the ones that contain examples (example-crates) The crates directory is composed of various projects, the most relevant are:chain: contains the structures needed for organizing the data synched from a blockchain source (could be esplora, electrum, bitcoind - more on that later). esplora, electrum, bitcoind_rpc: contain the methods needed for downloading data from esplora/electrum/bitcoind and inserting it in the chain structures bdk: uses the chain structures to create a high-level Wallet. This is eventually going to be renamed to bdk_wallet (see #1305) Today's PR changes bits of logic in the bdk_esplora crate. More specifically, it makes sure that the update we download from esplora includes the txouts needed for fee calculation. We don't store the tx fee in BDK, it is calculated on the fly when needed To calculate the fee, we need to know the previous txouts, which we wouldn't have by default for transactions received from an external wallet

A place to put down questions regarding the new 1.0 API. BDK Chain questions Why would you want a TxGraph::<()>? Why do we have different types of Anchors (ConfirmationTimeHeight, BlockId, etc)? In is_block_in_chain/try_list_chain_txs, why are you passing in a chain_tip? Why would anyone pass in a chain_tip different from chain_oracle.get_chain_tip()?Maybe the reasoning is the following: let's say you have a ChainOracle implementation that gets updated in a different thread. You are midway through a method that uses heavily chain_oracle related methods (for example: try_list_chain_txs, etc). You don't want the result of those calls to change just because a new block came in, so instead, you pass in always the same chain_tip (the one you obtain at the start of the method) and :tada:! The response to try_list_chain_txs will always be the same - as opposed to, for example bitcoin-cli listtransactions, which changes if a new block comes in BDK Core questions What did KeychainScan become?

User project Possible contact Dev who could help with the interview Repository Website Notes Bitkey ? ?

Goal: A clearer idea of what needs to get done before beta! Agenda Better Milestone Categories?alpha: larger API changes (i.e. #1203, backwards compatibility of wallet::ChangeSet/persistence). alpha.finalapi: Refactoring. beta: Comprehensive testing of esplora/electrum crates. Comprehensive docs. Move tickets to proposed categores. Minutes

A set of exercises that should help with deepening one's knowledge of bdk_chain. TxGraph Transaction tx_a just got confirmed in block block_1. Re-create the scenario in bdk_chain. You should be able to create one TxGraph and one LocalChain, and make sure that when tx_graph.try_list_chain_txs is called, one confirmed tx is returned. Hint: anchors

:::info Location: Online Date: Jan 10th, 2023 13:00 AM (UTC) Agenda:The purpose of this call is to establish the expectations for BDKF grantees. This includes discussions on time commitment, holiday/sick days, full-time versus part-time arrangements, etc. Additionally, we will discuss the topic of bounties - given that our primary goal is to onboard contributors that want to stay long-term, we need to determine the level of restriction in awarding bounties. Should bounties be granted exclusively to individuals willing to continue working on the project after the bounty is expired, or should we evaluate bounties on a case-by-case basis? :::

TODOs [x] TODO 1: Should we keep this? We'll need to pin dependencies [x] TODO 2: Other CI workflows use explicit Rust compiler versions, I think we should do the same here [x] TODO 3: Other CI workflows use explicit version of the Rust compiler, I think we should do the same here [ ] TODO 4: I DON'T KNOW IF THIS IS A DECENT WAY TO GENERATE ENTROPY PLEASE CONFIRM [x] TODO 6: Why are these imports required? [ ] TODO 7: It appears that the to_hex() method is not available anymore. Look into the correct way to pull the hex out of the DescriptorSecretKey. Note: ToHex was removed in bitcoin_hashes 0.12.0 [ ] TODO 8: Do we really need the mutex on the wallet? Could this be an Arc? [ ] TODO 9: Peek is not correctly implemented [ ] TODO 10: Do we need this mutex?

Paragraph Style Keep an eye out for the bdk 1.0.0-alpha.2 release with all the improvments added in Q3. Noteble changes include @evanlinjin's innovative new bitcoind RPC based blockchain client module that updates the chain and wallet state block by block. This enables quick syncing to bitcoind, even for wallets tracking many addresses. @evanlinjin also merged a major change to Implement linked-list LocalChain. This change enables more efficent and thread safe block data storage. @vladimirfomene did some required refactoring to the chain update structures to improve usability. @danielabrozzoni performed our long overdue upgrade to the latest rust-bitcoin 0.30 version which is a big win for interoperating with other rust-bitcoin base projects. @notmandatory removed the TransactionDetails type from the Wallet API and replaced it with new functions to provide the same info. @evanlinjin added a new cli example for the esplora blockchain client showing off new chain syncing features. And @LagginTimes and @danielabrozzoni implemented a new and improved set of tests to prevent conflicting transactions in the TxGraph struture. In related news, @danielabrozzoni's rust-miniscript planning module PR was merged :tada:. This work lays the foundation for future improvements to the bdk transaction builder. A new BDK Case Studies page was released on the bitcoindevkit website showcasing a growing list of projects that use the bitcoin development kit. a new maintenance bdk version 0.29.0 was released which fixes a small bug in the wallet and updates the rust-bitcoin dependency to the latest 0.30 version. The language bindings for BDK have a new release (0.30.0) of bdk-android, BitcoinDevKit (Swift library), bdkpython, bdk-rn, and bdk-flutter with support for new BIP-86 (Taproot) descriptor templates. The language bindings are also working to make their build tools and system well documented and produce templates so that other Rust-based bitcoin projects can leverage their process. Check out the uniffi examples website and Rust language bindings template for more information. Three successfull Summer of Bitcoin projects were completed, including a new Swift iOS Demo Wallet for which @reez and @notmandatory mentored @Ytemiloluwa, adding Payjoin support to bdk-cli for which @DanGould and @notmandatory mentored @willowenss, and a now ready-for-showtime Padawan Wallet, where @thunderbiscuit mentored @Prakhar. The summer also saw some of the crew active in the community and at conferences. @evanlinjin was on the 億聰哲史 podcast, helped start a new BitDevs in Taipei, and gave a talk and workshop at the first Bitcoin Thailand conference. @danielabrozzoni taught a few lessons on Bitcoin and BDK for the cubo+ mentoring program, gave a talk at hack.bs.it on Rust, and was on the "Il priorato del Bitcoin" podcast for an episode on Bitcoin technical news (BIP324, covenants, drivechains, Ark, etc). @notmandatory gave a workshop at TABConf2023 on how to use the new BDK 1.0 syncing mechanisms.

How did you spend your time? BDK 1.0 Completed bdk 1.0.0-alpha.2 release with all the improvments below. @evanlinjin implemented an innovative new bitcoind RPC based blockchain client module that updates the chain and wallet state block by block. This enables quick syncing to bitcoind, even for wallets tracking many addresses. @evanlinjin merged a major change to Implement linked-list LocalChain. This change enables more efficent and thread safe block data storage. @vladimirfomene did some required refactoring to the chain update structures to improve usability. @danielabrozzoni performed our long overdue upgrade to the latest rust-bitcoin 0.30 version which is a big win for interoperating with other rust-bitcoin base projects. @danielabrozzoni's rust-miniscript planning module PR was merged :tada:. This work lays the foundation for future improvements to the bdk transaction builder. @notmandatory removed the TransactionDetails type from the Wallet API and replaced it with new functions to provide the same info via new functions. @evanlinjin added a new cli example for the esplora blockchain client showing off new chain syncing features.