2

There seems to be a reasonably standardized format for some, but not all, commit messages in bitcoin's git repository. For example, in addition to the usual expository commit message, this commit (https://github.com/bitcoin/bitcoin/commit/270616228bc9a3856a0a82dea26ac3480b7585cd) also includes:

ACKs for top commit:
  MarcoFalke:
    ACK 0e7c90e crocodile
  fanquake:
    ACK 0e7c90e

Tree-SHA512: 6d954a0aaf402c9594201626b59d29263479059e68fa5155bb44ed973cd0c3347729dd78b78b4d5a2275e45da365dc1afb4cc7e3293dea33fcc2e3e83a39faf5

There are many commit messages with similar structure. As these commits get buried under other commits, this is quite reminiscent of aspects of the consensus mechanism that the bitcoin protocol itself uses.

In other words, if we squint hard enough, it seems like the commit messages themselves partially encode a slow-enough-for-humans-to-interpret blockchain.

For reference, here are some issues (https://github.com/bitcoin/bitcoin/issues/16200 and https://github.com/bitcoin/bitcoin/pull/16223) where some discussion about the content of these messages is taking place, but unless one is already a core contributor, it is difficult to pick up what is going on from context here.

Is there any documentation, informal or otherwise, about how/if these messages might encode aspects of consensus among the contributors?

4

From https://github.com/bitcoin/bitcoin/blob/v0.18.1/CONTRIBUTING.md#peer-review:

Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over GitHub, mailing list and IRC discussions). The following language is used within pull-request comments:

  • ACK means "I have tested the code and I agree it should be merged";
  • NACK means "I disagree this should be merged", and must be accompanied by sound technical justification (or in certain cases of copyright/patent/licensing issues, legal justification). NACKs without accompanying reasoning may be disregarded;
  • utACK means "I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged";
  • Concept ACK means "I agree in the general principle of this pull request";
  • Nit refers to trivial, often non-blocking issues.

When a Pull Request to Bitcoin Core is merged on GitHub, maintainers use a script that automatically incorporates the ACKs provided by reviewers in the merge commit.

  • Sorry if my question was not clear, and thank you for providing the reference. I should have included a link to that page too. I was explicitly referring to the ACKs that are within the git commit messages themselves, not the ones that may be in separate channels such as in github comments. Is it possible for you to clarify how/if the two things are related? Thanks! – philbw4 Nov 7 at 20:33
  • When a PR is merged, the ACKs provided on Github are automatically included in the merge commit. That's all. – Pieter Wuille Nov 7 at 20:35
  • Ok, I understand now and was very much overthinking it. Though it is an interesting thought experiment :-). Thank you for clarifying. – philbw4 Nov 7 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.