Skip to content
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

BIP105: Consensus based block size retargeting algorithm #187

Merged
merged 4 commits into from Sep 3, 2015

Conversation

btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Aug 28, 2015

@gmaxwell
Copy link
Contributor

gmaxwell commented Sep 1, 2015

Number 105.

@btcdrak btcdrak changed the title BIP: Consensus based block size retargeting algorithm BIP105: Consensus based block size retargeting algorithm Sep 1, 2015
Choosing 8MB because currently the consensus among miners
is 8MB is the largest tolerable size.
luke-jr added a commit that referenced this pull request Sep 3, 2015
BIP105: Consensus based block size retargeting algorithm
@luke-jr luke-jr merged commit a87bf5c into bitcoin:master Sep 3, 2015
@btcdrak btcdrak deleted the bip-cbbsra branch September 6, 2015 22:53
luke-jr pushed a commit to luke-jr/bips that referenced this pull request Jan 20, 2018
Appending new fields to the end of the messages allows us to add new
fields to an existing message, however it does not allow removing
existing fields, e.g., dropping the pubkeys like bitcoin#187 proposes. Moving
the features bitmap at the beginning of the signed payload allows
this type of change in the future. Nodes verify the integrity of the
message and then check whether there are any even bits they don't
implement. These even bits being required features would then result
in the message being discarded.

In addition to what we discussed during the call I also went ahead and
did the same reordering on `node_announcement`, which I think has the
same issue.

There is a subtle change in semantics, i.e., previously we would
add channels with unknown bits to our local view, but then ignore them
when computing a route. Now we no longer add them to our view, and may
discard the announcement altogether, stopping the broadcast. This is
safe I think since otherwise we'd be forwarding things we can only
verify the signatures of, but nothing else.
luke-jr pushed a commit that referenced this pull request Jan 24, 2020
Update acknowledgements, remove authors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants