Skip to content

BIP-99: fix footnotes and drop missing reference #1844

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 21, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 16 additions & 25 deletions bip-0099.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ which - being accidental - obviously doesn't need a deployment plan.
====11/12 March 2013 Chain Fork====

There is a precedent of an accidental consensus fork at height 225430.
Without entering into much detail (see [2]), the situation was different from
Without entering into much detail (see <ref name="bip-50">https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki</ref>), the situation was different from
what's being described from the alternative implementation risks (today alternative implementation
still usually rely in different degrees on Bitcoin Core trusted proxies, which
is very reasonable considering the lack of a complete libconsensus).
Expand Down Expand Up @@ -144,13 +144,13 @@ unnecessary.
Fundamental disagreements and controversies are part of social
systems, like the one defined as the human participants in the Bitcoin
network. Without judging the motivation of the rule discrepancies or
what rules were in place first, we're defining schism[1] hardforks as
what rules were in place first, we're defining schism<ref name="schism">https://en.wikipedia.org/wiki/Schism</ref> hardforks as
those in which - for whatever reason - users are consciously going to validate 2
different sets of consensus rules. Since they will validate different
rulesets, they will end up following 2 different chains for at least
some time, maybe forever.

One possible result observed in the past[non_proportional_inflatacoin_fork]
One possible result observed in the past
is that one of the chains rapidly disappears, but nothing indicates
that this must always be the case.

Expand All @@ -170,7 +170,7 @@ maybe mc(bitcoinA) + mc(bitcoinB) = 0,
...

Schism hardforks have been compared to one type of altcoins called
"spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to
"spinoffs"<ref name="spinoffs">https://bitcointalk.org/index.php?topic=563972.0</ref> that distribute all or part of its initial seigniorage to
bitcoin owners at a given block height.

This is very disruptive and hopefully will never be needed. But if
Expand Down Expand Up @@ -274,7 +274,7 @@ The current miners' voting mechanism can be modified to allow for
changes to be deployed in parallel, the rejection of a concrete
softfork without getting locked for the deployment of the next one,
and also a more efficient use of the version field in block
headers [3]. BIP65 is expected to be deployed with the improved
headers<ref name="versionbits">https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki</ref>. BIP65 is expected to be deployed with the improved
mechanism.

====Uncontroversial hardforks====
Expand Down Expand Up @@ -315,18 +315,25 @@ softfork unnecessary.

==Code==

This BIP is complemented with a concrete code proposal[4] for an
This BIP is complemented with a concrete code proposal<ref name="timewarp">https://github.com/jtimon/bitcoin/tree/hardfork-timewarp-0.11</ref> for an
uncontroversial hardfork which acts as a precedent and removes the
perception that hardforks are impossible in Bitcoin. The deployment of
the proposal should not block any other potential hardforks (thus it
will required the version bits proposal[3] to be implemented). The
will required the version bits proposal<ref name="versionbits"/> to be implemented). The
change itself doesn't add much complexity to Bitcoin Core and is simple
enough that is trivial to apply to diverse implementations (that
currently can only use libbitcoinconsensus to validate script-related
rules). The change has been already widely tested in many altcoins.

The chosen consensus change is the fix of the timewarp attack
discovered and also fixed with a simple patch[5] by @ArtForz. This
discovered and also fixed with a simple patch<ref name"original-references">
Original References:
https://bitcointalk.org/index.php?topic=114751.0,
https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772;
Rebased patch:
https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
</ref>
by @ArtForz. This
change has been deployed by most altcoins that made any minimally
meaningful change to bitcoin and thus can be considered somewhat
tested (in fact, most SHA256d altcoins that didn't implement it have
Expand All @@ -340,23 +347,7 @@ worth of blocks).

==Footnotes==

[1] https://en.wikipedia.org/wiki/Schism

[2] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

[non_proportional_inflatacoin_fork] TODO missing link

[spinoffs] https://bitcointalk.org/index.php?topic=563972.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You accidentally dropped this reference.


[3] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

[4] https://github.com/jtimon/bitcoin/tree/hardfork-timewarp-0.11

[5] Original references:
https://bitcointalk.org/index.php?topic=114751.0
https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
Rebased patch:
https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
<references />

==Attribution==

Expand Down