Updated newly generated xml files

static/bitcoin-dev/Nov_2024/m1bab216dee18c20e39cbf90f1261a736c18cd3a1_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-26-0.xml

@@ -0,0 +1,18 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<feed xmlns="http://www.w3.org/2005/Atom">
+  <id>0</id>
+  <title>Public disclosure of one vulnerability affecting Bitcoin Core &lt;26.0</title>
+  <updated>2024-11-06T02:22:10.656556+00:00</updated>
+  <author>
+    <name>Antoine Poinsot 2024-11-05 16: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>Public disclosure of one vulnerability affecting Bitcoin Core &lt;26.0</title>
+    <updated>2024-11-06T02:22:10.656594+00:00</updated>
+    <link href="https://gnusha.org/pi/bitcoindev/uJpfg8UeMOfVUATG4YRiGmyz5MALtZq68FCBXA6PT-BNstodivpqQfDxD1JAv5Qny_vuNr-A1m8jIDNHQLhAQt8hj8Ee9OT6ZFE5Z16O97A=@protonmail.com/T/#u#m1bab216dee18c20e39cbf90f1261a736c18cd3a1" rel="alternate"/>
+    <summary>The latest security advisories for historical issues concerning Bitcoin Core have been released and can be found on their official website. Interested parties are encouraged to review these details at [https://bitcoincore.org/en/2024/11/05/cb-stall-hindering-propagation](https://bitcoincore.org/en/2024/11/05/cb-stall-hindering-propagation). Moving forward, Bitcoin Core will adhere to its publicly advertised disclosure policy for any new vulnerabilities reported. This policy is detailed on their website under the security advisories section, accessible via [https://bitcoincore.org/en/security-advisories](https://bitcoincore.org/en/security-advisories). The implementation of this policy marks the completion of a process that began in July, showcasing the project's commitment to transparent and responsible security practices.</summary>
+    <published>2024-11-05T16:00:00+00:00</published>
+  </entry>
+</feed>

static/delvingbitcoin/April_2024/combined_Great-Consensus-Cleanup-Revival.xml

@@ -2,9 +2,12 @@
 <feed xmlns="http://www.w3.org/2005/Atom">
   <id>2</id>
   <title>Combined summary - Great Consensus Cleanup Revival</title>
-  <updated>2024-11-05T02:17:37.928041+00:00</updated>
+  <updated>2024-11-06T02:16:48.723797+00:00</updated>
   <author>
-    <name>AntoineP 2024-11-04 21:06:02.107000+00:00</name>
+    <name>AntoineP 2024-11-05 14:54:27.808000+00:00</name>
+  </author>
+  <author>
+    <name>AntoineP  . 2024-11-04 21:06:02.107000+00:00</name>
   </author>
   <author>
     <name>plebhash  . 2024-09-05 23:18:30.920000+00:00</name>
@@ -141,6 +144,7 @@
   <author>
     <name>AntoineP  . 2024-03-24 19:53:27.073000+00:00</name>
   </author>
+  <link href="delvingbitcoin/Nov_2024/3491_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Nov_2024/3480_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Sept_2024/3107_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Sept_2024/3100_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
@@ -191,13 +195,13 @@
   <entry>
     <id>2</id>
     <title>Combined summary - Great Consensus Cleanup Revival</title>
-    <updated>2024-11-05T02:17:37.928334+00:00</updated>
-    <link href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/47" rel="alternate"/>
-    <summary>The discussion surrounding the Bitcoin protocol's vulnerabilities and potential improvements is a multifaceted exploration of how to enhance network security and performance. At the heart of this discourse is Matt Corallo's Great Consensus Cleanup proposal, which identifies several key areas where the Bitcoin protocol could be refined. The timewarp vulnerability presents a significant risk, allowing for the artificial lowering of mining difficulty. By adjusting retarget periods, the proposal aims to safeguard the network against such exploits. Furthermore, the issue of maliciously crafted non-SegWit transactions that could prolong block validation times is addressed by proposing restrictions on legacy Script usage and capping the size of legacy transactions.
+    <updated>2024-11-06T02:16:48.724094+00:00</updated>
+    <link href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/48" rel="alternate"/>
+    <summary>The discussion delves into various proposals to improve the Bitcoin protocol's security and efficiency, addressing vulnerabilities like the timewarp exploit and risks posed by crafted non-SegWit transactions. A notable aspect of the proposal includes adjusting retarget periods to counteract the timewarp vulnerability, aiming to secure the network against manipulation that could artificially lower mining difficulty. The suggestion to impose constraints on legacy Script usage and limit the size of legacy transactions seeks to enhance network efficiency by mitigating the risks associated with block validation times.
 
-The vulnerability associated with transactions under 64 bytes is particularly concerning for the integrity of light clients and the broader blockchain. To counteract this, invalidating such transactions emerges as a necessary measure. The collective effort to identify and amend longstanding bugs underscores a community-driven approach to fortifying Bitcoin's framework. While consensus changes like fixing Merkle tree calculation errors and ensuring the uniqueness of Coinbase transactions garner widespread support for their potential to bolster protocol integrity, contentious suggestions, notably the proposed reduction of the block size limit, spark considerable debate within the community.
+Furthermore, the proposal advocates for the invalidation of transactions of 64 bytes or less to protect light clients and maintain blockchain integrity, highlighting a proactive approach to resolving known vulnerabilities. Community input is emphasized as crucial in identifying and addressing long-standing bugs and inefficiencies, suggesting a collaborative effort towards refining Bitcoin's design.
 
-Further proposals seek to standardize technical aspects of the protocol, including enforcing specific SIGHASH type bytes for Segwit v0 transactions and setting limits on scriptPubKey sizes. These moves are intended to improve security and tackle scalability issues. However, these recommendations are met with caution, reflecting concerns over limiting functionality or diverging from established practices. This nuanced dialogue highlights the complexities of enhancing a foundational technology like Bitcoin, balancing between innovation, security, and maintaining the protocol's core principles.</summary>
-    <published>2024-11-04T21:06:02.107000+00:00</published>
+While the proposal outlines several consensus changes aimed at strengthening the protocol's integrity, such as fixing Merkle tree calculation issues and ensuring Coinbase transaction uniqueness, it also introduces contentious changes. The debate surrounding the reduction of the block size limit underscores concerns about its potential impact on network scalability and performance. Additional suggestions include standardizing technical elements like mandating standard SIGHASH type bytes for Segwit v0 transactions and limiting scriptPubKey sizes, which are intended to bolster security and address scalability challenges. However, these ideas face skepticism, reflecting caution towards modifications that might limit functionality or diverge from established norms in the Bitcoin community.</summary>
+    <published>2024-11-05T14:54:27.808000+00:00</published>
   </entry>
 </feed>

static/delvingbitcoin/Aug_2024/combined_Great-Consensus-Cleanup-Revival.xml

@@ -2,9 +2,12 @@
 <feed xmlns="http://www.w3.org/2005/Atom">
   <id>2</id>
   <title>Combined summary - Great Consensus Cleanup Revival</title>
-  <updated>2024-11-05T02:17:37.928041+00:00</updated>
+  <updated>2024-11-06T02:16:48.723797+00:00</updated>
   <author>
-    <name>AntoineP 2024-11-04 21:06:02.107000+00:00</name>
+    <name>AntoineP 2024-11-05 14:54:27.808000+00:00</name>
+  </author>
+  <author>
+    <name>AntoineP  . 2024-11-04 21:06:02.107000+00:00</name>
   </author>
   <author>
     <name>plebhash  . 2024-09-05 23:18:30.920000+00:00</name>
@@ -141,6 +144,7 @@
   <author>
     <name>AntoineP  . 2024-03-24 19:53:27.073000+00:00</name>
   </author>
+  <link href="delvingbitcoin/Nov_2024/3491_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Nov_2024/3480_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Sept_2024/3107_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Sept_2024/3100_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
@@ -191,13 +195,13 @@
   <entry>
     <id>2</id>
     <title>Combined summary - Great Consensus Cleanup Revival</title>
-    <updated>2024-11-05T02:17:37.928334+00:00</updated>
-    <link href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/47" rel="alternate"/>
-    <summary>The discussion surrounding the Bitcoin protocol's vulnerabilities and potential improvements is a multifaceted exploration of how to enhance network security and performance. At the heart of this discourse is Matt Corallo's Great Consensus Cleanup proposal, which identifies several key areas where the Bitcoin protocol could be refined. The timewarp vulnerability presents a significant risk, allowing for the artificial lowering of mining difficulty. By adjusting retarget periods, the proposal aims to safeguard the network against such exploits. Furthermore, the issue of maliciously crafted non-SegWit transactions that could prolong block validation times is addressed by proposing restrictions on legacy Script usage and capping the size of legacy transactions.
+    <updated>2024-11-06T02:16:48.724094+00:00</updated>
+    <link href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/48" rel="alternate"/>
+    <summary>The discussion delves into various proposals to improve the Bitcoin protocol's security and efficiency, addressing vulnerabilities like the timewarp exploit and risks posed by crafted non-SegWit transactions. A notable aspect of the proposal includes adjusting retarget periods to counteract the timewarp vulnerability, aiming to secure the network against manipulation that could artificially lower mining difficulty. The suggestion to impose constraints on legacy Script usage and limit the size of legacy transactions seeks to enhance network efficiency by mitigating the risks associated with block validation times.
 
-The vulnerability associated with transactions under 64 bytes is particularly concerning for the integrity of light clients and the broader blockchain. To counteract this, invalidating such transactions emerges as a necessary measure. The collective effort to identify and amend longstanding bugs underscores a community-driven approach to fortifying Bitcoin's framework. While consensus changes like fixing Merkle tree calculation errors and ensuring the uniqueness of Coinbase transactions garner widespread support for their potential to bolster protocol integrity, contentious suggestions, notably the proposed reduction of the block size limit, spark considerable debate within the community.
+Furthermore, the proposal advocates for the invalidation of transactions of 64 bytes or less to protect light clients and maintain blockchain integrity, highlighting a proactive approach to resolving known vulnerabilities. Community input is emphasized as crucial in identifying and addressing long-standing bugs and inefficiencies, suggesting a collaborative effort towards refining Bitcoin's design.
 
-Further proposals seek to standardize technical aspects of the protocol, including enforcing specific SIGHASH type bytes for Segwit v0 transactions and setting limits on scriptPubKey sizes. These moves are intended to improve security and tackle scalability issues. However, these recommendations are met with caution, reflecting concerns over limiting functionality or diverging from established practices. This nuanced dialogue highlights the complexities of enhancing a foundational technology like Bitcoin, balancing between innovation, security, and maintaining the protocol's core principles.</summary>
-    <published>2024-11-04T21:06:02.107000+00:00</published>
+While the proposal outlines several consensus changes aimed at strengthening the protocol's integrity, such as fixing Merkle tree calculation issues and ensuring Coinbase transaction uniqueness, it also introduces contentious changes. The debate surrounding the reduction of the block size limit underscores concerns about its potential impact on network scalability and performance. Additional suggestions include standardizing technical elements like mandating standard SIGHASH type bytes for Segwit v0 transactions and limiting scriptPubKey sizes, which are intended to bolster security and address scalability challenges. However, these ideas face skepticism, reflecting caution towards modifications that might limit functionality or diverge from established norms in the Bitcoin community.</summary>
+    <published>2024-11-05T14:54:27.808000+00:00</published>
   </entry>
 </feed>

static/delvingbitcoin/July_2024/combined_Great-Consensus-Cleanup-Revival.xml

@@ -2,9 +2,12 @@
 <feed xmlns="http://www.w3.org/2005/Atom">
   <id>2</id>
   <title>Combined summary - Great Consensus Cleanup Revival</title>
-  <updated>2024-11-05T02:17:37.928041+00:00</updated>
+  <updated>2024-11-06T02:16:48.723797+00:00</updated>
   <author>
-    <name>AntoineP 2024-11-04 21:06:02.107000+00:00</name>
+    <name>AntoineP 2024-11-05 14:54:27.808000+00:00</name>
+  </author>
+  <author>
+    <name>AntoineP  . 2024-11-04 21:06:02.107000+00:00</name>
   </author>
   <author>
     <name>plebhash  . 2024-09-05 23:18:30.920000+00:00</name>
@@ -141,6 +144,7 @@
   <author>
     <name>AntoineP  . 2024-03-24 19:53:27.073000+00:00</name>
   </author>
+  <link href="delvingbitcoin/Nov_2024/3491_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Nov_2024/3480_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Sept_2024/3107_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
   <link href="delvingbitcoin/Sept_2024/3100_Great-Consensus-Cleanup-Revival.xml" rel="alternate"/>
@@ -191,13 +195,13 @@
   <entry>
     <id>2</id>
     <title>Combined summary - Great Consensus Cleanup Revival</title>
-    <updated>2024-11-05T02:17:37.928334+00:00</updated>
-    <link href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/47" rel="alternate"/>
-    <summary>The discussion surrounding the Bitcoin protocol's vulnerabilities and potential improvements is a multifaceted exploration of how to enhance network security and performance. At the heart of this discourse is Matt Corallo's Great Consensus Cleanup proposal, which identifies several key areas where the Bitcoin protocol could be refined. The timewarp vulnerability presents a significant risk, allowing for the artificial lowering of mining difficulty. By adjusting retarget periods, the proposal aims to safeguard the network against such exploits. Furthermore, the issue of maliciously crafted non-SegWit transactions that could prolong block validation times is addressed by proposing restrictions on legacy Script usage and capping the size of legacy transactions.
+    <updated>2024-11-06T02:16:48.724094+00:00</updated>
+    <link href="https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/48" rel="alternate"/>
+    <summary>The discussion delves into various proposals to improve the Bitcoin protocol's security and efficiency, addressing vulnerabilities like the timewarp exploit and risks posed by crafted non-SegWit transactions. A notable aspect of the proposal includes adjusting retarget periods to counteract the timewarp vulnerability, aiming to secure the network against manipulation that could artificially lower mining difficulty. The suggestion to impose constraints on legacy Script usage and limit the size of legacy transactions seeks to enhance network efficiency by mitigating the risks associated with block validation times.
 
-The vulnerability associated with transactions under 64 bytes is particularly concerning for the integrity of light clients and the broader blockchain. To counteract this, invalidating such transactions emerges as a necessary measure. The collective effort to identify and amend longstanding bugs underscores a community-driven approach to fortifying Bitcoin's framework. While consensus changes like fixing Merkle tree calculation errors and ensuring the uniqueness of Coinbase transactions garner widespread support for their potential to bolster protocol integrity, contentious suggestions, notably the proposed reduction of the block size limit, spark considerable debate within the community.
+Furthermore, the proposal advocates for the invalidation of transactions of 64 bytes or less to protect light clients and maintain blockchain integrity, highlighting a proactive approach to resolving known vulnerabilities. Community input is emphasized as crucial in identifying and addressing long-standing bugs and inefficiencies, suggesting a collaborative effort towards refining Bitcoin's design.
 
-Further proposals seek to standardize technical aspects of the protocol, including enforcing specific SIGHASH type bytes for Segwit v0 transactions and setting limits on scriptPubKey sizes. These moves are intended to improve security and tackle scalability issues. However, these recommendations are met with caution, reflecting concerns over limiting functionality or diverging from established practices. This nuanced dialogue highlights the complexities of enhancing a foundational technology like Bitcoin, balancing between innovation, security, and maintaining the protocol's core principles.</summary>
-    <published>2024-11-04T21:06:02.107000+00:00</published>
+While the proposal outlines several consensus changes aimed at strengthening the protocol's integrity, such as fixing Merkle tree calculation issues and ensuring Coinbase transaction uniqueness, it also introduces contentious changes. The debate surrounding the reduction of the block size limit underscores concerns about its potential impact on network scalability and performance. Additional suggestions include standardizing technical elements like mandating standard SIGHASH type bytes for Segwit v0 transactions and limiting scriptPubKey sizes, which are intended to bolster security and address scalability challenges. However, these ideas face skepticism, reflecting caution towards modifications that might limit functionality or diverge from established norms in the Bitcoin community.</summary>
+    <published>2024-11-05T14:54:27.808000+00:00</published>
   </entry>
 </feed>