Re: [bitcoin-dev] Ordinals BIP PR

Re: [bitcoin-dev] Ordinals BIP PR

[vjudeu]

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

> I've commented a few times asking the BIP editors to let me know what is needed for the BIP to either be merged or rejected.
I would accept it, if each Ordinal would require including OP_RETURN at the beginning of the TapScript, to prevent them from being pushed on-chain. In that case, they could still be moved by a single Schnorr signature. Or, even better, creating a new Ordinal should not require sending them to Taproot at all, but just the R-value of a signature, from any address type, should be sufficient to make a commitment.
Which means, if some user has some legacy address, then it should be possible to sign a regular transaction, and then, R-value of that signature could contain some Ordinal.
Also, Ordinals should support scanning the chain in a similar way as Silent Payments could do. Which means, users should not be forced to upload data, if they were already uploaded in a different form. For example, there was a user, trying to upload the whitepaper, even though it was already done, and it was wrapped in a multisig in some old transaction. Which means, Ordinals should allow scanning the chain, and discovering old data, without reinventing the wheel, and forcing users to post that data again on-chain.
Another thing to address is the content of each Ordinal: some people tried to create something like NFT. In that case, the uniqueness should be enforced. And by scanning the chain for similar data, it should note that "hey, the whitepaper was already pushed by someone, in a multisig, long time ago", so the Ordinals protocol should prevent users from uploading the same data again, and again. Because in some use cases, like NFTs, it could be misleading.

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

Re: [bitcoin-dev] Ordinals BIP PR

[Kostas Karasavvas]

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

Please see inline.

On Tue, Nov 21, 2023 at 3:21 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > I've commented a few times asking the BIP editors to let me know what is
> needed for the BIP to either be merged or rejected.
>
> I would accept it, if each Ordinal would require including OP_RETURN at
> the beginning of the TapScript, to prevent them from being pushed on-chain.
> In that case, they could still be moved by a single Schnorr signature.
>

I am not sure I understand this. The data are published when spending the
taproot (in the witness). Since it is spent it does not bloat the mempool.
Regardless of OP_RETURN the data will be on chain. What am I missing?


> Or, even better, creating a new Ordinal should not require sending them to
> Taproot at all, but just the R-value of a signature, from any address type,
> should be sufficient to make a commitment.
>
> Which means, if some user has some legacy address, then it should be
> possible to sign a regular transaction, and then, R-value of that signature
> could contain some Ordinal.
>
>
Actually, wrt to ordinals design I agree with comments like this suggesting
a different design. Why? I understand that the BIP process is fundamentally
to discuss a proposal. Something is suggested people tweak on it, improve
it and when they agree they might assign it a number. To Casey (and to
other contributors), you designed ordinals without consulting this list,
you finalized the design, created an implementation and it is running for
months and now you are submitting it for a BIP; i.e. asking for legitimacy
after the fact? Shouldn't people agree/disagree with the design?

Why do you want ordinals as a BIP (apologies if you explained this before
and I missed it)?
1) If you don't care about legitimacy then ordinals is live, you are good
to go.
2) If you are asking legitimacy then you should accept potential design
modifications like the one mentioned above.
3) If you want the BIP for standardisation it makes no sense. People can
design similar protocols anyway. It's permissionless.
4) For another reason?


> Also, Ordinals should support scanning the chain in a similar way as
> Silent Payments could do. Which means, users should not be forced to upload
> data, if they were already uploaded in a different form. For example, there
> was a user, trying to upload the whitepaper, even though it was already
> done, and it was wrapped in a multisig in some old transaction. Which
> means, Ordinals should allow scanning the chain, and discovering old data,
> without reinventing the wheel, and forcing users to post that data again
> on-chain.
>
> Another thing to address is the content of each Ordinal: some people tried
> to create something like NFT. In that case, the uniqueness should be
> enforced. And by scanning the chain for similar data, it should note that
> "hey, the whitepaper was already pushed by someone, in a multisig, long
> time ago", so the Ordinals protocol should prevent users from uploading the
> same data again, and again. Because in some use cases, like NFTs, it could
> be misleading.
>

I don't agree with this. This seems to be a business logic change and not a
technical one. People can and will create other similar protocols that
force (or not) uniqueness regardless of what ordinals do.

Besides, in any chain, NFTs can only enforce uniqueness per contract. A
different contract can have exactly the same NFTs. Uniqueness is kind-of
acquired because of the legitimacy of the person who issued the collection.

Re this BIP proposal:
I would not have an issue to accept this proposal if it was submitted for
discussion beforehand. If there was no need for people in this list to
discuss it before I don't see why a BIP is needed now.

Regards,
Kostas




> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
https://twitter.com/kkarasavvas

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

Re: [bitcoin-dev] Ordinals BIP PR

[vjudeu]

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

> Since it is spent it does not bloat the mempool.
 
This is not the case. If you post some 100 kB TapScript, with some Ordinal, then it of course bloats mempools, because then other users could post 100 kB less, when it comes to regular payments. If you have Ordinals in the current form, then they take place of regular payments. Which means, you can include some payment, or some data. You cannot include both, because you can produce 4 MB block per 10 minutes. It is always a choice: confirm this payment, or confirm that data.
 
> Regardless of OP_RETURN the data will be on chain. What am I missing?
 
If you have regular OP_RETURN, the data is pushed on-chain. However, if your OP_RETURN is part of your TapScript, then you cannot provide any valid input to satisfy that kind of TapScript, so it cannot be pushed on-chain. Which means, you have to use another TapScript branch, without OP_RETURN, or simply spend by key. Note that regular OP_RETURNs are placed in transaction outputs, but in that case, TapScript is revealed in transaction input (and to be more specific, in the witness part), which prevents from posting a commitment on-chain, if it contains OP_RETURN at the beginning of the TapScript.
 
> If there was no need for people in this list to discuss it before I don't see why a BIP is needed now.
 
It is needed, but for a different reason. There should be a BIP, but not to promote Ordinals, but to handle them properly, and to provide regular users a way, to compete with the currently posted Ordinals, in this fee-based competition. Which means, regular users should have a way, to turn their Ordinals into proper commitments. They should be hidden behind some R-value, instead of being posted as a TapScript, and fully revealed in the witness. That would make it smaller, cheaper, and will provide more room for more regular payments, while preserving the strong cryptographical proof, that a given data is connected with a given transaction input.
 
Also, it would allow them to be uncensorable, because then users could decide to hide any Ordinal behind their signature, in any address type (it works even on P2PK), and then reveal it later, but not on-chain, to not take a room of other regular payments. In general, transactions should always contain payments, and Ordinals could be attached as a feature, and not the other way around, when the actual payment is just a feature to be discarded, and the posted data is what people care about. Bitcoin is a payment system first, and not a P2P cloud storage, so it should work as "always a payment, and optionally also an Ordinal", and not "just a data push, and unfortunately a payment, because the protocol forced us to include some satoshis".

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

Re: [bitcoin-dev] Ordinals BIP PR

[Kostas Karasavvas]

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

On Wed, Nov 22, 2023 at 1:11 AM <vjudeu@gazeta.pl> wrote:

> > Since it is spent it does not bloat the mempool.
>
> This is not the case. If you post some 100 kB TapScript, with some
> Ordinal, then it of course bloats mempools, because then other users could
> post 100 kB less, when it comes to regular payments. If you have Ordinals
> in the current form, then they take place of regular payments. Which means,
> you can include some payment, or some data. You cannot include both,
> because you can produce 4 MB block per 10 minutes. It is always a choice:
> confirm this payment, or confirm that data.
>
>

I meant the UTXO set, not the mempool. But still, even for the mempool,
since tx fees are paid I don't see it as bloat. It is competing with the
other txs and won. The bloat is of course in storage since the blocks are
'fuller' with ordinals... but that is the whole point of ordinals (see
below).


> > Regardless of OP_RETURN the data will be on chain. What am I missing?
>
> If you have regular OP_RETURN, the data is pushed on-chain. However, if
> your OP_RETURN is part of your TapScript, then you cannot provide any valid
> input to satisfy that kind of TapScript, so it cannot be pushed on-chain.
> Which means, you have to use another TapScript branch, without OP_RETURN,
> or simply spend by key. Note that regular OP_RETURNs are placed in
> transaction outputs, but in that case, TapScript is revealed in transaction
> input (and to be more specific, in the witness part), which prevents from
> posting a commitment on-chain, if it contains OP_RETURN at the beginning of
> the TapScript.
>

I see, thanks.


> > If there was no need for people in this list to discuss it before I
> don't see why a BIP is needed now.
>
> It is needed, but for a different reason. There should be a BIP, but not
> to promote Ordinals, but to handle them properly, and to provide regular
> users a way, to compete with the currently posted Ordinals, in this
> fee-based competition. Which means, regular users should have a way, to
> turn their Ordinals into proper commitments. They should be hidden behind
> some R-value, instead of being posted as a TapScript, and fully revealed in
> the witness. That would make it smaller, cheaper, and will provide more
> room for more regular payments, while preserving the strong cryptographical
> proof, that a given data is connected with a given transaction input.
>
> Also, it would allow them to be uncensorable, because then users could
> decide to hide any Ordinal behind their signature, in any address type (it
> works even on P2PK), and then reveal it later, but not on-chain, to not
> take a room of other regular payments. In general, transactions should
> always contain payments, and Ordinals could be attached as a feature, and
> not the other way around, when the actual payment is just a feature to be
> discarded, and the posted data is what people care about. Bitcoin is a
> payment system first, and not a P2P cloud storage, so it should work as
> "always a payment, and optionally also an Ordinal", and not "just a data
> push, and unfortunately a payment, because the protocol forced us to
> include some satoshis".
>

The whole point of ordinals is supposed to have the data on-chain (the
ordinals team can correct me). You are not suggesting merely a technical
design change, you are suggesting a completely different design and
business logic, which I believe would never be accepted by the ordinals
team*, and thus no point for this BIP now. We'll just have to wait for
their reply and see.

* This is fair game for a new competing project. However, the 'on-chain'
part is the main ordinals selling point so a new project would not even be
competing.

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

Re: [bitcoin-dev] Ordinals BIP PR

[Léo Haf]

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

 BIPs such as the increase in block size, drives-chains, colored coins, etc... were proposals for Bitcoin improvements. On the other hand, your BIP brings absolutely no improvement, on the contrary it is a regression, but you already know that.

I strongly invite you to retract or if the desire continues to push you to negatively affect the chain, to create OIPs or anything similar, as far as possible from the development of Bitcoin and real BIPs that improve Bitcoin.

Léo Haf. 

> Le 23 oct. 2023 à 10:23, Casey Rodarmor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a écrit :
> 
> Dear List,
> 
> The Ordinals BIP PR has been sitting open for nine months now[0]. I've commented a few times asking the BIP editors to let me know what is needed for the BIP to either be merged or rejected. I've also reached out to the BIP editors via DM and email, but haven't received a response.
> 
> There has been much misunderstanding of the nature of the BIP process. BIPS, in particular informational BIPs, are a form of technical documentation, and their acceptance does not indicate that they will be included in any implementation, including Bitcoin Core, nor that they they have consensus among the community.
> 
> Preexisting BIPs include hard-fork block size increases, hard-fork proof-of-work changes, colored coin voting protocols, rejected soft fork proposals, encouragement of address reuse, and drivechain.
> 
> I believe ordinals is in-scope for a BIP, and am hoping to get the PR unstuck. I would appreciate feedback from the BIP editors on whether it is in-scope for a BIP, if not, why not, and if so, what changes need to be made for it to be accepted.
> 
> Best regards,
> Casey Rodarmor
> 
> [0] https://github.com/bitcoin/bips/pull/1408
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Ordinals BIP PR

[Ryan Breen]

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

Presumably the people using it feel it is an improvement. However you feel about it, Ordinals and Inscriptions are now a part of the Bitcoin ecosystem.

Whether Ordinals deserve a BIP is yet to be determined, but it doesn’t seem appropriate to try and force him to retract it. That solves nothing. If there is a reason this shouldn’t be a BIP, then that should be laid out as part of the process and formally rejected. Otherwise it should go through the normal process and be accepted.

As it is, leaving it in limbo and just hoping that it goes away is not a solution.

Thanks,

Ryan Breen
@ursuscamp

> On Oct 23, 2023, at 12:49 PM, Léo Haf via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
>  BIPs such as the increase in block size, drives-chains, colored coins, etc... were proposals for Bitcoin improvements. On the other hand, your BIP brings absolutely no improvement, on the contrary it is a regression, but you already know that.
> 
> I strongly invite you to retract or if the desire continues to push you to negatively affect the chain, to create OIPs or anything similar, as far as possible from the development of Bitcoin and real BIPs that improve Bitcoin.
> 
> Léo Haf. 
> 
>>> Le 23 oct. 2023 à 10:23, Casey Rodarmor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a écrit :
>>> 
>> 
>> Dear List,
>> 
>> The Ordinals BIP PR has been sitting open for nine months now[0]. I've commented a few times asking the BIP editors to let me know what is needed for the BIP to either be merged or rejected. I've also reached out to the BIP editors via DM and email, but haven't received a response.
>> 
>> There has been much misunderstanding of the nature of the BIP process. BIPS, in particular informational BIPs, are a form of technical documentation, and their acceptance does not indicate that they will be included in any implementation, including Bitcoin Core, nor that they they have consensus among the community.
>> 
>> Preexisting BIPs include hard-fork block size increases, hard-fork proof-of-work changes, colored coin voting protocols, rejected soft fork proposals, encouragement of address reuse, and drivechain.
>> 
>> I believe ordinals is in-scope for a BIP, and am hoping to get the PR unstuck. I would appreciate feedback from the BIP editors on whether it is in-scope for a BIP, if not, why not, and if so, what changes need to be made for it to be accepted.
>> 
>> Best regards,
>> Casey Rodarmor
>> 
>> [0] https://github.com/bitcoin/bips/pull/1408
>> _______________________________________________
>> 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: 4737 bytes --]

[bitcoin-dev] Ordinals BIP PR

[Casey Rodarmor]

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

Dear List,

The Ordinals BIP PR has been sitting open for nine months now[0]. I've
commented a few times asking the BIP editors to let me know what is needed
for the BIP to either be merged or rejected. I've also reached out to the
BIP editors via DM and email, but haven't received a response.

There has been much misunderstanding of the nature of the BIP process.
BIPS, in particular informational BIPs, are a form of technical
documentation, and their acceptance does not indicate that they will be
included in any implementation, including Bitcoin Core, nor that they they
have consensus among the community.

Preexisting BIPs include hard-fork block size increases, hard-fork
proof-of-work changes, colored coin voting protocols, rejected soft fork
proposals, encouragement of address reuse, and drivechain.

I believe ordinals is in-scope for a BIP, and am hoping to get the PR
unstuck. I would appreciate feedback from the BIP editors on whether it is
in-scope for a BIP, if not, why not, and if so, what changes need to be
made for it to be accepted.

Best regards,
Casey Rodarmor

[0] https://github.com/bitcoin/bips/pull/1408

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

Re: [bitcoin-dev] Ordinals BIP PR

[Andrew Poelstra]

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

On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote:
>
> <snip>
> 
> There has been much misunderstanding of the nature of the BIP process.
> BIPS, in particular informational BIPs, are a form of technical
> documentation, and their acceptance does not indicate that they will be
> included in any implementation, including Bitcoin Core, nor that they they
> have consensus among the community.
> 
> Preexisting BIPs include hard-fork block size increases, hard-fork
> proof-of-work changes, colored coin voting protocols, rejected soft fork
> proposals, encouragement of address reuse, and drivechain.
>
> <snip>
>

I agree and I think it sets a bad precedent to be evaluating BIPs based
on the merits of their implementation (vs their specification) or their
consequences for the network. Actual consensus is much bigger than the
BIPs repo, so this accomplishes little beyond making the BIPs repo itself
hard to interact with.

In the worst case it may cause people to interpret BIP numbers as
indicating that proposals are "blessed" by some particular influential
set of people, which can only cause problems.

-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Ordinals BIP PR

[Peter Todd]

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

On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote:
> Dear List,
> 
> The Ordinals BIP PR has been sitting open for nine months now[0]. I've
> commented a few times asking the BIP editors to let me know what is needed
> for the BIP to either be merged or rejected. I've also reached out to the
> BIP editors via DM and email, but haven't received a response.
> 
> There has been much misunderstanding of the nature of the BIP process.
> BIPS, in particular informational BIPs, are a form of technical
> documentation, and their acceptance does not indicate that they will be
> included in any implementation, including Bitcoin Core, nor that they they
> have consensus among the community.
> 
> Preexisting BIPs include hard-fork block size increases, hard-fork
> proof-of-work changes, colored coin voting protocols, rejected soft fork
> proposals, encouragement of address reuse, and drivechain.

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.

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Ordinals BIP PR

[Tim Ruffing]

On Mon, 2023-10-23 at 15:35 +0000, Peter Todd via bitcoin-dev wrote:
> 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.

BIPs are Bitcoin Improvement *Proposals*. What you suggest would imply
that someone needs to evaluate them even before they become proposals.
And this raises plenty of notoriously hard to answers questions:
 * Who is in charge?
 * How to predict if a proposal will be a widespread standard?
 * What is the core mission of Bitcoin?
 * How to measure if something is for the core mission?
 * Who and what is the _entire_ Bitcoin community?

Best,
Tim

Re: [bitcoin-dev] Ordinals BIP PR

[Peter Todd]

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

On Mon, Oct 23, 2023 at 06:32:47PM +0200, Tim Ruffing wrote:
> On Mon, 2023-10-23 at 15:35 +0000, Peter Todd via bitcoin-dev wrote:
> > 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.
> 
> BIPs are Bitcoin Improvement *Proposals*. What you suggest would imply

BIPs being proposals is itself part of the problem. Note how RFCs have a Draft
RFC system to avoid giving numbers for absolutely every idea.

> that someone needs to evaluate them even before they become proposals.
> And this raises plenty of notoriously hard to answers questions:
>  * Who is in charge?
>  * How to predict if a proposal will be a widespread standard?
>  * What is the core mission of Bitcoin?
>  * How to measure if something is for the core mission?
>  * Who and what is the _entire_ Bitcoin community?

...and we still face those problems with the current BIPs system. In particular
the "Who is in charge?" problem. BIPs are always going to be a centralized
system.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Ordinals BIP PR

[Andrew Poelstra]

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

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.


-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Ordinals BIP PR

[Luke Dashjr]

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

Re: [bitcoin-dev] Ordinals BIP PR

[alicexbt]

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

Re: [bitcoin-dev] Ordinals BIP PR

[Olaoluwa Osuntokun]

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

TL;DR: let's just use an automated system to assign BIP numbers, so we can
spend time on more impactful things.

IIUC, one the primary roles of the dedicated BIP maintainers is just to hand
out BIP numbers for documents. Supposedly with this privilege, the BIP
maintainer is able to tastefully assign related BIPs to consecutive numbers,
and also reserve certain BIP number ranges for broad categories, like 3xx
for p2p changes (just an example).

To my knowledge, the methodology for such BIP number selection isn't
published anywhere, and is mostly arbitrary. As motioned in this thread,
some perceive this manual process as a gatekeeping mechanism, and often
ascribe favoritism as the reason why PR X got a number immediately, but PR Y
has waited N months w/o an answer.

Every few years we go through an episode where someone is rightfully upset
that they haven't been assigned a BIP number after following the requisite
process.  Most recently, another BIP maintainer was appointed, with the hope
that the second maintainer would help to alleviate some of the subjective
load of the position.  Fast forward to this email thread, and it doesn't
seem like adding more BIP maintainers will actually help with the issue of
BIP number assignment.

Instead, what if we just removed the subjective human element from the
process, and switched to using PR numbers to assign BIPs? Now instead of
attempting to track down a BIP maintainer at the end of a potentially
involved review+iteration period, PRs are assigned BIP numbers as soon as
they're opened and we have one less thing to bikeshed and gatekeep.

One down side of this is that assuming the policy is adopted, we'll sorta
sky rocket the BIP number space. At the time of writing of this email, the
next PR number looks to be 1508. That doesn't seem like a big deal to me,
but we could offset that by some value, starting at the highest currently
manually assigned BIP number. BIP numbers would no longer always be
contiguous, but that's sort of already the case.

There's also the matter of related BIPs, like the segwit series (BIPs 141,
142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
think it would be too difficult to find a workable scheme.

Thoughts?

-- Laolu


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
>

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

Re: [bitcoin-dev] Ordinals BIP PR

[Christopher Allen]

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

I think this is a good idea, but suggest that the numbers include year and
number in the year. We do that for all the research and “wallet improvement
proposals” at Blockchain Commons. This way numbers don’t grow huge like
EIPs currently do.

I might also suggest that the numbers are only automatically offered when a
maintainer does not reject it for three days. That way they can focus on
just responding to obvious spam, and if rejected the moderator name is on
it, rather than the current anonymous pocket veto.

— Christopher Allen [via iPhone]

On Tue, Oct 24, 2023 at 3:57 PM Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> TL;DR: let's just use an automated system to assign BIP numbers, so we can
> spend time on more impactful things.
>
> IIUC, one the primary roles of the dedicated BIP maintainers is just to
> hand
> out BIP numbers for documents. Supposedly with this privilege, the BIP
> maintainer is able to tastefully assign related BIPs to consecutive
> numbers,
> and also reserve certain BIP number ranges for broad categories, like 3xx
> for p2p changes (just an example).
>
> To my knowledge, the methodology for such BIP number selection isn't
> published anywhere, and is mostly arbitrary. As motioned in this thread,
> some perceive this manual process as a gatekeeping mechanism, and often
> ascribe favoritism as the reason why PR X got a number immediately, but PR
> Y
> has waited N months w/o an answer.
>
> Every few years we go through an episode where someone is rightfully upset
> that they haven't been assigned a BIP number after following the requisite
> process.  Most recently, another BIP maintainer was appointed, with the
> hope
> that the second maintainer would help to alleviate some of the subjective
> load of the position.  Fast forward to this email thread, and it doesn't
> seem like adding more BIP maintainers will actually help with the issue of
> BIP number assignment.
>
> Instead, what if we just removed the subjective human element from the
> process, and switched to using PR numbers to assign BIPs? Now instead of
> attempting to track down a BIP maintainer at the end of a potentially
> involved review+iteration period, PRs are assigned BIP numbers as soon as
> they're opened and we have one less thing to bikeshed and gatekeep.
>
> One down side of this is that assuming the policy is adopted, we'll sorta
> sky rocket the BIP number space. At the time of writing of this email, the
> next PR number looks to be 1508. That doesn't seem like a big deal to me,
> but we could offset that by some value, starting at the highest currently
> manually assigned BIP number. BIP numbers would no longer always be
> contiguous, but that's sort of already the case.
>
> There's also the matter of related BIPs, like the segwit series (BIPs 141,
> 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> think it would be too difficult to find a workable scheme.
>
> Thoughts?
>
> -- Laolu
>
>
> 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: 9488 bytes --]

Re: [bitcoin-dev] Ordinals BIP PR

[Luke Dashjr]

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

Seems like a "solution" looking for a problem which doesn't actually 
exist. And not even a good "solution" for that - might as well not have 
BIP number at all, if they're not going to be usefully assigned. What we 
have now is working fine aside from a few trolls once in a while.

On 10/24/23 18:56, Olaoluwa Osuntokun wrote:
> TL;DR: let's just use an automated system to assign BIP numbers, so we can
> spend time on more impactful things.
>
> IIUC, one the primary roles of the dedicated BIP maintainers is just 
> to hand
> out BIP numbers for documents. Supposedly with this privilege, the BIP
> maintainer is able to tastefully assign related BIPs to consecutive 
> numbers,
> and also reserve certain BIP number ranges for broad categories, like 3xx
> for p2p changes (just an example).
>
> To my knowledge, the methodology for such BIP number selection isn't
> published anywhere, and is mostly arbitrary. As motioned in this thread,
> some perceive this manual process as a gatekeeping mechanism, and often
> ascribe favoritism as the reason why PR X got a number immediately, 
> but PR Y
> has waited N months w/o an answer.
>
> Every few years we go through an episode where someone is rightfully upset
> that they haven't been assigned a BIP number after following the requisite
> process.  Most recently, another BIP maintainer was appointed, with 
> the hope
> that the second maintainer would help to alleviate some of the subjective
> load of the position.  Fast forward to this email thread, and it doesn't
> seem like adding more BIP maintainers will actually help with the issue of
> BIP number assignment.
>
> Instead, what if we just removed the subjective human element from the
> process, and switched to using PR numbers to assign BIPs? Now instead of
> attempting to track down a BIP maintainer at the end of a potentially
> involved review+iteration period, PRs are assigned BIP numbers as soon as
> they're opened and we have one less thing to bikeshed and gatekeep.
>
> One down side of this is that assuming the policy is adopted, we'll sorta
> sky rocket the BIP number space. At the time of writing of this email, the
> next PR number looks to be 1508. That doesn't seem like a big deal to me,
> but we could offset that by some value, starting at the highest currently
> manually assigned BIP number. BIP numbers would no longer always be
> contiguous, but that's sort of already the case.
>
> There's also the matter of related BIPs, like the segwit series (BIPs 141,
> 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> think it would be too difficult to find a workable scheme.
>
> Thoughts?
>
> -- Laolu
>
>
> 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
>

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

Re: [bitcoin-dev] Ordinals BIP PR

[Peter Todd]

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

On Tue, Oct 24, 2023 at 03:56:55PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote:
> TL;DR: let's just use an automated system to assign BIP numbers, so we can
> spend time on more impactful things.

Yes, an easy way to do that is to use a mathematical function, like SHA256(<bip contents>)
or Pubkey(<bip author controlled secret key>).

Of course, that's also silly, as we might as well use URLs at that point...

> IIUC, one the primary roles of the dedicated BIP maintainers is just to hand
> out BIP numbers for documents. Supposedly with this privilege, the BIP
> maintainer is able to tastefully assign related BIPs to consecutive numbers,
> and also reserve certain BIP number ranges for broad categories, like 3xx
> for p2p changes (just an example).
>
> To my knowledge, the methodology for such BIP number selection isn't
> published anywhere, and is mostly arbitrary. As motioned in this thread,
> some perceive this manual process as a gatekeeping mechanism, and often
> ascribe favoritism as the reason why PR X got a number immediately, but PR Y
> has waited N months w/o an answer.
> 
> Every few years we go through an episode where someone is rightfully upset
> that they haven't been assigned a BIP number after following the requisite
> process.  Most recently, another BIP maintainer was appointed, with the hope
> that the second maintainer would help to alleviate some of the subjective
> load of the position.  Fast forward to this email thread, and it doesn't
> seem like adding more BIP maintainers will actually help with the issue of
> BIP number assignment.
> 
> Instead, what if we just removed the subjective human element from the
> process, and switched to using PR numbers to assign BIPs? Now instead of
> attempting to track down a BIP maintainer at the end of a potentially
> involved review+iteration period, PRs are assigned BIP numbers as soon as
> they're opened and we have one less thing to bikeshed and gatekeep.
> 
> One down side of this is that assuming the policy is adopted, we'll sorta
> sky rocket the BIP number space. At the time of writing of this email, the
> next PR number looks to be 1508. That doesn't seem like a big deal to me,
> but we could offset that by some value, starting at the highest currently
> manually assigned BIP number. BIP numbers would no longer always be
> contiguous, but that's sort of already the case.
> 
> There's also the matter of related BIPs, like the segwit series (BIPs 141,
> 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> think it would be too difficult to find a workable scheme.

At that point, why are we bothering with numbers at all? If BIP #'s aren't
memorable, what is their purpose? Why not just let people publish ideas on
their own web pages and figure out what we're going to call those ideas on a
case-by-case basis.

All this gets back to my original point: a functioning BIP system is
*inherently* centralized and involves human gatekeepers who inevitably have to
apply standards to approve BIPs. You can't avoid this as long as you want a BIP
system.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Ordinals BIP PR

[Alexander F. Moser]

A mostly self-managed scheme without exploding number spaces and half-decent quality control:

New ideas and proposals-in-development are in a draft/discussion state without any assigned or reserved BIP ordinal and remain as such until the following three conditions are true:

1 - author(s) consider the proposal final and want to promote it to a BIP.
Purpose: quality ensured by reputation 
Risk: Expectations, Experience, Ego

2 - enough non-author interactions with the draft exist. This can be platform agnostic, with „interactions“ meaning comments, non-author contributors, likes, stars, threads,.. and „enough“ meaning flat thresholds, a function of various factors, a combination of the two or nothing specific at all. 
Purpose: quality ensured by many 
Risk: heated discussions on stupid topics and spam inflate interactions 

3 - no other drafts exist that fulfill condition 1 and 2 and seek the ordinal „lastBIP#+1“. 
Purpose: avoiding coincidental concurrency issues and fights over esoteric numbers. 
Risk: resolutions may need moderation and can be tedious 

Draft promotions are done in batches at e.g. every quadruple-zero ending block number (xx0000) - a bit more often than once a quarter or more often at e.g every 2016 blocks (~2w) at difficulty adjustment. 



Fairly straightforward and simple methodology, but should still provide - in an ideal world - enough framework for proposers to self manage fully. In realistic worlds, we can use BIP maintainers to moderate and protect the process. 

Condition 2 „Interactions“ could be changed to „Enough non-authors consider proposal final“ to ensure more quality by enticing co-responsibility, but it’d need a new approval process, which is more annoying than soft-defining required levels of community engagement and relying on the authors for common sense. 

Best,
A


On 27.10.2023, at 00:12, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Tue, Oct 24, 2023 at 03:56:55PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote:
> TL;DR: let's just use an automated system to assign BIP numbers, so we can
> spend time on more impactful things.

Yes, an easy way to do that is to use a mathematical function, like SHA256(<bip contents>)
or Pubkey(<bip author controlled secret key>).

Of course, that's also silly, as we might as well use URLs at that point...

> IIUC, one the primary roles of the dedicated BIP maintainers is just to hand
> out BIP numbers for documents. Supposedly with this privilege, the BIP
> maintainer is able to tastefully assign related BIPs to consecutive numbers,
> and also reserve certain BIP number ranges for broad categories, like 3xx
> for p2p changes (just an example).
> 
> To my knowledge, the methodology for such BIP number selection isn't
> published anywhere, and is mostly arbitrary. As motioned in this thread,
> some perceive this manual process as a gatekeeping mechanism, and often
> ascribe favoritism as the reason why PR X got a number immediately, but PR Y
> has waited N months w/o an answer.
> 
> Every few years we go through an episode where someone is rightfully upset
> that they haven't been assigned a BIP number after following the requisite
> process.  Most recently, another BIP maintainer was appointed, with the hope
> that the second maintainer would help to alleviate some of the subjective
> load of the position.  Fast forward to this email thread, and it doesn't
> seem like adding more BIP maintainers will actually help with the issue of
> BIP number assignment.
> 
> Instead, what if we just removed the subjective human element from the
> process, and switched to using PR numbers to assign BIPs? Now instead of
> attempting to track down a BIP maintainer at the end of a potentially
> involved review+iteration period, PRs are assigned BIP numbers as soon as
> they're opened and we have one less thing to bikeshed and gatekeep.
> 
> One down side of this is that assuming the policy is adopted, we'll sorta
> sky rocket the BIP number space. At the time of writing of this email, the
> next PR number looks to be 1508. That doesn't seem like a big deal to me,
> but we could offset that by some value, starting at the highest currently
> manually assigned BIP number. BIP numbers would no longer always be
> contiguous, but that's sort of already the case.
> 
> There's also the matter of related BIPs, like the segwit series (BIPs 141,
> 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> think it would be too difficult to find a workable scheme.

At that point, why are we bothering with numbers at all? If BIP #'s aren't
memorable, what is their purpose? Why not just let people publish ideas on
their own web pages and figure out what we're going to call those ideas on a
case-by-case basis.

All this gets back to my original point: a functioning BIP system is
*inherently* centralized and involves human gatekeepers who inevitably have to
apply standards to approve BIPs. You can't avoid this as long as you want a BIP
system.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinals BIP PR

[alicexbt]

Hi Peter,

> At that point, why are we bothering with numbers at all? If BIP #'s aren't
memorable, what is their purpose? Why not just let people publish ideas on
their own web pages and figure out what we're going to call those ideas on a
case-by-case basis.

I agree people can maintain BIPs in their own repositories. I will list all the 
BIPs that are not maintained in https://github.com/bitcoin/bips repository on 
https://bips.wiki

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, October 27th, 2023 at 3:41 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> On Tue, Oct 24, 2023 at 03:56:55PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote:
> 
> > TL;DR: let's just use an automated system to assign BIP numbers, so we can
> > spend time on more impactful things.
> 
> 
> Yes, an easy way to do that is to use a mathematical function, like SHA256(<bip contents>)
> 
> or Pubkey(<bip author controlled secret key>).
> 
> 
> Of course, that's also silly, as we might as well use URLs at that point...
> 
> > IIUC, one the primary roles of the dedicated BIP maintainers is just to hand
> > out BIP numbers for documents. Supposedly with this privilege, the BIP
> > maintainer is able to tastefully assign related BIPs to consecutive numbers,
> > and also reserve certain BIP number ranges for broad categories, like 3xx
> > for p2p changes (just an example).
> > 
> > To my knowledge, the methodology for such BIP number selection isn't
> > published anywhere, and is mostly arbitrary. As motioned in this thread,
> > some perceive this manual process as a gatekeeping mechanism, and often
> > ascribe favoritism as the reason why PR X got a number immediately, but PR Y
> > has waited N months w/o an answer.
> > 
> > Every few years we go through an episode where someone is rightfully upset
> > that they haven't been assigned a BIP number after following the requisite
> > process. Most recently, another BIP maintainer was appointed, with the hope
> > that the second maintainer would help to alleviate some of the subjective
> > load of the position. Fast forward to this email thread, and it doesn't
> > seem like adding more BIP maintainers will actually help with the issue of
> > BIP number assignment.
> > 
> > Instead, what if we just removed the subjective human element from the
> > process, and switched to using PR numbers to assign BIPs? Now instead of
> > attempting to track down a BIP maintainer at the end of a potentially
> > involved review+iteration period, PRs are assigned BIP numbers as soon as
> > they're opened and we have one less thing to bikeshed and gatekeep.
> > 
> > One down side of this is that assuming the policy is adopted, we'll sorta
> > sky rocket the BIP number space. At the time of writing of this email, the
> > next PR number looks to be 1508. That doesn't seem like a big deal to me,
> > but we could offset that by some value, starting at the highest currently
> > manually assigned BIP number. BIP numbers would no longer always be
> > contiguous, but that's sort of already the case.
> > 
> > There's also the matter of related BIPs, like the segwit series (BIPs 141,
> > 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> > the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> > later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> > think it would be too difficult to find a workable scheme.
> 
> 
> At that point, why are we bothering with numbers at all? If BIP #'s aren't
> memorable, what is their purpose? Why not just let people publish ideas on
> their own web pages and figure out what we're going to call those ideas on a
> case-by-case basis.
> 
> All this gets back to my original point: a functioning BIP system is
> inherently centralized and involves human gatekeepers who inevitably have to
> apply standards to approve BIPs. You can't avoid this as long as you want a BIP
> system.
> 
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinals BIP PR

[Casey Rodarmor]

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

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
>

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

Re: [bitcoin-dev] Ordinals BIP PR

[Claus Ehrenberg]

[-- 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 --]