* [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
[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 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
* 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 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-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-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-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
* 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
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