From b5c24891a06355429f5efb94371cbd0a46135ebc Mon Sep 17 00:00:00 2001 From: urvishp80 Date: Tue, 24 Dec 2024 03:15:33 +0000 Subject: [PATCH] Updated homepage.json file --- static/homepage.json | 220 +++++++------- .../Dec_2024/2024-12-24-homepage.json | 283 ++++++++++++++++++ 2 files changed, 386 insertions(+), 117 deletions(-) create mode 100644 static/homepage/Dec_2024/2024-12-24-homepage.json diff --git a/static/homepage.json b/static/homepage.json index 36be1fb8..e4dbb2a1 100644 --- a/static/homepage.json +++ b/static/homepage.json @@ -1,23 +1,6 @@ { - "header_summary": "The discourse on censorship resistance within ecash implementations, particularly the cashu protocol, reveals a divide among community members concerning the optional feature allowing for the censorship of a specific key, despite it not being implemented in any mint to date. This discussion extends to the implications of integrating Know Your Customer (KYC) standards, with opinions split on whether this dilutes privacy and freedom, or is a necessary adaptation for certain mints operating within permissive jurisdictions. The conversation underscores the broader challenge of balancing innovation, privacy, and regulatory compliance in the development of ecash systems ([source](https://gnusha.org/pi/bitcoindev/51eb0cc8-c9e0-4a50-9928-461f5f13264en@googlegroups.com/T/#ma25ccd9f2ed04e6bbc5df4c212e67938bc276315)).\n\nYuval Kogman highlights critical deanonymization risks within the Wasabi & GingerWallet and the CoinJoin protocols they utilize, pointing out a persistent trust issue and vulnerabilities that allow for full deanonymization by malicious coordinators. This discourse stresses the importance of maintaining high standards of security, user trust, and the balance between innovation and privacy in cryptocurrency protocols, reflecting ongoing challenges in enhancing privacy without compromising security ([source](https://gnusha.org/pi/bitcoindev/CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com/T/#u#m995ad0da6c23dfb6ac4c420e17a4358181e3567e)).\n\nAva Chow announces the availability of Bitcoin Core version v28.1rc2 binaries, underscoring the importance of community engagement and transparent development processes in ensuring software reliability and security. This release candidate, pending community feedback, aims to advance to the official v28.1 release, highlighting the project's commitment to quality and stability through iterative testing and community feedback ([source](https://gnusha.org/pi/bitcoindev/61300d46-a82f-4ebe-af45-17c654642699@achow101.com/T/#u#m569484cae13e4e3f766703c27dc4757cb232c09e)).\n\nIn contrast, zawy's exploration into Braidpool's difficulty algorithm presents a new consensus approach that does not rely on traditional metrics, aiming for quicker agreement by targeting the Directed Acyclic Graph (DAG) width. This development showcases an innovative direction for blockchain consensus algorithms, potentially offering more efficient alternatives to current methodologies, while also engaging with foundational issues of efficiency, security, and decentralization in blockchain technology ([source](https://delvingbitcoin.org/t/fastest-possible-pow-via-simple-dag/1331)).", + "header_summary": "Recent discussions within the Bitcoin development community have spotlighted vulnerabilities in Wasabi and GingerWallet's CoinJoin protocols, revealing significant deanonymization risks due to fundamental design flaws. Yuval Kogman et al. critically examined these vulnerabilities, particularly emphasizing the lack of trust between users and coordinators and highlighting how coordination fees and the anonymous credential mechanism failed to prevent thefts of user funds, thereby questioning the balance between innovation in privacy-enhancing technologies and the need for user trust and security ([GitHub repository](https://github.com/)).\n\nAva Chow announced the availability of Bitcoin Core version v28.1rc2 binaries, encouraging community engagement with the new release candidate. This update, accessible for download and review, reflects Bitcoin Core's commitment to transparency, reliability, and user-informed development, marking a pivotal step in the software's release cycle and exemplifying the project's dedication to quality and stability through community feedback ([Bitcoin Core's official site](https://bitcoincore.org/bin/bitcoin-core-28.1/test.rc2/)).\n\nJeremy Rubin revisited the concept of introducing soft forks with a \"shelf life\" to address consensus cleanups with a nuanced perspective, proposing expiration terms for new protocol restrictions to allow for flexibility and adaptability in addressing vulnerabilities without making permanent commitments to potentially flawed solutions. This approach highlights the community's cautious optimism and collective effort to enhance blockchain technology responsibly, ensuring it remains robust, efficient, and adaptable ([delvingbitcoin.org](https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333)).\n\nIn a separate discourse, the importance of community input in refining technical parameters was underscored, with a consensus leaning towards adhering to the initially proposed value of 600 seconds for a specific operation, pending further insights from the mining development mailing list. This methodical decision-making process highlights the significance of collective input in technical refinements, reinforcing the community's role in blockchain development ([delvingbitcoin.org](https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326/13)).", "recent_posts": [ - { - "id": "ma25ccd9f2ed04e6bbc5df4c212e67938bc276315", - "title": "Censorship and Privacy in Chaumian ecash implementations", - "link": "https://gnusha.org/pi/bitcoindev/51eb0cc8-c9e0-4a50-9928-461f5f13264en@googlegroups.com/T/#ma25ccd9f2ed04e6bbc5df4c212e67938bc276315", - "authors": [ - "/dev /fd0" - ], - "published_at": "2024-12-21T23:03:00+00:00", - "summary": "- Discussions revolve around censorship resistance in ecash, notably the cashu protocol.\n- KYC integration in cashu sparks debate on privacy versus regulatory compliance.\n- The discourse highlights the balance between innovation, privacy, and regulation in ecash development.", - "n_threads": 2, - "dev_name": "bitcoin-dev", - "contributors": [ - "conduition" - ], - "file_path": "static/bitcoin-dev/Dec_2024/ma25ccd9f2ed04e6bbc5df4c212e67938bc276315_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml", - "combined_summ_file_path": "static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml" - }, { "id": "m995ad0da6c23dfb6ac4c420e17a4358181e3567e", "title": "Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks", @@ -26,7 +9,7 @@ "Yuval Kogman" ], "published_at": "2024-12-21T14:16:00+00:00", - "summary": "- Vulnerabilities in Wasabi, GingerWallet, and CoinJoin protocols expose significant deanonymization risks.\n- Fundamental design flaws allow malicious coordinators to fully deanonymize transactions in Whirlpool and WabiSabi.\n- Efforts to address these vulnerabilities, including economic incentives, have not ensured user privacy or financial security.", + "summary": "- Vulnerabilities in Wasabi & GingerWallet and CoinJoin protocols present deanonymization risks.\n- Critical flaws allow malicious coordinators to deanonymize transactions in Whirlpool and WabiSabi protocols.\n- Economic incentives and privacy mechanisms failed to prevent user fund thefts, underscoring security oversights.", "n_threads": 0, "dev_name": "bitcoin-dev", "contributors": [], @@ -41,7 +24,7 @@ "Ava Chow" ], "published_at": "2024-12-19T19:29:00+00:00", - "summary": "- Bitcoin Core version v28.1rc2 binaries and source code are now available for download and review.\n- Preliminary release notes for v28.1rc2 have been published, detailing changes and improvements.\n- Release candidates like v28.1rc2 are vital for testing before the final release, ensuring quality and stability.", + "summary": "- Bitcoin Core version v28.1rc2 binaries are now available for download and review.\n- Preliminary release notes provide insights into the new version's changes and improvements.\n- Release candidates like v28.1rc2 are crucial for testing before the final software release.", "n_threads": 0, "dev_name": "bitcoin-dev", "contributors": [], @@ -49,48 +32,30 @@ "combined_summ_file_path": "" }, { - "id": "3844", - "title": "Fastest-possible PoW via Simple DAG", - "link": "https://delvingbitcoin.org/t/fastest-possible-pow-via-simple-dag/1331", + "id": "3851", + "title": "Transitory Soft Forks for Consensus Cleanup Forks", + "link": "https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333", "authors": [ - "zawy" + "JeremyRubin" ], - "published_at": "2024-12-22T15:14:50.752000+00:00", - "summary": "- Braidpool's algorithm achieves consensus without traditional metrics, focusing on DAG width for difficulty.\n- Targeting two parents for a block optimizes consensus, with a unique adjustment mechanism adjusting difficulty.\n- This new method shows promise against traditional protocols, balancing efficiency, security, and decentralization.", + "published_at": "2024-12-23T22:53:02.859000+00:00", + "summary": "- Soft forks may now have expiration terms like two years to address potential flaws.\n- This approach offers flexibility and prevents long-term commitment to suboptimal solutions.\n- It aims at consensus cleanups rather than adding new features, enhancing system security.", "n_threads": 0, "dev_name": "delvingbitcoin", "contributors": [], - "file_path": "static/delvingbitcoin/Dec_2024/3844_Fastest-possible-PoW-via-Simple-DAG.xml", + "file_path": "static/delvingbitcoin/Dec_2024/3851_Transitory-Soft-Forks-for-Consensus-Cleanup-Forks.xml", "combined_summ_file_path": "" }, { - "id": "3841", - "title": "Security soft fork deployments arent risky", - "link": "https://delvingbitcoin.org/t/security-soft-fork-deployments-arent-risky/1328/5", - "authors": [ - "harding" - ], - "published_at": "2024-12-20T18:39:49.803000+00:00", - "summary": "- BIP66 introduced as a security soft fork, evidencing deployment risks like spy mining.\n- SegWit opposition, notably by Bitmain, stemmed from losing ASICBoost advantages.\n- BIP141's `OP_RETURN` commitment proposal highlighted economic repercussions for certain miners.", - "n_threads": 4, - "dev_name": "delvingbitcoin", - "contributors": [ - "1440000bytes", - "Chris_Stewart_5" - ], - "file_path": "static/delvingbitcoin/Dec_2024/3841_Security-soft-fork-deployments-arent-risky.xml", - "combined_summ_file_path": "static/delvingbitcoin/Dec_2024/combined_Security-soft-fork-deployments-arent-risky.xml" - }, - { - "id": "3839", + "id": "3849", "title": "Timewarp attack 600 second grace period", - "link": "https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326/11", + "link": "https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326/13", "authors": [ "AntoineP" ], - "published_at": "2024-12-20T12:54:41.985000+00:00", - "summary": "- The conversation examines risks in blockchain mining, specifically `nTime` rolling attacks.\n- It suggests more `nTime` rolling flexibility could mitigate bugs without major negative effects.\n- Mathematical models show leeway adjustments significantly impact blockchain difficulty levels.", - "n_threads": 10, + "published_at": "2024-12-23T15:53:31.395000+00:00", + "summary": "- Optimal numbers for operations consider various factors but often have multiple values.\n- Sticking to the initially proposed 600 seconds is advised without strong reasons to change.\n- Seeking further insights from the mining development mailing list will ensure a thorough approach.", + "n_threads": 12, "dev_name": "delvingbitcoin", "contributors": [ "sjors", @@ -98,8 +63,26 @@ "MattCorallo", "ajtowns" ], - "file_path": "static/delvingbitcoin/Dec_2024/3839_Timewarp-attack-600-second-grace-period.xml", + "file_path": "static/delvingbitcoin/Dec_2024/3849_Timewarp-attack-600-second-grace-period.xml", "combined_summ_file_path": "static/delvingbitcoin/Dec_2024/combined_Timewarp-attack-600-second-grace-period.xml" + }, + { + "id": "3847", + "title": "Security soft fork deployments arent risky", + "link": "https://delvingbitcoin.org/t/security-soft-fork-deployments-arent-risky/1328/6", + "authors": [ + "Chris_Stewart_5" + ], + "published_at": "2024-12-23T15:09:58.356000+00:00", + "summary": "- Soft forks introduce tighter network rules, posing a confiscation risk to miners.\n- Bitmain resisted SegWit due to its impact on their covert asicboost technology.\n- The design phase of soft forks requires consensus to accept potential confiscation risks.", + "n_threads": 5, + "dev_name": "delvingbitcoin", + "contributors": [ + "1440000bytes", + "harding" + ], + "file_path": "static/delvingbitcoin/Dec_2024/3847_Security-soft-fork-deployments-arent-risky.xml", + "combined_summ_file_path": "static/delvingbitcoin/Dec_2024/combined_Security-soft-fork-deployments-arent-risky.xml" } ], "active_posts": [ @@ -111,7 +94,7 @@ "Matt Corallo" ], "published_at": "2024-12-15T21:42:00+00:00", - "summary": "- Quantum computing may threaten Bitcoin's security within two decades, necessitating upgrades.\n- Community consensus favors SPHINCS/SPHINCS+ for post-quantum signature security in Bitcoin.\n- A taproot-based scheme allows for transitioning to quantum-resistant transactions without immediate user action.", + "summary": "- Quantum computers may break Bitcoin encryption within decades but face potential scaling issues.\n- Community favors hash-based signatures for post-quantum Bitcoin security, other methods seen as inadequate.\n- Proposed taproot enhancements could secure Bitcoin against quantum threats without immediate widespread action.", "n_threads": 8, "dev_name": "bitcoin-dev", "contributors": [ @@ -133,7 +116,7 @@ "Tim Ruffing" ], "published_at": "2024-07-08T20:05:00+00:00", - "summary": "- Jonas, Nick, and Tim are drafting a BIP for FROST Threshold Signatures.\n- Their draft, hosted on GitHub, seeks community feedback and includes a Python implementation.\n- Ongoing work focuses on development areas like wire format and test vectors for the proposal.", + "summary": "- Jonas, Nick, and Tim are drafting a BIP for FROST Threshold Signatures.\n- Their work, hosted on GitHub, seeks community feedback for improvement.\n- Ongoing enhancements focus on several development areas, including a separate BIP for FROST signing.", "n_threads": 3, "dev_name": "bitcoin-dev", "contributors": [ @@ -144,21 +127,21 @@ "combined_summ_file_path": "static/bitcoin-dev/July_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml" }, { - "id": "m03eb94cf0488aa80a78aeb2fd59ae5393924983c", - "title": "Double Exponential Hash Rate Growth and Difficulty Adjustment", - "link": "https://gnusha.org/pi/bitcoindev/ab246ea3-36ae-4c87-b4d1-32b0ec4f2603n@googlegroups.com/T/#m03eb94cf0488aa80a78aeb2fd59ae5393924983c", + "id": "m9a77a811b028160ad982a9a9d57571ecd331911a", + "title": "Censorship and Privacy in Chaumian ecash implementations", + "link": "https://gnusha.org/pi/bitcoindev/51eb0cc8-c9e0-4a50-9928-461f5f13264en@googlegroups.com/T/#m9a77a811b028160ad982a9a9d57571ecd331911a", "authors": [ - "Anders" + "/dev /fd0" ], - "published_at": "2024-12-19T01:19:00+00:00", - "summary": "- Anders discusses concerns about Bitcoin's hash rate potentially causing difficulty adjustment issues.\n- Rapid ASIC technology advancements could lead to unsustainable difficulty adjustments.\n- Suggests further analysis and strategies to manage hash rate growth and maintain network stability.", + "published_at": "2024-12-21T16:58:00+00:00", + "summary": "- Ecash faces censorship through P2PK methods and mandatory KYC processes, drawing developer criticism.\n- Technical discussions, like GitHub pull requests, reveal contradictions in ecash's censorship-resistant claims.\n- Efforts to balance regulatory compliance and privacy have not prevented potential censorship and surveillance issues.", "n_threads": 2, "dev_name": "bitcoin-dev", "contributors": [ - "Michael Cassano" + "conduition" ], - "file_path": "static/bitcoin-dev/Dec_2024/m03eb94cf0488aa80a78aeb2fd59ae5393924983c_Double-Exponential-Hash-Rate-Growth-and-Difficulty-Adjustment.xml", - "combined_summ_file_path": "static/bitcoin-dev/Dec_2024/combined_Double-Exponential-Hash-Rate-Growth-and-Difficulty-Adjustment.xml" + "file_path": "static/bitcoin-dev/Dec_2024/m9a77a811b028160ad982a9a9d57571ecd331911a_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml", + "combined_summ_file_path": "static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml" }, { "id": "1996", @@ -168,7 +151,7 @@ "AntoineP" ], "published_at": "2024-03-24T19:53:27.073000+00:00", - "summary": "- The analysis proposes improvements to Bitcoin's protocol, highlighting security and efficiency vulnerabilities.\n- It suggests addressing the timewarp vulnerability and limiting legacy transaction sizes to enhance stability.\n- Community engagement is encouraged for bug resolution, although debates arise over block size reduction impacts.", + "summary": "- The Great Consensus Cleanup targets Bitcoin's vulnerabilities, aiming to enhance security and performance.\n- Proposed changes include adjusting mining difficulty and invalidating small transactions to protect integrity.\n- Community debate surrounds block size reduction, with technical standardization suggestions aiming to increase security.", "n_threads": 61, "dev_name": "delvingbitcoin", "contributors": [ @@ -196,7 +179,7 @@ "Fi3" ], "published_at": "2024-08-28T14:21:15.076000+00:00", - "summary": "- An SV2 extension is being developed to improve mining pool payout transparency and fairness.\n- The extension gives miners the ability to select transactions, enhancing control over mining jobs.\n- The project, in its developmental phase, actively seeks contributions to refine the proposed system.", + "summary": "- An SV2 extension is being developed to improve mining pool payout transparency and fairness.\n- The extension empowers miners to select transactions, offering control over mining job fee structures.\n- The project, in development, seeks reviews and contributions to enhance the proposed system.", "n_threads": 53, "dev_name": "delvingbitcoin", "contributors": [ @@ -209,89 +192,92 @@ "combined_summ_file_path": "static/delvingbitcoin/Aug_2024/combined_PPLNS-with-job-declaration.xml" }, { - "id": "3521", - "title": "CTV, APO, CAT activity on signet", - "link": "https://delvingbitcoin.org/t/ctv-apo-cat-activity-on-signet/1257", + "id": "1886", + "title": "BTC Lisp as an alternative to Script", + "link": "https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682", "authors": [ "ajtowns" ], - "published_at": "2024-11-14T17:34:11.568000+00:00", - "summary": "- BIPs 118, 119, and 347 improve Bitcoin scripting, introducing APO, CTV, and OP_CAT.\n- APO usage is mainly for coinbase payouts and overcoming CTV via scripted transactions.\n- OP_CAT surpasses APO/CTV in usage, showing significant versatility and utility in Bitcoin's network.", + "published_at": "2024-03-14T12:51:49.490000+00:00", + "summary": "- The proposal integrates Lisp into Bitcoin, enhancing scripts without changing the UTXO database.\n- `btclisp.py` facilitates Lisp's blockchain experimentation, inspired by other Lisp projects.\n- Technical and practical challenges exist, but Lisp's inclusion could make blockchain scripting more expressive.", "n_threads": 16, "dev_name": "delvingbitcoin", "contributors": [ - "1440000bytes", - "fiatjaf", - "JeremyRubin", - "vostrnad", - "AdamISZ" + "ZmnSCPxj", + "prozacchiwawa", + "roconnor-blockstream", + "Ajian", + "Greg Sanders", + "bramcohen", + "cryptoquick" ], - "file_path": "static/delvingbitcoin/Nov_2024/3521_CTV-APO-CAT-activity-on-signet.xml", - "combined_summ_file_path": "static/delvingbitcoin/Nov_2024/combined_CTV-APO-CAT-activity-on-signet.xml" + "file_path": "static/delvingbitcoin/March_2024/1886_BTC-Lisp-as-an-alternative-to-Script.xml", + "combined_summ_file_path": "static/delvingbitcoin/March_2024/combined_BTC-Lisp-as-an-alternative-to-Script.xml" } ], "today_in_history_posts": [ { - "id": "018318", - "title": "BIP Proposal: Wallet Interface", - "link": "https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018318.html", + "id": "017529", + "title": "Base64-encoded descriptors", + "link": "https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017529.html", "authors": [ - "monokh" + "Chris Belcher" ], - "published_at": "2020-12-22T14:43:11+00:00", - "summary": "- Proposed BIP offers a simple interface for Bitcoin wallets to enhance application integration.\n- The proposal includes standards for wallet APIs, aiming for application-wallet compatibility.\n- Security and privacy concerns must be prioritized when exposing wallet functions externally.", - "n_threads": 6, + "published_at": "2019-12-24T17:06:01+00:00", + "summary": "- Chris Belcher finds descriptors user-friendly and proposes them as a standard.\n- Base64 encoding descriptors simplifies handling but risks checksum errors if mistyped.\n- The solution includes encoding without the checksum and appending it afterwards, inspired by achow101.", + "n_threads": 5, "dev_name": "bitcoin-dev", "contributors": [ - "Aymeric Vitte", - "Erik Aronesty", - "Luke Dashjr", - "Omar Shibli", - "Shane Jonas" + "Ava Chow", + "Pavol Rusnak", + "Spencer Dupre`", + "Trey Del Bonis", + "William Casarin" ], - "file_path": "static/bitcoin-dev/Dec_2020/018318_BIP-Proposal-Wallet-Interface.xml", - "combined_summ_file_path": "static/bitcoin-dev/Dec_2020/combined_BIP-Proposal-Wallet-Interface.xml" + "file_path": "static/bitcoin-dev/Dec_2019/017529_Base64-encoded-descriptors.xml", + "combined_summ_file_path": "static/bitcoin-dev/Dec_2019/combined_Base64-encoded-descriptors.xml" }, { - "id": "002943", - "title": "PoDLEs revisited", - "link": "https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002943.html", + "id": "002455", + "title": "Not revealing the channel capacity during opening of channel in lightning network", + "link": "https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002455.html", "authors": [ - "Lloyd Fournier" + "Subhra Mazumdar" ], - "published_at": "2021-02-03T06:33:44+00:00", - "summary": "- Rusty Russell inquired about a heuristic's relevance post-Taproot, receiving a negative.\n- Taproot secures private channels from being exposed through a certain tracing method.\n- This method links UTXOs to node IDs, undermining UTXO probing efforts.", - "n_threads": 9, + "published_at": "2020-01-27T07:14:41+00:00", + "summary": "- The forum discussed privacy in transactions without revealing channel capacity.\n- Solutions include smart contracts and penalties for fraudulent claims.\n- The debate focuses on balancing privacy with transaction integrity in blockchain.", + "n_threads": 10, "dev_name": "lightning-dev", "contributors": [ - "Rusty Russell", - "ZmnSCPxj" + "M", + "ZmnSCPxj", + "Christian Decker", + "Ugam Kam" ], - "file_path": "static/lightning-dev/Feb_2021/002943_PoDLEs-revisited.xml", - "combined_summ_file_path": "static/lightning-dev/Feb_2021/combined_PoDLEs-revisited.xml" + "file_path": "static/lightning-dev/Jan_2020/002455_Not-revealing-the-channel-capacity-during-opening-of-channel-in-lightning-network.xml", + "combined_summ_file_path": "static/lightning-dev/Jan_2020/combined_Not-revealing-the-channel-capacity-during-opening-of-channel-in-lightning-network.xml" }, { - "id": "789", - "title": "Unspendable keys in descriptors", - "link": "https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304", + "id": "873", + "title": "[BUG]: spammers get Bitcoin blockspace at discounted price. Let's fix it", + "link": "https://delvingbitcoin.org/t/bug-spammers-get-bitcoin-blockspace-at-discounted-price-lets-fix-it/327", "authors": [ - "salvatoshi" + "GregTonoski" ], - "published_at": "2023-12-19T13:29:37.600000+00:00", - "summary": "- Miniscript and taproot integration in Bitcoin Core enhances wallet development potential.\n- Various methods to create unspendable keys have been proposed, each with unique trade-offs.\n- The use of a root xpub with a random chaincode is currently favored for hardware signers.", - "n_threads": 28, + "published_at": "2023-12-27T20:54:30.891000+00:00", + "summary": "- Disparities in Bitcoin transaction pricing are highlighted, showing simpler ones often cost more.\n- The author criticizes this pricing model for causing block space misallocation and potential centralization.\n- A uniform pricing proposal for blockspace in Segwit transactions is suggested to address these issues.", + "n_threads": 25, "dev_name": "delvingbitcoin", "contributors": [ - "AntoineP", - "andrewtoth", - "josibake", - "sipa", - "RandyMcMillan", - "andrewkozlik", - "wydengyre" + "moonsettler", + "ProofOfKeags", + "DoctorBuzz1", + "murch", + "rustynail", + "sipa" ], - "file_path": "static/delvingbitcoin/Dec_2023/789_Unspendable-keys-in-descriptors.xml", - "combined_summ_file_path": "static/delvingbitcoin/Dec_2023/combined_Unspendable-keys-in-descriptors.xml" + "file_path": "static/delvingbitcoin/Dec_2023/873_-BUG-spammers-get-Bitcoin-blockspace-at-discounted-price-Let-s-fix-it.xml", + "combined_summ_file_path": "static/delvingbitcoin/Dec_2023/combined_-BUG-spammers-get-Bitcoin-blockspace-at-discounted-price-Let-s-fix-it.xml" } ] } \ No newline at end of file diff --git a/static/homepage/Dec_2024/2024-12-24-homepage.json b/static/homepage/Dec_2024/2024-12-24-homepage.json new file mode 100644 index 00000000..e4dbb2a1 --- /dev/null +++ b/static/homepage/Dec_2024/2024-12-24-homepage.json @@ -0,0 +1,283 @@ +{ + "header_summary": "Recent discussions within the Bitcoin development community have spotlighted vulnerabilities in Wasabi and GingerWallet's CoinJoin protocols, revealing significant deanonymization risks due to fundamental design flaws. Yuval Kogman et al. critically examined these vulnerabilities, particularly emphasizing the lack of trust between users and coordinators and highlighting how coordination fees and the anonymous credential mechanism failed to prevent thefts of user funds, thereby questioning the balance between innovation in privacy-enhancing technologies and the need for user trust and security ([GitHub repository](https://github.com/)).\n\nAva Chow announced the availability of Bitcoin Core version v28.1rc2 binaries, encouraging community engagement with the new release candidate. This update, accessible for download and review, reflects Bitcoin Core's commitment to transparency, reliability, and user-informed development, marking a pivotal step in the software's release cycle and exemplifying the project's dedication to quality and stability through community feedback ([Bitcoin Core's official site](https://bitcoincore.org/bin/bitcoin-core-28.1/test.rc2/)).\n\nJeremy Rubin revisited the concept of introducing soft forks with a \"shelf life\" to address consensus cleanups with a nuanced perspective, proposing expiration terms for new protocol restrictions to allow for flexibility and adaptability in addressing vulnerabilities without making permanent commitments to potentially flawed solutions. This approach highlights the community's cautious optimism and collective effort to enhance blockchain technology responsibly, ensuring it remains robust, efficient, and adaptable ([delvingbitcoin.org](https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333)).\n\nIn a separate discourse, the importance of community input in refining technical parameters was underscored, with a consensus leaning towards adhering to the initially proposed value of 600 seconds for a specific operation, pending further insights from the mining development mailing list. This methodical decision-making process highlights the significance of collective input in technical refinements, reinforcing the community's role in blockchain development ([delvingbitcoin.org](https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326/13)).", + "recent_posts": [ + { + "id": "m995ad0da6c23dfb6ac4c420e17a4358181e3567e", + "title": "Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks", + "link": "https://gnusha.org/pi/bitcoindev/CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com/T/#u#m995ad0da6c23dfb6ac4c420e17a4358181e3567e", + "authors": [ + "Yuval Kogman" + ], + "published_at": "2024-12-21T14:16:00+00:00", + "summary": "- Vulnerabilities in Wasabi & GingerWallet and CoinJoin protocols present deanonymization risks.\n- Critical flaws allow malicious coordinators to deanonymize transactions in Whirlpool and WabiSabi protocols.\n- Economic incentives and privacy mechanisms failed to prevent user fund thefts, underscoring security oversights.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Dec_2024/m995ad0da6c23dfb6ac4c420e17a4358181e3567e_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml", + "combined_summ_file_path": "" + }, + { + "id": "m569484cae13e4e3f766703c27dc4757cb232c09e", + "title": "Bitcoin Core 28.1 Release Candidate 2 Available", + "link": "https://gnusha.org/pi/bitcoindev/61300d46-a82f-4ebe-af45-17c654642699@achow101.com/T/#u#m569484cae13e4e3f766703c27dc4757cb232c09e", + "authors": [ + "Ava Chow" + ], + "published_at": "2024-12-19T19:29:00+00:00", + "summary": "- Bitcoin Core version v28.1rc2 binaries are now available for download and review.\n- Preliminary release notes provide insights into the new version's changes and improvements.\n- Release candidates like v28.1rc2 are crucial for testing before the final software release.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Dec_2024/m569484cae13e4e3f766703c27dc4757cb232c09e_Bitcoin-Core-28-1-Release-Candidate-2-Available.xml", + "combined_summ_file_path": "" + }, + { + "id": "3851", + "title": "Transitory Soft Forks for Consensus Cleanup Forks", + "link": "https://delvingbitcoin.org/t/transitory-soft-forks-for-consensus-cleanup-forks/1333", + "authors": [ + "JeremyRubin" + ], + "published_at": "2024-12-23T22:53:02.859000+00:00", + "summary": "- Soft forks may now have expiration terms like two years to address potential flaws.\n- This approach offers flexibility and prevents long-term commitment to suboptimal solutions.\n- It aims at consensus cleanups rather than adding new features, enhancing system security.", + "n_threads": 0, + "dev_name": "delvingbitcoin", + "contributors": [], + "file_path": "static/delvingbitcoin/Dec_2024/3851_Transitory-Soft-Forks-for-Consensus-Cleanup-Forks.xml", + "combined_summ_file_path": "" + }, + { + "id": "3849", + "title": "Timewarp attack 600 second grace period", + "link": "https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326/13", + "authors": [ + "AntoineP" + ], + "published_at": "2024-12-23T15:53:31.395000+00:00", + "summary": "- Optimal numbers for operations consider various factors but often have multiple values.\n- Sticking to the initially proposed 600 seconds is advised without strong reasons to change.\n- Seeking further insights from the mining development mailing list will ensure a thorough approach.", + "n_threads": 12, + "dev_name": "delvingbitcoin", + "contributors": [ + "sjors", + "zawy", + "MattCorallo", + "ajtowns" + ], + "file_path": "static/delvingbitcoin/Dec_2024/3849_Timewarp-attack-600-second-grace-period.xml", + "combined_summ_file_path": "static/delvingbitcoin/Dec_2024/combined_Timewarp-attack-600-second-grace-period.xml" + }, + { + "id": "3847", + "title": "Security soft fork deployments arent risky", + "link": "https://delvingbitcoin.org/t/security-soft-fork-deployments-arent-risky/1328/6", + "authors": [ + "Chris_Stewart_5" + ], + "published_at": "2024-12-23T15:09:58.356000+00:00", + "summary": "- Soft forks introduce tighter network rules, posing a confiscation risk to miners.\n- Bitmain resisted SegWit due to its impact on their covert asicboost technology.\n- The design phase of soft forks requires consensus to accept potential confiscation risks.", + "n_threads": 5, + "dev_name": "delvingbitcoin", + "contributors": [ + "1440000bytes", + "harding" + ], + "file_path": "static/delvingbitcoin/Dec_2024/3847_Security-soft-fork-deployments-arent-risky.xml", + "combined_summ_file_path": "static/delvingbitcoin/Dec_2024/combined_Security-soft-fork-deployments-arent-risky.xml" + } + ], + "active_posts": [ + { + "id": "m8c9407a48d3358be40fb94ab512c3e72b95e17cc", + "title": "Trivial QC signatures with clean upgrade path", + "link": "https://gnusha.org/pi/bitcoindev/52f3bfc0-9446-4400-bf7a-7e38e5777c56@dashjr.org/T/#m8c9407a48d3358be40fb94ab512c3e72b95e17cc", + "authors": [ + "Matt Corallo" + ], + "published_at": "2024-12-15T21:42:00+00:00", + "summary": "- Quantum computers may break Bitcoin encryption within decades but face potential scaling issues.\n- Community favors hash-based signatures for post-quantum Bitcoin security, other methods seen as inadequate.\n- Proposed taproot enhancements could secure Bitcoin against quantum threats without immediate widespread action.", + "n_threads": 8, + "dev_name": "bitcoin-dev", + "contributors": [ + "Anthony Towns", + "Antoine Riard", + "Luke Dashjr", + "Tadge Dryja", + "Weikeng Chen", + "conduition" + ], + "file_path": "static/bitcoin-dev/Dec_2024/m8c9407a48d3358be40fb94ab512c3e72b95e17cc_Trivial-QC-signatures-with-clean-upgrade-path.xml", + "combined_summ_file_path": "static/bitcoin-dev/Dec_2024/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml" + }, + { + "id": "m50e3cf085d204eab1b7dce4c0a708f0831129039", + "title": "BIP Draft: \"ChillDKG: Distributed Key Generation for FROST\"", + "link": "https://gnusha.org/pi/bitcoindev/8768422323203aa3a8b280940abd776526fab12e.camel@timruffing.de/T/#u#m50e3cf085d204eab1b7dce4c0a708f0831129039", + "authors": [ + "Tim Ruffing" + ], + "published_at": "2024-07-08T20:05:00+00:00", + "summary": "- Jonas, Nick, and Tim are drafting a BIP for FROST Threshold Signatures.\n- Their work, hosted on GitHub, seeks community feedback for improvement.\n- Ongoing enhancements focus on several development areas, including a separate BIP for FROST signing.", + "n_threads": 3, + "dev_name": "bitcoin-dev", + "contributors": [ + "David Harding", + "Jonas Nick" + ], + "file_path": "static/bitcoin-dev/July_2024/m50e3cf085d204eab1b7dce4c0a708f0831129039_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml", + "combined_summ_file_path": "static/bitcoin-dev/July_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml" + }, + { + "id": "m9a77a811b028160ad982a9a9d57571ecd331911a", + "title": "Censorship and Privacy in Chaumian ecash implementations", + "link": "https://gnusha.org/pi/bitcoindev/51eb0cc8-c9e0-4a50-9928-461f5f13264en@googlegroups.com/T/#m9a77a811b028160ad982a9a9d57571ecd331911a", + "authors": [ + "/dev /fd0" + ], + "published_at": "2024-12-21T16:58:00+00:00", + "summary": "- Ecash faces censorship through P2PK methods and mandatory KYC processes, drawing developer criticism.\n- Technical discussions, like GitHub pull requests, reveal contradictions in ecash's censorship-resistant claims.\n- Efforts to balance regulatory compliance and privacy have not prevented potential censorship and surveillance issues.", + "n_threads": 2, + "dev_name": "bitcoin-dev", + "contributors": [ + "conduition" + ], + "file_path": "static/bitcoin-dev/Dec_2024/m9a77a811b028160ad982a9a9d57571ecd331911a_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml", + "combined_summ_file_path": "static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml" + }, + { + "id": "1996", + "title": "Great Consensus Cleanup Revival", + "link": "https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710", + "authors": [ + "AntoineP" + ], + "published_at": "2024-03-24T19:53:27.073000+00:00", + "summary": "- The Great Consensus Cleanup targets Bitcoin's vulnerabilities, aiming to enhance security and performance.\n- Proposed changes include adjusting mining difficulty and invalidating small transactions to protect integrity.\n- Community debate surrounds block size reduction, with technical standardization suggestions aiming to increase security.", + "n_threads": 61, + "dev_name": "delvingbitcoin", + "contributors": [ + "ajtowns", + "evoskuil", + "David Harding", + "sjors", + "zawy", + "MattCorallo", + "recent798", + "1440000bytes", + "ariard", + "benthecarman", + "kcalvinalvin", + "plebhash" + ], + "file_path": "static/delvingbitcoin/March_2024/1996_Great-Consensus-Cleanup-Revival.xml", + "combined_summ_file_path": "static/delvingbitcoin/March_2024/combined_Great-Consensus-Cleanup-Revival.xml" + }, + { + "id": "3073", + "title": "PPLNS with job declaration", + "link": "https://delvingbitcoin.org/t/pplns-with-job-declaration/1099", + "authors": [ + "Fi3" + ], + "published_at": "2024-08-28T14:21:15.076000+00:00", + "summary": "- An SV2 extension is being developed to improve mining pool payout transparency and fairness.\n- The extension empowers miners to select transactions, offering control over mining job fee structures.\n- The project, in development, seeks reviews and contributions to enhance the proposed system.", + "n_threads": 53, + "dev_name": "delvingbitcoin", + "contributors": [ + "marathon-gary", + "plebhash", + "lorbax", + "sjors" + ], + "file_path": "static/delvingbitcoin/Aug_2024/3073_PPLNS-with-job-declaration.xml", + "combined_summ_file_path": "static/delvingbitcoin/Aug_2024/combined_PPLNS-with-job-declaration.xml" + }, + { + "id": "1886", + "title": "BTC Lisp as an alternative to Script", + "link": "https://delvingbitcoin.org/t/btc-lisp-as-an-alternative-to-script/682", + "authors": [ + "ajtowns" + ], + "published_at": "2024-03-14T12:51:49.490000+00:00", + "summary": "- The proposal integrates Lisp into Bitcoin, enhancing scripts without changing the UTXO database.\n- `btclisp.py` facilitates Lisp's blockchain experimentation, inspired by other Lisp projects.\n- Technical and practical challenges exist, but Lisp's inclusion could make blockchain scripting more expressive.", + "n_threads": 16, + "dev_name": "delvingbitcoin", + "contributors": [ + "ZmnSCPxj", + "prozacchiwawa", + "roconnor-blockstream", + "Ajian", + "Greg Sanders", + "bramcohen", + "cryptoquick" + ], + "file_path": "static/delvingbitcoin/March_2024/1886_BTC-Lisp-as-an-alternative-to-Script.xml", + "combined_summ_file_path": "static/delvingbitcoin/March_2024/combined_BTC-Lisp-as-an-alternative-to-Script.xml" + } + ], + "today_in_history_posts": [ + { + "id": "017529", + "title": "Base64-encoded descriptors", + "link": "https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017529.html", + "authors": [ + "Chris Belcher" + ], + "published_at": "2019-12-24T17:06:01+00:00", + "summary": "- Chris Belcher finds descriptors user-friendly and proposes them as a standard.\n- Base64 encoding descriptors simplifies handling but risks checksum errors if mistyped.\n- The solution includes encoding without the checksum and appending it afterwards, inspired by achow101.", + "n_threads": 5, + "dev_name": "bitcoin-dev", + "contributors": [ + "Ava Chow", + "Pavol Rusnak", + "Spencer Dupre`", + "Trey Del Bonis", + "William Casarin" + ], + "file_path": "static/bitcoin-dev/Dec_2019/017529_Base64-encoded-descriptors.xml", + "combined_summ_file_path": "static/bitcoin-dev/Dec_2019/combined_Base64-encoded-descriptors.xml" + }, + { + "id": "002455", + "title": "Not revealing the channel capacity during opening of channel in lightning network", + "link": "https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002455.html", + "authors": [ + "Subhra Mazumdar" + ], + "published_at": "2020-01-27T07:14:41+00:00", + "summary": "- The forum discussed privacy in transactions without revealing channel capacity.\n- Solutions include smart contracts and penalties for fraudulent claims.\n- The debate focuses on balancing privacy with transaction integrity in blockchain.", + "n_threads": 10, + "dev_name": "lightning-dev", + "contributors": [ + "M", + "ZmnSCPxj", + "Christian Decker", + "Ugam Kam" + ], + "file_path": "static/lightning-dev/Jan_2020/002455_Not-revealing-the-channel-capacity-during-opening-of-channel-in-lightning-network.xml", + "combined_summ_file_path": "static/lightning-dev/Jan_2020/combined_Not-revealing-the-channel-capacity-during-opening-of-channel-in-lightning-network.xml" + }, + { + "id": "873", + "title": "[BUG]: spammers get Bitcoin blockspace at discounted price. Let's fix it", + "link": "https://delvingbitcoin.org/t/bug-spammers-get-bitcoin-blockspace-at-discounted-price-lets-fix-it/327", + "authors": [ + "GregTonoski" + ], + "published_at": "2023-12-27T20:54:30.891000+00:00", + "summary": "- Disparities in Bitcoin transaction pricing are highlighted, showing simpler ones often cost more.\n- The author criticizes this pricing model for causing block space misallocation and potential centralization.\n- A uniform pricing proposal for blockspace in Segwit transactions is suggested to address these issues.", + "n_threads": 25, + "dev_name": "delvingbitcoin", + "contributors": [ + "moonsettler", + "ProofOfKeags", + "DoctorBuzz1", + "murch", + "rustynail", + "sipa" + ], + "file_path": "static/delvingbitcoin/Dec_2023/873_-BUG-spammers-get-Bitcoin-blockspace-at-discounted-price-Let-s-fix-it.xml", + "combined_summ_file_path": "static/delvingbitcoin/Dec_2023/combined_-BUG-spammers-get-Bitcoin-blockspace-at-discounted-price-Let-s-fix-it.xml" + } + ] +} \ No newline at end of file