BIP 2 promotion to Final
15 messages, 8 to 18 Mar 2016. Started by Luke Dashjr.
Luke Dashjr (4), Mustafa Al-Bassam (4), Jorge Timón (3), Btc Drak (2), Tom Zander, David A. Harding
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:
Quoted text (7 lines)
> 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
Quoted text (1 line)
> 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"?
Quoted text (1 line)
>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:
Quoted text (31 lines)
> 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
On 10/03/16 00:53, Luke Dashjr wrote:
Quoted text (6 lines)
> 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"?
Quoted text (16 lines)
>
>>> 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.
Quoted text (1 line)
> Luke
On Mar 10, 2016 02:04, "Mustafa Al-Bassam via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (10 lines)
>
> >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.
On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> 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?
On 10/03/16 15:59, Jorge Timón wrote:
Quoted text (18 lines)
> > > 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."
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:
Quoted text (35 lines)
> > > 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."
On Thursday, March 10, 2016 2:02:15 PM Mustafa Al-Bassam wrote:
Quoted text (25 lines)
> 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
On Mar 10, 2016 17:28, "Mustafa Al-Bassam" <mus@musalbas•com> wrote:
Quoted text (2 lines)
> > 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).
Quoted text (1 line)
> 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?
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:
Quoted text (40 lines)
> 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 >
On Wednesday, March 16, 2016 8:43:09 PM Btc Drak wrote:
Quoted text (7 lines)
> 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
On Wed, Mar 16, 2016 at 10:24 PM, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (6 lines)
> 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.
Quoted text (5 lines)
> 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.
Quoted text (11 lines)
> 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.
Quoted text (3 lines)
> 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.
Quoted text (6 lines)
> (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.
On Wednesday 16 Mar 2016 22:24:30 Luke Dashjr via bitcoin-dev wrote:
Quoted text (4 lines)
> 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.
On Friday, March 18, 2016 9:42:16 AM Btc Drak wrote:
Quoted text (9 lines)
> 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.
Quoted text (9 lines)
> > 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.
Quoted text (15 lines)
> > 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.
Quoted text (9 lines)
> > 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.
Quoted text (7 lines)
> > (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.
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