Delivery-date: Wed, 03 Apr 2024 22:33:12 -0700 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rsFip-0007Jn-Vm for bitcoindev@gnusha.org; Wed, 03 Apr 2024 22:33:12 -0700 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-5a4701f970fsf767885eaf.0 for ; Wed, 03 Apr 2024 22:33:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712208785; cv=pass; d=google.com; s=arc-20160816; b=hNNyfPUD3iIzWAinoW02mxWjrpJfFSr7EHJAGXTTC1174A11LAquYGSkr+vmV3ZNFs nklZmupSitvpTBkIvmvPEn2NG2h1gvlkNDiWk+JVUrgGgsoyfy4au2u9FfXz3uG9yZVL 1MmZOj+2XhTrSSfUHXiuGzuCXkCj6bELqoSi2WPS6TeQmwCpP++f1HnMm3GJmXkYtnoq G6KnhuyKvbA/gal3Ly1AGjbM+7NWONToSFqK51VJ0g0/s1ceQ0ykGuQQorKKmS5jlZqH Yzx+ajERXWj1ThHnWjaQzna2aFSyurkq2CZnY0VEHTUVEohN0NBl3142/rQ3SoDW40hd WmfQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:dkim-signature; bh=kJlZAEkkRQ6mRhK0g/+6XCK1fcGIlKguJ+bvUMGIuSE=; fh=6gnKUcDwY/ssyvMU2P1gU4vVpaAE2Img3ggPP0NBrp8=; b=X4bBiQQO+JYH3AwOdmE5fuXiUYNQJ82C6Phrs1JGOO2F9V4TBd6kCr3ZIUJsFDZCrw RJAPW1mnpQ9AqyOueuGhrzYBf527Z4nUIPRyK+g2NRenJKev1oCyen68AuNGfnk5ySeI /5hiQz6xEGDM6itIehmpQbBEDYUadZZPcr/vpe7n7UYL6zA7G/4g04flqncRwg978b3Q hYtoe3h/Es1M0wjjj3Ed5Vq4dNEwSIzVfxYO+1swFOg3yFYJsF/ABykOo11i3sJZ7y5b UUCXtP2JEWhcfPLdy4JTvFX4Jv3slP/iw69psEbywKGi9W5CiuM553ghMIikUdisTPVm Jg5Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1712208785; x=1712813585; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :x-original-authentication-results:x-original-sender:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:sender:from:to:cc:subject:date:message-id:reply-to; bh=kJlZAEkkRQ6mRhK0g/+6XCK1fcGIlKguJ+bvUMGIuSE=; b=AjI7NqZ3+/qDowGDLg2PKIGL3aylInZr52V5uZcuP8ySxxrqSZEUDQJgQ6d0pwf1Fr GcRkD9K9g1pl/395lCjvP3HfUma9yL0cgfj/uvwuTGfry+m08h8ROQdwIKYjkV+M8Z1d e3jtIzujVHxk/S/Z/89yaHlkH4u+UDkxaPY47yvw7GCyxfyO8YF+7EmbN82cH0tGsWgr kmyhSjTvNR/nzykB9AewPzddoE3WMeDrTSde5/XhZnSoEJQz3uBSRVmo/OFkHhkX/DV9 x5IY96tXNzgGp81reCNITUyTgtmNmFV9y8CQg9TKmqfVZ4u13BxaFBWgu2XbmmRZL7kk DWVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712208785; x=1712813585; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :x-original-authentication-results:x-original-sender:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-beenthere:x-gm-message-state:sender:from:to:cc :subject:date:message-id:reply-to; bh=kJlZAEkkRQ6mRhK0g/+6XCK1fcGIlKguJ+bvUMGIuSE=; b=gWuRz1GpPpTnr83hP5QnofAfxSnjiK2r9xDuXMKQwCskqOPHGL1cTPmck3CFvqopz4 6RJZkgiOhhWzRridZriZCatQTBrqDdsdjbHqeum/Z7nsKmBWFtBtyR/fD45jOImXnmbo oW62mvFPZql/D9XWgPvL2XbFzMDP3uA76Bttqu1ku+dsWHFiXnOoWfkD8B55yz3mL7sw hp+2xNxQ8mNW8HlWbEYYEWjCfVabh4+53bahDn+jVYEkkR5nB1iXpGXLDxLXyYqFDYZe DMTkmHfxKF6GXo0Z+IkQwoDyL7gmXY1O7raH9qEYIcgmLQ4q0nX/BwwpJ8hcQv5iZjog gnPg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW6BE8hiP6NfFOftzKLY10BLMIQcupnCmKMx8C16YwcfKi3IsFo+/yt3RjD7ri75kfOd6JSeR/7eRJ6rP9LmsnCWq+WHWc= X-Gm-Message-State: AOJu0YyDgwmYAZxRhCv2EIiMgPZzZOX5ZQpYQj9r9NDjHd551dXURRb0 tzR44Fw6N/tiHjVwbq2KFfe/JmJ7NaczXdgX624kVNRx9grjwAQe X-Google-Smtp-Source: AGHT+IGnZut3wBsMxPbnQJCnQSbbBHYP/GhwnuluSoElbLJraVU+mHNJisY3riw1agCJa1ocR29uBA== X-Received: by 2002:a05:6820:3093:b0:5a5:1fdc:8542 with SMTP id eu19-20020a056820309300b005a51fdc8542mr1421351oob.2.1712208785552; Wed, 03 Apr 2024 22:33:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6820:60d:b0:5a9:cb2e:d7ee with SMTP id e13-20020a056820060d00b005a9cb2ed7eels19310oow.1.-pod-prod-01-us; Wed, 03 Apr 2024 22:33:04 -0700 (PDT) X-Received: by 2002:a05:6820:16a3:b0:5a5:1e07:2433 with SMTP id bc35-20020a05682016a300b005a51e072433mr88912oob.1.1712208784475; Wed, 03 Apr 2024 22:33:04 -0700 (PDT) Received: by 2002:a05:6808:1895:b0:3c3:d110:85c6 with SMTP id 5614622812f47-3c5d63e1a9amsb6e; Wed, 3 Apr 2024 22:00:41 -0700 (PDT) X-Received: by 2002:a05:6a20:6f8e:b0:1a7:243a:2a3e with SMTP id gv14-20020a056a206f8e00b001a7243a2a3emr1894981pzb.42.1712206839960; Wed, 03 Apr 2024 22:00:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1712206839; cv=none; d=google.com; s=arc-20160816; b=h4o/pTxKuGQX0HDeht78/QtHTlJ8GmwOgO7ulGrF54phsxa3bO8XK9opJ9DudyHigu gPyX7O1g8hut5IvSkJ754wcsJpSqPn7jyYt6eCs9Rira/RfMouEi7P0eZyNDuNVKzUpZ wD6jza2COXwRboJqHat/mnFZJvRbv6ajvDkAHoUbOgkYGklQ1QxYa0lFikyVDrBzzEqG EYdVy0/dBbpiRB1hh6ndHUtUhUVyc+6ZSBWLMWAXHaHjKZQMBUnQJ1Nr+5vIzGepk0cZ bwms92fBJ4PkTO89hLmmnncjvFyRel4wastAIXQCk1s9mleqL4rp9kw2RkgW2kKtAW5w se6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date; bh=X01VYRQi1CsVmad+CKwDlt1vLauxZF/4wjAlxNPHGfE=; fh=AJmo87NE5dfEu3UrLyv4VoizShv5307BT3L8qe2e/iY=; b=r6F7qhBU5bldtQEFLiGW2Ypih39ilzStZoH3JlK/zJtNnrbXwUXIYLmDUAf5rEf02M IOnyKtSod53sQJGCrI2e47FwlJ2ErQ75kza5U7QPfwAaw7JRyWf98O95WnA9B25YUxzQ AJMF3Z11feohxM0xDgmD1r0ce3d3jdJSexvrb3p9hwI002RQCuRA34EdKCDdHs/frK1N oLe8oyKelJqTTUVv6xamhgV6CxfnnJBqyi2NIjBVtslxwS6+69z4kpSxpWjRYINOl8RL XeSgRRrHAY7zgSaY5LgwoMThkty5Yjj7/lNgp/pSL5r5A009edCK9D0BOnHA0Rpam2YK zKVg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id r2-20020a170902c60200b001e29e0aef75si131764plr.10.2024.04.03.22.00.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 22:00:39 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rsFDF-00079N-3K; Thu, 04 Apr 2024 15:00:37 +1000 Received: by email (sSMTP sendmail emulation); Thu, 04 Apr 2024 15:00:28 +1000 Date: Thu, 4 Apr 2024 15:00:28 +1000 From: Anthony Towns To: Pieter Wuille Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Time for an update to BIP2? Message-ID: References: <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org> <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de> <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one> <9ebd08b0-7680-4896-aad3-1c225b764bcb@mattcorallo.com> <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de> <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net> X-Spam_score: 0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Content-Transfer-Encoding: quoted-printable Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On Wed, Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote: > - Scope: related to technology that supports the bitcoin currency. > This last one may be controversial, but I feel that some of the discussio= n the past months about the process has shown that there is unclarity/disag= reement here, and it would be good to have some guideline written out here.= I think scope will inevitably be somewhat of a grey zone, but I feel some = limits (whether spelled out or not) will exist regardless (nobody would con= sider including the HTTP spec in scope for a BIP, I think?). > I also don't think scope should be tied to specific technologies (e.g. it= shouldn't just be about on-chain transactions, as e.g. that would exclude = address formats), but if not that, what scoping is useful? And to me, restr= icting to technology that supports the bitcoin currency is fairly clear, re= asonable, and avoids a circular definition. As an example, that would exclu= de OpenTimestamps from scope (which was suggested in https://lists.linuxfou= ndation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as = an unrelated application which happens to make use of the Bitcoin blockchai= n, which on itself is one of the technologies that supports bitcoin - but i= s an indirection too far to be in scope. For BINANA I phrased that as "proposals only being rejected if they are ... unrelated to Bitcoin", on the basis that deciding some BIP/BIN is dumb and ignoring it wastes a lot less time than arguing about whether it's a good thing for the monetary properties of Bitcoin (which is what I'm interested in helping people work on). For example, would adding script opcodes whose only purpose is to better support moving BTC to/from sidechains like Liquid or WBTC on Eth, where they can be used as collateral in market makers for trading other tokens count as "supporting the bitcoin currency"? This might include such things like Drivechains (BIP 300, 301), eg. Is such a feature more about supporting asset trading, or is anything that involves buying/selling things with Bitcoin count as supporting bitcoin as a currency? Does it make a difference that a script opcode would be consensus critical? Another way of allowing trading between BTC and other assets is the "Taproot Assets" proposal (BIPs PR#1489), which anchor trades between BTC and tokenized assets on the Bitcoin blockchain, but don't require consensus changes. If the BIPS repo includes docs on Drivechains, is excluding proposals about Taproot Assets or RGB or similar that valuable? Those all seems arguable to me; but why force people to have those arguments over making up a number and hosting a document in a git repo? > > * The Comments-URI thing is outdated and everyone seems to ignore it. > > Comments-Summary is even weirder. > Agreed. It's unused, and sometimes misinterpreted. I think we should get = rid of it. For BINANA I added a "Discussion" header where the BIN author can point to locations where discussion has/can take place -- it seemed like a useful thing to have beyond just links in the "rationale", both for researching background into the proposals development, and as a pointer to somewhere people can leave additional feedback. I don't think there's much value in having a dedicated discussion area in the BINANA/BIP repo itself though. > > * "Informational BIPs do not necessarily represent a Bitcoin community > > consensus or recommendation". Aha, does this imply that Standards > > Track BIPs need to represent a Bitcoin community consensus or > > recommendation? > Indeed. I don't think BIPs should be representing community consensus or = recommendations. But perhaps they can document individual pieces of evidenc= e of acceptance; see further? Documenting consensus change activation seems useful if nothing else, eg as in BIP 90. > > * Ever tried to write pseudocode or LaTeX in mediawiki format? It's > > more than annoying, believe me. > I'd like permitting BIPs to be written in markdown. This is already permitted, see https://github.com/bitcoin/bips/pull/1504 > Some forms of Status are useful I think, but they ought to reflect the au= thor's intent, not the community's perception. E.g. "Draft", "Proposed", an= d "Withdrawn" make sense to me for any kind of standard. In Draft stage mor= e substantial changes could be permitted, but would convey the idea isn't y= et intended for adoption. Of course, the BIP1 status fields weren't really = used, and the BIP2 status fields don't seem to be doing much better. If we = assume that BIP3 status fields aren't going to be used either this is all f= or nought, but perhaps it's still worth trying with a significantly simplif= ied assortment of statuses. >=20 > Things like "Active / Final" and "Rejected" relate to community acceptanc= e, and I agree those don't belong in BIPs. I think "Proposed" is much more related to community acceptance than "Active" -- you can reasonably say something is "Active" once a single implementation has a released version that actively supports it, for example; but describing a standard as "Proposed" seems to be pretty clearly trying to achieve so form of community acceptance? Who else would you be proposing it to? I'd look at the lifecycle more as something like: * Draft: author expects further changes, don't deploy this * Proposed: author is hoping for multiple implementations to adopt this; author thinks it's complete, but there may be objections and it may need to go back to Draft state to resolve those objections * Active: one or more implementations have deployed this feature as specced. changes will usually be specified in a new proposal/standard. acceptable changes might be fixing ambiguities, adding extra rationale or test cases, etc. * Withdrawn: no current implementations support this, author doesn't think it should be adopted, author isn't planning on making further changes to it For comparison, BINANA currently has BINs marked Draft, Active and Info: https://github.com/bitcoin-inquisition/binana (Note that adding a consensus change in inquisition and doing a heretical activation of that change on signet would still leave the spec in "Draft" -- further changes are expected) (As far as BIP 2's list goes, I think Deferred should just be Draft; Rejected/Obsolete should just be Withdrawn; Final should just be Active; and Replaced should either be Withdrawn or Active depending on whether the replacement is backwards compatible, accompanied by Superseded-By) > As far as judging consensus goes, perhaps actual consensus changes are an= exception? I feel that for those, an "Accepted" status may actually make s= ense, because they actually require the ecosystem to have agreement about. How about BIP 148 or BIP 91? I think it's fair to call both of those "Active" and would have been fair to mark them Active sometime in April-July 2017 -- that doesn't mean there was necessarily community consensus behind them: merely that there was software implementing those standards active on the network, and that if someone wanted to do something similar but different, that would warrant being a different standard. If it had turned out there wasn't consensus behind either proposal, and no one was mining a blockchain that those implementations would accept, at most that would warrant the author marking the BIPs as "Withdrawn" IMO. The same argument applies to BIP 343 I think. I believe only one implementation adopted it [0], and I don't believe any actively maintained software implements that BIP as written, but if you did implement it you'd continue to track the bitcoin blockchain, so I think it would be fair to have marked that BIP as "Active" once it was adopted by an implementation, and to have left it marked that way. [0] "Bitcoin Core-based Taproot Client" which doesn't even seem to exist in web.archive.org. https://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/tap= root.html If the segwit2x fork had ever had a written spec, I likewise think it would have been appropriate for it to be a BIP, perhaps being marked as Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo was marked as archived). [1] https://github.com/btc1/bitcoin/pull/50 [2] https://github.com/btc1/bitcoin/releases/tag/v1.14.5 [3] https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-Novem= ber/000685.html Cheers, aj --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/Zg4z7P%2BMKzEfCkdM%40erisian.com.au.