Ed Hennis

> After some numbers of open conversations GH going crazy and makes review impossible. It will randomly drop you to some another comment when you just reading something. When you...

> Want to make sure I understood this correctly: with largeRange, we can support full precision up to 2^63 - 1, so integer types (MPT or XRP) don’t lose precision...

I've been running this code locally off and on, and one thing I notice is `LedgerMaster`'s validated ledger index is updated before the corresponding ledger is fully updated and available...

Not sure how, but this branch got some changes from #5644 appended to it. I forced push to remove them and re-merge from `develop`.

> [#295](https://github.com/XRPLF/rippled/pull/295) failed This is, unfortunately, an artifact of what is probably a very old test. In short, every time `expect` is called, it increments a counter. The counter is...

> Some thoughts on the fixed ledger entries: > > * Should the value be truthy? > > * If a string hash is provided, shouldn't that be checked for...

Thank you for explaining! My main goal with this change, aside from just getting something I could use myself, was to make it as easy as possible to get the...

> my attitude is that nobody is going to complain about _not_ getting an error, right? On second thought. I forgot my old maxim that "a wrong answer is worse...

> I would perhaps accept all non-null, non-string values (plus the actual key string). `null` because I hate how `Json::Value` treats `null` as a real value and I don't want...

> How about supporting `amendment: {}`? This would be consistent with other non-fixed types. It wouldn't be all that consistent, IMHO. First json objects are used to pass additional parameters....