The solver was purely based on our (mine and my partner's) ideas. We tried reading some papers to find ideas to improve our solver but we had found that they are not very helpful - written in opaque language, using wrong tree representation and not focusing on practical implementation aspect. Maybe things changed since then but I haven't found anything useful at all in published papers about poker with the exception of two page one by Oskari Tammelin describing CFR+ algorithm (which we haven't used in our software because of its significant memory requirements).

We considered it very unlucky that the science paper was published as we thought more people will implement solvers then (ours was ready in mid 2014 and we released and a working solver with a GUI in early 2015, 3 months after the Limit Holdem paper). As it turned out though it didn't really matter much.

I had an idea to code a poker solver around 2008. Unfortunately I was yet to learn to code back then. The biggest challenge was to overcome implementation issues. Once I got the crucial part to be fast enough I knew the solver is possible. I think not having much background in the field allowed me to come up with more natural (and better) tree representation and memory efficient (even if not the fastest) algorithm as I was thinking more as poker player than a computer scientist back then.

Interesting! We have very recently wrote a paper on the various tree representations [1]. Maybe it is the same distinction you found on your own? I judge this based on the screenshots on your website. Public state trees are amenable to nice factorization over the hands, and indeed most implementations use it, but formally they write they use the history tree notation.

[1] https://arxiv.org/abs/2112.10890

It's a paper so it will take me a while to go through but that sounds more or less right from your description. The history tree notation and the whole information sets nonsense just make things very confusing to read and think about.