Last week in bitcoin (August 18 - 23)
Highlights from the bitcoin developer ecosystem...
Hi Insiders. This is Tuma, open source reporter from the Insider Edition. I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:
LDK Node v0.6.2 has been released to fix an issue with TLS.
During the LDK developer call, on Monday 18th, developer Elias Rohrer announced the release of the new patch version for LDK Node, the ready-to-go LN node implementation that leverages both LDK and BDK.
This releases fixes an issue when synching to a TLS-enabled Electrum Server, which would hit a panic whenever a node would try to first access an Electrum server behind an ssl:// address. The issue was fixed by explicitly installing a default CryptoProvider, as requested by the rustls library.
Core Lightning v25.09 release candidate version is out, preparing the way for the 25.09 release.
During the CLN developer call, on Monday 18th, Madeline announced a freeze on development for the new version of Core Lightning and the launch of the release process starting from the rc1. This is a pre-release and is open to everyone for testing and sharing feedback.
The new version brings many updates, such as improvements for splicing for better integration with other Lightning implementations, (i.e. Eclair’s) the migration of the bookkeeping plugin inside the main software, the possibility to pay to BIP353 human-readable addresses, and more. Check the release notes for the complete list of updates.
ISSUE147 in StratumV2 specifications repository has been closed without merging. This issue highlighted a possible redundant field in the SetNewPrevHash message, but was not merged for a very interesting motive.
The SetNewPrevHash message is sent by the pool to individual miners to signal that a new block has been found, so as to update them on the new hash of the previous block, adjustment in difficulties, etc. While working on ISSUE130, Stratum developers noticed two fields, target and nBits, which appeared redundant.
While both refer to the difficulty target for a block, the former value is usually set to a lower level than the latter. This is done to allow for the so-called weak-block based block propagation, an optimization in which nodes receive blocks that do not meet the real difficulty requirements to allow them to cache the content of the block beforehand, so that whenever the actual block is propagated, they would require less work to verify it.
After some discussion on GitHub, during the weekly call on Tuesday 19th developers decided to close the issue without merging, due to the fact that the two fields, though similar, have different goals.
Payjoin is preparing for 1.0 milestone, which will bring Payjoin v2 into production. Although there is no release date yet, this marks an important step towards the release of the asynchronous version of the famous privacy-preserving protocol.
During the weekly call, on Monday 18th, Payjoin developer Dan Gould called for the feature freeze to move toward the 1.0 milestone for the project. This milestone will bring to production the v2 implementation for the Payjoin protocol, based on the recently-merged BIP77 and improving the previous Payjoin v1, based on BIP78.
The first version of the protocol requires the receiver to host a server where the sender can submit a PSBT. The two parties need to be online at the same time to do this. The new implementation eliminates these requirements by shifting the need to run a server to a untrusted third party, called Payjoin directory. This server stores pending transactions and forwards them to and from the receiver when one of the parties comes back online. This improves privacy by leveraging a protocol called Oblivious HTTP (OHTTP), which hides important metadata such as the IP address of the actors involved.
What’s cool about the tech: A stable version of the improved implementation of Payjoin can help enhancing the privacy on Bitcoin.