<p>From <a href="https://github.com/bitcoin/bitcoin/blob/v0.18.1/CONTRIBUTING.md#peer-review" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/v0.18.1/CONTRIBUTING.md#peer-review</a>:</p>

<blockquote>
  <p>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:</p>
  
  <ul>
  <li>ACK means "I have tested the code and I agree it should be merged";</li>
  <li>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;</li>
  <li>utACK means "I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged";</li>
  <li>Concept ACK means "I agree in the general principle of this pull request";</li>
  <li>Nit refers to trivial, often non-blocking issues.</li>
  </ul>
</blockquote>

<p>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.</p>

CC BY-SA 4.0
2019-11-07T20:33:03.633Z
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
CC BY-SA 4.0
2019-11-07T20:35:54.537Z
When a PR is merged, the ACKs provided on Github are automatically included in the merge commit. That's all.
Pieter Wuille
CC BY-SA 4.0
2019-11-07T20:38:48.257Z
Ok, I understand now and was very much overthinking it. Though it is an interesting thought experiment :-). Thank you for clarifying.
philbw4
CC BY-SA 4.0
2019-11-07T20:25:18.010Z
2019-11-07T20:37:59.657Z
2019-11-07T20:37:59.657Z
Pieter Wuille
<p>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 (<a href="https://github.com/bitcoin/bitcoin/commit/270616228bc9a3856a0a82dea26ac3480b7585cd" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/commit/270616228bc9a3856a0a82dea26ac3480b7585cd</a>) also includes:</p>

<pre><code>ACKs for top commit:
  MarcoFalke:
    ACK 0e7c90e crocodile
  fanquake:
    ACK 0e7c90e

Tree-SHA512: 6d954a0aaf402c9594201626b59d29263479059e68fa5155bb44ed973cd0c3347729dd78b78b4d5a2275e45da365dc1afb4cc7e3293dea33fcc2e3e83a39faf5
</code></pre>

<p>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.</p>

<p>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.</p>

<p>For reference, here are some issues (<a href="https://github.com/bitcoin/bitcoin/issues/16200" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/issues/16200</a>
and <a href="https://github.com/bitcoin/bitcoin/pull/16223" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/pull/16223</a>) 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.</p>

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

<bitcoin-core-development><bitcoincore-review>
what is the significance (if any) of "ACKs for top commit:" in the git commit messages of bitcoin core?
philbw4
# what is the significance (if any) of "ACKs for top commit:" in the git commit messages of bitcoin core?

(Asked by: username_0 on 2019-11-07)

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?

**Tags:** bitcoin-core-development, bitcoincore-review


---

## 1 answers

### Answer by username_1 on 2019-11-07. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: 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!  
> **username_1**: When a PR is merged, the ACKs provided on Github are automatically included in the merge commit. That's all.  
> **username_0**: Ok, I understand now and was very much overthinking it. Though it is an interesting thought experiment :-). Thank you for clarifying.  

---

