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] Proposed BIP for OP_CAT
I agree that there is no reason not to use OP_SUCCESS126, i.e. the original OP_CAT opcode 0x7e. In many codebases, for example in Core, there might be two OP_CAT constants than which might be confusing. On 10/22/23 09:58, vjudeu via bitcoin-dev wrote: > This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS80. Why OP_SUCCESS80, and not OP_SUCCESS126? When there is some existing opcode, it should be reused. And if OP_RESERVED will ever be re-enabled, I think it should behave in the same way, as in pre-Taproot, so it should "Mark transaction as invalid unless occuring in an unexecuted OP_IF branch". Which means, " OP_VERIFY" should be equivalent to " OP_NOTIF OP_RESERVED OP_ENDIF". On 2023-10-21 07:09:13 user Ethan Heilman via bitcoin-dev wrote: Hi everyone, We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki OP_CAT was available in early versions of Bitcoin. It was disabled as it allowed the construction of a script whose evaluation could create stack elements exponential in the size of the script. This is no longer an issue in the current age as tapscript enforces a maximum stack element size of 520 Bytes. Thanks, Ethan ==Abstract== This BIP defines OP_CAT a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS80. When evaluated the OP_CAT instruction: # Pops the top two values off the stack, # concatenate the popped values together, # and then pushes the concatenated value on the top of the stack. OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size of greater than the maximum script element size of 520 Bytes. ==Motivation== Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. For instance this prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript. OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular and useful opcode in the spirit of Unix[1]. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable: * Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions. [2] * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely requires the ability to hash and concatenate values on the stack. [3] * Non-equivocation contracts [4] in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols. * Vaults [5] which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin. * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures. [6] The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script for which an evaluation could have memory usage exponential in the size of the script. For instance a script which pushed an 1 Byte value on the stack then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes. ==Specification== Implementation if (stack.size() <
Re: [bitcoin-dev] Proposed BIP for OP_CAT
On Tue, Oct 24, 2023 at 02:15:49PM +1030, Rusty Russell wrote: > Andrew Poelstra writes: > > I had a similar thought. But my feeling is that replacing the stack > > interpreter data structure is still too invasive to justify the benefit. > > > > Also, one of my favorite things about this BIP is the tiny diff. > > To be fair, this diff is even smaller than the OP_CAT diff :) > Oh, look at that :). For some reason I had it in my head that looping like this would mess up the asymptotics and meaningfully harm performance. But no, it just involves adding (at most) 1000 numbers. Which is unlikely to even be measurable. > Though I had to strongly resist refactoring, that interpreter code > needs a good shake! Using a class for the stack is worth doing anyway > (macros, really??). > Hah, agreed, but it still makes my hands sweat to think about refactoring that file. -- 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
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
