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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
