Hello,

I have developed nodes/wallets for Bitcoin and Bitcoin-derived Altcoins.
3rd-party Bitcoin developers take BIPs very seriously, basically as
must-implement/must-comply features.

Therefore, I think it would be best to restrict BIPs to the minimum
necessary to implement a complying node/wallet.

Cheers!

Claus

On Thu, Nov 9, 2023 at 1:43 PM Casey Rodarmor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Luke is definitely entitled to his opinions about ordinals, and I
> certainly understand why people may not like ordinals and inscriptions.
>
> I don't think that ordinals are "nonsense", an "attack on Bitcoin", or
> that I'm dishonest, as Luke implies, or that my actions are an attempt to
> "harm/destroy Bitcoin".
>
> I think that whether or not ordinals are good is something about which
> reasonable people do and will disagree, and that an impartial BIP editor
> would recognize this above their own personal feelings about the matter.
>
> Also, regarding:
>
> > There is a debate on the PR whether the "technically unsound, ..., or
> not in keeping with the Bitcoin philosophy." or "must represent a net
> improvement." clauses (BIP 2) are relevant.
>
> As I said in my initial email, I think these standards are being applied
> in a way that they have not been to previous BIPs, which include all manner
> of things, including changes to bitcoin which are nearly unanimously
> thought to be quite harmful if adopted.
>
> Best,
> Casey
>
> On Mon, Oct 23, 2023 at 11:35 AM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Everything standardized between Bitcoin software is eligible to be and
>> should be a BIP. I completely disagree with the claim that it's used for
>> too many things.
>>
>> SLIPs exist for altcoin stuff. They shouldn't be used for things related
>> to Bitcoin.
>>
>> BOLTs also shouldn't have ever been a separate process and should really
>> just get merged into BIPs. But at this point, that will probably take
>> quite a bit of effort, and obviously cooperation and active involvement
>> from the Lightning development community.
>>
>> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
>> to keep up. There are several PRs far more important than Ordinals
>> nonsense that need to be triaged and probably merged.
>>
>> The issue with Ordinals is that it is actually unclear if it's eligible
>> to be a BIP at all, since it is an attack on Bitcoin rather than a
>> proposed improvement. There is a debate on the PR whether the
>> "technically unsound, ..., or not in keeping with the Bitcoin
>> philosophy." or "must represent a net improvement." clauses (BIP 2) are
>> relevant. Those issues need to be resolved somehow before it could be
>> merged. I have already commented to this effect and given my own
>> opinions on the PR, and simply pretending the issues don't exist won't
>> make them go away. (Nor is it worth the time of honest people to help
>> Casey resolve this just so he can further try to harm/destroy Bitcoin.)
>>
>> Luke
>>
>>
>> On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:
>> > On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via bitcoin-dev
>> wrote:
>> >> I have _not_ requested a BIP for OpenTimestamps, even though it is of
>> much
>> >> wider relevance to Bitcoin users than Ordinals by virtue of the fact
>> that much
>> >> of the commonly used software, including Bitcoin Core, is timestamped
>> with OTS.
>> >> I have not, because there is no need to document every single little
>> protocol
>> >> that happens to use Bitcoin with a BIP.
>> >>
>> >> Frankly we've been using BIPs for too many things. There is no
>> avoiding the act
>> >> that BIP assignment and acceptance is a mark of approval for a
>> protocol. Thus
>> >> we should limit BIP assignment to the minimum possible: _extremely_
>> widespread
>> >> standards used by the _entire_ Bitcoin community, for the core mission
>> of
>> >> Bitcoin.
>> >>
>> > This would eliminate most wallet-related protocols e.g. BIP69 (sorted
>> > keys), ypubs, zpubs, etc. I don't particularly like any of those but if
>> > they can't be BIPs then they'd need to find another spec repository
>> > where they wouldn't be lost and where updates could be tracked.
>> >
>> > The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not
>> a BIP
>> > in part because of perceived friction and exclusivity of the BIPs repo.
>> > But I'm not thrilled with this situation.
>> >
>> > In fact, I would prefer that OpenTimestamps were a BIP :).
>> >
>> >> It's notable that Lightning is _not_ standardized via the BIP process.
>> I think
>> >> that's a good thing. While it's arguably of wide enough use to warrent
>> BIPs,
>> >> Lightning doesn't need the approval of Core maintainers, and using
>> their
>> >> separate BOLT process makes that clear.
>> >>
>> > Well, LN is a bit special because it's so big that it can have its own
>> > spec repo which is actively maintained and used.
>> >
>> > While it's technically true that BIPs need "approval of Core
>> maintainers"
>> > to be merged, the text of BIP2 suggests that this approval should be a
>> > functionary role and be pretty-much automatic. And not require the BIP
>> > be relevant or interesting or desireable to Core developers.
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>