-
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
7 changed files
with
169 additions
and
8 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/delvingbitcoin/Oct_2024/3396_Bitcoin-PIPEs-Covenants-on-Bitcoin-Without-Soft-Fork.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>Bitcoin PIPEs: Covenants on Bitcoin Without Soft Fork</title> | ||
| <updated>2024-10-23T02:20:17.717786+00:00</updated> | ||
| <author> | ||
| <name>GaloisField2718 2024-10-22 13:52:11.352000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Bitcoin PIPEs: Covenants on Bitcoin Without Soft Fork</title> | ||
| <updated>2024-10-23T02:20:17.717818+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/bitcoin-pipes-covenants-on-bitcoin-without-soft-fork/1195/2" rel="alternate"/> | ||
| <summary>The inquiries revolve around the intricacies of implementing Zero-Knowledge Proofs (ZKPs) within a PIPE setup, specifically focusing on the verification processes and the integration of ZKPs with covenants in blockchain technology. The discussion opens with a question about the creation of ZKPs to prove computation execution before covenants are applied, highlighting that this verification occurs off-chain. It then explores the possibility of implementing a ZKP covenant as a PIPE address, which could potentially allow for on-chain verification of setups for other PIPE covenants, transitioning from an off-chain to an on-chain verification process. | ||
|
|
||
| Further, the email touches upon the technical mechanics of pushing ciphertext in a blockchain environment, questioning whether it follows a specific sequence of operations or if it involves commit-reveal mechanisms with data pushed at the end. This point delves into the granularity of how data encryption and transmission are handled within the proposed system. | ||
|
|
||
| Another significant aspect raised is the paper's assertion that CAT PIPEs should employ an optimistic verification of commitment schemes, questioning why this approach is recommended exclusively for CAT PIPEs. This leads to concerns about resolving disputes in transactions that have already been executed on-chain, suggesting a need for mechanisms to address potential conflicts post-transaction. | ||
|
|
||
| Lastly, there's curiosity regarding the practical application of the theoretical concepts discussed in the paper, specifically asking whether there has been any attempt to implement the algorithms outlined. This inquiry underscores a desire to understand the feasibility and real-world applicability of the proposed systems and methodologies beyond their theoretical foundation.</summary> | ||
| <published>2024-10-22T13:52:11.352000+00:00</published> | ||
| </entry> | ||
| </feed> |
22 changes: 22 additions & 0 deletions
22
...vingbitcoin/Oct_2024/3397_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.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>Proposing a P2QRH BIP towards a quantum resistant soft fork</title> | ||
| <updated>2024-10-23T02:19:22.095045+00:00</updated> | ||
| <author> | ||
| <name>conduition 2024-10-22 19:51:57.030000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Proposing a P2QRH BIP towards a quantum resistant soft fork</title> | ||
| <updated>2024-10-23T02:19:22.095081+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956/3" rel="alternate"/> | ||
| <summary>The push for quantum resistance in the realm of cryptography, particularly concerning Bitcoin, reflects a proactive approach to a potential future challenge posed by quantum computing. The discussion highlights the importance of considering long-term solutions today, even though the emergence of large-scale quantum computers might seem distant. It is anticipated that our understanding and development of post-quantum signature schemes will evolve significantly in the years leading up to the realization of such quantum computers. This evolution underpins the caution against prematurely standardizing soft-forks for quantum-resistant addresses based on current post-quantum signing algorithms, which may not stand the test of time or technological advancement. | ||
|
|
||
| A proposed strategy to transition Bitcoin users to post-quantum secure keys involves a series of steps that do not require immediate consensus changes within the Bitcoin network. This method suggests deriving a secret key from a seed value using a hash-based signature algorithm (HBS), then computing a corresponding HBS public key. If necessary, this key could be hashed into a 32-byte value to fit certain requirements. This public key (or its hash) would serve as an secp256k1 secret key, allowing for the computation of a secp256k1 public key used in standard Bitcoin transactions. The innovative aspect of this approach lies in its preparation for a future where quantum computing could compromise current cryptographic standards. By the time a viable quantum computer becomes imminent, Bitcoin could implement a consensus rule change to disable ECDSA/Schnorr signatures in favor of requiring signatures from the inner HBS key. This flexibility also extends to the possibility of the inner key endorsing another post-quantum signing key for transaction signatures, accommodating algorithms that have yet to be developed. | ||
|
|
||
| Furthermore, the adoption of [Winternitz OTS](https://conduition.io/cryptography/quantum-hbs/Winternitz-One-Time-Signatures-WOTS), a one-time signature algorithm, as part of this transitional framework underscores an emergency fallback mechanism. This choice is commended for its pragmatic approach to dealing with the uncertainties of quantum advancements without necessitating immediate consensus or scalability modifications within the Bitcoin network. The eventual need for a first-class quantum-resistant address format is acknowledged, pointing towards a future requirement for more scalable and secure post-quantum algorithms. However, the current stance advocates for the standardization of the fallback HBS key format as a client-side adaptation, deferring consensus changes until the advent of quantum computing necessitates such a shift. This cautious yet forward-thinking strategy aims to provide the cryptographic community with ample time to refine and develop post-quantum algorithms that are both efficient and resilient against the test of time and technological progress.</summary> | ||
| <published>2024-10-22T19:51:57.030000+00:00</published> | ||
| </entry> | ||
| </feed> |
20 changes: 20 additions & 0 deletions
20
...lvingbitcoin/Oct_2024/3398_Updates-to-the-Gossip-1-75-proposal-post-LN-summit-meeting.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,20 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Updates to the Gossip 1.75 proposal post LN summit meeting</title> | ||
| <updated>2024-10-23T02:20:44.908102+00:00</updated> | ||
| <author> | ||
| <name>harding 2024-10-22 20:21:13.939000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Updates to the Gossip 1.75 proposal post LN summit meeting</title> | ||
| <updated>2024-10-23T02:20:44.908135+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/updates-to-the-gossip-1-75-proposal-post-ln-summit-meeting/1202/2" rel="alternate"/> | ||
| <summary>The current discussion revolves around the necessity for updates to a specific proposal. For those interested in reviewing or contributing further, the proposal in question is accessible through GitHub at [this link](https://github.com/lightning/bolts/pull/1059). This document appears to be under active consideration and requires modifications to align with the project's goals or standards. The call for updates suggests that there are areas within the proposal that may not meet the current requirements or expectations set by the community or project leads. | ||
|
|
||
| Contributors and stakeholders are encouraged to examine the details of the proposal via the provided URL. Engagement from the community is crucial in refining and enhancing the proposal to ensure it meets the necessary criteria for acceptance or implementation. The collaborative nature of this process underscores the importance of collective input and revisions.</summary> | ||
| <published>2024-10-22T20:21:13.939000+00:00</published> | ||
| </entry> | ||
| </feed> |
29 changes: 29 additions & 0 deletions
29
...delvingbitcoin/Oct_2024/combined_Bitcoin-PIPEs-Covenants-on-Bitcoin-Without-Soft-Fork.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,29 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Bitcoin PIPEs: Covenants on Bitcoin Without Soft Fork</title> | ||
| <updated>2024-10-23T02:20:37.267552+00:00</updated> | ||
| <author> | ||
| <name>GaloisField2718 2024-10-22 13:52:11.352000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>MishaKomarov . 2024-10-14 20:27:07.532000+00:00</name> | ||
| </author> | ||
| <link href="delvingbitcoin/Oct_2024/3396_Bitcoin-PIPEs-Covenants-on-Bitcoin-Without-Soft-Fork.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3361_Bitcoin-PIPEs-Covenants-on-Bitcoin-Without-Soft-Fork.xml" rel="alternate"/> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>2</id> | ||
| <title>Combined summary - Bitcoin PIPEs: Covenants on Bitcoin Without Soft Fork</title> | ||
| <updated>2024-10-23T02:20:37.267601+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/bitcoin-pipes-covenants-on-bitcoin-without-soft-fork/1195/2" rel="alternate"/> | ||
| <summary>The discussion centers around the innovative implementation of covenants in Bitcoin through the use of Polynomial Inner Product Encryption (PIPE), which does not necessitate a soft fork, enhancing the blockchain's capabilities by allowing for advanced spending rules. These rules can specify conditions under which coins can be spent, such as restricting transactions to certain addresses or after particular conditions are met. This advancement introduces the potential for native verification of Zero-Knowledge Proofs (ZKPs), creation of native tokens with complex behaviors, and mechanisms for restaking to secure other networks, thereby significantly increasing Bitcoin's versatility without altering its core protocol. | ||
|
|
||
| Covenants, enabled by cryptographic techniques like PIPE, extend Bitcoin's functionality to include more sophisticated transaction structures, efficient batch transactions, scalable cryptographic proofs, and applications such as Zero-Knowledge Rollups (zkRollups) which consolidate multiple computations into a single proof. The employment of opcodes like `OP_CAT` and `OP_CTV` enhances security, privacy, and efficiency within Bitcoin's ecosystem by supporting advanced transaction capabilities. Additionally, restaking mechanisms demonstrate the covenant's potential to facilitate staking-like activities directly on the Bitcoin blockchain. | ||
|
|
||
| Polynomial Inner Product Encryption (PIPE) underpins these developments, offering a full-hiding multi-input inner product encryption scheme that allows the creation of predicates. These predicates authorize Bitcoin transactions based on encrypted signing keys if specific logical conditions are met, without disclosing the key itself. This method effectively simulates missing opcodes and executes complex logic in transactions without necessitating protocol upgrades or soft forks. The architecture of Bitcoin PIPE involves a setup phase where a functionality is defined, a zero-knowledge proof is created, and a PIPE (Covenant) is submitted as a Taproot transaction into Bitcoin, ensuring secure and condition-adherent transaction submissions. | ||
|
|
||
| Bitcoin PIPEs minimize trust assumptions, requiring only a one-time trusted setup to become virtually trustless, thus reducing dependence on custodians, bridging, or sidechains. This technology aligns with Bitcoin's original principles while broadening its functional scope for more intricate financial and contractual applications, all without compromising security or simplicity. The inclusion of a [research paper](https://www.allocin.it/uploads/placeholder-bitcoin.pdf) further elucidates the technical foundations and possible applications of Bitcoin PIPEs, highlighting a significant progression in Bitcoin's evolution towards accommodating complex, secure, and flexible transaction rules without consensus on new opcodes or soft forks.</summary> | ||
| <published>2024-10-22T13:52:11.352000+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.