This week’s newsletter includes an announcement of the 2019 Chaincode Residency program, summarizes a few talks from the Stanford Blockchain Conference, and provides the usual list of notable code changes in popular Bitcoin infrastructure projects.

Chaincode is inviting developers who want to contribute to open source Bitcoin and Lightning protocol projects to apply to the residency . Applicants from all backgrounds are welcomed, and Chaincode will cover travel and accommodation costs and provide a stipend to support living expenses.

● Chaincode Residency 2019: Chaincode Labs opened applications for its fourth residency program to be held in New York over summer 2019. The program combines a 3 week seminar and discussion series covering Bitcoin and Lightning protocol development with a two month period for working on an open source Bitcoin or Lightning project under the guidance of an established protocol developer. The list of confirmed speakers and mentors includes some of the most prolific contributors to Bitcoin and Lightning. The previous Chaincode Residency (focused on Lightning Network applications) was covered in Newsletter #21 .

The third edition of this annual conference (formerly named BPASE) included more than two dozen presentations across three days. We found the following topics especially interesting from a Bitcoin perspective, although we encourage anyone who wants to learn more to look at the transcripts provided by Bryan Bishop or the videos provided by the organizers (day 1, day 2, day 3).

● Accumulators for blockchains presented by Benedikt Bünz (transcript, video). Bitcoin full nodes maintain a ledger (called the UTXO set) that stores the ownership information for every currently-spendable grouping of bitcoins. Currently, that ledger contains over 50 million entries and uses about three gigabytes of disk space. This allows nodes who receive a transaction to ensure the bitcoins being spent exist in the UTXO set, retrieve the ownership information for those bitcoins, and verify that information against the signature and other witness data provided in the transaction. But what if we also asked the spender to provide a copy of the ownership information in their transaction along with a cryptographic proof that the information is actually in the UTXO set? In that case, we wouldn’t need to store the whole set, we’d only need to store a commitment to a set we knew was accurate and that could be referenced by accurate proofs. RSA accumulators are one idea (among several others) for how to create that commitment and its related proofs. Using an accumulator, the size of the UTXO commitment that nodes would store on disk would be tiny compared to the full state. Transactions would increase in size due to needing to provide ownership data and a proof that they were part of the current UTXO set, but the size increase would be modest (assuming current typical transactions, about 70 bytes of ownership information per input plus a proof that could be aggregated down to about 325 bytes per block). Other considerations affect the suitability of accumulators to the task, including being relatively new to cryptography, requiring either a well-studied trusted setup or a more novel untrusted setup, and potentially making blocks take longer to verify than the current system given that accumulator verification is about 100x slower than alternative systems using merkle trees. In a new development compared to a previous version of this talk given at Scaling Bitcoin 2018, the speaker describes a potential major speedup to practical verification. In summary, RSA accumulators remain an interesting area of investigation into how to reduce full node requirements for storing and quickly accessing the UTXO set. This may not be particularly important now, when the UTXO set is relatively small and fast, but it could make it easier to support initiatives that would change how people use the UTXO set in the future. For example: If accumulator-based proofs can indeed be verified quickly, they could allow the UTXO set size to grow considerably (perhaps because of a block size increase) while still ensuring that miners can verify transaction inputs quickly enough to minimize the use of spy mining or the production of stale blocks.

Software that uses trusted UTXO sets with newly-started nodes to avoid the cost and delay of downloading and verifying the full block chain (an option some software already provides) could reduce those costs and delays even further by replacing the multi-gigabyte UTXO set with an accumulator a million times smaller. It should be possible for eager experimenters to explore the use of accumulators in Bitcoin without changing any consensus rules, such as Tadge Dryja has been doing with his similar Utreexo system based on merkle trees.

● Miniscript presented by Pieter Wuille (transcript, video, slides). Imagine you had a Bitcoin script that gave control over your bitcoins to your lawyer a year after you last moved them, in case he needed to distribute them to your heirs. That’s an easy script to write. But what if someone then asked you to join a 3-of-4 multisig contract where you’d be one of parties holding some funds. How hard would it be for you to insert your existing policy into their generic multisig contract and be sure you haven’t broken anything? That’s the question asked by this speaker, and his answer is the composable policy language miniscript. Miniscript is a subset of the full Bitcoin Script language that focuses on just a few features such signatures, times, and hashes plus operators for combining them, such as and, or, or threshold. It’s compact, easy to read, and will compile down to the most efficient script implementing a given policy. From an existing script compatible with its operations, it will also reverse it back into a policy for easy review. By design, it uses a similar vocabulary to the output script descriptors Wuille has been implementing in Bitcoin Core and it can help the updater or finalizer in a BIP174 PSBT workflow figure out who needs to sign next or whether all data for finalizing the script has been received. Looking at the problem posed in the introduction paragraph, we can define the example personal spending policy as either you providing a signature for your compressed pubkey, pk(C) , or your lawyer waiting for a year, time(<seconds>) , and then providing a signature for his own compressed pubkey. We combine these branches with an asymmetric “or,” aor , to reduce the witness data required when following the first branch. aor(pk(C),and(time(31536000),pk(C))) We can define the generic 3-of-4 multisig policy similarly using compressed pubkeys ( C ): multi(3,C,C,C,C) A functionally equivalent policy that allows more flexibility would use the threshold operation: thres(3,pk(C),pk(C),pk(C),pk(C)) This allows you to just replace one of the public keys with your personal policy: thres(3,pk(C),pk(C),pk(C),aor(pk(C),and(time(31536000),pk(C)))) When compiled, the result is the following script: [pk] CHECKSIG SWAP [pk] CHECKSIG ADD SWAP [pk] CHECKSIG ADD TOALTSTACK IF [pk] CHECKSIGVERIFY 0x8033e101 CHECKSEQUENCEVERIFY 0NOTEQUAL ELSE [pk] CHECKSIG ENDIF FROMALTSTACK ADD 3 EQUAL A final benefit of miniscript is that it should allow a policy written today to be automatically translated into a structure that makes optimal use of MAST, taproot, or other possible Bitcoin protocol upgrades. That means, as the Bitcoin protocol advances, the user or developer who invested time into crafting a policy won’t have to redo their work in order to continue using it with newer technology. The speaker has provided an interactive Javascript demo of the miniscript compiler, and he and his collaborators also have a Rust language version of the compiler they plan to release as open source soon.