新しい CMoney 型によるコイン残高のカプセル化
コイン残高の表現と算術演算に異なる型を使用するサイドチェーンとビットコインの間でコードの同等性を提供する。例えば、Freicoin では分割可能性の向上と利息計算のために GMP ライブラリの任意精度有理数型を使用している。これにより、コードの共有やアップストリームへのコード提出における摩擦が大幅に軽減される。また、FormatMoney や ParseMoney などの関連機能を単一のクラスフレームワークに整理する。
通貨型を定義することがある意味で「より良いソフトウェア工学」であるという点には同意する。しかし、Bitcoin Core の将来はあくまで Bitcoin Core であり、「Altcoin Core」ではないと考えている。
最終的には、ビットコイン固有のコンセンサースコードを、可能な限り小さく独立した、完全にビットコインに特化したライブラリにしたいと考えている。アルトコインは独自のコンセンサースライブラリを作成すればよい。これらの間でコード共有はほとんどないか、全くないと予想している。コンセンサースコードは汎用的である必要はない。
この目標のために、_コンセンサースコード内部では_より低レベルで具体的であることが良いと考えており、抽象化を増やすべきではない。最近、CBigNum 型から明確に定義された具体的な uint256/uint160/CScriptNum 型への移行をすでに行った。
しかし、クライアントアプリケーション（RPC）やユーザーとのインターフェース、その他のインターフェースを提供するコードの残りの部分では、システム内部の通貨の具体的な表現から分離する、より抽象的なインターフェースが有用である。
無害な typedef 変更に誰も反対しないようなので、おそらくそれ（個人的にはそれほど興味深いとは思わないが、容易に受け入れられる可能性がある）を、シリアライゼーションと算術をカプセル化するクラスアプローチ（明らかにはるかに議論の的となっている）から分離するのが賢明だと思う。 また、2 つ目のコミット/PR は、より小さく明確なコミットに分割した方がレビューしやすいと思う。
脱線していたり、メーリングリストに移すべきであれば指摘してほしい。自分のプルリクエストにも役立つと感じているので、その理論的根拠をより良く理解しようとしている。 @laanwj の「低レベルで明確に定義された int64 型の上に抽象化を置くことがコンセンサースコードにおいてリスクがある、または望ましくない」という主張は理解できないが、コンセンサースに影響を与える可能性のある変更はリスクが高く、したがってより保守的であるべきだという点は理解できる。「これはビットコインには全く役に立たず、アルトチェーンにのみ有用である」という主張には同意しないが。
一方で、「レビューコスト」の議論は理解できない。誰かが特定の変更をレビューする時間がない、または優先事項ではないと考えるのは完全に理解できる。この理由で PR をレビューせずに宙ぶらりんにしておくのは一つのことである。しかし、「レビューコストを削減する」ために NACK を正当化するのは、少なくとも時期尚早に思える。 何か見落としているかもしれないが、理想的には NACK は次のような形であるべきである：「A と B が X、Y、Z を壊すため、これは決してマージされるべきではない」、「テスト X、Y、Z も実装すれば、より受け入れられやすくなる」、「A、B、C も実装しなければこの PR は不完全に見える」。異議が具体的であればあるほど、貢献しようとしている開発者にとってフラストレーションが少なくなり、適切に貢献する方法を学ぶためにプルリクエストを読んでいる貢献者や潜在的な貢献者にとってより教育的である。
繰り返しになるが、後半の所見がここにふさわしくない場合はお詫びする。
正しく理解しているか確認したい。コンセンサースコードは変更せず（または typedef にとどめ）、コードベースの残りの部分に CMoney を導入するという妥協案は、全員にとって有益だということか（ビットコインにはフォークリスクがなくモジュール化が向上し、Freicoin には変更のマージ作業が軽減される）？少なくとも、そのバージョンはドージコインにも恩恵があると言える。つまり、テストに関して我々からもより多くの協力が得られるということである。
@jtimon 「レビューコスト」というのは、レビューでほぼ確実にすべてのバグや不整合を見つけられないからである。問題は、予期しない変更がフォークを引き起こすコストである。サトシが去ってから何年も経った今でも、コンセンサースコードに予期しない小さなケースが発見され続けている。
コードを一見しただけで誰も問題を指摘できないからといって、問題が存在しないわけではない。コードの可読性や一貫性を（おそらく）少し向上させるだけでは、そのリスクに見合わない。理解してほしい。潜在的な利益が潜在的な問題を上回らなければ、誰もマージのリスクを取りたくないのであり、NACK は妥当である。個人的には、永遠に宙ぶらりんにしておくよりもその方がよいと思う。
@leofidus コンセンサースコードの外部でのみ行えるのであれば、受け入れ可能である。それにはコンセンサースコードとその他の部分の間にインターフェース層が必要であり、それ自体は良いことである。コンセンサースライブラリの作成という目標に沿っている。
自動健全性テスト：マージ失敗。テストログは http://jenkins.bluematt.me/pull-tester/p4067_fc1cd73d0ff73e26da2548193c630b3b8a4d630b/ を参照。
このプルは現在の master にクリーンにマージできない。
このテストスクリプトはプルが更新されるたびに検証を行う。ただし、時々停止し適切にテストできないことがある。テストを待っている場合は、http://jenkins.bluematt.me/pull-tester/current/ で test.log が更新されているかタイムスタンプを確認してほしい。
何かおかしい場合は、freenode で BlueMatt に連絡してほしい。
#4234 を優先してこれをクローズする。