[bitcoin-dev] BIP 2 promotion to Final

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

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
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,

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Jorge Timón via bitcoin-dev

2016-03-10 15:46:57 UTC

On Mar 10, 2016 02:04, "Mustafa Al-Bassam via bitcoin-dev" <

A hard-fork BIP requires adoption from the entire Bitcoin economy,

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.

Mustafa Al-Bassam via bitcoin-dev

2016-03-10 14:02:15 UTC

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

Jorge Timón via bitcoin-dev

2016-03-10 15:59:32 UTC

On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" <

Post by Mustafa Al-Bassam via bitcoin-dev
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?

Mustafa Al-Bassam via bitcoin-dev

2016-03-10 16:28:43 UTC

Post by Jorge TimÃ³n via bitcoin-dev
On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev"

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."

Mustafa Al-Bassam via bitcoin-dev

2016-03-10 16:33:40 UTC

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.

Post by Jorge TimÃ³n via bitcoin-dev
On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev"

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."

Jorge Timón via bitcoin-dev

2016-03-10 18:30:22 UTC

Post by Mustafa Al-Bassam via bitcoin-dev
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).

Post by Mustafa Al-Bassam via bitcoin-dev
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?

Luke Dashjr via bitcoin-dev

2016-03-10 16:43:59 UTC

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.

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

Btc Drak via bitcoin-dev

2016-03-16 20:43:09 UTC

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 <

Post by Luke Dashjr via 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
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,

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

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Luke Dashjr via bitcoin-dev

2016-03-16 22:24:30 UTC

Post by Btc Drak via bitcoin-dev
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

Tom via bitcoin-dev

2016-03-18 11:59:36 UTC

Post by Luke Dashjr via bitcoin-dev
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.

Btc Drak via bitcoin-dev

2016-03-18 09:42:16 UTC

Post by Luke Dashjr via bitcoin-dev
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.

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.

Post by Luke Dashjr via bitcoin-dev
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.

Post by Luke Dashjr via bitcoin-dev
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.

Post by Luke Dashjr via bitcoin-dev
(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.

Luke Dashjr via bitcoin-dev

2016-03-18 19:34:52 UTC

Post by Luke Dashjr via bitcoin-dev
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.

Post by Luke Dashjr via bitcoin-dev
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.

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.

GitHub's collaborative features for the wiki function is clearly inferior.

Post by Luke Dashjr via bitcoin-dev
I hope this addresses all your concerns and we can move forward with BIP
2 unmodified?

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.

Certainly those could be on the comments page.

David A. Harding via bitcoin-dev

2016-03-18 22:52:55 UTC