無害な typedef 変更に誰も反対しないようなので、おそらくそれ（個人的にはそれほど興味深いとは思わないが、容易に受け入れられる可能性がある）を、シリアライゼーションと算術をカプセル化するクラスアプローチ（明らかにはるかに議論の的となっている）から分離するのが賢明だと思う。 また、2 つ目のコミット/PR は、より小さく明確なコミットに分割した方がレビューしやすいと思う。
脱線していたり、メーリングリストに移すべきであれば指摘してほしい。自分のプルリクエストにも役立つと感じているので、その理論的根拠をより良く理解しようとしている。 @laanwj の「低レベルで明確に定義された int64 型の上に抽象化を置くことがコンセンサースコードにおいてリスクがある、または望ましくない」という主張は理解できないが、コンセンサースに影響を与える可能性のある変更はリスクが高く、したがってより保守的であるべきだという点は理解できる。「これはビットコインには全く役に立たず、アルトチェーンにのみ有用である」という主張には同意しないが。
一方で、「レビューコスト」の議論は理解できない。誰かが特定の変更をレビューする時間がない、または優先事項ではないと考えるのは完全に理解できる。この理由で PR をレビューせずに宙ぶらりんにしておくのは一つのことである。しかし、「レビューコストを削減する」ために NACK を正当化するのは、少なくとも時期尚早に思える。 何か見落としているかもしれないが、理想的には NACK は次のような形であるべきである：「A と B が X、Y、Z を壊すため、これは決してマージされるべきではない」、「テスト X、Y、Z も実装すれば、より受け入れられやすくなる」、「A、B、C も実装しなければこの PR は不完全に見える」。異議が具体的であればあるほど、貢献しようとしている開発者にとってフラストレーションが少なくなり、適切に貢献する方法を学ぶためにプルリクエストを読んでいる貢献者や潜在的な貢献者にとってより教育的である。
繰り返しになるが、後半の所見がここにふさわしくない場合はお詫びする。