public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Claus Ehrenberg <aubergemediale@gmail.com>
To: Casey Rodarmor <casey@rodarmor.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Date: Thu, 9 Nov 2023 23:32:10 +0100	[thread overview]
Message-ID: <CANPykMqq-1Xh5WcHpKPeyfi6YAfjP2gJsO863K=D0yr2McT4aQ@mail.gmail.com> (raw)
In-Reply-To: <CANLPe+NAd4imuGji7+o+Y3bWtC4aeTMNj0RrJw0Pu4=e6TEdeQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6046 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 7732 bytes --]

  reply	other threads:[~2023-11-09 22:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-21  5:38 [bitcoin-dev] Ordinals BIP PR Casey Rodarmor
2023-10-23 13:45 ` Andrew Poelstra
2023-10-23 15:35 ` Peter Todd
2023-10-23 16:32   ` Tim Ruffing
2023-10-26 22:05     ` Peter Todd
2023-10-23 17:43   ` Andrew Poelstra
2023-10-23 18:29     ` Luke Dashjr
2023-10-24  1:28       ` alicexbt
2023-10-24 22:56       ` Olaoluwa Osuntokun
2023-10-24 23:08         ` Christopher Allen
2023-10-25  0:15         ` Luke Dashjr
2023-10-26 22:11         ` Peter Todd
2023-10-27  9:39           ` Alexander F. Moser
2023-10-27 17:05           ` alicexbt
2023-11-09  2:15       ` Casey Rodarmor
2023-11-09 22:32         ` Claus Ehrenberg [this message]
2023-10-23 14:57 Léo Haf
2023-10-23 17:26 ` Ryan Breen
2023-11-20 22:20 vjudeu
2023-11-21 12:13 ` Kostas Karasavvas
2023-11-21 23:10 vjudeu
2023-11-22 11:27 ` Kostas Karasavvas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANPykMqq-1Xh5WcHpKPeyfi6YAfjP2gJsO863K=D0yr2McT4aQ@mail.gmail.com' \
    --to=aubergemediale@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=casey@rodarmor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox