I have recently become interested in closures and their usage in Rust, primarily because I have spent the past few weeks learning about and building web servers. When I first learned about closures and how to share objects between tasks (invoked functions, spawned threads), I found it helpful to think about these guides: The lexical scope and the nesting of functions within an enclosing function. Nested function(s) - named or anonymous - defined in the enclosing function. Variables are scoped to the enclosing function, accessible to the nested function, and shared between the enclosing and enclosed functions. The variables accessed by the closures are not copied by the closure. These variables are kept alive (on the heap) even after their enclosing function has been popped off the stack. Any updates to the variables will be reflected across the closures accessing them. Some of these hold in Rust (somewhat), however, there are nuances to be considered, especially regarding ownership rules. In this article I try to outline what I have learned about closures in the past week, focusing on: what closures are

Introduction In a prior article - Part I: Bloom Filters - on simple payment verification for light clients, I explored how light clients utilize bloom filters for transaction verification, highlighting the reasons why these filters were implemented and some known flaws in their usage. The challenges are mostly related to privacy leaks, incentive misalignment for full nodes, and trust. The key highlight from part I is this - BIP37 bloom filters are unsuitable for use and a new method of payment verification for clients must address the design flaws inherent in them. BIP37 peer-to-peer protocol has also been disabled by default on Bitcoin Core. BIP 157 proposed a new protocol that permits transaction filtering on the client-side for light clients connected to at least one honest node securely verify transactions included in a block; without loss of privacy or reliance on trusted full nodes. It also eliminates I/O asymmetry between light and full nodes, and minimizes the DOS vector that full nodes were subject and vulnerable to. This proposal details probabilistic compact block filters with concrete implementation in BIP 158. In this article, I will share what I have learned about the need for client-side transaction filtering, what compact block filters are, and how they are used in the network. Client-side Transaction Filtering

Outline: Create your own service such as Casa that provides secure and collaborative custody of bitcoin. You need to create a 2-of-3 multi-sig wallet where the user holds two of the keys and the service holds one. In this setup, it's impossible for the service to move any user funds as they only posses a single key. In normal operation, the user makes use of both of their own keys and the service just coordinates the signing process. You must also allow the user to ask the service to sign with its key in the event the user does not have access to one of theirs. Allowing a hardware wallet as one of the user keys would be a bonus, where the client can interact with the hardware wallet to sign. Format Backend service | APIs Service Name cosign cosine