[Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón]

This is an attempt to unify views on why and how hardforks can be
deployed. I would like to turn this into an informational BIP later
after gathering some feedback.

Please, do not discuss block size issues here: there's plenty of
threads to do so. The scope of this one is only hardforks and
softforks in a more abstract way. Sometimes block size changes are
used as examples because no other example came to mind
(non-blocksize-related examples for the same cases [or others] are
a user should be just ignored. But what if the welcomed), and
if we go into too much detail they stop being useful as examples. So
please, try to avoid going into too much detail about the concrete
examples when possible.

https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org

Please, feel free to make suggestions or bike-shed some of the terms.

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

The off by 1 bug could be fixed by a soft fork.  Since the point is to show
how a non-controversial hard fork works, it doesn't matter much.

[-- Attachment #2: Type: text/html, Size: 172 bytes --]

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón]

On Sun, Jun 21, 2015 at 12:08 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
> The off by 1 bug could be fixed by a soft fork.  Since the point is to show
> how a non-controversial hard fork works, it doesn't matter much.

You mean the timewarp fix can be coded as a softfork instead of a
hardfork? How so?
If that's the case, do you have a better candidate?

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón <jtimon@jtimon.cc> wrote:

> You mean the timewarp fix can be coded as a softfork instead of a
> hardfork? How so?
>

The easiest would be a rule requiring that all blocks are within 1 day of
the median of the previous 11 blocks.  At the moment, you need to be
greater than that value.  This would add a condition at the other end.

It wouldn't be a total fix, but it would protect against the exploit.

A stricter soft fork would be that the two blocks in question have to have
the same timestamp.  This would force the off by 1 and the correct value to
give the same result.

If that's the case, do you have a better candidate?
>

I think it is fine, since fixing it "right" does require a hard fork,
especially if it is only to show a non controversial hard fork.

[-- Attachment #2: Type: text/html, Size: 1370 bytes --]

Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón]

Discussions about whether to get miner's confirmation on
uncontroversial hardforks or not, and about whether to use nHeight,
nMedianTime or just use nTime are spreading all around. Hopefully
getting a BIP number (even though this is still a draft) will help
concentrating discussions about deployment of uncontroversial
hardforks to a single place.
Greg, can I get a BIP number for this?

On Sun, Jun 21, 2015 at 12:54 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
>>
>> You mean the timewarp fix can be coded as a softfork instead of a
>> hardfork? How so?
>
>
> The easiest would be a rule requiring that all blocks are within 1 day of
> the median of the previous 11 blocks.  At the moment, you need to be greater
> than that value.  This would add a condition at the other end.
>
> It wouldn't be a total fix, but it would protect against the exploit.
>
> A stricter soft fork would be that the two blocks in question have to have
> the same timestamp.  This would force the off by 1 and the correct value to
> give the same result.
>
>> If that's the case, do you have a better candidate?
>
>
> I think it is fine, since fixing it "right" does require a hard fork,
> especially if it is only to show a non controversial hard fork.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Thomas Kerin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I really think there should be a document before a BIP number is assigned.


On 23/07/15 12:10, Jorge Timón via bitcoin-dev wrote:
> Discussions about whether to get miner's confirmation on
> uncontroversial hardforks or not, and about whether to use nHeight,
> nMedianTime or just use nTime are spreading all around. Hopefully
> getting a BIP number (even though this is still a draft) will help
> concentrating discussions about deployment of uncontroversial
> hardforks to a single place.
> Greg, can I get a BIP number for this?
>
> On Sun, Jun 21, 2015 at 12:54 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
>> On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
>>>
>>> You mean the timewarp fix can be coded as a softfork instead of a
>>> hardfork? How so?
>>
>>
>> The easiest would be a rule requiring that all blocks are within 1 day of
>> the median of the previous 11 blocks.  At the moment, you need to be
greater
>> than that value.  This would add a condition at the other end.
>>
>> It wouldn't be a total fix, but it would protect against the exploit.
>>
>> A stricter soft fork would be that the two blocks in question have to
have
>> the same timestamp.  This would force the off by 1 and the correct
value to
>> give the same result.
>>
>>> If that's the case, do you have a better candidate?
>>
>>
>> I think it is fine, since fixing it "right" does require a hard fork,
>> especially if it is only to show a non controversial hard fork.
>>
>>
------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- -- 
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVu7MlAAoJEAiDZR291eTlGnkP/jG/oW2PfPwDt6t+1UJ7P1LO
/NDtpUI5wiPQ6aXBmqKSx7FxZ9QJQM1tB1SpGhFosOXXSiYLjNos0l0S6oRw7yGC
LzXmbNTL863F0vOfRU35yxQJbcUi6gOHk8E/oo2X/V+BgAoc4cweK4080C8k1vki
7kPPiSek4erMo7TVNb5vsHkOI6QXhKNV/lFuSOuRAwklRY5vL2BZi56HekOnoFdr
iHebmRrjL7R+IFzasnWtHh6KGs51tg02SOPTMXwJ/H+xDqN9LXk/DJUbp9QhEa+t
TwojQBj7D+HMWavaLRVjVQOcvxxm3PTwZHmHxzfrx3kG5nsZNWrebWElHikW8BuW
dg6Yq/6mIW59HPyNSc5HCBnNonKpZebsQU0rdzOcwWFdk0SZ1TuKrYjNu9uDVGpo
od21hIpGYa1FTxk1HQ63PMf5SKmLunvHOehWw8pmXy44k3WVkABAhi7YNIbA8Qvj
DJ+k9wtypDBraoQh1yur4r1cBbBVcbaxRwv42MBGhtTXPVzRu6CikJNwa65z1AqT
AM3av8+IIgiq9dYn1uzDh1BQGSsB5YYQZ3QDHpM1DxCvjXvmgf4RdFwC0Q0B0X3S
jnWebazQvxN9qsylHAJeTZ0+rJCsx+R3Fl2Myasz/c3a6uaYJVi9/N0j3yRm1EYt
3Py8BGrArkIe3CeXaTCV
=Yh0o
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón]

On Fri, Jul 31, 2015 at 7:40 PM, Thomas Kerin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I really think there should be a document before a BIP number is assigned.

There was a document from the start, but after I got the BIP number, I
was renaming the file, moving from org-mode to mediawiki and getting
the code ready.
I'm sorry, I broke the old link to the document, here's the new one:
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki

Maybe I should create a PR already to have a permanent link, I don't know.
As said in the document, the code is now here:
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11

Also, I should mention that one particular discussion related to this
BIP (whether we should use Block.nTime, median time or block.nHeight
for the activation thresholds) is being discussed in:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

The BIP is currently assuming that the preferred choice for all
non-emergency uncontroversial hardforks is defining a starting
block.nHeight after which miners start confirming their upgrade. Once
the 95% threshold is reached the hardfork takes effect.
Long after that, after that first block enforcing the new rules is
deeply buried, that check can simply replaced by re-defining the
threshold height not with the height when miners started voting, but
simply with the height in which the rules started being enforced for
the first time (see https://github.com/bitcoin/bitcoin/pull/5966/files
).

Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón]

On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> As I understand Github is not to be used for the high-level discussion
> of a draft BIP so I will post my thoughts here (is this specified
> somewhere? Can we specify this in BIP-0001?).

As specified in BIP001, there's an optional field to link to the
discussion on the mailing list, which in this case links to this
thread (that's why I'm replying here):

https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR8

> -   I have some concerns about the structure and the wording of this
>     proposal. I think both the structure and the internal wording can be
>     slimmed down and simplified

You are probably right, but that is too vague for me to take any action.
Can you propose something more concrete as a PR to my branch?

https://github.com/jtimon/bips/tree/bip-forks

>     -   I also believe the "history lessons" should be trimmed out,
>         mentioned at best

Can you explain why?
I think they're helpful as examples for the explanations (even though
the concrete texts can probably improved/summarized).

>     -   There's separate BIP for at least one of the code forks

I'm not sure I understand this.
What do you mean by "code forks"?
If you mean "software fork" (like libcoin or bitcoin xt
[pre-controversial-bip101]) those are completely fine and out of scope
for this BIP, since they don't require coordination by the different
users/implementations to upgrade/re-implement the consensus changes.


> -   BIP-001 specifies that BIP proposals should not be given a BIP
>     number until after they have been spelled checked and approved by an
>     editor. Greg Maxwell: was this followed?

I don't think the spell checking had been followed at all for this or
any other BIP, but yes, Greg assigned the number 99 (he did so
privately instead of here on this thread, which I find very annoying
because you are the second person who complains about this).

> -   What kind of proposal is this? Informational, Process or Standards
>     track?
>
>     -   I believe it should be Standards Track. Include the proposed
>         upgrade path as a patch into core as a module that hard forks
>         can use in the future. This will also give us some space to work
>         through some of the complexities of forks in a definite way.
>     -   Alternatively maybe we can split up this BIP into a Standards
>         track and a separate Informational BIP?

That is a good question. The proposal currently says "informational |
process": https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR6
But I wasn't really convinced about this so I'm happy to change it to
whatever it's more appropriate.
The contained code is an example of an uncontroversial hardfork to
create a precedent. I'm not sure I understand your proposal for a
"patch into core as a module that hard forks can use in the future".
Can you elaborate what would go in that patch?