Re: [bitcoin-dev] Ordinals BIP PR
> 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".___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Wed, Nov 22, 2023 at 1:11 AM 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
> 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.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
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 +, 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
Re: [bitcoin-dev] Ordinals BIP PR
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 +, 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
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 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() > > or Pubkey(). > > > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
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 (xx) - 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 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() or Pubkey(). 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
Re: [bitcoin-dev] Ordinals BIP PR
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() or Pubkey(). 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Mon, Oct 23, 2023 at 06:32:47PM +0200, Tim Ruffing wrote: > On Mon, 2023-10-23 at 15:35 +, 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
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 +, Peter Todd via bitcoin-dev >> wrote: >> >> I have _not_ requested a BIP for OpenTimestamps, even though it is of >> much >> >> wider relevance
Re: [bitcoin-dev] Ordinals BIP PR
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 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 +, 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
Re: [bitcoin-dev] Ordinals BIP PR
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 +, 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 > >
Re: [bitcoin-dev] Ordinals BIP PR
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 > 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 >>> 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
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 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 +, 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, > > >
Re: [bitcoin-dev] Ordinals BIP PR
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 +, 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
On Mon, Oct 23, 2023 at 03:35:30PM +, 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Mon, 2023-10-23 at 15:35 +, 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
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 > 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
Re: [bitcoin-dev] Ordinals BIP PR
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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote: > > > > 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 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Ordinals BIP PR
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
