-
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
10 changed files
with
212 additions
and
38 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,24 +2,34 @@ | |
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-07T02:32:15.878133+00:00</updated> | ||
| <updated>2024-12-08T02:45:19.595748+00:00</updated> | ||
| <author> | ||
| <name>Yuval Kogman 2024-12-07 01:42:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>/dev /fd0 2024-12-07 00:29:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Jonas Nick 2024-12-06 21:45:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>/dev /fd 2024-11-29 14:08:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Dec_2024/m9514dfbbdecae448769fbbfb1698b1ab047de85b_Covenants-Support-Bitcoin-Wiki.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m44c625ff2928ddc0b2736b8b09abb218766c91cd_Covenants-Support-Bitcoin-Wiki.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m73f853879153d979a8c1d7bbc9ffcf9c0313c461_Covenants-Support-Bitcoin-Wiki.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Nov_2024/m91e5a68b8275a73acdcc8fc2276b9caf678fdab4_Covenants-Support-Bitcoin-Wiki.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 - Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-07T02:32:15.878173+00:00</updated> | ||
| <updated>2024-12-08T02:45:19.595816+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#u#m91e5a68b8275a73acdcc8fc2276b9caf678fdab4" rel="alternate"/> | ||
| <summary>The email initiates a dialogue concerning the current methodology employed for building consensus around Bitcoin covenant proposals, specifically critiquing the format modeled after the SegWit support page. It suggests that this approach inadequately facilitates rough consensus as per the guidelines of RFC 7282, which it recommends for a comprehensive understanding of consensus-building principles. The sender proposes significant modifications to enhance the process: firstly, by advocating for the separation of technical evaluation from community support, arguing that current ratings presuppose levels of support that could lead to biased outcomes. Secondly, it stresses the necessity of providing reasons for objections, recommending that each negative assessment be accompanied by detailed documentation of the concerns raised. This adjustment aims to foster constructive debate and more informed decision-making within the community. Lastly, the suggestion to add links to corresponding draft Bitcoin Improvement Proposals (BIPs) for all opcodes listed aims to offer a solid foundation for technical evaluations. | ||
| <summary>The email discussions revolve around the methodology for achieving consensus within the Bitcoin development community, particularly concerning covenant proposals and the SegWit support page. There is a pointed critique of the current system used to gauge community support and technical evaluation, suggesting that it falls short of fostering genuine consensus as outlined in RFC 7282. The critique highlights a misalignment between the approach taken on the SegWit support page and effective consensus-building principles. Specifically, the use of categories like "Deficient" and "Wanting," which presuppose community support levels, is seen as problematic. This method could inadvertently influence the outcome of proposals, leading to premature judgments rather than an unbiased assessment. To address these concerns, the email proposes eliminating such categories to allow for a more open evaluation process. Moreover, it emphasizes the need for transparency and detailed justification of objections, suggesting that negative evaluations be linked to comprehensive justifications covering technical shortcomings, potential for adoption, and decentralization implications. | ||
|
|
||
| In parallel, there's an initiative underway to compile developer opinions on various covenant proposals through a draft Bitcoin wiki page. This effort aims to replicate the SegWit page's consensus-building approach for soft forks. Contributors are encouraged to add relevant opcodes and their insights to the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Covenants_support), with an emphasis on the importance of linking to Bitcoin Improvement Proposal (BIP) drafts. Such links are deemed critical for providing context and clarity to technical evaluations. A notable mention in this context is the proposal for OP_CTV, highlighted through a presentation link ([Rationale for OP_CTV](https://notes.dunst.be/slide//2/slide/view/Ekky-cAegV9dSOaNOjH9TStNOmAnrhDDc9hxHlmRs5M/embed/present/)), which outlines its potential benefits for pools with covenants and joinstr implementations. | ||
|
|
||
| In a broader context, the email mentions the creation of a draft Bitcoin wiki page intended to compile developer insights on various covenant proposals. This initiative seeks to replicate the SegWit page's success in gathering support for soft forks related to Bitcoin's development. The wiki page, open for contributions from developers, is designed to be a platform for sharing opinions and technical evaluations. Developers are encouraged to list relevant opcodes, add their GitHub usernames, and articulate their positions on proposals such as OP_CheckTemplateVerify (OP_CTV). The latter is singled out for its potential benefits, including enhancing pools with covenants and improving implementations like coinjoin. A linked presentation provides further rationale for supporting OP_CTV, underlining its significance in the broader conversation about Bitcoin's evolution. The sender underscores the collaborative nature of this endeavor, aiming to simplify the consensus process towards the next soft fork and highlighting the collective work needed to identify and agree upon the most advantageous proposals.</summary> | ||
| <published>2024-12-06T21:45:00+00:00</published> | ||
| The collective effort to refine and agree upon the most beneficial proposals for the next soft fork is underscored, marking a significant push towards simplifying and enhancing the consensus-building process within the Bitcoin development community. This includes a reevaluation of how community support and technical merit are assessed, advocating for a more transparent, inclusive, and reasoned pathway toward achieving consensus.</summary> | ||
| <published>2024-12-07T01:42:00+00:00</published> | ||
| </entry> | ||
| </feed> | ||
22 changes: 22 additions & 0 deletions
22
...dev/Dec_2024/m44c625ff2928ddc0b2736b8b09abb218766c91cd_Covenants-Support-Bitcoin-Wiki.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-08T02:45:07.443214+00:00</updated> | ||
| <author> | ||
| <name>/dev /fd0 2024-12-07 00:29: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>Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-08T02:45:07.443250+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/CAAQdECALHHysr4PNRGXcFMCk5AjRDYgquUUUvuvwHGoeJDgZJA@mail.gmail.com/T/#m44c625ff2928ddc0b2736b8b09abb218766c91cd" rel="alternate"/> | ||
| <summary>In the recent communication on the Bitcoin Development Mailing List, Yuval Kogman outlined updates and clarifications regarding the process for sharing opinions on opcode proposals within the community. He highlighted that developers have seven options to express their stance on a proposal, with only two options indicating community support. These options allow developers to acknowledge a proposal as 'prefer' or 'acceptable', or to reject it with 'no'. Modifications have been made to three categories to refine their definitions, including removing the association of community support from the 'no' option and rephrasing 'prefer' and 'evaluating'. | ||
|
|
||
| Kogman also addressed the concerns about the potential impact of eliminating some categories, emphasizing the importance of maintaining the integrity of the existing system to avoid disruptions. He acknowledged the diverse perspectives within the Bitcoin developer community and advocated for allowing individuals the freedom to express their views, even if they choose to label a proposal as 'deficient' or 'wanting'. This approach underscores the value placed on diverse input and the desire to accommodate varying degrees of caution and scrutiny among contributors. | ||
|
|
||
| Furthermore, Kogman announced the upcoming addition of a feature that will enable contributors to include links to their rationale behind opinions on opcodes, enhancing transparency and understanding within the community. This update was previously mentioned on social media but had not been communicated through the mailing list. In addition to these procedural updates, Kogman has facilitated the inclusion of links to Bitcoin Improvement Proposal (BIP) drafts for all opcodes, ensuring that detailed information is accessible for thorough evaluation and discussion. This effort demonstrates a commitment to fostering informed participation and comprehensive review processes within the Bitcoin development ecosystem.</summary> | ||
| <published>2024-12-07T00:29:00+00:00</published> | ||
| </entry> | ||
| </feed> |
24 changes: 24 additions & 0 deletions
24
...dev/Dec_2024/m9514dfbbdecae448769fbbfb1698b1ab047de85b_Covenants-Support-Bitcoin-Wiki.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-08T02:44:58.648154+00:00</updated> | ||
| <author> | ||
| <name>Yuval Kogman 2024-12-07 01: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>Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-08T02:44:58.648188+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/CAAQdECALHHysr4PNRGXcFMCk5AjRDYgquUUUvuvwHGoeJDgZJA@mail.gmail.com/T/#m9514dfbbdecae448769fbbfb1698b1ab047de85b" rel="alternate"/> | ||
| <summary>The communication outlines a nuanced perspective on the process of gauging developer sentiments and community support for proposals within a technical or development environment. It highlights the complexity of accurately capturing a developer's technical assessment and their speculation on community support through a simplified voting system. The proposed system attempts to categorize opinions along two independent dimensions: technical merit and perceived community support. These dimensions are further broken down into options such as "no," "weak," "acceptable," and "prefer" for technical merit, alongside "sufficient" and "insufficient" for gauging community backing. | ||
|
|
||
| A significant issue identified is the conflation of these two distinct aspects into a single evaluative framework, which can lead to confusion and misinterpretation. For instance, a developer might personally favor a proposal but doubt its community support, a situation that the current model handles inadequately by merging these considerations. To address this, an expanded model is suggested that allows developers to abstain from commenting on community support while still expressing a technical opinion. This model introduces placeholders (represented by the symbol "⊥") for situations where a developer chooses not to, or cannot, speculate on community support or evaluate the technical merits, aiming to provide a more flexible and expressive framework. | ||
|
|
||
| Furthermore, the discussion references the Keynesian beauty contest ([Keynesian beauty contest](https://en.wikipedia.org/wiki/Keynesian_beauty_contest)), drawing parallels to the challenges of speculative evaluation based on perceptions of others' opinions. This analogy underlines the inherent difficulties in creating a fully ordered or objective ranking system based on subjective evaluations that involve speculation about collective opinions. The critique extends to the use of a color scheme in the existing system, which could inadvertently suggest a clarity or hierarchy that the nuanced nature of opinion and support does not warrant. | ||
|
|
||
| Overall, the message underscores the complexity of decision-making processes in collaborative environments and suggests that a more nuanced approach, which allows participants to express a range of opinions without forcing a binary choice, could be beneficial. This would acknowledge the layered reality of technical evaluations and community dynamics, reducing potential ambiguities and fostering a more inclusive and accurate reflection of diverse perspectives.</summary> | ||
| <published>2024-12-07T01:42:00+00:00</published> | ||
| </entry> | ||
| </feed> |
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,24 +2,34 @@ | |
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-07T02:32:15.878133+00:00</updated> | ||
| <updated>2024-12-08T02:45:19.595748+00:00</updated> | ||
| <author> | ||
| <name>Yuval Kogman 2024-12-07 01:42:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>/dev /fd0 2024-12-07 00:29:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>Jonas Nick 2024-12-06 21:45:00+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>/dev /fd 2024-11-29 14:08:00+00:00</name> | ||
| </author> | ||
| <link href="bitcoin-dev/Dec_2024/m9514dfbbdecae448769fbbfb1698b1ab047de85b_Covenants-Support-Bitcoin-Wiki.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m44c625ff2928ddc0b2736b8b09abb218766c91cd_Covenants-Support-Bitcoin-Wiki.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Dec_2024/m73f853879153d979a8c1d7bbc9ffcf9c0313c461_Covenants-Support-Bitcoin-Wiki.xml" rel="alternate"/> | ||
| <link href="bitcoin-dev/Nov_2024/m91e5a68b8275a73acdcc8fc2276b9caf678fdab4_Covenants-Support-Bitcoin-Wiki.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 - Covenants Support - Bitcoin Wiki</title> | ||
| <updated>2024-12-07T02:32:15.878173+00:00</updated> | ||
| <updated>2024-12-08T02:45:19.595816+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/[email protected]/T/#u#m91e5a68b8275a73acdcc8fc2276b9caf678fdab4" rel="alternate"/> | ||
| <summary>The email initiates a dialogue concerning the current methodology employed for building consensus around Bitcoin covenant proposals, specifically critiquing the format modeled after the SegWit support page. It suggests that this approach inadequately facilitates rough consensus as per the guidelines of RFC 7282, which it recommends for a comprehensive understanding of consensus-building principles. The sender proposes significant modifications to enhance the process: firstly, by advocating for the separation of technical evaluation from community support, arguing that current ratings presuppose levels of support that could lead to biased outcomes. Secondly, it stresses the necessity of providing reasons for objections, recommending that each negative assessment be accompanied by detailed documentation of the concerns raised. This adjustment aims to foster constructive debate and more informed decision-making within the community. Lastly, the suggestion to add links to corresponding draft Bitcoin Improvement Proposals (BIPs) for all opcodes listed aims to offer a solid foundation for technical evaluations. | ||
| <summary>The email discussions revolve around the methodology for achieving consensus within the Bitcoin development community, particularly concerning covenant proposals and the SegWit support page. There is a pointed critique of the current system used to gauge community support and technical evaluation, suggesting that it falls short of fostering genuine consensus as outlined in RFC 7282. The critique highlights a misalignment between the approach taken on the SegWit support page and effective consensus-building principles. Specifically, the use of categories like "Deficient" and "Wanting," which presuppose community support levels, is seen as problematic. This method could inadvertently influence the outcome of proposals, leading to premature judgments rather than an unbiased assessment. To address these concerns, the email proposes eliminating such categories to allow for a more open evaluation process. Moreover, it emphasizes the need for transparency and detailed justification of objections, suggesting that negative evaluations be linked to comprehensive justifications covering technical shortcomings, potential for adoption, and decentralization implications. | ||
|
|
||
| In parallel, there's an initiative underway to compile developer opinions on various covenant proposals through a draft Bitcoin wiki page. This effort aims to replicate the SegWit page's consensus-building approach for soft forks. Contributors are encouraged to add relevant opcodes and their insights to the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Covenants_support), with an emphasis on the importance of linking to Bitcoin Improvement Proposal (BIP) drafts. Such links are deemed critical for providing context and clarity to technical evaluations. A notable mention in this context is the proposal for OP_CTV, highlighted through a presentation link ([Rationale for OP_CTV](https://notes.dunst.be/slide//2/slide/view/Ekky-cAegV9dSOaNOjH9TStNOmAnrhDDc9hxHlmRs5M/embed/present/)), which outlines its potential benefits for pools with covenants and joinstr implementations. | ||
|
|
||
| In a broader context, the email mentions the creation of a draft Bitcoin wiki page intended to compile developer insights on various covenant proposals. This initiative seeks to replicate the SegWit page's success in gathering support for soft forks related to Bitcoin's development. The wiki page, open for contributions from developers, is designed to be a platform for sharing opinions and technical evaluations. Developers are encouraged to list relevant opcodes, add their GitHub usernames, and articulate their positions on proposals such as OP_CheckTemplateVerify (OP_CTV). The latter is singled out for its potential benefits, including enhancing pools with covenants and improving implementations like coinjoin. A linked presentation provides further rationale for supporting OP_CTV, underlining its significance in the broader conversation about Bitcoin's evolution. The sender underscores the collaborative nature of this endeavor, aiming to simplify the consensus process towards the next soft fork and highlighting the collective work needed to identify and agree upon the most advantageous proposals.</summary> | ||
| <published>2024-12-06T21:45:00+00:00</published> | ||
| The collective effort to refine and agree upon the most beneficial proposals for the next soft fork is underscored, marking a significant push towards simplifying and enhancing the consensus-building process within the Bitcoin development community. This includes a reevaluation of how community support and technical merit are assessed, advocating for a more transparent, inclusive, and reasoned pathway toward achieving consensus.</summary> | ||
| <published>2024-12-07T01:42:00+00:00</published> | ||
| </entry> | ||
| </feed> | ||
Oops, something went wrong.