* [bitcoin-dev] BIP 2 promotion to Final
@ 2016-03-08 19:04 Luke Dashjr
2016-03-10 0:36 ` Mustafa Al-Bassam
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Luke Dashjr @ 2016-03-08 19:04 UTC (permalink / raw)
To: Bitcoin Dev
It has been about 1 month since BIP 2 finished receiving comments, so I
believe it is an appropriate time to begin the process of moving it to Final
Status. Toward this end, I have opened a pull request:
https://github.com/bitcoin/bips/pull/350
The current requirement for this is that "the reference implementation is
complete and accepted by the community". Given the vagueness of this criteria,
I intend to move forward applying BIP 2's more specific criteria to itself:
> A process BIP may change status from Draft to Active when it achieves rough
> consensus on the mailing list. Such a proposal is said to have rough
> consensus if it has been open to discussion on the development mailing list
> for at least one month, and no person maintains any unaddressed
> substantiated objections to it. Addressed or obstructive objections may be
> ignored/overruled by general agreement that they have been sufficiently
> addressed, but clear reasoning must be given in such circumstances.
Furthermore, there is a reference implementation in the mentioned PR.
Please review the latest draft BIP and provide any objections ASAP.
If there are no outstanding objections on 2016 April 9th, I will consider the
current draft to have reached rough consensus and update its Status to Final
by merging the PR.
Thanks,
Luke
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-08 19:04 [bitcoin-dev] BIP 2 promotion to Final Luke Dashjr @ 2016-03-10 0:36 ` Mustafa Al-Bassam 2016-03-10 15:46 ` Jorge Timón [not found] ` <56E0BFDC.5070604@musalbas.com> 2016-03-16 20:43 ` Btc Drak 2 siblings, 1 reply; 15+ messages in thread From: Mustafa Al-Bassam @ 2016-03-10 0:36 UTC (permalink / raw) To: bitcoin-dev > the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. This wording is awkward. What is "potentially-majority"? >A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. What if one shop owner, for example, out of thousands, doesn't adapt the hard-fork? It is expected, and should perhaps be encouraged, for a small minority to not accept a hard fork, but by the wording of the BIP ("entire Bitcoin economy"), one shop owner can veto a hard-fork. Mustafa On 08/03/16 19:04, Luke Dashjr via bitcoin-dev wrote: > It has been about 1 month since BIP 2 finished receiving comments, so I > believe it is an appropriate time to begin the process of moving it to Final > Status. Toward this end, I have opened a pull request: > > https://github.com/bitcoin/bips/pull/350 > > The current requirement for this is that "the reference implementation is > complete and accepted by the community". Given the vagueness of this criteria, > I intend to move forward applying BIP 2's more specific criteria to itself: > >> A process BIP may change status from Draft to Active when it achieves rough >> consensus on the mailing list. Such a proposal is said to have rough >> consensus if it has been open to discussion on the development mailing list >> for at least one month, and no person maintains any unaddressed >> substantiated objections to it. Addressed or obstructive objections may be >> ignored/overruled by general agreement that they have been sufficiently >> addressed, but clear reasoning must be given in such circumstances. > Furthermore, there is a reference implementation in the mentioned PR. > > Please review the latest draft BIP and provide any objections ASAP. > If there are no outstanding objections on 2016 April 9th, I will consider the > current draft to have reached rough consensus and update its Status to Final > by merging the PR. > > Thanks, > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-10 0:36 ` Mustafa Al-Bassam @ 2016-03-10 15:46 ` Jorge Timón 0 siblings, 0 replies; 15+ messages in thread From: Jorge Timón @ 2016-03-10 15:46 UTC (permalink / raw) To: Mustafa Al-Bassam; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1256 bytes --] On Mar 10, 2016 02:04, "Mustafa Al-Bassam via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > > >A hard-fork BIP requires adoption from the entire Bitcoin economy, > particularly including those selling desirable goods and services in > exchange for bitcoin payments, as well as Bitcoin holders who wish to > spend or would spend their bitcoins (including selling for other > currencies) differently in the event of such a hard-fork. > What if one shop owner, for example, out of thousands, doesn't adapt the > hard-fork? It is expected, and should perhaps be encouraged, for a small > minority to not accept a hard fork, but by the wording of the BIP > ("entire Bitcoin economy"), one shop owner can veto a hard-fork. No, the hardfork can still happen, but if a small group remains using the old chain (a single person will likely abandon it very soon), then it cannot be said that deployment was universal and thus the hardfork BIP doesn't move to the final state. As long as there's users using the old chain, a hardfork BIP shouldn't become final if I understood BIP2 correctly. In other words, uncontroversial hardfork bips can make it to the final state once deployed, controversial hardforks may never become universally deployed. [-- Attachment #2: Type: text/html, Size: 1499 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <56E0BFDC.5070604@musalbas.com>]
[parent not found: <201603100053.43822.luke@dashjr.org>]
* Re: [bitcoin-dev] BIP 2 promotion to Final [not found] ` <201603100053.43822.luke@dashjr.org> @ 2016-03-10 14:02 ` Mustafa Al-Bassam 2016-03-10 15:59 ` Jorge Timón 2016-03-10 16:43 ` Luke Dashjr 0 siblings, 2 replies; 15+ messages in thread From: Mustafa Al-Bassam @ 2016-03-10 14:02 UTC (permalink / raw) To: Luke Dashjr, bitcoin-dev On 10/03/16 00:53, Luke Dashjr wrote: > On Thursday, March 10, 2016 12:29:16 AM Mustafa Al-Bassam wrote: >>> the soft-fork does not become Final for as long as such a hard-fork >>> has potentially-majority support, or at most three months. >> This wording is awkward. What is "potentially-majority"? > A group that is large enough that it may constitute a majority. > How can I reword this better/clearer? "potentially has majority support"? > >>> A hard-fork BIP requires adoption from the entire Bitcoin economy, >>> particularly including those selling desirable goods and services in >>> exchange for bitcoin payments, as well as Bitcoin holders who wish to >>> spend or would spend their bitcoins (including selling for other >>> currencies) differently in the event of such a hard-fork. >> What if one shop owner, for example, out of thousands, doesn't adapt the >> hard-fork? It is expected, and should perhaps be encouraged, for a small >> minority to not accept a hard fork, but by the wording of the BIP >> ("entire Bitcoin economy"), one shop owner can veto a hard-fork. > It's not the hard-fork they can veto (in this context, anyway), but the > progression of the BIP Status field. However, one shop cannot operate in a > vacuum: if they are indeed alone, they will soon find themselves no longer > selling in exchange for bitcoin payments, as nobody else would exist willing > to use the previous blockchain to pay them. If they are no longer selling, > they cease to meet the criteria here enabling their veto. I think in general this sounds like a good definition for a hard-fork becoming active. But I can envision a situation where someone will try to be annoying about it and point to one instance of one buyer and one seller using the blockchain to buy and sell from each other, or set one up. > Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-10 14:02 ` Mustafa Al-Bassam @ 2016-03-10 15:59 ` Jorge Timón 2016-03-10 16:28 ` Mustafa Al-Bassam 2016-03-10 16:43 ` Luke Dashjr 1 sibling, 1 reply; 15+ messages in thread From: Jorge Timón @ 2016-03-10 15:59 UTC (permalink / raw) To: Mustafa Al-Bassam; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 671 bytes --] On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > I think in general this sounds like a good definition for a hard-fork > becoming active. But I can envision a situation where someone will try > to be annoying about it and point to one instance of one buyer and one > seller using the blockchain to buy and sell from each other, or set one up. And all the attacker will achieve is preventing a field on a text file on github from moving from "active" to "final". Seems pretty stupid. Why would an attacker care so much about this? Is there any way the attacker can make gains or harm bitcoin with this attack? [-- Attachment #2: Type: text/html, Size: 848 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-10 15:59 ` Jorge Timón @ 2016-03-10 16:28 ` Mustafa Al-Bassam 2016-03-10 16:33 ` Mustafa Al-Bassam 2016-03-10 18:30 ` Jorge Timón 0 siblings, 2 replies; 15+ messages in thread From: Mustafa Al-Bassam @ 2016-03-10 16:28 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1625 bytes --] On 10/03/16 15:59, Jorge Timón wrote: > > > On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > > I think in general this sounds like a good definition for a hard-fork > > becoming active. But I can envision a situation where someone will try > > to be annoying about it and point to one instance of one buyer and one > > seller using the blockchain to buy and sell from each other, or set > one up. > > And all the attacker will achieve is preventing a field on a text file > on github from moving from "active" to "final". > Seems pretty stupid. Why would an attacker care so much about this? Is > there any way the attacker can make gains or harm bitcoin with this > attack? > It's extremely naive to think that just because you can't think of an incentive for a reason for an attack to do this, an attacker will never to do this. There are many people that would be willing to spend some time to cause some trouble for the enjoyment of it, if the attack is free to execute. The fact that it takes very little time and effort to prevent a BIP from reaching final status, means that in an base of millions of users it's guaranteed that some disgruntled or bored person out there will attack it, even if it's for the lulz. To reasonably expect that any hark fork - including an uncontroversial one - will be adapted by every single person in a ecosystem of millions of people, is wishful thinking and the BIP may as well say "hard fork BIPs shall never reach final status." [-- Attachment #2: Type: text/html, Size: 2354 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-10 16:28 ` Mustafa Al-Bassam @ 2016-03-10 16:33 ` Mustafa Al-Bassam 2016-03-10 18:30 ` Jorge Timón 1 sibling, 0 replies; 15+ messages in thread From: Mustafa Al-Bassam @ 2016-03-10 16:33 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1863 bytes --] By the way, on that basis it might be a good idea to introduce an extra status called "deployed" to indicate when a hard fork has reached a super-majority and is being used by the economy in practice, but not the whole economy. On 10/03/16 16:28, Mustafa Al-Bassam wrote: > > > On 10/03/16 15:59, Jorge Timón wrote: >> >> >> On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> > I think in general this sounds like a good definition for a hard-fork >> > becoming active. But I can envision a situation where someone will try >> > to be annoying about it and point to one instance of one buyer and one >> > seller using the blockchain to buy and sell from each other, or set >> one up. >> >> And all the attacker will achieve is preventing a field on a text >> file on github from moving from "active" to "final". >> Seems pretty stupid. Why would an attacker care so much about this? >> Is there any way the attacker can make gains or harm bitcoin with >> this attack? >> > It's extremely naive to think that just because you can't think of an > incentive for a reason for an attack to do this, an attacker will > never to do this. There are many people that would be willing to spend > some time to cause some trouble for the enjoyment of it, if the attack > is free to execute. > > The fact that it takes very little time and effort to prevent a BIP > from reaching final status, means that in an base of millions of users > it's guaranteed that some disgruntled or bored person out there will > attack it, even if it's for the lulz. > > To reasonably expect that any hark fork - including an uncontroversial > one - will be adapted by every single person in a ecosystem of > millions of people, is wishful thinking and the BIP may as well say > "hard fork BIPs shall never reach final status." [-- Attachment #2: Type: text/html, Size: 2902 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-10 16:28 ` Mustafa Al-Bassam 2016-03-10 16:33 ` Mustafa Al-Bassam @ 2016-03-10 18:30 ` Jorge Timón 1 sibling, 0 replies; 15+ messages in thread From: Jorge Timón @ 2016-03-10 18:30 UTC (permalink / raw) To: Mustafa Al-Bassam; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 904 bytes --] On Mar 10, 2016 17:28, "Mustafa Al-Bassam" <mus@musalbas•com> wrote: > > The fact that it takes very little time and effort to prevent a BIP from reaching final status, means that in an base of millions of users it's guaranteed that some disgruntled or bored person out there will attack it, even if it's for the lulz. I still fail to see the harm caused by this attack. At some point the attacker will get bored of laughing even if the attack has a small costs (which I'm not that sure it is). > To reasonably expect that any hark fork - including an uncontroversial one - will be adapted by every single person in a ecosystem of millions of people, is wishful thinking and the BIP may as well say "hard fork BIPs shall never reach final status." This is what seem to have happened with uncontroversial softforks in the past. Why is wishful thinking to expect the same for uncontroversial hardforks? [-- Attachment #2: Type: text/html, Size: 1074 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-10 14:02 ` Mustafa Al-Bassam 2016-03-10 15:59 ` Jorge Timón @ 2016-03-10 16:43 ` Luke Dashjr 1 sibling, 0 replies; 15+ messages in thread From: Luke Dashjr @ 2016-03-10 16:43 UTC (permalink / raw) To: Mustafa Al-Bassam; +Cc: bitcoin-dev On Thursday, March 10, 2016 2:02:15 PM Mustafa Al-Bassam wrote: > On 10/03/16 00:53, Luke Dashjr wrote: > > On Thursday, March 10, 2016 12:29:16 AM Mustafa Al-Bassam wrote: > >>> A hard-fork BIP requires adoption from the entire Bitcoin economy, > >>> particularly including those selling desirable goods and services in > >>> exchange for bitcoin payments, as well as Bitcoin holders who wish to > >>> spend or would spend their bitcoins (including selling for other > >>> currencies) differently in the event of such a hard-fork. > >> > >> What if one shop owner, for example, out of thousands, doesn't adapt the > >> hard-fork? It is expected, and should perhaps be encouraged, for a small > >> minority to not accept a hard fork, but by the wording of the BIP > >> ("entire Bitcoin economy"), one shop owner can veto a hard-fork. > > > > It's not the hard-fork they can veto (in this context, anyway), but the > > progression of the BIP Status field. However, one shop cannot operate in > > a vacuum: if they are indeed alone, they will soon find themselves no > > longer selling in exchange for bitcoin payments, as nobody else would > > exist willing to use the previous blockchain to pay them. If they are no > > longer selling, they cease to meet the criteria here enabling their > > veto. > > I think in general this sounds like a good definition for a hard-fork > becoming active. But I can envision a situation where someone will try > to be annoying about it and point to one instance of one buyer and one > seller using the blockchain to buy and sell from each other, or set one up. In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of the BIP process IMO. Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-08 19:04 [bitcoin-dev] BIP 2 promotion to Final Luke Dashjr 2016-03-10 0:36 ` Mustafa Al-Bassam [not found] ` <56E0BFDC.5070604@musalbas.com> @ 2016-03-16 20:43 ` Btc Drak 2016-03-16 22:24 ` Luke Dashjr 2 siblings, 1 reply; 15+ messages in thread From: Btc Drak @ 2016-03-16 20:43 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2176 bytes --] I have an objection about "BIP comments" in BIP2. I think BIPs should be self contained, but the specification recommends posting comments to the Bitcoin Wiki (bitcoin.it). I think this is a bad idea and external sources are bound to go stale over time as can be evidenced by a number of existing BIPs which link to external content that has long since expired. Comments should be made instead using the Wiki feature at bitcoin/bips itself (which can be enabled in the administration settings). On Tue, Mar 8, 2016 at 7:04 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > It has been about 1 month since BIP 2 finished receiving comments, so I > believe it is an appropriate time to begin the process of moving it to > Final > Status. Toward this end, I have opened a pull request: > > https://github.com/bitcoin/bips/pull/350 > > The current requirement for this is that "the reference implementation is > complete and accepted by the community". Given the vagueness of this > criteria, > I intend to move forward applying BIP 2's more specific criteria to itself: > > > A process BIP may change status from Draft to Active when it achieves > rough > > consensus on the mailing list. Such a proposal is said to have rough > > consensus if it has been open to discussion on the development mailing > list > > for at least one month, and no person maintains any unaddressed > > substantiated objections to it. Addressed or obstructive objections may > be > > ignored/overruled by general agreement that they have been sufficiently > > addressed, but clear reasoning must be given in such circumstances. > > Furthermore, there is a reference implementation in the mentioned PR. > > Please review the latest draft BIP and provide any objections ASAP. > If there are no outstanding objections on 2016 April 9th, I will consider > the > current draft to have reached rough consensus and update its Status to > Final > by merging the PR. > > Thanks, > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3016 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-16 20:43 ` Btc Drak @ 2016-03-16 22:24 ` Luke Dashjr 2016-03-18 9:42 ` Btc Drak 2016-03-18 11:59 ` Tom 0 siblings, 2 replies; 15+ messages in thread From: Luke Dashjr @ 2016-03-16 22:24 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev On Wednesday, March 16, 2016 8:43:09 PM Btc Drak wrote: > I have an objection about "BIP comments" in BIP2. I think BIPs should be > self contained, but the specification recommends posting comments to the > Bitcoin Wiki (bitcoin.it). I think this is a bad idea and external sources > are bound to go stale over time as can be evidenced by a number of existing > BIPs which link to external content that has long since expired. Comments > should be made instead using the Wiki feature at bitcoin/bips itself (which > can be enabled in the administration settings). BIP Comments are not a part of the BIP itself, merely post-completion notes from various external parties. So having them external does not make the BIP any less self-contained. Right now, this information takes the form of reddit/forum comments, IRC chats, etc. It is important that the forum for comments have a low barrier of use. The Bitcoin Wiki requires only a request for editing privileges, whereas GitHub wiki would require reading and agreeing to a lengthy Terms of Service contract. In terms of staleness, the Wiki has been shown to stand the test of time, and is frankly less likely to move than the GitHub repository. The BIP process originated on the Wiki, and was only moved to GitHub because stronger moderation was needed (eg, to prevent random other people from editing someone else's BIP; number self-assignments; etc). Such moderation is not only unnecessary for BIP Comments, but would be an outright nuisance. I hope this addresses all your concerns and we can move forward with BIP 2 unmodified? (On another note, I wonder if we should recommend non-reference implementation lists/links be moved to BIP Comments rather than constantly revising the BIPs with them...) Luke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-16 22:24 ` Luke Dashjr @ 2016-03-18 9:42 ` Btc Drak 2016-03-18 19:34 ` Luke Dashjr 2016-03-18 11:59 ` Tom 1 sibling, 1 reply; 15+ messages in thread From: Btc Drak @ 2016-03-18 9:42 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2389 bytes --] On Wed, Mar 16, 2016 at 10:24 PM, Luke Dashjr <luke@dashjr•org> wrote: > BIP Comments are not a part of the BIP itself, merely post-completion notes > from various external parties. So having them external does not make the > BIP > any less self-contained. Right now, this information takes the form of > reddit/forum comments, IRC chats, etc. > BIP2 does not state the comments section is where discussion happens for the BIP, but for a sort of final summary. > It is important that the forum for comments have a low barrier of use. The > Bitcoin Wiki requires only a request for editing privileges, whereas GitHub > wiki would require reading and agreeing to a lengthy Terms of Service > contract. > Seems weak, it's much easier to sign up for a Github account and most have one already. It's certainly easier than either paying to get edit privileges on the Bitcoin Wiki find someone to convince you're genuine an obscure IRC channel. > In terms of staleness, the Wiki has been shown to stand the test of time, > and > is frankly less likely to move than the GitHub repository. > > The BIP process originated on the Wiki, and was only moved to GitHub > because > stronger moderation was needed (eg, to prevent random other people from > editing someone else's BIP; number self-assignments; etc). Such moderation > is > not only unnecessary for BIP Comments, but would be an outright nuisance. > I'm not sure that is the reason why, but in any case, Github is a more sensible place because of the collaborative features which is why they became the centre of OSS software development for hundreds of thousands of projects. > I hope this addresses all your concerns and we can move forward with BIP 2 > unmodified? > I am sorry but it has not. I still strongly object to using the Bitcoin Wiki or any external source source for the commentary part of BIP2. I believe it should be done on using the Wiki feature at bitcoin/bips. If that is not acceptable, then I would suggest a separate page in the bip assets folder, called bip<nnnn>/comments.md. On a side note, more complex reference implementation code should be stored in that folder too. > (On another note, I wonder if we should recommend non-reference > implementation > lists/links be moved to BIP Comments rather than constantly revising the > BIPs > with them...) > Certainly those could be on the comments page. [-- Attachment #2: Type: text/html, Size: 3393 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-18 9:42 ` Btc Drak @ 2016-03-18 19:34 ` Luke Dashjr 2016-03-18 22:52 ` David A. Harding 0 siblings, 1 reply; 15+ messages in thread From: Luke Dashjr @ 2016-03-18 19:34 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev On Friday, March 18, 2016 9:42:16 AM Btc Drak wrote: > On Wed, Mar 16, 2016 at 10:24 PM, Luke Dashjr <luke@dashjr•org> wrote: > > BIP Comments are not a part of the BIP itself, merely post-completion > > notes from various external parties. So having them external does not > > make the BIP > > any less self-contained. Right now, this information takes the form of > > reddit/forum comments, IRC chats, etc. > > BIP2 does not state the comments section is where discussion happens for > the BIP, but for a sort of final summary. Yes, discussion for the BIP still happens on the mailing list. > > It is important that the forum for comments have a low barrier of use. > > The Bitcoin Wiki requires only a request for editing privileges, whereas > > GitHub wiki would require reading and agreeing to a lengthy Terms of > > Service contract. > > Seems weak, it's much easier to sign up for a Github account and most have > one already. It's certainly easier than either paying to get edit > privileges on the Bitcoin Wiki find someone to convince you're genuine an > obscure IRC channel. Weak? What does that even mean? GitHub's terms are no trivial list. It's not a matter of "easy", but whether you're willing to agree to the terms or not - and people should be free to participate without doing so. The Bitcoin Wiki has never had a problem with whitelisting people, and isn't exclusively available via IRC. > > In terms of staleness, the Wiki has been shown to stand the test of time, > > and > > is frankly less likely to move than the GitHub repository. > > > > The BIP process originated on the Wiki, and was only moved to GitHub > > because > > stronger moderation was needed (eg, to prevent random other people from > > editing someone else's BIP; number self-assignments; etc). Such > > moderation is > > not only unnecessary for BIP Comments, but would be an outright nuisance. > > I'm not sure that is the reason why, but in any case, Github is a more > sensible place because of the collaborative features which is why they > became the centre of OSS software development for hundreds of thousands of > projects. GitHub's collaborative features for the wiki function is clearly inferior. > > I hope this addresses all your concerns and we can move forward with BIP > > 2 unmodified? > > I am sorry but it has not. I still strongly object to using the Bitcoin > Wiki or any external source source for the commentary part of BIP2. I > believe it should be done on using the Wiki feature at bitcoin/bips. If > that is not acceptable, then I would suggest a separate page in the bip > assets folder, called bip<nnnn>/comments.md. On a side note, more complex > reference implementation code should be stored in that folder too. Then you're essentially standing in the way of BIP 2 and stalling it. I have no interest in having to manually approve every single little comment on BIPs, and I think it's likely nobody will use it if doing so requires such effort. > > (On another note, I wonder if we should recommend non-reference > > implementation > > lists/links be moved to BIP Comments rather than constantly revising the > > BIPs > > with them...) > > Certainly those could be on the comments page. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-18 19:34 ` Luke Dashjr @ 2016-03-18 22:52 ` David A. Harding 0 siblings, 0 replies; 15+ messages in thread From: David A. Harding @ 2016-03-18 22:52 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev Hi, Arguing about which wiki is better doesn't feel productive to me. Can we just let BIP authors decide for themselves? Draft-BIP2 already has a provision for allowing authors to specify a backup wiki of their own choosing; can we just make that the policy in all cases (and drop the need for a backup wiki)? -Dave ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] BIP 2 promotion to Final 2016-03-16 22:24 ` Luke Dashjr 2016-03-18 9:42 ` Btc Drak @ 2016-03-18 11:59 ` Tom 1 sibling, 0 replies; 15+ messages in thread From: Tom @ 2016-03-18 11:59 UTC (permalink / raw) To: bitcoin-dev On Wednesday 16 Mar 2016 22:24:30 Luke Dashjr via bitcoin-dev wrote: > It is important that the forum for comments have a low barrier of use. The > Bitcoin Wiki requires only a request for editing privileges, whereas GitHub > wiki would require reading and agreeing to a lengthy Terms of Service > contract. I'd argue that neither of those two qualifies in that case. I second BTCDraks' objection. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-03-18 22:53 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-08 19:04 [bitcoin-dev] BIP 2 promotion to Final Luke Dashjr
2016-03-10 0:36 ` Mustafa Al-Bassam
2016-03-10 15:46 ` Jorge Timón
[not found] ` <56E0BFDC.5070604@musalbas.com>
[not found] ` <201603100053.43822.luke@dashjr.org>
2016-03-10 14:02 ` Mustafa Al-Bassam
2016-03-10 15:59 ` Jorge Timón
2016-03-10 16:28 ` Mustafa Al-Bassam
2016-03-10 16:33 ` Mustafa Al-Bassam
2016-03-10 18:30 ` Jorge Timón
2016-03-10 16:43 ` Luke Dashjr
2016-03-16 20:43 ` Btc Drak
2016-03-16 22:24 ` Luke Dashjr
2016-03-18 9:42 ` Btc Drak
2016-03-18 19:34 ` Luke Dashjr
2016-03-18 22:52 ` David A. Harding
2016-03-18 11:59 ` Tom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox