macro: analyze Bitcoin's RNG #23

New Issue

2024-03-11T03:38:45Z

AaronFiore commented

2024-03-11 03:38:45 +00:00

(Migrated from gitea.com)

A review of Bitcoin's RNG implementation has demonstrated that, in my opinion, there's no quick or easy refactor to get straight to the RNG itself.

The reasons being:

Bitcoin's build is (largely) not designed to be used as a library. The build is designed as pro-static, not shared (due to various security considerations and philosophy).
The RNG component that is there is tied-in with too many other components and, in my opinion, could use a separation of concerns.
There is sparingly ad-hoc use of C++20 throughout essential paths surrounding the RNG and cannot be refactored on their own without negatively affecting other components (again, those separation of concerns).

This is a docker-finance issue because ROOT is not yet C++20 compatible and simply grabbing snippets of Bitcoin's RNG is simply not possible (or at least the juice is not worth the squeeze). With that said, what I personally find annoying is that Bitcoin's C++20 usage (within the scope of the RNG component) is somewhat trivial and could be re-implemented in C++17 or at least thrown into a larger #ifdef for the sake of compatibility (in my most humblest, most-respectful of opinionated opinions).

These grievances could be relayed upstream but... perhaps that's a road you could take on your own... or perhaps ROOT will become C++20 compatible before any Bitcoin changes are made... (and no, I will not kowtow to Python hooks because I don't believe that is a solution for the issue at hand).

Speaking of separation of concerns, why is any of this being done with docker-finance?

Useful for mitigating potentially devastating bugs, as was discovered when analyzing Botan's RNG (when not fully digesting Botan's documentation): b621e87df2/container/src/root/src/internal/impl/random.hh (L124)
Getting to the RNG itself is probably one of the more trivial proof-of-concepts that serves as a framework to get to more interesting parts of Bitcoin that existing clients don't quite leverage.

Remember: this is modern finance or, what I like to call, "transcendental finance".

A review of Bitcoin's RNG implementation has demonstrated that, in my opinion, there's no quick or easy refactor to get straight to the RNG itself. The reasons being: - Bitcoin's build is (largely) not designed to be used as a library. The build is designed as pro-static, not shared (due to various security considerations and philosophy). - The RNG component that *is* there is tied-in with too many other components and, in my opinion, could use a separation of concerns. - There is sparingly ad-hoc use of C++20 throughout essential paths surrounding the RNG and cannot be refactored on their own without negatively affecting other components (again, those separation of concerns). This is a `docker-finance` issue because ROOT is not yet C++20 compatible and simply grabbing snippets of Bitcoin's RNG is simply not possible (or at least the juice is not worth the squeeze). With that said, what I personally find annoying is that Bitcoin's C++20 usage (within the scope of the RNG component) is somewhat trivial and could be re-implemented in C++17 or at least thrown into a larger `#ifdef` for the sake of compatibility (in my most humblest, most-respectful of opinionated opinions). These grievances *could* be relayed upstream but... perhaps that's a road you could take on your own... or perhaps ROOT will become C++20 compatible before any Bitcoin changes are made... (and no, I will not kowtow to Python hooks because I don't believe that is a solution for the issue at hand). Speaking of separation of concerns, why is any of this being done with `docker-finance`? 1. Useful for mitigating potentially devastating bugs, as was discovered when analyzing Botan's RNG (when not fully digesting Botan's documentation): https://gitea.com/EvergreenCrypto/docker-finance/src/commit/b621e87df2cce60a8daab9fc5de6afe8e77fba96/container/src/root/src/internal/impl/random.hh#L124 2. Getting to the RNG itself is probably one of the more trivial proof-of-concepts that serves as a framework to get to more interesting parts of Bitcoin that existing clients don't quite leverage. Remember: this is modern finance or, what I like to call, "transcendental finance".

AaronFiore commented

2025-11-06 00:50:16 +00:00

(Migrated from gitea.com)

Updates:

Since posting this issue, bitcoin has moved even more towards c++20; closing the gap between factoring out c++20 and separating concerns. In other words: it's out the question now.
With the continued development of bitcoin's libbitcoinkernel, a re-think here is possible.
Most importantly: after continued development and many requests (including the LHC folks), ROOT now supports up to c++23 🥳 However, after speaking with Arch Linux devs, it's not feasible to expect the ROOT package maintainers to build root higher than 17, as ROOT does not explicitly call for anything above 17.

At the moment, point 3 renders the other points moot and leaves the only option of building and maintaining a c++20 or higher build here. That would require more hardware and maintenance on my end (it's a big'ish build). But, with that solution, point 1 would be resolved, point 2 would be free to explore and this issue could be resolved as well.

TBD.

Updates: 1. Since posting this issue, bitcoin has moved even more towards c++20; closing the gap between factoring out c++20 and separating concerns. In other words: it's out the question now. 2. With the continued development of bitcoin's `libbitcoinkernel`, a re-think here is possible. 3. Most importantly: after continued development and many requests (including the LHC folks), ROOT now supports up to c++23 🥳 **However**, after speaking with Arch Linux devs, it's not feasible to expect the ROOT package maintainers to build root higher than 17, as ROOT does not explicitly call for anything above 17. At the moment, point 3 renders the other points moot and leaves the only option of building and maintaining a c++20 or higher build here. That would require more hardware and maintenance on my end (it's a big'ish build). **But**, with that solution, point 1 would be resolved, point 2 would be free to explore and **this** issue could be resolved as well. TBD.

AaronFiore commented

2025-11-14 21:05:15 +00:00

(Migrated from gitea.com)

Success :)

Details and caveats will be noted in the pull request, once it comes.

Success :) Details and caveats will be noted in the pull request, once it comes.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Reference: EvergreenCrypto/docker-finance#23