[bitcoin-dev] BIP 2 promotion to Final

[bitcoin-dev] BIP 2 promotion to Final

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam]

> 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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Jorge Timón]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Jorge Timón]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Jorge Timón]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Btc Drak]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Btc Drak]

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

Re: [bitcoin-dev] BIP 2 promotion to Final

[Tom]

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.

Re: [bitcoin-dev] BIP 2 promotion to Final

[Luke Dashjr]

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.

Re: [bitcoin-dev] BIP 2 promotion to Final

[David A. Harding]

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