path: root/e2/92c614c997a3c0f7f4c7aebc9c8a30cfb46f54

Return-Path: <melvincarvalho@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3F7E2C001C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 19:43:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2E89C40217
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 19:43:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6JGJsUXyQ2_U
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 19:43:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com
 [IPv6:2607:f8b0:4864:20::136])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 6708C40212
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 19:43:52 +0000 (UTC)
Received: by mail-il1-x136.google.com with SMTP id b17so50473422ilh.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 27 Apr 2021 12:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=+5/6avyzgnd/v0X60E0QNn4RzPYJ06hVdiIEBLrHqcw=;
 b=eI2sI/mDe+VVXY2QfUul9EV/F/+Oa912xI5sQ91EWOW2ug2GzkZeZU3U4iB2vkKk3J
 ao+qFUkQBg60gBe5kbNFyBEgaHKC9FZUK9ZXfc0roZXxTTBQt+H4maA+k+7ol57jzVZ4
 Ov0sVJvNjPsr6AXEbHQ90Ae/VuS9NeZna5is6yoMji2rsJuQsQMkXpfEPJKjcuKN1fOy
 X5O5+F+osvgdtAQ2ItjuaEALgprg2mRgooT/4zO36Wi/EeC3wnNebCbrIwEWDGIcOjD1
 iY8ha3lO7RitBg6qSvsuOSvqsQUd1twaUYT0lskKEG6n+fKwtiLcELaUL3NVdhnm31Vn
 Ta6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=+5/6avyzgnd/v0X60E0QNn4RzPYJ06hVdiIEBLrHqcw=;
 b=J1nvtCh7k6IJN4A/uO/OKG6jGwO85x5hQdC6OiJVeYfm56PIUS4U/sEATJkvVcyzlT
 ww0OZjXgIKRjhZ+QGzQvNIGoDbA4nXa1wpmJqlDu9R5v1yZik0A4TSzK4J9MZGdbOSsT
 7E9lSqgAgA6InlDYo6X9LqfQlmUU0hGJnKtRy25/o/FXnwd4sSg80nIrvR3IP26BV8gQ
 /qaIla1SQJy2C0jbzRivf7x6c7PTPkNd7aB8rxEOzza69VwzZs8ULZWM7qZWfkMFJ8DB
 FHnUHrA30/5HTWYTegy22FdvRw3uXX/tcO8wORRop2FSGmCaih09tYG8yceXCqL+XNnM
 iLMg==
X-Gm-Message-State: AOAM530WogHvkCjpGth2Tdy77xv8AHu6bMdyep2nrzdsOY3Wqz0A4xrw
 gDEmExHdeAF1QnurhD1wdVdmxejmRNWq+tBBzj0=
X-Google-Smtp-Source: ABdhPJwrnq99a7bLg8tDDnVoWk09lYp4U3lns2PTmEcpJ4EkNHcPDQ/waDScFoxmzsIp4k3hIs0KIeGCv8Jts4PBL3A=
X-Received: by 2002:a05:6e02:1b81:: with SMTP id
 h1mr20269145ili.157.1619552631566; 
 Tue, 27 Apr 2021 12:43:51 -0700 (PDT)
MIME-Version: 1.0
References: <202104230209.05373.luke@dashjr.org>
 <202104252100.07296.luke@dashjr.org>
 <40214e32-ffb3-9518-7bc8-9c1059f50da7@mattcorallo.com>
 <202104252122.40909.luke@dashjr.org>
 <248f871e-1b83-8c7c-678b-3ed0585a6357@mattcorallo.com>
 <20210426194309.2k5exujz23vjrgwc@ganymede>
 <CAAS2fgRZwf=SBB4EvpeTBLshRfT1tmnv33GP+Ln+w2bxt48=pA@mail.gmail.com>
In-Reply-To: <CAAS2fgRZwf=SBB4EvpeTBLshRfT1tmnv33GP+Ln+w2bxt48=pA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 27 Apr 2021 21:43:40 +0200
Message-ID: <CAKaEYhKB-zkXc-6KgOcsTOAreAMwnqhFjB7mBOSnkXt=oxLg3w@mail.gmail.com>
To: Greg Maxwell <gmaxwell@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004cb6f005c0f97b24"
X-Mailman-Approved-At: Tue, 27 Apr 2021 20:21:09 +0000
Subject: Re: [bitcoin-dev] Reminder on the Purpose of BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2021 19:43:54 -0000

--0000000000004cb6f005c0f97b24
Content-Type: text/plain; charset="UTF-8"

On Mon, 26 Apr 2021 at 22:08, Greg Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I endorse Harding's recommendations.  On the point about mirroring,
> one thing to keep in mind is that the other repositories may go
> offline.
>
> Modification confusion could be avoided by recording what revision
> (commit hash) was current at the time of inclusion, but the document
> going offline can only be protected against by maintaining a copy
> somewhere.
>

One could partially solve the mirroring issue by giving each decentralized
BIP (optionally) a genesis transaction ID, that moved in time on the block
chain

This can be made to mirror / witness the evolution in git of the BIP using
git commit hashes (in time), and then matching those commit hashes in the
block chain by tweaking the public key address by the same amount (with no
change address)

What would occur then would be a genesis and current definitive HEAD of a
BIP, and the history it's gone through.  The whole history can be
reconstructed from any one transaction.  This is quite similar to Peter
Todd's single use seals, and the work done on RGB

Regarding commit trees going offline, they can be mirrored, hosted on
popular sites (github/gitlab) and it's natural that popular repos in git
are cloned

This also provides a little skin in the game and prevents some sybil
attacks, because you need to spend money on a TX

In this way whole BIPs can have a life cycle outside of any official body,
but also be assigned BIP numbers in the bitcoin repo

This mainly an informational idea, however, I have been working on some
code and early prototypes to do this, so feel free to message me off-list
if there's additional interest


>
>
> On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > > In general, I think its time we all agree the BIP process has simply
> failed
> > > and move on. Luckily its not really all that critical and proposed
> protocol
> > > documents can be placed nearly anywhere with the same effect.
> >
> > I recommend:
> >
> > 1. We add additional BIP editors, starting with Kalle Alm (if there are
> >    no continuing significant objections).
> >
> > 2. We seek Luke Dashjr's resignation as BIPs editor.
> >
> > 3. We begin treating protocol documents outside the BIPs repository as
> >    first-class BIP documentation.
> >
> > The first recommendation permits continued maintenance of existing BIPs
> > plus gives the additional maintainers an opportunity to rebuild the
> > credibility of the repository.
> >
> > The second recommendation addresses the dissatisfaction of many BIP
> > authors and potential authors with the current editor, which I think
> > will discourage many of them from making additional significant
> > contributions to the repository.  It also seems to me to be a better use
> > of Luke's talents and interests for him to focus on protocol research
> > and review rather than procedurally checking whether a bunch of
> > documents are well formed.
> >
> > The third recommendation provides an escape hatch for anyone, such as
> > Matt, who currently thinks the process has failed, or for anyone who
> > comes to that same conclusion in the future under a different editing
> > team.  My specific recommendations there are:
> >
> > a. Anyone writing protocol documentation in the spirit of the BIP
> >    process can post their idea to this mailing list like we've always
> >    done and, when they've finished collecting initial feedback, they can
> >    assign themselves a unique decentralized identifier starting with
> >    "bip-".  They may also define a shorter alias that they encourage
> >    people to use in cases where the correct document can be inferred
> >    from context.  E.g.,
> >
> >       bip-wuille-taproot (bip-taproot)
> >       bip-towns-versionbits-min-activation-height (bip-vbmah)
> >       bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
> >
> > b. The author then publishes the document to any place they'd like,
> although
> >    they are strongly encouraged to make any document source available
> >    under an open license to ensure others can create their own
> >    modifications.
> >
> > c. Implementations of BIPs, whether original repository BIPs or
> >    decentralized BIPs, link to the BIPs they implement to ensure
> >    researchers and developers can find the relevant protocol
> >    documentation.  E.g.,
> >
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
> >
> >      (It may also be advisable for implementations to mirror copies of
> >      the BIPs they implement so later modifications to the document
> >      don't confuse anyone.  For this reason, extremely liberal
> >      licensing of BIP documents is encouraged.)
> >
> > d. To help maintain quality and consistency between documentation, the
> >    BIP editors provide a BIP document template, guidelines similar to
> >    the existing BIP2, and an easy-to-run format linter.
> >
> > I think this decentralized BIPs alternative also helps address some
> > longstanding problems with the BIPs system: that many casual Bitcoin
> > users and developers think of documents in the BIPs repo as
> > authoritative and that there are some development teams (such as for LN)
> > that have already abandoned the BIPs process because, in part, they want
> > complete control over their own documentation.
> >
> > The recommendations above were developed based on conversations I had
> > with a few stakeholders in the BIPs process, but I did not attempt a
> > comprehensive survey and I certainly don't claim to speak for anyone
> > else.  I hope the recommendations are satisfactory and I look forward to
> > your feedback.
> >
> > Thanks,
> >
> > -Dave
> > _______________________________________________
> > 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
>

--0000000000004cb6f005c0f97b24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, 26 Apr 2021 at 22:08, Greg Ma=
xwell via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">I endorse Harding&#39;s recomm=
endations.=C2=A0 On the point about mirroring,<br>
one thing to keep in mind is that the other repositories may go<br>
offline.<br>
<br>
Modification confusion could be avoided by recording what revision<br>
(commit hash) was current at the time of inclusion, but the document<br>
going offline can only be protected against by maintaining a copy<br>
somewhere.<br></blockquote><div><br></div><div>One could partially solve th=
e mirroring issue by giving each decentralized BIP (optionally) a genesis t=
ransaction ID, that moved in time on the block chain<br></div><div><br></di=
v><div>This can be made to mirror / witness the evolution in git of the BIP=
 using git commit hashes (in time), and then matching those commit hashes i=
n the block chain by tweaking the public key address by the same amount (wi=
th no change address)<br></div><div><br></div><div>What would occur then wo=
uld be a genesis and current definitive HEAD of a BIP, and the history it&#=
39;s gone through.=C2=A0 The whole history can be reconstructed from any on=
e transaction.=C2=A0 This is quite similar to Peter Todd&#39;s single use s=
eals, and the work done on RGB<br></div><div><br></div><div>Regarding commi=
t trees going offline, they can be mirrored, hosted on popular sites (githu=
b/gitlab) and it&#39;s natural that popular repos in git are cloned</div><d=
iv><br></div><div>This also provides a little skin in the game and prevents=
 some sybil attacks, because you need to spend money on a TX<br></div><div>=
<br></div><div>In this way whole BIPs can have a life cycle outside of any =
official body, but also be assigned BIP numbers in the bitcoin repo</div><d=
iv><br></div><div>This mainly an informational idea, however, I have been w=
orking on some code and early prototypes to do this, so feel free to messag=
e me off-list if there&#39;s additional interest<br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev=
 wrote:<br>
&gt; &gt; In general, I think its time we all agree the BIP process has sim=
ply failed<br>
&gt; &gt; and move on. Luckily its not really all that critical and propose=
d protocol<br>
&gt; &gt; documents can be placed nearly anywhere with the same effect.<br>
&gt;<br>
&gt; I recommend:<br>
&gt;<br>
&gt; 1. We add additional BIP editors, starting with Kalle Alm (if there ar=
e<br>
&gt;=C2=A0 =C2=A0 no continuing significant objections).<br>
&gt;<br>
&gt; 2. We seek Luke Dashjr&#39;s resignation as BIPs editor.<br>
&gt;<br>
&gt; 3. We begin treating protocol documents outside the BIPs repository as=
<br>
&gt;=C2=A0 =C2=A0 first-class BIP documentation.<br>
&gt;<br>
&gt; The first recommendation permits continued maintenance of existing BIP=
s<br>
&gt; plus gives the additional maintainers an opportunity to rebuild the<br=
>
&gt; credibility of the repository.<br>
&gt;<br>
&gt; The second recommendation addresses the dissatisfaction of many BIP<br=
>
&gt; authors and potential authors with the current editor, which I think<b=
r>
&gt; will discourage many of them from making additional significant<br>
&gt; contributions to the repository.=C2=A0 It also seems to me to be a bet=
ter use<br>
&gt; of Luke&#39;s talents and interests for him to focus on protocol resea=
rch<br>
&gt; and review rather than procedurally checking whether a bunch of<br>
&gt; documents are well formed.<br>
&gt;<br>
&gt; The third recommendation provides an escape hatch for anyone, such as<=
br>
&gt; Matt, who currently thinks the process has failed, or for anyone who<b=
r>
&gt; comes to that same conclusion in the future under a different editing<=
br>
&gt; team.=C2=A0 My specific recommendations there are:<br>
&gt;<br>
&gt; a. Anyone writing protocol documentation in the spirit of the BIP<br>
&gt;=C2=A0 =C2=A0 process can post their idea to this mailing list like we&=
#39;ve always<br>
&gt;=C2=A0 =C2=A0 done and, when they&#39;ve finished collecting initial fe=
edback, they can<br>
&gt;=C2=A0 =C2=A0 assign themselves a unique decentralized identifier start=
ing with<br>
&gt;=C2=A0 =C2=A0 &quot;bip-&quot;.=C2=A0 They may also define a shorter al=
ias that they encourage<br>
&gt;=C2=A0 =C2=A0 people to use in cases where the correct document can be =
inferred<br>
&gt;=C2=A0 =C2=A0 from context.=C2=A0 E.g.,<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0bip-wuille-taproot (bip-taproot)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0bip-towns-versionbits-min-activation-height =
(bip-vbmah)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0bip-todd-harding-opt-in-replace-by-fee (bip-=
opt-in-rbf)<br>
&gt;<br>
&gt; b. The author then publishes the document to any place they&#39;d like=
, although<br>
&gt;=C2=A0 =C2=A0 they are strongly encouraged to make any document source =
available<br>
&gt;=C2=A0 =C2=A0 under an open license to ensure others can create their o=
wn<br>
&gt;=C2=A0 =C2=A0 modifications.<br>
&gt;<br>
&gt; c. Implementations of BIPs, whether original repository BIPs or<br>
&gt;=C2=A0 =C2=A0 decentralized BIPs, link to the BIPs they implement to en=
sure<br>
&gt;=C2=A0 =C2=A0 researchers and developers can find the relevant protocol=
<br>
&gt;=C2=A0 =C2=A0 documentation.=C2=A0 E.g.,<br>
&gt;=C2=A0 =C2=A0 <a href=3D"https://github.com/bitcoin/bitcoin/blob/fe5e49=
5c31de47b0ec732b943db11fe345d874af/doc/bips.md" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b9=
43db11fe345d874af/doc/bips.md</a><br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 (It may also be advisable for implementations to m=
irror copies of<br>
&gt;=C2=A0 =C2=A0 =C2=A0 the BIPs they implement so later modifications to =
the document<br>
&gt;=C2=A0 =C2=A0 =C2=A0 don&#39;t confuse anyone.=C2=A0 For this reason, e=
xtremely liberal<br>
&gt;=C2=A0 =C2=A0 =C2=A0 licensing of BIP documents is encouraged.)<br>
&gt;<br>
&gt; d. To help maintain quality and consistency between documentation, the=
<br>
&gt;=C2=A0 =C2=A0 BIP editors provide a BIP document template, guidelines s=
imilar to<br>
&gt;=C2=A0 =C2=A0 the existing BIP2, and an easy-to-run format linter.<br>
&gt;<br>
&gt; I think this decentralized BIPs alternative also helps address some<br=
>
&gt; longstanding problems with the BIPs system: that many casual Bitcoin<b=
r>
&gt; users and developers think of documents in the BIPs repo as<br>
&gt; authoritative and that there are some development teams (such as for L=
N)<br>
&gt; that have already abandoned the BIPs process because, in part, they wa=
nt<br>
&gt; complete control over their own documentation.<br>
&gt;<br>
&gt; The recommendations above were developed based on conversations I had<=
br>
&gt; with a few stakeholders in the BIPs process, but I did not attempt a<b=
r>
&gt; comprehensive survey and I certainly don&#39;t claim to speak for anyo=
ne<br>
&gt; else.=C2=A0 I hope the recommendations are satisfactory and I look for=
ward to<br>
&gt; your feedback.<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; -Dave<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000004cb6f005c0f97b24--