Remove 'hard fork' designation on BIP 90

sdaftuar commented at 6:52 pm on January 29, 2018: member

#478 added a label to BIP 90 that I disagree with. While the term “hard fork” is sometimes used in the way defined in BIP 123, it also is used by many – including the BIP 123 author – to refer to consensus changes that require network-wide coordination in deployment to avoid a chain split[1], which is untrue for BIP 90.

As the whole purpose of this BIP is explain the type of consensus change that was made and point out that the network split risk is minimal, I don’t accept the label “hard fork” as a useful or correct designation, and I think it does a disservice to our collective understanding of consensus changes to try to apply a label like this.

–

[1] From https://medium.com/@elombrozo/forks-signaling-and-activation-d60b6abda49a:

Since hard forks loosen or eliminate existing rules, blocks which would have been rejected by the old rules are now accepted by nodes using the new rules. Examples include increasing the block reward, increasing the maximum base block size, changing the block header format, or changing the proof of work function. Nodes that do not update their rules will reject these blocks and will continue to follow only chains that enforce the old rules. This means that unless all nodes update, we will get a chain split.

jnewbery commented at 6:57 pm on January 29, 2018: member

ACK. I don’t think hard fork or soft fork accurately describe this change.

evoskuil commented at 8:32 pm on January 29, 2018: contributor

NACK - the term is clearly correct as used.

morcos commented at 9:09 pm on January 29, 2018: member

ACK. Also I didn’t know BIP 90 could be changed over it’s author’s objection as seems to be the case here.

luke-jr commented at 3:05 am on January 30, 2018: member

“Consensus” is not a valid layer by itself. And not only is it technically a hardfork, but that it is one is the only reason it was a subject matter for a BIP in the first place. If not a hardfork, it would otherwise only be an implementation detail, which doesn’t need to be coordinated across software in the ecosystem.

I am personally divided whether we should have BIPs for these. But if we aren’t going to treat them like live (for lack of a better term) hardforks, then we shouldn’t have BIPs for them at all, and PR #638 shouldn’t be added…

luke-jr commented at 3:06 am on January 30, 2018: member

(This topic should be brought up on the bitcoin-dev mailing list for discussion.)

luke-jr cross-referenced this on Jan 30, 2018 from issue New BIP: P2SH and Version 0 Segwit Script enforcement from genesis by sdaftuar

sdaftuar commented at 4:07 pm on January 30, 2018: member

@luke-jr Can you explain to me what you think the process here is?

MarcoFalke commented at 9:07 pm on January 30, 2018: member

@sdaftuar I think the process is to post to bitcoin-dev mailing list with a writeup saying something along the lines of “BIP 123 categorization might not be the best thing to do. Do people agree to get rid of it. Or even better, has anyone a better proposal?”

I think in the long term everyone agrees to use some (hopefully) clearer categorization… In fact, instead of “working around” it and fixing only this BIP, we could use it as motivation to fix the general problem.

luke-jr commented at 9:41 pm on January 30, 2018: member

There isn’t a problem with this BIP. The layer is correct… The only real question is whether we consider these kinda of hardforks as a standard/BIP, or an implementation detail (no BIP).

sdaftuar commented at 10:19 pm on January 30, 2018: member

There isn’t a problem with this BIP. The layer is correct… The only real question is whether we consider these kinda of hardforks as a standard/BIP, or an implementation detail (no BIP).

I disagree. I think another real question is whether the BIP editor can modify the header against an author’s wishes, as was done here.

An additional question is whether BIP 123 is misguided in the first place. I gave one example above, of commentary from the BIP 123 author about hard forks that suggests the common understanding of a “hard fork” is something other than the change introduced by BIP 90. I found another example in BIP 2, under the description of progressing a BIP to “Final” status:

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. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).

BIP 90 is, in my view, “Final”, yet I don’t believe the above paragraph applies to it. In my view, the point of putting the “Consensus layer” designation in the header is to aid in a reader’s understanding of the change that was made. In this case, the term “hard fork” seems to be generally used to mean something other than the kind of change that was documented in BIP 90 – even according to the language in BIP 2.

As to your question of whether these kind of consensus changes are mere implementation details that should not be documented as BIPs: the fact that there is disagreement over whether the change that this BIP describes is a good idea (at least one commenter “NACK"ed the change, in discussion on the mailing list) suggests that this is more than an implementation detail, and that documentation and discussion is worthwhile. And since the changes affect existing, published BIPs, I don’t know of a better place to document such changes other than as a BIP itself.

Further, I’m not sure why you think that is the “only real question” here – that question doesn’t apply to existing BIPs, only new ones. The subject of this PR is an existing, implemented BIP.

–

As for alternatives to BIP 123 – I think a framework more along the lines of what Johnson Lau wrote up could be helpful. Overall, I think we’ve learned over the years that the terms “soft fork” and “hard fork” are not very descriptive to indicate the scope of the sort of changes that can be made, or how safe such a proposed change can be to deploy.

But while I’d prefer that we move away from BIP 123, I don’t really feel like I should have to sway the whole community to adopt a new framework in order to get the language reverted on a BIP that I have authored. Changing the document without my approval should not have happened in the first place. While that may have been an honest mistake, we should not hold up correcting it.

evoskuil commented at 10:21 pm on January 30, 2018: contributor

If it’s a hard fork (which this is) it should be documented. It’s not clear to me why there is resistance to doing so.

sdaftuar commented at 10:22 pm on January 30, 2018: member

@evoskuil I believe the text of the BIP explains that, in excruciating detail.

evoskuil commented at 10:36 pm on January 30, 2018: contributor

It goes to great lengths to explain that the chance of a chain split from the hard fork is low (or cost of producing it is high), but it does not explain why the author does not want to call the hard fork a hard fork.

luke-jr commented at 10:47 pm on January 30, 2018: member

To be clear, the document itself was not changed, only the preamble/header, which is explicitly the BIP editor’s job to maintain.

sdaftuar commented at 10:52 pm on January 30, 2018: member

@luke-jr What is the process for getting the BIP editor to revert a change to the header?

gmaxwell commented at 10:59 pm on January 30, 2018: contributor

ACK. The characterization of the material described in BIP 90 as a hardfork is simply false on its face.

evoskuil commented at 11:31 pm on January 30, 2018: contributor

It would seem that technical accuracy is taking a back seat to political concerns. Certain people have an interest in preserving a claim that Core has never hardforked. In fact I raised this question when bip90 was implemented. The change was an unnecessary hardfork. As I pointed out on bitcoin-dev at the time, the performance optimization was achievable without a consensus change (as libbitcoin had already done it). This observation went unanswered. The shortcut was taken, it is a hardfork, whether this bip calls it one or not.

evoskuil commented at 11:55 pm on January 30, 2018: contributor

The claim I am referring to is important to some people because it is the basis of a claim that Core represents the true Bitcoin. Otherwise we would not be niggling over the use of the term hardfork in this bip. Core can still claim that it has not introduced a hardfork that has caused a chain split, so there’s still that, but this ship has sailed.

luke-jr commented at 3:25 am on January 31, 2018: member

Regardless of whether this hardfork “counts” or not, there was still the 2013 May hardfork removing the db lock limits that could be used as an example that Core has done a hardfork before. So I don’t think that’s it. And this fact doesn’t take away from Bitcoin being Bitcoin at all anyway.

evoskuil commented at 6:08 am on January 31, 2018: contributor

While I agree with you that the BIP50 hardfork did in fact happen, there is also denial of this fact among Core contributors, which only reinforces my point.

While you and I both accept the fact that the BIP50 and BIP90 hardforks happened, there are those willing to use torturous language to preserve the illusion that Core has never hardforked. There is only one rational explanation for this, which is the idea of an objective criteria for definition of the one true Bitcoin.

As one who does not find the concept of a “legitimate” Bitcoin objective or even interesting, it is easy for me to see that these arguments are bogus and motivated by petty self-interest. Core folks can claim that they have produced only two hardforks, one of which was unintentional and the other has not yet resulted in a chain split. At least that’s accurate (until #638) and an actual differentiation.

sdaftuar commented at 1:15 pm on April 10, 2018: member

@luke-jr Can you please answer my question above, about what process you think is necessary to get the BIP editor to revert the header change?

sdaftuar commented at 3:26 pm on April 16, 2018: member

ping @luke-jr Sorry to keep asking but I don’t know how I’m supposed to proceed. Can you please explain the process that you think I need to follow in order to get this merged?

evoskuil commented at 6:50 pm on April 16, 2018: contributor

What’s the process for changing the meaning of words? One option is to gain control of a small country… “the word for bread were changed to his mother’s name.”

laanwj commented at 7:35 pm on April 16, 2018: member

ACK

jnewbery commented at 7:43 pm on April 16, 2018: member

This is a reversion to the BIP author’s original intent and has 4 ACKs. Presumably it can be merged?

evoskuil commented at 8:37 pm on April 16, 2018: contributor

The issue that @luke-jr has raised has not been addressed. If this BIP does not represent a hard fork it is an implementation detail, not a protocol change, and therefore does not warrant a BIP. OTOH, if it is a protocol change, it’s a hard fork.

A comparable issue could be raised with the removal of the removal of BIP30 check following the activation of BIP34. This change was only a fork if one considers hash collisions possible. Of course hash collisions are possible, but most implementations accept the assumption that they are not. Under this assumption the change became an implementation detail and did therefore not warrant a BIP.

If the community similarly accepts the assumption that deep reorgs are not possible, then BIP90 is just an implementation detail, and does not warrant a BIP. However this assumption is clearly not generally accepted. For it to be accepted there would need to at least be some agreement on the depth at which reorgs are considered impossible. That implies that implementations should enforce such a limit, ensuring that it is actually impossible.

As I see it, and as I have mentioned previously, this attempt to move BIP90 into the ambiguous (and irrational) category of “fork that’s neither hard nor soft” is being sought as a matter of precedent. There is another pending proposal that attempts to apply the same “maximum reorg depth” rationale in other areas. The only reason these categorizations matter to people is in the marketing war over what is the “one true chain”. As the argument goes, if there are no hard forks it’s still the true Bitcoin. That argument has already been surrendered by the merge of BIP90.

TheBlueMatt commented at 6:06 pm on April 17, 2018: contributor

This seems pretty obviously correct to me. “hard fork” implies, well, a fork, whereas a historical rule simplification pretty much isnt. If we intend BIPs to be a way for people to learn about the workings of Bitcoin/be a useful reference, calling things by an appropriate term, instead of some technical quirk resulting in something being called a “hard fork” is much more useful. ACK.

evoskuil commented at 6:58 pm on April 17, 2018: contributor

A great many core development discussions pertaining to hard forks do not support your theory, nor does the existing BIP99 definition of a hard fork. In fact I think it would be hard to find any thread that supports the idea that a forked block must be mined in order for a rule change to be a hard fork. You are conflating hard fork with chain split. They are NOT the same. If we want BIPs to be useful they need to be both correct and consistent.

TheBlueMatt commented at 7:01 pm on April 17, 2018: contributor

I did not claim a forked block “must be mined”, that would obviously be wrong, but you’re arguing against a straw man there. What is more important is that it is conceivable that a forked block could be mined. In the case described here, thats absurd, if it were to happen we’d probably all decide to give up on Bitcoin entirely, thus calling it a “fork” is obviously wrong.

evoskuil commented at 7:10 pm on April 17, 2018: contributor

In other words it is (without question) a hard fork that is (presumably) unlikely to cause a chain split. As I proposed, if there is a depth (or amount of work) that we assume impossible to overcome, we must clearly define that level and implementations must consistently enforce it. Otherwise every dev can make an argument about what depth is seemingly impossible, and deploy it claiming no fork. I’m sure some would argue 100 blocks is more than sufficient.

But again I will point out that the only reason this question matters is the marketing battle over the “one true chain”. We are not discussing protocol or even implementation, but how (and why) to define a deployed hard fork as not a hard fork.

TheBlueMatt commented at 7:18 pm on April 17, 2018: contributor

But again I will point out that the only reason this question matters is the marketing battle over the “one true chain”. We are not discussing protocol or even implementation, but how (and why) to define a deployed hard fork as not a hard fork.

Please go troll elsewhere. You can use any arbitrarily pedantic and useless definitions you’d like, but if you want to ignore reality of something just to make your pedantic definitions feel more warm and fuzzy, dont do it here.

evoskuil commented at 7:27 pm on April 17, 2018: contributor

If anything is not an argument it is the childish statement you just made. Amir created the BIP process to generate discussion over questions of community interest. The “core” group at the time tended to act as if they owned the process (as you are now doing), resulting in more than one less-than-optimal decision. You are not in a position to tell me to go away simply because you cannot defend your argument.

TheBlueMatt commented at 7:30 pm on April 17, 2018: contributor

Gonna go ahead and block you. If you’d like to be so pedantic so as to misinform people about the nature of a change (that it is a “fork”, which has clear meaning to most of the community as a consensus rule change which may in some way impact them depending on the decisions miners may realistically take), then please take it to reddit.

evoskuil commented at 7:48 pm on April 17, 2018: contributor

Brilliant. Are you going to block @luke-jr as well? Are you also going to make a PR into BIP99 to redefine “hard fork”?

sipa commented at 7:52 pm on April 17, 2018: member

Please, there is no reason for name calling here.

As for the “Bitcoin has never hard forked” claim, that is blatantly false. Before Bitcoin v0.3.6 (which removed OP_VER), every release was a hard fork. After that, the change to split execution of scriptSig and scriptPubKey in 0.3.7 was a hard fork for certain scripts that include an OP_CODESEPARATOR. The removal of the BDB lock limit in 0.8 is disputable as it wasn’t consistent with itself beforehand, but the introduction of a time limited reintroduction of the limit in 0.8.1 certainly was a hard fork compared to 0.8.0.

None of this matters, in my view. The BIP123 soft fork classification (no risk of a permanent fork conditional on a majority of the hashrate enforcing it) is just one to reduce the risk of consensus changes. Consensus changes are not inherently good or bad. A BIP123 soft fork that froze certain individual’s funds would be a complete violation of Bitcoin’s principles; a hard fork that fixes a coin stealing bug would be a necessity. Hard forks in this classification are simply far more risky, and to be avoided if possible for that reason.

I think you misunderstand the reasons why people want to see this BIP published without a “hard fork” classification. You see it as part of a revisionist plot to maintain a narrative that Bitcoin never hard forked. I believe that narrative is both wrong and irrelevant.

Instead, people want this published as a BIP because the community deserves well-communicated explanations for why a certain implementation believes this change is made, and safe. But the term “hard fork”, while correct according to BIP123, gives an incorrect understanding. This change will not affect which chain is treated as valid.

If people insist that BIP90 is classified as a hard fork, I believe the author will just drop the BIP, as it fails to achieve that goal. I believe this would be doing the Bitcoin community a disservice, so I urge to reco sider whether the BIP123 classification is the relevant one.

boooya commented at 7:53 pm on April 17, 2018: none

did someone call someone a hard fork?!?!?! this is getting real GUD!!!

evoskuil commented at 7:54 pm on April 17, 2018: contributor

If it is not a hard fork it should be dropped - it’s not a change, as @luke-jr ponted out.

evoskuil commented at 8:01 pm on April 17, 2018: contributor

@sipa While I do not buy the argument on motivation (please see my previous comments in this thread regarding hard fork denial), it is ultimately unimportant. The question of “well-communicated explanations” is easily resolved with a statement that it is very unlikely the hard fork will result in a chain split.

evoskuil commented at 11:29 pm on April 17, 2018: contributor

By orphaning non-signalling blocks during the last month of the BIP9…

So is BIP148 a hard fork now?

luke-jr commented at 11:58 pm on April 17, 2018: member

IMO this thread is ridiculous. It’s just a header…

My current thoughts, is that these occupy a grey area between implementation detail and hardfork. It’s also annoying to have multiple BIPs for every softfork (the “real” BIP, and an “activation simplification” BIP).

I propose that to resolve this:

We get rid of the Layer header entirely on BIP 90 (just to avoid arguments); and
Future such simplifications are added to the original BIP as an appendix.

evoskuil commented at 0:19 am on April 18, 2018: contributor

You are trivializing what is ultimately an important decision because it doesn’t appear important in this instance. This issue is a precedent for the acceptance of at least one pending BIP that proposes to significantly step down the assumed maximum reorganization depth/work established here while avoiding the questions necessarily associated with hard forks, by pretending no such hard fork is being deployed. We are actually discussing that very important precedent. At what point does a split permanently lock itself in. Nobody has bothered to address that question. That is the central question raised by BIP90 - what is the consensus rule on maximum reorg depth/work? This is a very reasonable and important question to ask, and I asked it when this BIP was first proposed. No answer to date.

sipa commented at 0:32 am on April 18, 2018: member

@evoskuil I think it’s unreasonable to insist that because the security assumptions for a consensus change include no deep reorgs, that we must outlaw such reorgs.

Consider the following. BIP123 soft forks assume that - in order to avoid a permanent fork - a majority hashrate enforces the new rule. That is an assumption, but we don’t (and can’t) enforce its correctness. What rules are being enforced by miners is not observable to the network. We approximate it by signalling, but we cannot verify that signalling corresponds to what rules they actually enforce.

Similarly, I think BIP90 is analogous in a way: its security assumption is that no deep reorg happens. We need to be upfront about this assumption, but similarly, if the assumption is held, it doesn’t require enforcing it. In fact, your suggested way of enforcing it (locking in a block after a certain number of blocks) is not consistent: a new node in the network which only sees the hypothetical newly created branch and only later learns about the original chain will come to a different conclusion. In fact, I believe there is no way to actually enforce a maximum reorg depth that does not in itself introduce extra assumptions.

My view is that we should treat security assumptions as assumptions. They need to be stated explicitly, but they are not consensus rules.

That is also my suggested answer to this debate: get rid of the hard fork/soft fork designation in BIP headers, but require that all consensus changing BIPs have a section that explicitly state their security assumptions. In many cases, that assumption can be “As BIP123 soft fork, this change will not result in a permanent fork as long as majority of the hashrate enforces the rule”. In other cases that assumption can be “Would require an excessively deep reorganization to affect the chain’s validity” or “Assumes every full node user will upgrade their software by date X”. People can then be free to adopt software that implements such changes based on whether they believe these assumptions are reasonable, but based on clear information.

evoskuil commented at 0:44 am on April 18, 2018: contributor

You misunderstand me. I do not actually propose that we define a max reorg depth. I’m pointing out that by deploying code with such assumptions we are in effect doing so, as if the assumption doesn’t hold we encounter a chain split. I agree with you that it’s not reasonable/consistent, which is why I opposed BIP90 from the outset. And if you re-read above you will see that I in fact proposed what you are now suggesting… extra verbiage that describes the assumption that a chain split is unlikely. There is no reason whatsoever to change the definition of a hard fork to do that, and this is a hard fork (with the security assumption that it is not likely to cause a chain split because…). But if you change the definition of hard fork to include a requirement of a likely chain split you break lots of exiting documentation, including BIP99, BIP123, BIP148 for starters.

luke-jr commented at 1:51 am on April 18, 2018: member

@evoskuil I’m not sure what you’re referring to. Locking in a fork is not necessarily a hardfork. The most recent softfork - Segwit - is already well locked-in, by both BIP148 and updated checkpoints in at least the past two Bitcoin Knots releases. Consensus checkpoints established the precedent you seem concerned with, a long, long time ago. It is the movement away from checkpoints in Core that is the change - not the existence or continuation of them.

Remove 'hard fork' designation on BIP 90 d208ed3ff1

sdaftuar force-pushed on Apr 18, 2018

sdaftuar commented at 1:37 pm on April 18, 2018: member

@luke-jr Updated as you suggested.

evoskuil commented at 6:22 pm on April 18, 2018: contributor

Segwit - is already well locked-in, by both BIP148

This is not correct. BIP148 does not “lock in” Segwit, either in the sense we are using the term here (i.e. permanently) or in the sense the term is used in BIP9 (i.e. relative to a branch). BIP148 can have no effect on Segwit if the latter was to be reorganized out (which remains possible though difficult).

and updated checkpoints in at least the past two Bitcoin Knots releases. Consensus checkpoints established the precedent you seem concerned with, a long, long time ago. It is the movement away from checkpoints in Core that is the change - not the existence or continuation of them.

This statement is oddly contradictory. Checkpoints are bad, that is the point. Moving away from their future use is not a consensus change. The fact that Knots is (apparently) using them to enforce Segwit is just an example of Knots deploying a hard fork against other implementations. Given the presumption that Knots users don’t want to split from more-widely-deployed nodes this is less-than-ideal. If one is operating under the assumption that such a deep reorg is impossible then there is no reason to employ such a hard fork in the first place. The fact of this enforcement implies that one assumes it is possible.

luke-jr commented at 6:43 pm on April 18, 2018: member

BIP148 guarantees that even if there was a deep reorg, Segwit would still be active.

Checkpoints aren’t bad. They are an established part of the Bitcoin consensus system, introduced by Satoshi himself as not only a DoS mechanism, but part of Bitcoin’s security model as an explicit consensus rule. Checkpoints are also not a hardfork under any definition - they are stricter rules, not looser. The assumption is not that reorgs are strictly impossible, but that such a reorg would be rejected by the network. Those using checkpoint-less implementations would incur losses and need to take manual action to reject such a reorg, while those using nodes with a reasonable checkpoint preventing it would survive the attack without action.

sipa commented at 6:57 pm on April 18, 2018: member

part of Bitcoin’s security model

I strongly disagree with that. If checkpoints ever affect which chain is accepted by the network (and not just as DoS protection of an individual node during initial sync), PoW has completely failed and we should abandon it.

However, I also don’t think checkpoints are inherently bad. If people exercise the same caution when reviewing checkpoints as when reviewing other parts of the code, or relying on such review to determine what code they’re running, I don’t think there is much of an issue.

The reason for moving away from checkpoints (at least in my eyes) is that they’re confusing. I think it’s very dangerous if people treat them as a security mechanism.

evoskuil commented at 6:59 pm on April 18, 2018: contributor

BIP148 guarantees that even if there was a deep reorg, Segwit would still be active.

This is incorrect. Segwit cannot reactivate, nor can BIP148 compel signaling for it (not that it would matter, since again, it cannot reactivate).

evoskuil commented at 7:07 pm on April 18, 2018: contributor

However, I also don’t think checkpoints are inherently bad. If people exercise the same caution when reviewing checkpoints…

True, but the only way to do this is to first obtain and verify the chain to verify the checkpoints. IOW it is not appropriate to embed checkpoints in the implementation as that precludes such verification. Still, it is not possible to ensure that one is seeing the strongest chain, so even the use of verified checkpoints is not a good practice.

As you have said many times, and I agree, checkpoints are not a security measure. They actually reduce security by preventing one from accepting a stronger chain. They are at best an optimization in a permissive environment. However a milestone (known-good block?) can provide the same optimization without the security downside of a checkpoint.

sipa commented at 7:08 pm on April 18, 2018: member

However a milestone (known-good block?) can provide the same optimization without the security downside of a checkpoint.

Bitcoin Core has these (-assumevalid) since 0.14.

evoskuil commented at 7:08 pm on April 18, 2018: contributor

Bitcoin Core has these (-assumevalid) since 0.14.

Yes, I am aware.

luke-jr commented at 8:15 pm on April 18, 2018: member

Disagree with it all you want, but it’s been part of the model since the beginning. Therefore, checkpoint-like mechanisms such as BIP 90 are clearly not introducing something new or setting a new precedent - the precedent already exists.

evoskuil commented at 0:38 am on April 19, 2018: contributor

it’s [checkpointing] been part of the model [bitcoin consensus rules] since the beginning

You are arguing against a point that nobody here has made. The question is not whether checkponting has existed in Bitcoin, the question is whether to continue what is widely considered a bad and unnecessary practice.

Therefore, checkpoint-like mechanisms such as BIP 90 are clearly not introducing something new

Incorrect, they are introducing new rules.

or setting a new precedent

Again,the existence of a precedent was never the question.

luke-jr commented at 5:32 am on April 19, 2018: member

This issue is a precedent for… We are actually discussing that very important precedent.

evoskuil commented at 4:14 am on April 23, 2018: contributor

The “existence of a precedent was never the question” - meaning that it is not disputed anywhere (in question) that a (bad) precedent had been set.

You argued that a “new precedent” was not being set. This is not the issue. The issue is whether we will continue a bad precedent that we have been trying to eliminate.

To be perfectly clear, you see it as good precedent and I see it as very bad precedent. Given that you misrepresent the nature of checkpoints (as security) it’s not surprising that we disagree.

luke-jr commented at 4:28 am on April 23, 2018: member

Core has been trying to eliminate it. Maybe you have, too. But that’s a matter of purity at the expense of the very slight security improvement checkpoints provide.

I am not misrepresenting their purpose. Satoshi introduced it as a security safeguard: https://bitcointalk.org/index.php?topic=437

evoskuil commented at 4:37 am on April 23, 2018: contributor

Appeal to authority is a fallacy independent of who is the cited authority. Checkpoints do not increase the security of bitcoin, at all. The strong chain is the correct chain. Reliance on an authority to publish checkpoints is akin to reliance on an authority to publish the chain itself. The only way to determine the “right” checkpoint is to…. validate the strongest chain one can find.

luke-jr commented at 5:32 am on April 23, 2018: member

Appeal to authority is not a fallacy when the question involves a historical fact about that entity.

Checkpoints prevent you from following a deep reorganisation, nothing more. Should such a reorganisation ever occur, the community would no doubt reject it one way or another by hand. Automating that rejection improves your security, as you wouldn’t have accidentally followed it even temporarily.

evoskuil commented at 1:33 pm on April 23, 2018: contributor

The point is not a question about Satoshi (that entity), it is a question of Bitcoin behavior. Feel free to quote Satoshi on questions of Satoshi’s motivation but his comment that checkpoints are security does not make them so.

The Bitcoin security model requires that deep reorg are possible. The entity that defines what branch cannot be reorged has the power to prevent people from overpowering that entity’s 51% attack. You will then argue that this should be done with another checkpoint. And there Bitcoin has devolved into a political money, where the group that can get the checkpoints accepted by others controls the money. That is the end of the experiment. The battle is necessarily waged with energy, not funny hats.

sdaftuar commented at 12:44 pm on April 24, 2018: member

@luke-jr Anything else needed here? Your last proposal on this topic is fine with me (I updated this PR accordingly and closed the one related to segwit script verification, which I’ll re-propose as appendices to the relevant BIPs).

sdaftuar commented at 8:07 pm on May 3, 2018: member

@luke-jr I think this is ready for merge now?

sdaftuar commented at 9:12 pm on May 16, 2018: member

ping @luke-jr

luke-jr merged this on May 20, 2018

luke-jr closed this on May 20, 2018

Remove ‘hard fork’ designation on BIP 90 #639