* [bitcoin-dev] BIP process friction
@ 2024-01-17 2:42 Anthony Towns
2024-01-17 6:55 ` Christopher Allen
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Anthony Towns @ 2024-01-17 2:42 UTC (permalink / raw)
To: bitcoin-dev
Hi all,
Just under three years ago there was some discussion about the BIPs repo,
with the result that Kalle became a BIPs editor in addition to Luke, eg:
* https://gnusha.org/bitcoin-core-dev/2021-04-22.log
* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html
It remains, however, quite hard to get BIPs merged into the repo, eg
the following PRs have been open for quite some time:
* #1408: Ordinal Numbers; opened 2023-01-21, editors comments:
Kalle:
https://github.com/bitcoin/bips/pull/1408#issuecomment-1421641390
https://github.com/bitcoin/bips/pull/1408#issuecomment-1435389476
Luke:
https://github.com/bitcoin/bips/pull/1408#issuecomment-1429146796
https://github.com/bitcoin/bips/pull/1408#issuecomment-1438831607
https://github.com/bitcoin/bips/pull/1408#issuecomment-1465016571
* #1489: Taproot Assets Protocol; opened 2023-09-07, editors comments:
Kalle: https://github.com/bitcoin/bips/pull/1489#issuecomment-1855079626
Luke: https://github.com/bitcoin/bips/pull/1489#issuecomment-1869721535j
* #1500: OP_TXHASH; opened 2023-09-30, editors comments:
Luke:
https://github.com/bitcoin/bips/pull/1500#pullrequestreview-1796550166
https://twitter.com/LukeDashjr/status/1735701932520382839
The range of acceptable BIPs seems to also be becoming more limited,
such that mempool/relay policy is out of scope:
* https://github.com/bitcoin/bips/pull/1524#issuecomment-1869734387
Despite having two editors, only Luke seems to be able to assign new
numbers to BIPs, eg:
* https://github.com/bitcoin/bips/pull/1458#issuecomment-1597917780
There's also been some not very productive delays due to the editors
wanting backwards compatibility sections even if authors don't think
that's necessary, eg:
* https://github.com/bitcoin/bips/pull/1372#issuecomment-1439132867
Even working out whether to go back to allowing markdown as a text format
is a multi-month slog due to process confusion:
* https://github.com/bitcoin/bips/pull/1504
Anyway, while it's not totally dysfunctional, it's very high friction.
There are a variety of recent proposals that have PRs open against
inquisition; up until now I've been suggesting people write a BIP, and
have been keying off the BIP number to signal activation. But that just
seems to be introducing friction, when all I need is a way of linking
an arbitrary number to a spec.
So I'm switching inquisition over to having a dedicated "IANA"-ish
thing that's independent of BIP process nonsense. It's at:
* https://github.com/bitcoin-inquisition/binana
If people want to use it for bitcoin-related proposals that don't have
anything to do with inquisition, that's fine; I'm intending to apply the
policies I think the BIPs repo should be using, so feel free to open a PR,
even if you already know I think your idea is BS on its merits. If someone
wants to write an automatic-merge-bot for me, that'd also be great.
If someone wants to reform the BIPs repo itself so it works better,
that'd be even better, but I'm not volunteering for that fight.
Cheers,
aj
(It's called "numbers and names" primarily because that way the acronym
amuses me, but also in case inquisition eventually needs an authoritative
dictionary for what "cat" or "txhash" or similar terms refer to)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-17 2:42 [bitcoin-dev] BIP process friction Anthony Towns
@ 2024-01-17 6:55 ` Christopher Allen
2024-01-17 16:45 ` Luke Dashjr
2024-01-18 15:41 ` David A. Harding
2024-01-18 16:47 ` alicexbt
2 siblings, 1 reply; 11+ messages in thread
From: Christopher Allen @ 2024-01-17 6:55 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]
On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine; I'm intending to apply the
> policies I think the BIPs repo should be using, so feel free to open a PR,
> even if you already know I think your idea is BS on its merits. If someone
> wants to write an automatic-merge-bot for me, that'd also be great.
>
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
>
I've no idea how to reform BIPs, but we have a similar problem with the
Blockchain Commons Research (BCR) vs Proposals (BCP), vs. specifications
that are emerging in various other standards groups (IETF, W3C, and we have
desire to submit some of these as BIPs as well).
We do a few things differently, one of which in particular might be useful
for the future of BIPs: we reset the numbers every year. So the first new
BCR (research proposal) for 2024 would be 2024-01. Also, when there is a
major change in an old BCR, we create a new number for it in the new year
it is update.
We also have a concept called "Status", which is a progression that only
moves forward if BCRs are actually implemented with a reference
implementation, and advances further when they have multiple
implementations (and thus are qualified moved over to BCP repo as it is
somewhat stable and no longer "research".). A last form is when a
specification has moved to be controlled by another standards group (such
as a BIP). If only one organization implements a BCR, it will never advance
to BCP.
Some form of Status for BIPs inspired by this concept could track if a BIP
was ever actually implemented by someone, or more ideally, implemented by
multiple people in multiple organizations, ideally in multiple languages.
Here is how we currently do status, and the status of our current
specifications:
https://github.com/BlockchainCommons/Research/blob/master/README.md#status
Each BCR has a status which is indicated by a symbol.
SymbolTitleDescription
❌❌ Withdrawn Of historic interest only. Withdrawn either because never came
into use or proved sufficiently problematic that we do not recommend its
usage in any way.
❌ Superseded Superseded by a newer BCR. We do not suggest implementing as
an output format, but you may still wish to implement as an input format to
maintain backward compatibility.
📙 Research Contains original research or proposes specifications that have
not yet been implemented by us. Offered to the community for consideration.
⭐️ Reference Implementation At least one reference implementation has been
released, usually as a library, and may include demos or other supporting
tools. This specification still remains very open to change because it has
not yet (to our knowledge) been implemented by additional parties.
⭐️⭐️ Multiple Implementations At least two (known) implementations exist,
at least one not by the owner of the reference implementation. Has
demonstrable community support. May still change due to the needs of the
community, but community feedback will be sought.
⭐️⭐️⭐️ Standards Track Typically at least two implementations, and is
considered stable and ready for standardization. Being proposed as a BIP,
IETF Internet Draft, or some other standardization draft format. Will
typically be moved to the BCP repo
<https://github.com/BlockchainCommons/bcps>. Though changes may still be
made to the specification, these changes will exclusively be to allow for
standardization, and will be conducted with community feedback.
⭐️⭐️⭐️⭐️ Standardized A specification has been standardized as a an IETF
RFC, BIP, or approved by some other standards body.
❌❌ after another status symbol is read, "...but withdrawn" and ❌ is read,
"...but superseded".
-- Christopher Allen
[-- Attachment #2: Type: text/html, Size: 11496 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-17 6:55 ` Christopher Allen
@ 2024-01-17 16:45 ` Luke Dashjr
2024-01-17 17:29 ` Michael Folkson
0 siblings, 1 reply; 11+ messages in thread
From: Luke Dashjr @ 2024-01-17 16:45 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4673 bytes --]
Perhaps a BIP 3 is in order, but most of the real issue is simply a
matter of volunteer time.
AJ's attempt to conflate that with his own personal disagreements with
how BIPs have always worked, is unrelated.
Luke
On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote:
>
>
> On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine; I'm intending to
> apply the
> policies I think the BIPs repo should be using, so feel free to
> open a PR,
> even if you already know I think your idea is BS on its merits. If
> someone
> wants to write an automatic-merge-bot for me, that'd also be great.
>
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
>
>
> I've no idea how to reform BIPs, but we have a similar problem with
> the Blockchain Commons Research (BCR) vs Proposals (BCP), vs.
> specifications that are emerging in various other standards groups
> (IETF, W3C, and we have desire to submit some of these as BIPs as well).
>
> We do a few things differently, one of which in particular might be
> useful for the future of BIPs: we reset the numbers every year. So the
> first new BCR (research proposal) for 2024 would be 2024-01. Also,
> when there is a major change in an old BCR, we create a new number for
> it in the new year it is update.
>
> We also have a concept called "Status", which is a progression that
> only moves forward if BCRs are actually implemented with a reference
> implementation, and advances further when they have multiple
> implementations (and thus are qualified moved over to BCP repo as it
> is somewhat stable and no longer "research".). A last form is when a
> specification has moved to be controlled by another standards group
> (such as a BIP). If only one organization implements a BCR, it will
> never advance to BCP.
>
> Some form of Status for BIPs inspired by this concept could track if a
> BIP was ever actually implemented by someone, or more ideally,
> implemented by multiple people in multiple organizations, ideally in
> multiple languages.
>
> Here is how we currently do status, and the status of our current
> specifications:
> https://github.com/BlockchainCommons/Research/blob/master/README.md#status
>
> Each BCR has a status which is indicated by a symbol.
>
> Symbol Title Description
> ❌❌ Withdrawn Of historic interest only. Withdrawn either because
> never came into use or proved sufficiently problematic that we do not
> recommend its usage in any way.
> ❌ Superseded Superseded by a newer BCR. We do not suggest
> implementing as an output format, but you may still wish to implement
> as an input format to maintain backward compatibility.
> 📙 Research Contains original research or proposes specifications
> that have not yet been implemented by us. Offered to the community for
> consideration.
> ⭐️ Reference Implementation At least one reference implementation
> has been released, usually as a library, and may include demos or
> other supporting tools. This specification still remains very open to
> change because it has not yet (to our knowledge) been implemented by
> additional parties.
> ⭐️⭐️ Multiple Implementations At least two (known) implementations
> exist, at least one not by the owner of the reference implementation.
> Has demonstrable community support. May still change due to the needs
> of the community, but community feedback will be sought.
> ⭐️⭐️⭐️ Standards Track Typically at least two implementations, and
> is considered stable and ready for standardization. Being proposed as
> a BIP, IETF Internet Draft, or some other standardization draft
> format. Will typically be moved to theBCP repo
> <https://github.com/BlockchainCommons/bcps>. Though changes may still
> be made to the specification, these changes will exclusively be to
> allow for standardization, and will be conducted with community feedback.
> ⭐️⭐️⭐️⭐️ Standardized A specification has been standardized as a an
> IETF RFC, BIP, or approved by some other standards body.
>
> ❌❌ after another status symbol is read, "...but withdrawn" and ❌ is
> read, "...but superseded".
>
> -- Christopher Allen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 9170 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-17 16:45 ` Luke Dashjr
@ 2024-01-17 17:29 ` Michael Folkson
2024-01-18 18:00 ` Peter Todd
0 siblings, 1 reply; 11+ messages in thread
From: Michael Folkson @ 2024-01-17 17:29 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 8960 bytes --]
Hey Luke
I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this issue and others that are repeatedly cropping up (e.g. confusion on the recommended flow for working on proposed consensus changes, when to open a pull request to bitcoin-inquisition, when to open a pull request to Core, when to include/exclude activation params etc).
I don't think there is much I personally disagree with you on with regards to BIPs but one issue where I do think there is disagreement is on whether proposed default policy changes can/should be BIPed.
I previously drafted this on proposed default policy changes [2]:
"To address problems such as pinning attacks on Lightning and multiparty protocols (e.g. vaults) there are and will continue to be draft proposals on changing the default policy rules in Bitcoin Core and/or alternative implementations. As these proposals are for default policy rules and **not** consensus rules there is absolutely no obligation for Bitcoin Core and/or alternative implementations to change their default policy rules nor users to run any particular policy rules (default or otherwise). The authors of these draft proposals are clearly recommending what they think the default policy rules should be and what policy rules users should run but it is merely a recommendation. There are a lot of moving parts, subtleties and complexities involved in designing default policy rules so any recommendation(s) to significantly upgrade default policy rules would benefit from being subject to a spec process. This would also aid the review of any policy related pull requests in Bitcoin Core and/or alternative implementations. An interesting recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bitcoin Core not implementing the exact wording of BIP 125 RBF. In this case (for various reasons) as a response Bitcoin Core just removed references to BIP 125 and started documenting the replacement to BIP 125 rules in the Bitcoin Core repo instead. However, it is my view that recommendations for default policy rules should be recommendations to all implementations, reviewed by Lightning and multiparty protocol developers (not just Bitcoin Core) and hence they would benefit from being standardized and being subject to a specification process. I will reiterate once again though that policy rules are **not** consensus rules. Consensus rules are much closer to an obligation as divergences from consensus rules risk the user being forked off the blockchain and could ultimately end up in network splits. This does not apply to policy rules."
Are you open to adjusting your stance on proposed policy changes being BIPed? I do think it really stunts work on proposed default policy changes and people's ability to follow work on these proposals when the specifications for them are littered all over the place. I've certainly struggled to follow the latest state of V3 policy proposals without clear reference points for the latest state of these proposals e.g. [3]. In addition some proposed consensus change BIPs are starting to want to include sections on policy (e.g. BIP345, OP_VAULT [4]) where it would be much better if they could just refer to a separate policy BIP rather than including proposals for both policy and consensus in the same BIP.
Thanks for your long and continued work on the BIP process. It is thankless work and we don't see the alternative futures where all sorts of garbage was merged and given BIP numbers because the BIP editors just merged everything without looking at it and not caring about quality standards.
Thanks
Michael
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html
[1]: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
[2]: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist#default-policy-changes-eg-v3-a-recommendation-but-not-an-obligation-for-bitcoin-implementations
[3]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy
[4]: https://github.com/bitcoin/bips/pull/1421
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
On Wednesday, 17 January 2024 at 16:45, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Perhaps a BIP 3 is in order, but most of the real issue is simply a matter of volunteer time.
>
> AJ's attempt to conflate that with his own personal disagreements with how BIPs have always worked, is unrelated.
>
> Luke
>
> On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote:
>
>> On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> If people want to use it for bitcoin-related proposals that don't have
>>> anything to do with inquisition, that's fine; I'm intending to apply the
>>> policies I think the BIPs repo should be using, so feel free to open a PR,
>>> even if you already know I think your idea is BS on its merits. If someone
>>> wants to write an automatic-merge-bot for me, that'd also be great.
>>>
>>> If someone wants to reform the BIPs repo itself so it works better,
>>> that'd be even better, but I'm not volunteering for that fight.
>>
>> I've no idea how to reform BIPs, but we have a similar problem with the Blockchain Commons Research (BCR) vs Proposals (BCP), vs. specifications that are emerging in various other standards groups (IETF, W3C, and we have desire to submit some of these as BIPs as well).
>>
>> We do a few things differently, one of which in particular might be useful for the future of BIPs: we reset the numbers every year. So the first new BCR (research proposal) for 2024 would be 2024-01. Also, when there is a major change in an old BCR, we create a new number for it in the new year it is update.
>>
>> We also have a concept called "Status", which is a progression that only moves forward if BCRs are actually implemented with a reference implementation, and advances further when they have multiple implementations (and thus are qualified moved over to BCP repo as it is somewhat stable and no longer "research".). A last form is when a specification has moved to be controlled by another standards group (such as a BIP). If only one organization implements a BCR, it will never advance to BCP.
>>
>> Some form of Status for BIPs inspired by this concept could track if a BIP was ever actually implemented by someone, or more ideally, implemented by multiple people in multiple organizations, ideally in multiple languages.
>>
>> Here is how we currently do status, and the status of our current specifications: https://github.com/BlockchainCommons/Research/blob/master/README.md#status
>>
>> Each BCR has a status which is indicated by a symbol.
>>
>> Symbol Title Description
>> ❌❌ Withdrawn Of historic interest only. Withdrawn either because never came into use or proved sufficiently problematic that we do not recommend its usage in any way.
>> ❌ Superseded Superseded by a newer BCR. We do not suggest implementing as an output format, but you may still wish to implement as an input format to maintain backward compatibility.
>> 📙 Research Contains original research or proposes specifications that have not yet been implemented by us. Offered to the community for consideration.
>> ⭐️ Reference Implementation At least one reference implementation has been released, usually as a library, and may include demos or other supporting tools. This specification still remains very open to change because it has not yet (to our knowledge) been implemented by additional parties.
>> ⭐️⭐️ Multiple Implementations At least two (known) implementations exist, at least one not by the owner of the reference implementation. Has demonstrable community support. May still change due to the needs of the community, but community feedback will be sought.
>> ⭐️⭐️⭐️ Standards Track Typically at least two implementations, and is considered stable and ready for standardization. Being proposed as a BIP, IETF Internet Draft, or some other standardization draft format. Will typically be moved to the[BCP repo](https://github.com/BlockchainCommons/bcps). Though changes may still be made to the specification, these changes will exclusively be to allow for standardization, and will be conducted with community feedback.
>> ⭐️⭐️⭐️⭐️ Standardized A specification has been standardized as a an IETF RFC, BIP, or approved by some other standards body.
>>
>> ❌❌ after another status symbol is read, "...but withdrawn" and ❌ is read, "...but superseded".
>>
>> -- Christopher Allen
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 24218 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-17 2:42 [bitcoin-dev] BIP process friction Anthony Towns
2024-01-17 6:55 ` Christopher Allen
@ 2024-01-18 15:41 ` David A. Harding
2024-01-19 0:46 ` Anthony Towns
2024-01-18 16:47 ` alicexbt
2 siblings, 1 reply; 11+ messages in thread
From: David A. Harding @ 2024-01-18 15:41 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
On 2024-01-16 16:42, Anthony Towns via bitcoin-dev wrote:
> I'm switching inquisition over to having a dedicated "IANA"-ish
> thing that's independent of BIP process nonsense. It's at:
>
> * https://github.com/bitcoin-inquisition/binana
>
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine
Thank you for doing this!
Question: is there a recommended way to produce a shorter identifier for
inline use in reading material? For example, for proposal
BIN-2024-0001-000, I'm thinking:
- BIN24-1 (references whatever the current version of the proposal is)
- BIN24-1.0 (references revision 0)
I think that doesn't look too bad even if there are over 100 proposals a
year, with some of them getting into over a hundred revisions:
- BIN24-123
- BIN24-123.123
Rationale:
- Using "BIN" for both full-length and shortened versions makes it
explicit which document set we're talking about
- Eliminating the first dash losslessly saves space and reduces visual
clutter
- Shortening a four-digit year to two digits works for the next 75
years. Adding more digits as necessary after that won't produce any
ambiguity
- Although I'd like to eliminate the second dash, and it wouldn't
introduce any ambiguity in machine parsing for the next 175 years, I
think it would lead to people interpreting numbers incorrectly. E.g.,
"BIN241" would be read "BIN two-hundred fourty-one" instead of a more
desirable "BIN twenty-four dash one"
- Eliminating prefix zeroes in the proposal and revision numbers
losslessly saves space and reduces visual clutter
- A decimal point between the proposal number and revision number
creates less visual clutter than the third dash and still conveys the
intended meaning
- Overall, for the typical case I'd expect---BIN proposals numbered 1-99
with no mention of revision---this produces strings only one or two or
characters longer than a typical modern BIP number in shortened format,
e.g. BIN24-12 versus BIP123.
Thoughts?
-Dave
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-17 2:42 [bitcoin-dev] BIP process friction Anthony Towns
2024-01-17 6:55 ` Christopher Allen
2024-01-18 15:41 ` David A. Harding
@ 2024-01-18 16:47 ` alicexbt
2024-01-18 17:42 ` Peter Todd
2 siblings, 1 reply; 11+ messages in thread
From: alicexbt @ 2024-01-18 16:47 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev
Hi AJ,
I like the idea and agree with everything you shared in the email except one thing:
> So I'm switching inquisition over to having a dedicated "IANA"-ish
> thing that's independent of BIP process nonsense. It's at:
>
> * https://github.com/bitcoin-inquisition/binana
I think "authority" is a strong word especially in bitcoin and this process could even work with BINN (Bitcoin Inquisition Numbers And Names). IANA (a function of ICANN) is different thing altogether which was founded by US government.
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
On Wednesday, January 17th, 2024 at 2:42 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi all,
>
> Just under three years ago there was some discussion about the BIPs repo,
> with the result that Kalle became a BIPs editor in addition to Luke, eg:
>
> * https://gnusha.org/bitcoin-core-dev/2021-04-22.log
> * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html
>
> It remains, however, quite hard to get BIPs merged into the repo, eg
> the following PRs have been open for quite some time:
>
> * #1408: Ordinal Numbers; opened 2023-01-21, editors comments:
> Kalle:
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1421641390
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1435389476
>
> Luke:
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1429146796
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1438831607
> https://github.com/bitcoin/bips/pull/1408#issuecomment-1465016571
>
> * #1489: Taproot Assets Protocol; opened 2023-09-07, editors comments:
> Kalle: https://github.com/bitcoin/bips/pull/1489#issuecomment-1855079626
> Luke: https://github.com/bitcoin/bips/pull/1489#issuecomment-1869721535j
>
> * #1500: OP_TXHASH; opened 2023-09-30, editors comments:
> Luke:
> https://github.com/bitcoin/bips/pull/1500#pullrequestreview-1796550166
> https://twitter.com/LukeDashjr/status/1735701932520382839
>
> The range of acceptable BIPs seems to also be becoming more limited,
> such that mempool/relay policy is out of scope:
>
> * https://github.com/bitcoin/bips/pull/1524#issuecomment-1869734387
>
> Despite having two editors, only Luke seems to be able to assign new
> numbers to BIPs, eg:
>
> * https://github.com/bitcoin/bips/pull/1458#issuecomment-1597917780
>
> There's also been some not very productive delays due to the editors
> wanting backwards compatibility sections even if authors don't think
> that's necessary, eg:
>
> * https://github.com/bitcoin/bips/pull/1372#issuecomment-1439132867
>
> Even working out whether to go back to allowing markdown as a text format
> is a multi-month slog due to process confusion:
>
> * https://github.com/bitcoin/bips/pull/1504
>
> Anyway, while it's not totally dysfunctional, it's very high friction.
>
> There are a variety of recent proposals that have PRs open against
> inquisition; up until now I've been suggesting people write a BIP, and
> have been keying off the BIP number to signal activation. But that just
> seems to be introducing friction, when all I need is a way of linking
> an arbitrary number to a spec.
>
> So I'm switching inquisition over to having a dedicated "IANA"-ish
> thing that's independent of BIP process nonsense. It's at:
>
> * https://github.com/bitcoin-inquisition/binana
>
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine; I'm intending to apply the
> policies I think the BIPs repo should be using, so feel free to open a PR,
> even if you already know I think your idea is BS on its merits. If someone
> wants to write an automatic-merge-bot for me, that'd also be great.
>
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
>
> Cheers,
> aj
>
> (It's called "numbers and names" primarily because that way the acronym
> amuses me, but also in case inquisition eventually needs an authoritative
> dictionary for what "cat" or "txhash" or similar terms refer to)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-18 16:47 ` alicexbt
@ 2024-01-18 17:42 ` Peter Todd
0 siblings, 0 replies; 11+ messages in thread
From: Peter Todd @ 2024-01-18 17:42 UTC (permalink / raw)
To: alicexbt, Bitcoin Protocol Discussion; +Cc: Anthony Towns
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Thu, Jan 18, 2024 at 04:47:33PM +0000, alicexbt via bitcoin-dev wrote:
> Hi AJ,
>
> I like the idea and agree with everything you shared in the email except one thing:
>
> > So I'm switching inquisition over to having a dedicated "IANA"-ish
> > thing that's independent of BIP process nonsense. It's at:
> >
> > * https://github.com/bitcoin-inquisition/binana
>
> I think "authority" is a strong word especially in bitcoin and this process could even work with BINN (Bitcoin Inquisition Numbers And Names). IANA (a function of ICANN) is different thing altogether which was founded by US government.
Bitcoin Inquisition is based on signet, which is a centralized blockchain for
testing run by a central authority whose consensus is based on signatures from
that authority. Using the term "authority" in this context is fine.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-17 17:29 ` Michael Folkson
@ 2024-01-18 18:00 ` Peter Todd
2024-01-19 19:27 ` Michael Folkson
0 siblings, 1 reply; 11+ messages in thread
From: Peter Todd @ 2024-01-18 18:00 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5439 bytes --]
On Wed, Jan 17, 2024 at 05:29:48PM +0000, Michael Folkson via bitcoin-dev wrote:
> Hey Luke
>
> I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this issue and others that are repeatedly cropping up (e.g. confusion on the recommended flow for working on proposed consensus changes, when to open a pull request to bitcoin-inquisition, when to open a pull request to Core, when to include/exclude activation params etc).
>
> I don't think there is much I personally disagree with you on with regards to BIPs but one issue where I do think there is disagreement is on whether proposed default policy changes can/should be BIPed.
>
> I previously drafted this on proposed default policy changes [2]:
>
> "To address problems such as pinning attacks on Lightning and multiparty protocols (e.g. vaults) there are and will continue to be draft proposals on changing the default policy rules in Bitcoin Core and/or alternative implementations. As these proposals are for default policy rules and **not** consensus rules there is absolutely no obligation for Bitcoin Core and/or alternative implementations to change their default policy rules nor users to run any particular policy rules (default or otherwise). The authors of these draft proposals are clearly recommending what they think the default policy rules should be and what policy rules users should run but it is merely a recommendation. There are a lot of moving parts, subtleties and complexities involved in designing default policy rules so any recommendation(s) to significantly upgrade default policy rules would benefit from being subject to a spec process. This would also aid the review of any policy related pull requests in Bitcoin Core and/or alternative implementations. An interesting recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bitcoin Core not implementing the exact wording of BIP 125 RBF. In this case (for various reasons) as a response Bitcoin Core just removed references to BIP 125 and started documenting the replacement to BIP 125 rules in the Bitcoin Core repo instead. However, it is my view that recommendations for default policy rules should be recommendations to all implementations, reviewed by Lightning and multiparty protocol developers (not just Bitcoin Core) and hence they would benefit from being standardized and being subject to a specification process. I will reiterate once again though that policy rules are **not** consensus rules. Consensus rules are much closer to an obligation as divergences from consensus rules risk the user being forked off the blockchain and could ultimately end up in network splits. This does not apply to policy rules."
>
> Are you open to adjusting your stance on proposed policy changes being BIPed? I do think it really stunts work on proposed default policy changes and people's ability to follow work on these proposals when the specifications for them are littered all over the place. I've certainly struggled to follow the latest state of V3 policy proposals without clear reference points for the latest state of these proposals e.g. [3]. In addition some proposed consensus change BIPs are starting to want to include sections on policy (e.g. BIP345, OP_VAULT [4]) where it would be much better if they could just refer to a separate policy BIP rather than including proposals for both policy and consensus in the same BIP.
BIP-125 is I think an interesting case study. It is a much more fundamental
standard than Ordinals or Taproot Assets, in the sense that transaction
replacement is expected to be used by essentially all wallets as all wallets
have to deal with fee-rate fluctuations; I do not think that Ordinals or
Taproot assets are appropriate BIP material due to their niche use-case.
The V3 proposal, and ephemeral anchors, would be expected to be used by a wide
range of contracting protocols, most notably lightning. This isn't quite as
broad usage as BIP-124 RBF. But it is close. And yes, Core making changes to
what is essentially BIP125 has an impact: just the other day I ran into someone
that didn't know RBF Rule #6 existed, which Core added on top of BIP-125, and
had made a mistake in their safety analysis of a protocol due to that.
Meanwhile, engineering documentation on V3 is extremely lacking, with basics
like worked through use-case examples not being available. We don't even have
solid agreement let alone documentation on how Lightning channels are meant to
use V3 transactions and what the trade-offs are. And that has lead to mistaken
claims, such as overstating(1) the benefit V3 transactions in their current
form have for transaction pinning.
I don't think V3 necessarily needs a formal BIP. But it would benefit from a
proper engineering process where use-cases are actually worked out and analyzed
properly.
Finally, I think the lesson to be learned here is that mempool policy is better
served by *living* documentation that gets updated to reflect the real world.
There's no easy way for someone to get up to speed on what mempool policy is
actually implemented, and more importantly, *why* it is implemented and what
trade-offs were made to get there. It's quite possible that this "living
documentation" requirement rules out the BIP process.
1) https://petertodd.org/2023/v3-txs-pinning-vulnerability
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-18 15:41 ` David A. Harding
@ 2024-01-19 0:46 ` Anthony Towns
2024-01-19 2:33 ` Karl-Johan Alm
0 siblings, 1 reply; 11+ messages in thread
From: Anthony Towns @ 2024-01-19 0:46 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
On Thu, Jan 18, 2024 at 05:41:14AM -1000, David A. Harding via bitcoin-dev wrote:
> Question: is there a recommended way to produce a shorter identifier for
> inline use in reading material? For example, for proposal
> BIN-2024-0001-000, I'm thinking:
>
> - BIN24-1 (references whatever the current version of the proposal is)
> - BIN24-1.0 (references revision 0)
>
> I think that doesn't look too bad even if there are over 100 proposals a
> year, with some of them getting into over a hundred revisions:
>
> - BIN24-123
> - BIN24-123.123
Having lived through y2k, two-digit years give me the ick, but otherwise
sure.
Cheers,
aj, that's how the kids who didn't live through y2k say it, right?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-19 0:46 ` Anthony Towns
@ 2024-01-19 2:33 ` Karl-Johan Alm
0 siblings, 0 replies; 11+ messages in thread
From: Karl-Johan Alm @ 2024-01-19 2:33 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
Hello,
First off, apologies about my lack of participation. I am working on
mostly unrelated things and I'm afraid I have failed the community in
terms of what I can do on my end to keep the BIP process functional.
As such I am hereby resigning as BIP editor effective immediately.
Please remove my access privileges to the repository when possible.
-Kalle.
On Fri, 19 Jan 2024 at 09:46, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Thu, Jan 18, 2024 at 05:41:14AM -1000, David A. Harding via bitcoin-dev wrote:
> > Question: is there a recommended way to produce a shorter identifier for
> > inline use in reading material? For example, for proposal
> > BIN-2024-0001-000, I'm thinking:
> >
> > - BIN24-1 (references whatever the current version of the proposal is)
> > - BIN24-1.0 (references revision 0)
> >
> > I think that doesn't look too bad even if there are over 100 proposals a
> > year, with some of them getting into over a hundred revisions:
> >
> > - BIN24-123
> > - BIN24-123.123
>
> Having lived through y2k, two-digit years give me the ick, but otherwise
> sure.
>
> Cheers,
> aj, that's how the kids who didn't live through y2k say it, right?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] BIP process friction
2024-01-18 18:00 ` Peter Todd
@ 2024-01-19 19:27 ` Michael Folkson
0 siblings, 0 replies; 11+ messages in thread
From: Michael Folkson @ 2024-01-19 19:27 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
Thanks for this Peter, really helpful.
> It is a much more fundamental
standard than Ordinals or Taproot Assets, in the sense that transaction
replacement is expected to be used by essentially all wallets as all wallets
have to deal with fee-rate fluctuations; I do not think that Ordinals or
Taproot assets are appropriate BIP material due to their niche use-case.
Yes I'd personally lean towards this view too. Certainly when you go into alternative asset territory (e.g. Counterparty, Liquid (Network) assets, Taproot assets) it is moving away from what you can do with the Bitcoin asset/currency and into building a new ecosystem with a different asset/currency. I would agree that that should probably be out of scope for *Bitcoin* Improvement Proposals without having any particular opinion on the utility of any of those ecosystems.
> just the other day I ran into someone
that didn't know RBF Rule #6 existed, which Core added on top of BIP-125, and
had made a mistake in their safety analysis of a protocol due to that.
I suspected this might be the case but to actually have a data point to back that up (beyond I personally find it unnecessarily confusing and hard to follow) is helpful, thanks.
> Finally, I think the lesson to be learned here is that mempool policy is better
served by *living* documentation that gets updated to reflect the real world.
There's no easy way for someone to get up to speed on what mempool policy is
actually implemented, and more importantly, *why* it is implemented and what
trade-offs were made to get there. It's quite possible that this "living
documentation" requirement rules out the BIP process.
I get the "living", evolving point. Policy proposals are definitely different to say consensus proposals where assuming they are ever activated you'd expect them to stay static for the rest of Bitcoin's existence barring minor cleanups, clarifications etc. However, one possible addition in a new BIP 3 process would be the introduction of versioning for a particular BIP e.g. BIP 789 version 2 which would be more conducive to these evolving proposals such as policy proposals. You could then update a BIP without needing a new BIP number for every material update.
I'll wait to hear what Luke thinks on this. Beyond the friction concern I think improving the BIP process for consensus and policy proposals would be the biggest potential win for a BIP 3 update.
Thanks also to Kalle too for his 18 month stint as a BIP editor :)
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
On Thursday, 18 January 2024 at 18:00, Peter Todd <pete@petertodd•org> wrote:
> On Wed, Jan 17, 2024 at 05:29:48PM +0000, Michael Folkson via bitcoin-dev wrote:
>
> > Hey Luke
> >
> > I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of this issue and others that are repeatedly cropping up (e.g. confusion on the recommended flow for working on proposed consensus changes, when to open a pull request to bitcoin-inquisition, when to open a pull request to Core, when to include/exclude activation params etc).
> >
> > I don't think there is much I personally disagree with you on with regards to BIPs but one issue where I do think there is disagreement is on whether proposed default policy changes can/should be BIPed.
> >
> > I previously drafted this on proposed default policy changes [2]:
> >
> > "To address problems such as pinning attacks on Lightning and multiparty protocols (e.g. vaults) there are and will continue to be draft proposals on changing the default policy rules in Bitcoin Core and/or alternative implementations. As these proposals are for default policy rules and not consensus rules there is absolutely no obligation for Bitcoin Core and/or alternative implementations to change their default policy rules nor users to run any particular policy rules (default or otherwise). The authors of these draft proposals are clearly recommending what they think the default policy rules should be and what policy rules users should run but it is merely a recommendation. There are a lot of moving parts, subtleties and complexities involved in designing default policy rules so any recommendation(s) to significantly upgrade default policy rules would benefit from being subject to a spec process. This would also aid the review of any policy related pull requests in Bitcoin Core and/or alternative implementations. An interesting recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bitcoin Core not implementing the exact wording of BIP 125 RBF. In this case (for various reasons) as a response Bitcoin Core just removed references to BIP 125 and started documenting the replacement to BIP 125 rules in the Bitcoin Core repo instead. However, it is my view that recommendations for default policy rules should be recommendations to all implementations, reviewed by Lightning and multiparty protocol developers (not just Bitcoin Core) and hence they would benefit from being standardized and being subject to a specification process. I will reiterate once again though that policy rules are not consensus rules. Consensus rules are much closer to an obligation as divergences from consensus rules risk the user being forked off the blockchain and could ultimately end up in network splits. This does not apply to policy rules."
> >
> > Are you open to adjusting your stance on proposed policy changes being BIPed? I do think it really stunts work on proposed default policy changes and people's ability to follow work on these proposals when the specifications for them are littered all over the place. I've certainly struggled to follow the latest state of V3 policy proposals without clear reference points for the latest state of these proposals e.g. [3]. In addition some proposed consensus change BIPs are starting to want to include sections on policy (e.g. BIP345, OP_VAULT [4]) where it would be much better if they could just refer to a separate policy BIP rather than including proposals for both policy and consensus in the same BIP.
>
>
> BIP-125 is I think an interesting case study. It is a much more fundamental
> standard than Ordinals or Taproot Assets, in the sense that transaction
> replacement is expected to be used by essentially all wallets as all wallets
> have to deal with fee-rate fluctuations; I do not think that Ordinals or
> Taproot assets are appropriate BIP material due to their niche use-case.
>
> The V3 proposal, and ephemeral anchors, would be expected to be used by a wide
> range of contracting protocols, most notably lightning. This isn't quite as
> broad usage as BIP-124 RBF. But it is close. And yes, Core making changes to
> what is essentially BIP125 has an impact: just the other day I ran into someone
> that didn't know RBF Rule #6 existed, which Core added on top of BIP-125, and
> had made a mistake in their safety analysis of a protocol due to that.
>
> Meanwhile, engineering documentation on V3 is extremely lacking, with basics
> like worked through use-case examples not being available. We don't even have
> solid agreement let alone documentation on how Lightning channels are meant to
> use V3 transactions and what the trade-offs are. And that has lead to mistaken
> claims, such as overstating(1) the benefit V3 transactions in their current
> form have for transaction pinning.
>
> I don't think V3 necessarily needs a formal BIP. But it would benefit from a
> proper engineering process where use-cases are actually worked out and analyzed
> properly.
>
> Finally, I think the lesson to be learned here is that mempool policy is better
> served by living documentation that gets updated to reflect the real world.
> There's no easy way for someone to get up to speed on what mempool policy is
> actually implemented, and more importantly, why it is implemented and what
> trade-offs were made to get there. It's quite possible that this "living
> documentation" requirement rules out the BIP process.
>
> 1) https://petertodd.org/2023/v3-txs-pinning-vulnerability
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-01-19 19:27 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-17 2:42 [bitcoin-dev] BIP process friction Anthony Towns
2024-01-17 6:55 ` Christopher Allen
2024-01-17 16:45 ` Luke Dashjr
2024-01-17 17:29 ` Michael Folkson
2024-01-18 18:00 ` Peter Todd
2024-01-19 19:27 ` Michael Folkson
2024-01-18 15:41 ` David A. Harding
2024-01-19 0:46 ` Anthony Towns
2024-01-19 2:33 ` Karl-Johan Alm
2024-01-18 16:47 ` alicexbt
2024-01-18 17:42 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox