📅 Original date posted:2021-04-27
📝 Original message:On Mon, 26 Apr 2021 at 22:08, Greg Maxwell via bitcoin-dev <
bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210427/3e9db685/attachment-0001.html>;
Melvin Carvalho [ARCHIVE] /
npub1uv…saxrt
2023-06-07 22:52:11
in reply to nevent1q…t2yf
Author Public Key
npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrtPublished at
2023-06-07 22:52:11Event JSON
{
"id": "2b6e8440ea20b66af5137b90e8599f138ca6642b5ce2df7c521a53494ac36f43",
"pubkey": "e316966328c4cb66c34719ef9a7b3bc54ef601663ad4ab06185991237735aa19",
"created_at": 1686178331,
"kind": 1,
"tags": [
[
"e",
"df836c08d17c8829c94bdff4bd50436435b585a258e1227991e1c4e4a55feeb7",
"",
"root"
],
[
"e",
"7a5de60ec476f37c8452e6b351305c5245d2519cac5ac79726405fbab47065da",
"",
"reply"
],
[
"p",
"c15c8800d747ca99260c227e8a2e45189be385760ca56bec8045e4a1beb4613b"
]
],
"content": "📅 Original date posted:2021-04-27\n📝 Original message:On Mon, 26 Apr 2021 at 22:08, Greg Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I endorse Harding's recommendations. On the point about mirroring,\n\u003e one thing to keep in mind is that the other repositories may go\n\u003e offline.\n\u003e\n\u003e Modification confusion could be avoided by recording what revision\n\u003e (commit hash) was current at the time of inclusion, but the document\n\u003e going offline can only be protected against by maintaining a copy\n\u003e somewhere.\n\u003e\n\nOne could partially solve the mirroring issue by giving each decentralized\nBIP (optionally) a genesis transaction ID, that moved in time on the block\nchain\n\nThis can be made to mirror / witness the evolution in git of the BIP using\ngit commit hashes (in time), and then matching those commit hashes in the\nblock chain by tweaking the public key address by the same amount (with no\nchange address)\n\nWhat would occur then would be a genesis and current definitive HEAD of a\nBIP, and the history it's gone through. The whole history can be\nreconstructed from any one transaction. This is quite similar to Peter\nTodd's single use seals, and the work done on RGB\n\nRegarding commit trees going offline, they can be mirrored, hosted on\npopular sites (github/gitlab) and it's natural that popular repos in git\nare cloned\n\nThis also provides a little skin in the game and prevents some sybil\nattacks, because you need to spend money on a TX\n\nIn this way whole BIPs can have a life cycle outside of any official body,\nbut also be assigned BIP numbers in the bitcoin repo\n\nThis mainly an informational idea, however, I have been working on some\ncode and early prototypes to do this, so feel free to message me off-list\nif there's additional interest\n\n\n\u003e\n\u003e\n\u003e On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev\n\u003e wrote:\n\u003e \u003e \u003e In general, I think its time we all agree the BIP process has simply\n\u003e failed\n\u003e \u003e \u003e and move on. Luckily its not really all that critical and proposed\n\u003e protocol\n\u003e \u003e \u003e documents can be placed nearly anywhere with the same effect.\n\u003e \u003e\n\u003e \u003e I recommend:\n\u003e \u003e\n\u003e \u003e 1. We add additional BIP editors, starting with Kalle Alm (if there are\n\u003e \u003e no continuing significant objections).\n\u003e \u003e\n\u003e \u003e 2. We seek Luke Dashjr's resignation as BIPs editor.\n\u003e \u003e\n\u003e \u003e 3. We begin treating protocol documents outside the BIPs repository as\n\u003e \u003e first-class BIP documentation.\n\u003e \u003e\n\u003e \u003e The first recommendation permits continued maintenance of existing BIPs\n\u003e \u003e plus gives the additional maintainers an opportunity to rebuild the\n\u003e \u003e credibility of the repository.\n\u003e \u003e\n\u003e \u003e The second recommendation addresses the dissatisfaction of many BIP\n\u003e \u003e authors and potential authors with the current editor, which I think\n\u003e \u003e will discourage many of them from making additional significant\n\u003e \u003e contributions to the repository. It also seems to me to be a better use\n\u003e \u003e of Luke's talents and interests for him to focus on protocol research\n\u003e \u003e and review rather than procedurally checking whether a bunch of\n\u003e \u003e documents are well formed.\n\u003e \u003e\n\u003e \u003e The third recommendation provides an escape hatch for anyone, such as\n\u003e \u003e Matt, who currently thinks the process has failed, or for anyone who\n\u003e \u003e comes to that same conclusion in the future under a different editing\n\u003e \u003e team. My specific recommendations there are:\n\u003e \u003e\n\u003e \u003e a. Anyone writing protocol documentation in the spirit of the BIP\n\u003e \u003e process can post their idea to this mailing list like we've always\n\u003e \u003e done and, when they've finished collecting initial feedback, they can\n\u003e \u003e assign themselves a unique decentralized identifier starting with\n\u003e \u003e \"bip-\". They may also define a shorter alias that they encourage\n\u003e \u003e people to use in cases where the correct document can be inferred\n\u003e \u003e from context. E.g.,\n\u003e \u003e\n\u003e \u003e bip-wuille-taproot (bip-taproot)\n\u003e \u003e bip-towns-versionbits-min-activation-height (bip-vbmah)\n\u003e \u003e bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)\n\u003e \u003e\n\u003e \u003e b. The author then publishes the document to any place they'd like,\n\u003e although\n\u003e \u003e they are strongly encouraged to make any document source available\n\u003e \u003e under an open license to ensure others can create their own\n\u003e \u003e modifications.\n\u003e \u003e\n\u003e \u003e c. Implementations of BIPs, whether original repository BIPs or\n\u003e \u003e decentralized BIPs, link to the BIPs they implement to ensure\n\u003e \u003e researchers and developers can find the relevant protocol\n\u003e \u003e documentation. E.g.,\n\u003e \u003e\n\u003e https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md\n\u003e \u003e\n\u003e \u003e (It may also be advisable for implementations to mirror copies of\n\u003e \u003e the BIPs they implement so later modifications to the document\n\u003e \u003e don't confuse anyone. For this reason, extremely liberal\n\u003e \u003e licensing of BIP documents is encouraged.)\n\u003e \u003e\n\u003e \u003e d. To help maintain quality and consistency between documentation, the\n\u003e \u003e BIP editors provide a BIP document template, guidelines similar to\n\u003e \u003e the existing BIP2, and an easy-to-run format linter.\n\u003e \u003e\n\u003e \u003e I think this decentralized BIPs alternative also helps address some\n\u003e \u003e longstanding problems with the BIPs system: that many casual Bitcoin\n\u003e \u003e users and developers think of documents in the BIPs repo as\n\u003e \u003e authoritative and that there are some development teams (such as for LN)\n\u003e \u003e that have already abandoned the BIPs process because, in part, they want\n\u003e \u003e complete control over their own documentation.\n\u003e \u003e\n\u003e \u003e The recommendations above were developed based on conversations I had\n\u003e \u003e with a few stakeholders in the BIPs process, but I did not attempt a\n\u003e \u003e comprehensive survey and I certainly don't claim to speak for anyone\n\u003e \u003e else. I hope the recommendations are satisfactory and I look forward to\n\u003e \u003e your feedback.\n\u003e \u003e\n\u003e \u003e Thanks,\n\u003e \u003e\n\u003e \u003e -Dave\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210427/3e9db685/attachment-0001.html\u003e",
"sig": "82ec327f262021bb0a382afc1e92a339740fb0b397d4f74e758a3e0b601f34fb388db1a7855990e180a61b6d20aa36578afdcf9150187a126e245c47b4f1a764"
}