The following are AI generated summaries of the topics list for tonight’s meetup. Keep in mind that each article reflects the opinions and bias of its own author, and the LLM generated summary may introduce further inaccuracies.
A bathhouse in Brooklyn, New York, has generated controversy by using waste heat from Bitcoin mining rigs to heat its spa pools. The bathhouse, called Bathhouse, runs mining rigs that produce heat as a byproduct, which is then captured and used to heat the pools through a circulating system. This concept is similar to Deep Green's campaign in the UK, which heats swimming pools with heat from data centers. While some praise Bathhouse for finding a use for Bitcoin's energy waste, others criticize the inherent energy consumption of Bitcoin mining and question the transparency of the mining process. Additionally, New York has become increasingly hostile towards cryptocurrencies, passing a bill to ban crypto mining with fossil-derived electricity.
In a series of email exchanges and discussions on the bitcoin-dev mailing list, various individuals, including Joost Jager and Dave, have been exploring the benefits and potential use cases of the annex feature in Bitcoin transactions. The annex is a way to store additional data in a transaction without affecting its transaction ID or parent commit transaction's ID. One of the primary use cases discussed is the backing up of ephemeral signatures in time-locked vaults. By storing these signatures on the blockchain itself, the vault can always be "opened" even if the ephemeral signatures are lost. However, without the annex, this process is not as secure due to a circular reference problem. Joost Jager suggests that the annex could be used to solve this issue and make time-locked vaults more robust. Another benefit of the annex is its potential use as a publication space for collectibles. Using the annex as a way to sign and store collectible ownership information on the blockchain enables a clear chain of ownership for these assets. There are also discussions around the implementation of an opt-in annex and setting a maximum size limit for values in Bitcoin transactions. The opt-in annex would require every input to commit to an annex, even if it is empty, ensuring that existing multi-party protocols remain unaffected. However, concerns are raised about how this would impact current Taproot support on the Lightning side. Joost Jager proposes a policy that includes the opt-in annex requirement, the use of a Type-Length-Value (TLV) format defined in BIP #1381, and limiting the maximum size of the value to 256 bytes. However, it is noted that the current limit of 126 bytes is insufficient for certain vault applications that require storing multiple presigned transactions and other parameters.The discussions also touch on the safety of time-locked vaults and alternative solutions such as using a scriptpath or a widely-used decentralized protocol to store data without putting it on the chain. The issue of malleability vector is also addressed, with suggestions for potential solutions to prevent denial of entry into the mempool due to transaction bloat. Overall, the annex feature in Bitcoin transactions has the potential to enhance the security and functionality of various applications, including time-locked vaults and collectibles. However, there are still ongoing discussions and considerations regarding its implementation and potential impact on existing protocols and systems.
The author of the message reflects on their previous proposal for a new community process to specify covenants in the Bitcoin ecosystem. They highlight the goals of building a consistent framework for evaluating covenant proposals and expanding the consensus changes development process beyond Bitcoin Core. The author acknowledges complementary initiatives by others and provides an update on the Bitcoin Contracting Primitives Working Group, including monthly meetings and in-depth discussions. They express their personal conclusion that focusing on Lightning Network development is more critical for Bitcoin's survival. The author invites others to continue the maintenance and nurturing of the Bitcoin Contracting Primitives WG if they have the resources and commitment.
The message informs the reader about an exploit discovered by the LNbits team in their Lightning Network application. The exploit allowed an attacker to create fraudulent balances by manipulating invoices. The attacker inserted a payment hash from one invoice into another, tricking the system into treating them as the same. The backend processed the payment based on the manipulated invoice, resulting in the attacker receiving undeserved funds. The message emphasizes the need for developers of Lightning applications to be aware of such exploits and suggests using unique checking IDs or additional checks to prevent similar attacks. It also highlights the misconception surrounding the "payment hash" field in invoices, emphasizing that it is actually a "preimage" hash and does not commit to payment details. The message concludes by sharing the lessons learned from the exploit.
In recent discussions on the Lightning-dev mailing list, the topic of implementing self-payment support for Lightning Network (LN) node implementations has been raised. Currently, no LN node has this ability, which is seen as a significant limitation. The suggestion is to enable LN nodes to support self-payment of their own invoices, eliminating the need for separate short-circuit mechanisms like the one used in LNBits.The idea is that when a user requests a payment, the underlying LN implementation's standard requestpayment API would be called by platforms like LNBits. Similarly, when a user wants to review and pay an invoice, the pay API of the underlying implementation would be utilized. This approach simplifies the codebase of platforms like LNBits, reduces the need for frequent updates, and allows for easier adoption of new features.
Implementing self-payment support could add complexity to LN implementations, but it is believed that the benefits outweigh the drawbacks, especially considering the potential adoption of platforms like LNBits by various services. By avoiding the duplication of payment processing logic in both the underlying implementation and account management software, the security and efficiency of the LN ecosystem can be improved.In another development, LNBits disclosed an exploit that allowed attackers to create fraudulent balances by exploiting a quirk in how invoices are handled internally. This issue has been addressed in the latest version of LNBits, and users are advised to update their systems. The team believes that similar exploits may be possible in other LN applications, particularly those related to custodial wallets, payment processors, and account management software. The attack involved inserting the payment hash of one payment into a different payment, creating a malicious invoice that tricks the backend into treating it as a legitimate payment.
To mitigate such issues, backends should use unique "checking IDs" for internal payment lookups or implement additional checks to ensure invoice details have not been tampered with.This incident highlights the sophistication of LN-savvy attackers and the importance of implementing robust security measures in LN applications. It also emphasizes that the "payment hash" of an invoice should be referred to as a "preimage" hash, as it only commits to the preimage and not other payment details like amount or pubkey. Developers are urged to be aware of potential vulnerabilities and take appropriate measures to prevent similar attacks.In an email conversation, David A. Harding raises the question of whether LN node implementations should support self-payment of invoices. He suggests reaching out to the developers of these implementations to consider implementing this feature if they don't already have it. This could be a significant feature for custodial Lightning service providers, enhancing their capabilities. The lack of self-payment support in current LN nodes is seen as unfortunate, and its implementation is highly desirable.Overall, these discussions highlight the ongoing efforts to improve the functionality and security of the Lightning Network by implementing features like self-payment support and addressing vulnerabilities in invoice handling. Collaboration among developers and awareness of potential exploits are crucial for the growth and success of the LN ecosystem.