-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
11 changed files
with
240 additions
and
33 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
24 changes: 24 additions & 0 deletions
24
static/bitcoin-dev/Nov_2024/m53078da2568e93a70d05c6be71ec0951c3a5786f_OP-PAIRCOMMIT.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>0</id> | ||
| <title>OP_PAIRCOMMIT</title> | ||
| <updated>2024-11-15T02:28:24.926949+00:00</updated> | ||
| <author> | ||
| <name>moonsettler 2024-11-15 00:00:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>0</id> | ||
| <title>OP_PAIRCOMMIT</title> | ||
| <updated>2024-11-15T02:28:24.926981+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/xyv6XTAFIPmbG1yvB0l2N3c9sWAt6lDTG-xjIbogOZ-lc9RfsFeJ-JPuXuXKzVea8T9TztlCvSrxZOWXKCwogCy9tqa49l3LXjF5K2cLtP4=@protonmail.com/T/#u#m53078da2568e93a70d05c6be71ec0951c3a5786f" rel="alternate"/> | ||
| <summary>A new opcode, `OP_PAIRCOMMIT`, is proposed to be added to tapscript as part of the LNhance opcode family. This family includes CTV, CSFS, IKEY, and PC, aimed at enabling efficient rebindable channels adaptable to various covenant tree or channel factory constructions. The `OP_PAIRCOMMIT` operation functions by removing the top two values from the stack, computing a "PairCommit" tagged SHA256 hash of these elements, and pushing this commitment back onto the stack. This proposal is detailed in a [GitHub gist](https://gist.github.com/moonsettler/d7f1fb88e3e54ee7ecb6d69ff126433b) and has been submitted as PR: 1699 to the [bitcoin/bips repository](https://github.com/bitcoin/bips). | ||
|
|
||
| The introduction of `OP_PAIRCOMMIT` addresses the dependency on the CAT opcode for constructing efficient LN-Symmetry. If CAT were available or its activation imminent, the necessity for `OP_PAIRCOMMIT` might not be as critical. However, given the current circumstances, `OP_PAIRCOMMIT` offers a targeted solution without the broader implications associated with CAT, such as enabling the inspection of sighashes on the stack and ancestor transactions, which could lead to novel two-way peg mechanisms. | ||
|
|
||
| `OP_PAIRCOMMIT` specifically aims to minimize the number of SHA256 iterations required in its primary use case, thereby optimizing for LN-Symmetry. This optimization is particularly relevant in scenarios involving unilateral closes, where channel peers must reconstruct the spend script of an intermediate state. By employing `OP_CHECKTEMPLATEVERIFY`, `OP_PAIRCOMMIT`, `OP_INTERNALKEY`, and `OP_CHECKSIGFROMSTACK` in sequence, a rebindable channel that remains optimal can be achieved. The opcode repurposes opcode 205 (formerly `OP_SUCCESS`) for its functionality, ensuring backward compatibility through a soft-fork deployment strategy. | ||
|
|
||
| A reference implementation of the proposal is available for review at the [LNhance bitcoin repository](https://github.com/lnhance/bitcoin/pull/6/files). This initiative has garnered input and support from several contributors, including Jeremy Rubin, Brandon Black, Salvatore Ingala, and Anthony Towns, and is licensed under the BSD-3-Clause license. Further exploration and discussion regarding `OP_PAIRCOMMIT` and its implications for Bitcoin's scripting capabilities are encouraged within the community.</summary> | ||
| <published>2024-11-15T00:00:00+00:00</published> | ||
| </entry> | ||
| </feed> |
22 changes: 22 additions & 0 deletions
22
...901b1f12eaea319b5ba6982357905be04bd_Broken-links-to-the-previous-mailing-list-archive.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Broken links to the previous mailing list archive</title> | ||
| <updated>2024-11-15T02:27:42.000192+00:00</updated> | ||
| <author> | ||
| <name>Andrew Poelstra 2024-11-14 14:30:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Broken links to the previous mailing list archive</title> | ||
| <updated>2024-11-15T02:27:42.000221+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/CABaSBaz13bUoHCupXYhmX+yS0dn89f80yx8ZD3uO5-1RiLZJCQ@mail.gmail.com/T/#ma5834901b1f12eaea319b5ba6982357905be04bd" rel="alternate"/> | ||
| <summary>In the realm of Bitcoin development, the challenge of maintaining an accessible and reliable email archive has proven to be significant. The absence of a centralized entity like a "Bitcoin mailing list" means there's no straightforward mechanism for purchasing domain or hosting services specifically for this purpose. Instead, the responsibility falls upon community members who volunteer their resources to sustain these archives, a solution that is not only temporary but also fraught with potential issues. This decentralized approach mirrors current efforts, such as those observed with the new gnusha.org archives, which rely on communal support rather than a dedicated organization. | ||
|
|
||
| The theoretical solution of establishing an organization endowed with sufficient funds to manage such an archive faces practical obstacles. Despite the potential benefits of having a dedicated sysadmin funded by an endowment, the likelihood of finding an individual or group willing to commit substantial financial resources for the sake of preserving email archives remains low. This skepticism is further justified by past experiences, including issues faced with Linux Foundation servers and the vulnerability of even well-intentioned organizations to cyber threats, as demonstrated by the recent hack of the Internet Archive. | ||
|
|
||
| These challenges underscore the fragility of relying on third-party organizations for the preservation of information. Even when an organization like the Linux Foundation, which shares a common ideology with the Bitcoin community regarding access to information, offers its servers, the reliability of such solutions is not guaranteed. This situation emphasizes the broader dilemma within the tech community about how best to ensure the longevity and accessibility of valuable digital archives in the face of technical, financial, and security challenges.</summary> | ||
| <published>2024-11-14T14:30:00+00:00</published> | ||
| </entry> | ||
| </feed> |
22 changes: 22 additions & 0 deletions
22
...-dev/Nov_2024/mfe9c974e575666fb49b475a9d6fa184bf8f55ab1_CHECKSIGFROMSTACK-VERIFY-ADD-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>0</id> | ||
| <title>CHECKSIGFROMSTACK(VERIFY/ADD)</title> | ||
| <updated>2024-11-15T02:28:08.861553+00:00</updated> | ||
| <author> | ||
| <name>Brandon Black 2024-11-14 22:02:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>0</id> | ||
| <title>CHECKSIGFROMSTACK(VERIFY/ADD)</title> | ||
| <updated>2024-11-15T02:28:08.861583+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/ZzZziZOy4IrTNbNG@console/T/#u#mfe9c974e575666fb49b475a9d6fa184bf8f55ab1" rel="alternate"/> | ||
| <summary>The ongoing discussions around the CHECKSIGFROMSTACK (CSFS) Bitcoin Improvement Proposal (BIP) bring to light two primary considerations that are currently under debate. The first issue revolves around whether to include the CHECKSIGFROMSTACKVERIFY (CSFSV) opcode in pre-tapscript versions. Proponents argue that its compatibility with NOP forking justifies its inclusion, especially since it maintains consistency with CTV (CHECKTEMPLATEVERIFY), which is designed as a NOP compatible upgrade. This approach would enable Schnorr signatures to be utilized across earlier script versions for specific applications, potentially enhancing the utility and flexibility of these scripts. However, there's an opposing viewpoint suggesting that without a clear, significant benefit, such as the case presented by bare CTV for earlier script versions, the inclusion of CSFSV might not be justified. The concern here centers on the efficient use of limited NOPs for extending Schnorr signature commitments to older scripts, questioning the value of this allocation. | ||
|
|
||
| The second point of discussion focuses on the potential addition of CHECKSIGFROMSTACKADD (CSFSA). This proposal emerges from the recognition that if script multisig becomes a common method for verifying signatures on stack data, CSFSA could streamline the script-writing process, reducing the weight units (WU) required per key. Although the development and standardization of MuSig2 and FROST suggest that script multisig may not become the predominant application for these opcodes, the argument for including CSFSA hinges on the availability of OP_SUCCESSes. Allocating one for CSFSA is seen as a low-cost strategy for simplifying the creation of script multisigs, such as those enabled by miniscript, making them easier and less prone to errors. | ||
|
|
||
| Brandon's communication to the mailing list invites feedback on these deliberations, indicating a readiness to adapt the BIP and implementations of CSFS(V/A) based on community input. This open invitation underscores the collaborative nature of Bitcoin protocol development, where diverse opinions are considered to refine and enhance proposals before formal adoption.</summary> | ||
| <published>2024-11-14T22:02:00+00:00</published> | ||
| </entry> | ||
| </feed> |
24 changes: 24 additions & 0 deletions
24
static/delvingbitcoin/Nov_2024/3514_Pluggable-Channel-Factories.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Pluggable Channel Factories</title> | ||
| <updated>2024-11-15T02:25:57.255527+00:00</updated> | ||
| <author> | ||
| <name>renepickhardt 2024-11-14 12:45:29.445000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Pluggable Channel Factories</title> | ||
| <updated>2024-11-15T02:25:57.255559+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/pluggable-channel-factories/1252/2" rel="alternate"/> | ||
| <summary>Exploring the innovative potential of channel factories in solving the "last mile problem" for Lightning Service Providers (LSPs), there's a notable interest in utilizing them as a practical solution. Channel factories, particularly when integrated with mechanisms like SuperScalar proposal VTXOs in Ark, present an intriguing approach to funding transactions for channels. This concept aligns with the broader vision of enhancing liquidity management and payment facilitation within the Lightning Network. | ||
|
|
||
| The technical intricacies of channel factories, however, pose certain challenges, especially concerning their visibility and operability within the network. Current guidelines, as outlined in [BOLT7](https://github.com/lightning/bolts/blob/aa5207aeaa32d841353dd2df3ce725a4046d528d/07-routing-gossip.md), highlight that channels within a factory are not observable on the blockchain, complicating their announcement and monitoring. This limitation underscores the necessity for adjustments or extensions to BOLT7 to accommodate the unique characteristics of channel factories effectively. | ||
|
|
||
| Further examination into the subject reveals a promising direction for integrating channel factories into the network's routing nodes, as detailed in the referenced research. The proposition suggests that for the Lightning Network to adequately support liquidity management and address payment requests, the incorporation of channel factories is essential. To achieve this, a refined protocol is proposed that would enable the creation and closure of such channels to be communicated and verified through a dedicated API. This would offer a structured method for nodes to acknowledge the existence and status of these specialized channels, thereby facilitating more seamless transaction processes. | ||
|
|
||
| In essence, the development and implementation of a protocol supporting pluggable channel factories could significantly enhance the operational dynamics of the Lightning Network. By providing a means for the secure and efficient establishment of channel factories, along with mechanisms for their monitoring and announcement, it is possible to advance the network's capabilities in managing liquidity and facilitating payments.</summary> | ||
| <published>2024-11-14T12:45:29.445000+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.