-
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
9 changed files
with
220 additions
and
0 deletions.
There are no files selected for viewing
33 changes: 33 additions & 0 deletions
33
...2024/combined_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.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,33 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - [BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination</title> | ||
| <updated>2024-12-16T02:44:28.929637+00:00</updated> | ||
| <author> | ||
| <name>Michael Cassano 2024-12-13 17:16:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>George Burke 2024-12-13 15:09:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Bitcoin Error Log 2024-12-12 19:52:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Dec_2024/mfdc986b87c9738216032a7c3f3824082d6452efb_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/mac276df3e06ac87ca7dfc22b28ecd0be33d056d0_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m0d898700e0c21764380a75952b3b901866b63713_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.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 - [BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination</title> | ||
| <updated>2024-12-16T02:44:28.929687+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/CAE2fw6tjVQQT4mpvec2kQg45eLS7VemzQgUfW7Pghdk_Si3PpA@mail.gmail.com/T/#u#m0d898700e0c21764380a75952b3b901866b63713" rel="alternate"/> | ||
| <summary>In a recent discourse within the Bitcoin development community, a novel proposal has been tabled that seeks to alter the conventional unit representation of Bitcoin. This proposition advocates for a radical departure from the current system, where one bitcoin is subdivided into 100 million base units (sats), each represented down to eight decimal places. The essence of the proposal is to recalibrate the unit definition so that the smallest indivisible unit in the Bitcoin protocol, currently known as "satoshi" or "sat," would henceforth be recognized as "one bitcoin." This change aims to simplify the currency's accounting system by eliminating decimals, thereby facilitating easier transaction processes and enhancing the overall comprehension of Bitcoin's value system. | ||
|
|
||
| The proponents of this change underscore several benefits designed to enhance user interaction with Bitcoin. One of the primary advantages includes simplifying mental calculations and reducing confusion associated with the decimal representation of Bitcoin values. By shifting to an integer-based display format, the proposal also seeks to preempt the necessity for introducing new fractional denominations as the currency gains wider adoption and its value increases. Furthermore, it addresses concerns related to unit bias and misinformation about Bitcoin’s divisibility which can affect new users' understanding and adoption. | ||
|
|
||
| Critically, the proposal contrasts itself with previous attempts to introduce new denominational units, such as BIP 176's "bits," arguing that these efforts fall short of resolving the fundamental issues of complexity and confusion due to their reliance on decimal points and multiple denominations. The push towards an integer-only display framework is presented as a more straightforward, intuitive, and enduring solution for denoting Bitcoin's value. | ||
|
|
||
| John Carvalho, the author behind this initiative, has made the draft proposal available on GitHub for community review at [this link](https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/BIP%2021Q.md). Carvalho emphasizes the importance of gathering feedback from the Bitcoin community to refine and possibly adopt this significant change in how Bitcoin's value is expressed, highlighting the critical role of consensus within the community in effecting such foundational adjustments.</summary> | ||
| <published>2024-12-13T17:16:00+00:00</published> | ||
| </entry> | ||
| </feed> |
31 changes: 31 additions & 0 deletions
31
static/bitcoin-dev/Dec_2024/combined_Trivial-QC-signatures-with-clean-upgrade-path.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,31 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Trivial QC signatures with clean upgrade path</title> | ||
| <updated>2024-12-16T02:45:01.484311+00:00</updated> | ||
| <author> | ||
| <name>Luke Dashjr 2024-12-15 23:54:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Matt Corallo 2024-12-15 21:42:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Dec_2024/md01effffbf854b3914226fd20a367713515a1244_Trivial-QC-signatures-with-clean-upgrade-path.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m8c9407a48d3358be40fb94ab512c3e72b95e17cc_Trivial-QC-signatures-with-clean-upgrade-path.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 - Trivial QC signatures with clean upgrade path</title> | ||
| <updated>2024-12-16T02:45:01.484349+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#m8c9407a48d3358be40fb94ab512c3e72b95e17cc" rel="alternate"/> | ||
| <summary>The discussion revolves around the preparedness of Bitcoin's transaction signature scheme for the eventuality of quantum computing (QC) breaking existing elliptic curve cryptography. It acknowledges that while the development of QCs capable of this feat might take a decade or more, based on NSA and other expert recommendations, the Bitcoin community should consider options today that would enable wallets to achieve QC security in the future. The fundamental assumption is that we will receive a reasonable warning before QCs reach a level capable of breaking current cryptographic defenses, given the immense resources required for such development. | ||
|
|
||
| A significant portion of the conversation critiques the feasibility of incorporating certain post-QC security assumptions into Bitcoin's consensus today due to potential future advancements in cryptography research. Among the considered options, hash-based signatures stand out as the only viable candidate for enhancing Bitcoin's transaction security in anticipation of QC threats. However, the deployment of such measures directly into Bitcoin's consensus faces practical challenges, including the reluctance to lock funds with a higher on-chain footprint cost for QC security preemptively. | ||
|
|
||
| Taproot is highlighted as offering a promising solution by allowing the construction of outputs containing an alternative spending condition that could secure transactions against QC threats without immediate changes to the consensus. This method involves preparing taproot outputs with a script-path alternative, which can be activated in response to the emergence of QC capabilities. The proposal suggests enabling this feature through the addition of an opcode, similar to OP_CHECKSIG, dedicated to verifying post-QC non-one-time-use signatures within taproot constructs. | ||
|
|
||
| Furthermore, the email touches on the complexities of opting into this scheme, considering the implications for on-chain identity and the potential for a supply shock resulting from unspent Bitcoin. An alternative suggestion proposes allowing key-path spends for wallets that employ a NUMS point proof, thus offering a way to opt out of the stricter QC-proof requirements without significantly impacting existing wallet operations. | ||
|
|
||
| This discourse encapsulates a proactive approach to securing Bitcoin against future quantum computing disruptions, emphasizing the need for adaptability in cryptographic practices and the potential for taproot to facilitate a smooth transition. The ideas presented reflect a blend of technical foresight and pragmatism, aiming to balance the security benefits against the operational and economic impacts on the Bitcoin network.</summary> | ||
| <published>2024-12-15T23:54:00+00:00</published> | ||
| </entry> | ||
| </feed> |
26 changes: 26 additions & 0 deletions
26
...c9407a48d3358be40fb94ab512c3e72b95e17cc_Trivial-QC-signatures-with-clean-upgrade-path.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,26 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Trivial QC signatures with clean upgrade path</title> | ||
| <updated>2024-12-16T02:44:48.096214+00:00</updated> | ||
| <author> | ||
| <name>Matt Corallo 2024-12-15 21:42: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>Trivial QC signatures with clean upgrade path</title> | ||
| <updated>2024-12-16T02:44:48.096245+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#m8c9407a48d3358be40fb94ab512c3e72b95e17cc" rel="alternate"/> | ||
| <summary>The debate on quantum computing (QC) robustness in Bitcoin's signature scheme has highlighted several critical considerations and proposals. Quantum computers capable of breaking current encryption methods like elliptic curves (EC) are anticipated to be developed within the next two decades, adhering to NSA recommendations and suggesting that we have time to upgrade Bitcoin's security protocols. However, the possibility exists that such quantum computers may never come to fruition due to potential fundamental scaling constraints. Despite this uncertainty, the development of quantum computing is expected to provide a warning period due to its immense resource requirements, signaling when an upgrade to Bitcoin's security measures becomes necessary. | ||
|
|
||
| The consensus within the community points towards hash-based signatures, specifically SPHINCS/SPHINCS+, as the only viable candidates for post-QC signature security within Bitcoin's consensus mechanism today. This is because other post-QC security assumptions, like Lattices and Supersingular Elliptic Curve Isogeny, are deemed insufficient for securing coins today and are considered bad candidates due to the potential for future cryptographic research to render them obsolete. The discussion also highlights the impracticality of waiting for opcode additions like OP_CAT, which are mired in complexities and uncertainties, including those surrounding miner extractable value (MEV) issues and Bitcoin's future developments. | ||
|
|
||
| A proposed solution involves leveraging taproot to build a scheme that provides post-QC security without requiring immediate action from wallet developers or users. Taproot script-path spends, which incorporate the internal key in their hash, offer a method for creating transactions that are secure against quantum computing threats. By adding a new opcode, similar to OP_CHECKSIG but for verifying post-QC non-one-time-use signatures, wallets could construct taproot outputs containing an alternative spending condition secure against QC attacks. This approach would allow for the soft-fork disabling of key-path taproot spends in favor of QC-secure paths once quantum computing becomes a tangible threat. | ||
|
|
||
| However, this proposal is not without its drawbacks, notably the potential for non-upgraded funds to be confiscated once QC becomes a reality. To mitigate this, two alternatives are suggested: requiring explicit opt-in for the scheme or allowing key-path spends for wallets that can prove their script-path is a Nothing-Up-My-Sleeve (NUMS) point. Each option has its trade-offs, including on-chain fingerprint concerns and the impact on existing wallets not committed to a NUMS point. | ||
|
|
||
| The discussion also touches upon the broader implications for Bitcoin's proof of work (PoW) in a post-QC world, suggesting that modifications to Bitcoin's PoW hash function might delay quantum computing's impact on mining. However, such considerations are speculative and dependent on future developments in quantum computing technology.</summary> | ||
| <published>2024-12-15T21:42:00+00:00</published> | ||
| </entry> | ||
| </feed> |
20 changes: 20 additions & 0 deletions
20
...cd0be33d056d0_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.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>[BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination</title> | ||
| <updated>2024-12-16T02:44:17.624330+00:00</updated> | ||
| <author> | ||
| <name>George Burke 2024-12-13 15:09: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>[BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination</title> | ||
| <updated>2024-12-16T02:44:17.624362+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/CAAg3Je02CszYvwF1kL3DofpnxXZvBZx7GAJaM2y1z6ePiG5Y2A@mail.gmail.com/T/#mac276df3e06ac87ca7dfc22b28ecd0be33d056d0" rel="alternate"/> | ||
| <summary>George Burke raises concerns about the implications of redefining 1 Bitcoin (BTC) into smaller, more inexpensive units for broader adoption. He questions the potential impacts on global mindshare, considering how such a change might affect the existing body of knowledge—including social media posts, articles, books, and videos—that reference current denominational units. This body of work could become bifurcated, leading to confusion or misinterpretation of historical data and discussions surrounding BTC's value and transactions. George's inquiry stems from a proposal discussed within the Bitcoin Development Mailing List, highlighting the need for careful consideration of psychological and informational ramifications when contemplating significant changes to cryptocurrency denominations. | ||
|
|
||
| For further information on George Burke's projects and contributions to the Bitcoin community, visit [Portal](https://portaldefi.com/), [Silicon Valley Bitcoin](https://svbtc.org/), and [FounderPool](https://founderpool.co/). Additional security measures and contact information can be found through his [Keybase](https://keybase.io/geoburke) profile and [OneName](https://onename.com/geoburke) page.</summary> | ||
| <published>2024-12-13T15:09:00+00:00</published> | ||
| </entry> | ||
| </feed> |
20 changes: 20 additions & 0 deletions
20
...01effffbf854b3914226fd20a367713515a1244_Trivial-QC-signatures-with-clean-upgrade-path.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>Trivial QC signatures with clean upgrade path</title> | ||
| <updated>2024-12-16T02:44:35.192130+00:00</updated> | ||
| <author> | ||
| <name>Luke Dashjr 2024-12-15 23:54: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>Trivial QC signatures with clean upgrade path</title> | ||
| <updated>2024-12-16T02:44:35.192163+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#md01effffbf854b3914226fd20a367713515a1244" rel="alternate"/> | ||
| <summary>The discussion highlights an important update regarding the post-quantum cryptography (QC) script path in Bitcoin's development. This path does not require a softfork to be committed, making it possible for wallets to start integrating this fallback mechanism as soon as the specification is finalized. This approach allows for immediate action without needing to wait for any softfork activations. However, there is a significant security consideration that needs to be addressed: the post-QC script must be protected similarly to a private key. This presents a particular challenge for hardware wallets, though the suggestion implies there might be solutions to overcome this obstacle. | ||
|
|
||
| This information originates from the Bitcoin Development Mailing List, emphasizing the ongoing discussions and developments in the space of cryptocurrency security and adaptability to future technological advancements such as quantum computing.</summary> | ||
| <published>2024-12-15T23:54:00+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...24082d6452efb_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.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,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>[BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination</title> | ||
| <updated>2024-12-16T02:44:09.438297+00:00</updated> | ||
| <author> | ||
| <name>Michael Cassano 2024-12-13 17:16: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>[BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination</title> | ||
| <updated>2024-12-16T02:44:09.438332+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/CAAg3Je02CszYvwF1kL3DofpnxXZvBZx7GAJaM2y1z6ePiG5Y2A@mail.gmail.com/T/#mfdc986b87c9738216032a7c3f3824082d6452efb" rel="alternate"/> | ||
| <summary>The email from George Burke to John discusses the terminology used in the Bitcoin network, specifically the terms "bitcoin" and "sats." George outlines several advantages of maintaining the current nomenclature without repurposing the term "bitcoin" to signify something other than its original meaning. He highlights that keeping "sats" as a well-defined term throughout the system minimizes the need for changes. Additionally, allowing "bitcoin" to continue representing the Bitcoin network honors Satoshi Nakamoto's legacy as the founder. Furthermore, George mentions that this approach simplifies the rollout process by gradually phasing out the usage of "bitcoin" in favor of "sats," based on a collective agreement that the term "bitcoin" leads to decimalization awkwardness. This exchange emphasizes the importance of preserving the foundational aspects of Bitcoin while considering practical implications of terminology adjustments within the development community.</summary> | ||
| <published>2024-12-13T17:16:00+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
static/delvingbitcoin/Dec_2024/3777_Optimistic-ZK-verification-using-MATT.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,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Optimistic ZK verification using MATT</title> | ||
| <updated>2024-12-16T02:39:42.069636+00:00</updated> | ||
| <author> | ||
| <name>AdamISZ 2024-12-15 16:06:16.862000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Optimistic ZK verification using MATT</title> | ||
| <updated>2024-12-16T02:39:42.069675+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/optimistic-zk-verification-using-matt/1050/2" rel="alternate"/> | ||
| <summary>The inquiry seeks to understand the significance and necessity of OP_CAT and covenants in a specific context, possibly related to blockchain or cryptocurrency technology. The questioner acknowledges the potential promise of the discussed direction but requests further clarification on these components' roles. Specifically, there is curiosity about whether these elements are crucial in a model that incorporates fraud proofs, hinting at familiarity with concepts like bitvm and optimistic rollups, albeit from a self-professed partially informed perspective. This suggests a technical discussion around the mechanisms of ensuring security or functionality within a cryptographic or blockchain framework, with an interest in how new or proposed features (OP_CAT and covenants) fit into existing or theoretical models for verification or transaction processing.</summary> | ||
| <published>2024-12-15T16:06:16.862000+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.