Re: [bitcoin-dev] Ordinals BIP PR

[alicexbt <alicexbt@protonmail.com>]

Hi Luke,

> 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.

I don't think adding another editor solves the problem discussed in this thread. 
Last time we had similar situation and Kalle was added as editor instead of making BIP
process decentralized. It was discussed in this [thread][0].

BIP editors can have personal opinions and bias but if it affects PRs getting merged,
then repo has no use except for a few developers.

> 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. 

What makes it an attack on bitcoin? Some users want to use their money in a different way.
How is it different from taproot assets and other standards to achieve similar goals?

Some users and developers believe drivechain is an attack on bitcoin, BIP 47 is considered bad,
use of OP_RETURN in colored coins is controversial, increasing blocksize is not an improvement etc.
Still these BIPs exist in the same repository.

> 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.

Can we remove terms like "philosophy", "net improvement" etc. from BIP 2? Because they could mean different
things for different people.

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html


/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, October 23rd, 2023 at 11:59 PM, 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