-
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
12 changed files
with
534 additions
and
65 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,7 +2,10 @@ | |
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Mandatory Inclusion of Old Transactions in Blocks</title> | ||
| <updated>2024-12-30T02:24:40.775903+00:00</updated> | ||
| <updated>2025-01-10T02:25:45.035585+00:00</updated> | ||
| <author> | ||
| <name>Jameson Lopp 2025-01-09 12:24:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>developer 2024-12-29 16:35:00+00:00</name> | ||
| </author> | ||
|
|
@@ -21,6 +24,7 @@ | |
| <author> | ||
| <name>developer 2024-12-28 15:54:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Jan_2025/md45faf348c4d6ff9b7a87019770ad6967382bd2a_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m79b93d3c8f40715707d41cd1b4a2e8158496005e_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m38744997198e453612c8f1ea4e6ab316adc29c59_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m126ba2a532db9769c52f3cae2aeaf3bafb3bf937_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
|
|
@@ -31,15 +35,15 @@ | |
| <entry> | ||
| <id>2</id> | ||
| <title>Combined summary - Mandatory Inclusion of Old Transactions in Blocks</title> | ||
| <updated>2024-12-30T02:24:40.775964+00:00</updated> | ||
| <updated>2025-01-10T02:25:45.035651+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#mc0ab2bf99af67117f9cb23eca68107d7bccea3e1" rel="alternate"/> | ||
| <summary>The recent discussions and proposals regarding the Bitcoin network focus on enhancing its robustness against censorship, centralization, and the challenges in maintaining a decentralized and fair transaction confirmation process. A notable suggestion involves adjusting the Bitcoin protocol to ensure that miners include a small percentage of the oldest transactions in each block they mine, specifically targeting those with potentially lower fees than the current market average. This approach aims to combat mining centralization and mitigate potential regulatory pressures that could lead to transaction censorship or exclusion based on fee size. The proposal specifies that every mined block must contain at least 0.1% of transactions selected from the oldest in the mempool, prioritizing their age over the fees offered. This requirement is designed to discourage miners from omitting transactions for personal gain or due to external pressures, thereby promoting inclusivity and fairness in the transaction validation process. | ||
| <summary>The recent discussions on the Bitcoin Development Mailing List have sparked significant interest in the potential for adjusting the way transactions are processed and confirmed within the Bitcoin network. A major focus of these conversations has been on the utilization of the "nLockTime" feature, which traditionally is set to zero, suggesting its innovative application could enhance the protocol's resilience against control and censorship by indicating a transaction's readiness for immediate block inclusion. This proposal leverages legal and existing functionalities of the Bitcoin protocol, aiming to refine the transaction selection process currently based on fee rates. By introducing a dual sorting mechanism that considers both the transaction fee rate and "nLockTime," the proposal suggests older transactions with lower fees may have a better opportunity to get included in a block, potentially reducing mempool stagnation. | ||
|
|
||
| Furthermore, the dialogue within the Bitcoin Development Mailing List emphasizes the technical intricacies and theoretical debates surrounding the management of mempools across different nodes. It highlights the critical challenge of achieving consensus on the visibility and processing order of transactions, given the decentralized nature of blockchain networks. Critics argue that mandating miners to prioritize older transactions could lead to inconsistencies in transaction recognition and potentially cause regular chainsplits, undermining the blockchain's integrity. This critique rests on the foundational principle of blockchain technology, where mining plays an essential role in reaching consensus on transaction history, emphasizing the difficulty of universally agreeing on transaction order without centralized control. | ||
| Further exploration into the technical challenges reveals concerns about achieving consensus on the oldest transactions, a key factor in advancing the proposal's practicality. The conversation acknowledges the complexity of this issue, mirroring the consensus process already inherent in Bitcoin but also highlights the necessity of further innovation before considering it mature enough for a formal Bitcoin Improvement Proposal (BIP). Critics of the proposed system argue it could lead to regular chainsplits due to discrepancies in transaction visibility across nodes, emphasizing the blockchain's reliance on mining to achieve consensus on transaction history. This critique underscores the fundamental challenges in altering the transaction confirmation process and the essential role of mining in maintaining the integrity of the blockchain. | ||
|
|
||
| Additionally, feedback on the proposed Bitcoin Improvement Proposal (BIP) points out significant technical and philosophical hurdles that need addressing before such ideas can be considered viable. Key issues include the lack of consensus within the community regarding how unconfirmed transactions are handled and the overlooked necessity of associating accurate timestamps with transactions. These concerns reflect the stringent criteria and rigorous scrutiny that any changes to the Bitcoin protocol must undergo to ensure they enhance the network's security, reliability, and decentralization. | ||
| A specific proposal discussed mandates Bitcoin miners to include a minimum percentage of the oldest transactions in their blocks, irrespective of the fee levels, aiming to combat mining centralization and censorship. The specification requires each miner to ensure their blocks contain at least 0.1% of transactions from the oldest in the mempool, promoting a democratic processing approach. This initiative addresses concerns over mining centralization and regulatory pressures that might influence transaction selection. By enforcing the inclusion of older, possibly lower-fee transactions, the proposal seeks to prevent exclusion based on fee size alone, enhancing the fairness and inclusivity of the transaction confirmation process. | ||
|
|
||
| In summary, these discussions and proposals shed light on the ongoing efforts to refine and improve the Bitcoin network's resilience against external pressures and internal vulnerabilities. By considering innovative mechanisms to ensure fair transaction processing and prevent censorship, the community continues to explore ways to preserve the decentralized ethos of Bitcoin. However, the path forward requires careful analysis, broad consensus, and a deep understanding of the potential impacts on the network's dynamics and overall security posture.</summary> | ||
| <published>2024-12-29T16:35:00+00:00</published> | ||
| The proposal outlines several anticipated benefits, including increased censorship resistance, promotion of decentralization by reducing centralized control over the network, and improvement in the mempool's dynamics by facilitating the confirmation of old and low-fee transactions. However, it also necessitates miners adjusting their resource management practices to identify and include these specified transactions automatically. Ultimately, the proposal advocates for a more equitable Bitcoin network, ensuring all transactions have a fair chance of being confirmed without bias towards higher fees, thereby maintaining the network's integrity and decentralization.</summary> | ||
| <published>2025-01-09T12:24:00+00:00</published> | ||
| </entry> | ||
| </feed> | ||
49 changes: 49 additions & 0 deletions
49
static/bitcoin-dev/Jan_2025/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.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,49 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Mandatory Inclusion of Old Transactions in Blocks</title> | ||
| <updated>2025-01-10T02:25:45.035585+00:00</updated> | ||
| <author> | ||
| <name>Jameson Lopp 2025-01-09 12:24:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>developer 2024-12-29 16:35:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Ethan Heilman 2024-12-28 18:48:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Owen Kemeys 2024-12-28 16:23:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Luke Dashjr 2024-12-28 16:22:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>developer 2024-12-28 16:15:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>developer 2024-12-28 15:54:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Jan_2025/md45faf348c4d6ff9b7a87019770ad6967382bd2a_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m79b93d3c8f40715707d41cd1b4a2e8158496005e_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m38744997198e453612c8f1ea4e6ab316adc29c59_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m126ba2a532db9769c52f3cae2aeaf3bafb3bf937_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/mc0472634b3df4ec00cee5a756ffb1fe6605da00d_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m82cfaeeb4a170cab2618e71893e84c5395a9ed3c_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/mc0ab2bf99af67117f9cb23eca68107d7bccea3e1_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.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 - Mandatory Inclusion of Old Transactions in Blocks</title> | ||
| <updated>2025-01-10T02:25:45.035651+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#mc0ab2bf99af67117f9cb23eca68107d7bccea3e1" rel="alternate"/> | ||
| <summary>The recent discussions on the Bitcoin Development Mailing List have sparked significant interest in the potential for adjusting the way transactions are processed and confirmed within the Bitcoin network. A major focus of these conversations has been on the utilization of the "nLockTime" feature, which traditionally is set to zero, suggesting its innovative application could enhance the protocol's resilience against control and censorship by indicating a transaction's readiness for immediate block inclusion. This proposal leverages legal and existing functionalities of the Bitcoin protocol, aiming to refine the transaction selection process currently based on fee rates. By introducing a dual sorting mechanism that considers both the transaction fee rate and "nLockTime," the proposal suggests older transactions with lower fees may have a better opportunity to get included in a block, potentially reducing mempool stagnation. | ||
|
|
||
| Further exploration into the technical challenges reveals concerns about achieving consensus on the oldest transactions, a key factor in advancing the proposal's practicality. The conversation acknowledges the complexity of this issue, mirroring the consensus process already inherent in Bitcoin but also highlights the necessity of further innovation before considering it mature enough for a formal Bitcoin Improvement Proposal (BIP). Critics of the proposed system argue it could lead to regular chainsplits due to discrepancies in transaction visibility across nodes, emphasizing the blockchain's reliance on mining to achieve consensus on transaction history. This critique underscores the fundamental challenges in altering the transaction confirmation process and the essential role of mining in maintaining the integrity of the blockchain. | ||
|
|
||
| A specific proposal discussed mandates Bitcoin miners to include a minimum percentage of the oldest transactions in their blocks, irrespective of the fee levels, aiming to combat mining centralization and censorship. The specification requires each miner to ensure their blocks contain at least 0.1% of transactions from the oldest in the mempool, promoting a democratic processing approach. This initiative addresses concerns over mining centralization and regulatory pressures that might influence transaction selection. By enforcing the inclusion of older, possibly lower-fee transactions, the proposal seeks to prevent exclusion based on fee size alone, enhancing the fairness and inclusivity of the transaction confirmation process. | ||
|
|
||
| The proposal outlines several anticipated benefits, including increased censorship resistance, promotion of decentralization by reducing centralized control over the network, and improvement in the mempool's dynamics by facilitating the confirmation of old and low-fee transactions. However, it also necessitates miners adjusting their resource management practices to identify and include these specified transactions automatically. Ultimately, the proposal advocates for a more equitable Bitcoin network, ensuring all transactions have a fair chance of being confirmed without bias towards higher fees, thereby maintaining the network's integrity and decentralization.</summary> | ||
| <published>2025-01-09T12:24:00+00:00</published> | ||
| </entry> | ||
| </feed> |
28 changes: 28 additions & 0 deletions
28
...oin-dev/Jan_2025/m84ccc38c755e241887897b660cdcc51e7873d9e6_Bitcoin-Core-28-1-Released.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,28 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>0</id> | ||
| <title>Bitcoin Core 28.1 Released</title> | ||
| <updated>2025-01-10T02:26:16.738018+00:00</updated> | ||
| <author> | ||
| <name>Ava Chow 2025-01-09 19:02:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>0</id> | ||
| <title>Bitcoin Core 28.1 Released</title> | ||
| <updated>2025-01-10T02:26:16.738050+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#u#m84ccc38c755e241887897b660cdcc51e7873d9e6" rel="alternate"/> | ||
| <summary>Bitcoin Core version 28.1 has been released and is available for download from [Bitcoin Core's official website](https://bitcoincore.org/bin/bitcoin-core-28.1) or via BitTorrent with the provided magnet link. This update introduces new features, various bug fixes, performance improvements, and updated translations. Users are encouraged to report any bugs they encounter using the project's GitHub issue tracker at [https://github.com/bitcoin/bitcoin/issues](https://github.com/bitcoin/bitcoin/issues). Additionally, those interested can join the announcement list through [this link](https://bitcoincore.org/en/list/announcements/join/). | ||
|
|
||
| For users upgrading from an older version of Bitcoin Core, it's recommended to shut down the existing application completely before proceeding with the installation of version 28.1. The upgrade process may require extra time if migrating from a version that has reached its end of life (EOL), particularly if the data directory needs to be migrated. It's noted that old wallet versions are generally supported by Bitcoin Core. Specific steps are provided for macOS users regarding self-signing of the Bitcoin Core binaries to comply with macOS security policies. | ||
|
|
||
| Bitcoin Core version 28.1 boasts compatibility with Linux Kernel version 3.17+, macOS 11.0+, and Windows 7 or newer. While the software may operate on other UNIX-like systems, these environments are not as rigorously tested, and using Bitcoin Core on unsupported systems is not recommended. | ||
|
|
||
| Significant changes in this release include adjustments to peer-to-peer (P2P) configurations. Specifically, when using the `-port` option, the default onion listening port will now increment by one from the specified port rather than being fixed to a default value. This modification aims to avoid startup failures due to port collisions in setups running multiple local nodes with distinct ports without using the `-bind` option. Further details are provided for users who manually configure their Tor `HiddenServicePort`, suggesting necessary adjustments to accommodate the new port derivation logic. | ||
|
|
||
| Additional updates encompass internal ID counting changes within addrman to int64_t, enhancements to key handling and secret data clearance in DecodeExtKey, and various build system improvements, including adjustments for mingw cross-compilation and NetBSD. The release also includes test enhancements, documentation updates, and miscellaneous code refactorings. | ||
|
|
||
| Contributors to this release, including both direct contributions and assistance with translations, are acknowledged, highlighting the collaborative effort behind Bitcoin Core's ongoing development.</summary> | ||
| <published>2025-01-09T19:02:00+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...f348c4d6ff9b7a87019770ad6967382bd2a_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.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>Mandatory Inclusion of Old Transactions in Blocks</title> | ||
| <updated>2025-01-10T02:25:25.420390+00:00</updated> | ||
| <author> | ||
| <name>Jameson Lopp 2025-01-09 12:24: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>Mandatory Inclusion of Old Transactions in Blocks</title> | ||
| <updated>2025-01-10T02:25:25.420416+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#md45faf348c4d6ff9b7a87019770ad6967382bd2a" rel="alternate"/> | ||
| <summary>The email discusses concerns regarding the reliability of timestamp data, such as nLockTime, in Bitcoin transactions. The sender highlights a significant flaw in the proposal related to transaction prioritization based on timestamp data. They point out that adversaries could exploit this system by deliberately setting their transactions' nLockTime to dates far in the past. This manipulation would enable them to benefit unfairly from the prioritization rules. Furthermore, the email anticipates a problematic scenario where more users start employing the same tactic, leading to a widespread gaming of the system. Such behavior would result in a "race to the bottom," ultimately rendering the new prioritization rules ineffective. This insight was shared within the context of a discussion on the Bitcoin Development Mailing List, indicating the sender's intention to address a potential vulnerability in the proposed system and stimulate further deliberation on securing transaction timestamp integrity.</summary> | ||
| <published>2025-01-09T12:24:00+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.