|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #294' |
| 3 | +permalink: /en/newsletters/2024/03/20/ |
| 4 | +name: 2024-03-20-newsletter |
| 5 | +slug: 2024-03-20-newsletter |
| 6 | +type: newsletter |
| 7 | +layout: newsletter |
| 8 | +lang: en |
| 9 | +--- |
| 10 | +This week's newsletter FIXME |
| 11 | + |
| 12 | +## News |
| 13 | + |
| 14 | +- **BIP324 proxy for light clients:** Sebastian Falbesoner |
| 15 | + [posted][falbesoner bip324] to Delving Bitcoin to announce a TCP proxy |
| 16 | + for translating between the version 1 (v1) Bitcoin P2P protocol and |
| 17 | + the [v2 protocol][topic v2 p2p transport] defined in [BIP324][]. This |
| 18 | + is especially intended to allow light client wallets written for v1 to |
| 19 | + take advantage of v2's traffic encryption. |
| 20 | + |
| 21 | + Light clients typically only announce transactions belonging to their |
| 22 | + own wallets, so anyone capable of eavesdropping on an unencrypted v1 |
| 23 | + connection can reasonably conclude that a transaction sent by a light |
| 24 | + client belonged to someone using the origin IP address. When v2 |
| 25 | + encryption is used, only the full nodes receiving the transaction will |
| 26 | + be able to definitively identify it as originating from the light |
| 27 | + client's IP address, assuming none of the light client connections is |
| 28 | + subject to a man-in-the-middle attack (which is possible to detect in |
| 29 | + some cases and which [later upgrades][topic countersign] may |
| 30 | + automatically defend against). |
| 31 | + |
| 32 | + Falbesoner's initial work pulls together BIP324 functions written in |
| 33 | + Python for Bitcoin Core's testing suite, which results in a proxy that |
| 34 | + is "terribly slow and vulnerable to side-channel attacks [and] not |
| 35 | + recommended to use it for anything but tests right now". However, he |
| 36 | + is working on rewriting the proxy in Rust and may also make some or |
| 37 | + all of its functions available as a library for light clients or other |
| 38 | + software that wants to natively support the v2 Bitcoin P2P protocol. |
| 39 | + |
| 40 | +- **Overview of BTC Lisp:** Anthony Towns [posted][towns lisp] to |
| 41 | + Delving Bitcoin about his experiments over the past couple years |
| 42 | + creating a variant of the [Lisp][] language for Bitcoin, called BTC |
| 43 | + Lisp. See Newsletters [#293][news293 lisp] and [#191][news191 lisp] |
| 44 | + for previous discussions. The post goes into significant detail; we |
| 45 | + encourage anyone interested in the idea to read it directly. We will |
| 46 | + briefly quote from its _conclusion_ and _future work_ sections: |
| 47 | + |
| 48 | + "[BTC Lisp] can be a little expensive on-chain, but it seems like you |
| 49 | + can do pretty much anything [...] I don’t think implementing either a |
| 50 | + Lisp interpreter or the bucket of opcodes that would need to accompany |
| 51 | + it is too hard [but] it is pretty annoying to write Lisp code without |
| 52 | + a compiler translating from a higher level representation down to the |
| 53 | + consensus-level opcodes, [though] that seems solvable. [T]this could |
| 54 | + be taken further [by] implementing a language like this and deploying |
| 55 | + it on signet/inquisition." |
| 56 | + |
| 57 | + Russell O'Connor, developer of the [Simplicity][topic simplicity] |
| 58 | + language that may also one day be considered as an alternative |
| 59 | + consensus scripting language, [replied][oconnor lisp] with some |
| 60 | + comparisons between Bitcoin's current Script language, Simplicity, and |
| 61 | + Chia/BTC Lisp. He concludes, "Simplicity and the [Chia Lisp Virtual |
| 62 | + Machine] clvm are both low level languages that are meant to be easy |
| 63 | + for machines to evaluate, which causes tradeoffs that make them hard |
| 64 | + for humans to read. They are intended to be the compiled from some |
| 65 | + different, human-readable, non-consensus-critical language. |
| 66 | + Simplicity and the clvm are different ways of expressing the same old |
| 67 | + things: fetching data from an environment, tupling up bits of data, |
| 68 | + running conditional statements, and a whole bunch of primitive |
| 69 | + operations of some sorts. [...] Since we want this [split between |
| 70 | + efficient low-level consensus language and high-level non-consensus |
| 71 | + comprehensible language] regardless, the details of the low-level |
| 72 | + language become somewhat less important. I.e., with some effort, your |
| 73 | + high level BTC lisp language could probably be translated/complied to |
| 74 | + Simplicity [...] Similarly, wherever the design of [Simplicity-based] |
| 75 | + Simphony [high-level non-consensus language] ends up, it can probably |
| 76 | + be translated/complied your low level BTC lisp language, with each |
| 77 | + translator/compiler language pair offering different potential |
| 78 | + complexity/optimization opportunities." |
| 79 | + |
| 80 | +## Changes to services and client software |
| 81 | + |
| 82 | +*In this monthly feature, we highlight interesting updates to Bitcoin |
| 83 | +wallets and services.* |
| 84 | + |
| 85 | +FIXME:bitschmidty |
| 86 | + |
| 87 | +## Releases and release candidates |
| 88 | + |
| 89 | +*New releases and release candidates for popular Bitcoin infrastructure |
| 90 | +projects. Please consider upgrading to new releases or helping to test |
| 91 | +release candidates.* |
| 92 | + |
| 93 | +- [Bitcoin Core 26.1rc1][] is a release candidate for a maintenance release |
| 94 | + of the network's predominant full node implementation. |
| 95 | + |
| 96 | +- [Bitcoin Core 27.0rc1][] is a release candidate for the next major |
| 97 | + version of the network's predominant full node implementation. |
| 98 | + |
| 99 | +<!-- FIXME:harding to update on Tuesday --> |
| 100 | + |
| 101 | +## Notable code and documentation changes |
| 102 | + |
| 103 | +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core |
| 104 | +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], |
| 105 | +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet |
| 106 | +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay |
| 107 | +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement |
| 108 | +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], |
| 109 | +[Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana |
| 110 | +repo]._ |
| 111 | + |
| 112 | +*Note: the commits to Bitcoin Core mentioned below apply to its master |
| 113 | +development branch and so those changes will likely not be released |
| 114 | +until about six months after the release of the upcoming version 27.* |
| 115 | + |
| 116 | +- [Bitcoin Core #27375][] adds support to the `-proxy` and `-onion` |
| 117 | + feature for using Unix domain sockets rather than local TCP ports. |
| 118 | + Sockets can be faster than TCP ports and offer different security |
| 119 | + tradeoffs. |
| 120 | + |
| 121 | +- [Bitcoin Core #27114][] allows adding "in" and "out" to the |
| 122 | + `whitelist` configuration parameter to give special access to |
| 123 | + particular _incoming_ and _outgoing_ connections. By default, a peer |
| 124 | + listed in the whitelist will only receive special access when it |
| 125 | + connects to the user's local node (an incoming connection). By |
| 126 | + specifying "out", the user can now ensure a peer receives special |
| 127 | + access if the local node connects to it, such as by the user calling |
| 128 | + the `addnode` RPC. |
| 129 | + |
| 130 | +- [Bitcoin Core #29306][] adds [sibling eviction][topic sibling |
| 131 | + eviction] for transactions descended from an unconfirmed [v3 |
| 132 | + parent][topic v3 transaction relay]. This can provide a satisfactory |
| 133 | + alternative to [CPFP carve-out][topic cpfp carve out], which is |
| 134 | + currently used by [LN anchor outputs][topic anchor outputs]. V3 |
| 135 | + transaction relay is not currently enabled for mainnet and (as noted |
| 136 | + above) this PR is merged into the development branch that is not |
| 137 | + expected to be released for about six months. |
| 138 | + |
| 139 | +- [LND #8310][] allows the `rpcuser` and `rpcpass` (password) |
| 140 | + configuration parameters to be retrieved from the Unix environment. |
| 141 | + This can allow, for example, a `lnd.conf` file to be managed using a |
| 142 | + non-private revision control system without storing the private |
| 143 | + username and password. |
| 144 | + |
| 145 | +- [Rust Bitcoin #2458][] adds support for signing [PSBTs][topic psbt] |
| 146 | + for transactions that include taproot inputs. |
| 147 | + |
| 148 | +{% assign day_after_posting = page.date | date: "%s" | plus: 86400 | date: "%Y-%m-%d 14:00" %} |
| 149 | +{% include snippets/recap-ad.md when=day_after_posting %} |
| 150 | +{% include references.md %} |
| 151 | +{% include linkers/issues.md v=2 issues="27375,27114,29306,8310,2458" %} |
| 152 | +[bitcoin core 26.1rc1]: https://bitcoincore.org/bin/bitcoin-core-26.1/ |
| 153 | +[Bitcoin Core 27.0rc1]: https://bitcoincore.org/bin/bitcoin-core-27.0/test.rc1/ |
| 154 | +[topic sibling eviction]: https://example.com/#FIXME-harding-to-write-topic-page |
| 155 | +[lisp]: https://en.wikipedia.org/wiki/Lisp_(programming_language) |
| 156 | +[news293 lisp]: /en/newsletters/2024/03/13/#overview-of-chia-lisp-for-bitcoiners |
| 157 | +[news191 lisp]: /en/newsletters/2022/03/16/#using-chia-lisp |
| 158 | +[falbesoner bip324]: https://delvingbitcoin.org/t/bip324-proxy-easy-integration-of-v2-transport-protocol-for-light-clients-poc/678 |
| 159 | +[towns lisp]: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682 |
| 160 | +[oconnor lisp]: https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682/7 |
0 commit comments