新しい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を優先してこれをクローズする。