Motivation and deployment of consensus rules changes ([soft/hard]forks)
8 messages, 20 Jun to 29 Aug 2015. Started by Jorge Timón.
Jorge Timón (5), Tier Nolan (2), Thomas Kerin
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.
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.
On Sun, Jun 21, 2015 at 12:08 AM, Tier Nolan <tier.nolan@gmail•com> wrote:
Quoted text (2 lines)
> 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?
On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
Quoted text (3 lines)
> 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?
Quoted text (1 line)
>
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.
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:
Quoted text (29 lines)
> 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 >
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:
Quoted text (17 lines)
> 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
Quoted text (5 lines)
>> 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
Quoted text (1 line)
>> the same timestamp. This would force the off by 1 and the correct
value to
Quoted text (9 lines)
>> 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. >> >>
On Fri, Jul 31, 2015 at 7:40 PM, Thomas Kerin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (1 line)
> 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 ).
On Wed, Aug 26, 2015 at 1:20 AM, Andy Chase via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (3 lines)
> 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
Quoted text (3 lines)
> - 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
Quoted text (2 lines)
> - 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).
Quoted text (1 line)
> - 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.
Quoted text (3 lines)
> - 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).
Quoted text (9 lines)
> - 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?