Asymmetric encryption of transaction log file: is RSA the correct algorithm

I want to produce a transaction log that is encrypted while being produced. I'd prefer asymmetric encryption. It is possible that my program will terminate without writing any closing blocks, so my output can't depend upon being able to write any end-of-file blocks the encryption scheme may require.

I can open new transaction logs as needed and do not require the ability to append to a previous one.

I believe I can do this by storing the public key on the server (and hiding the private key), choosing the proper algorithm, and using a stream encryption writer in my output.

Later, when viewing the transaction log, I can just do everything in reverse. And in this way, my transaction logs are always stored encrypted at rest.

Is RSA the correct algorithm? If not, what should I use instead?

Coding is in C++. I presume I can do what I need to do with crypto++.

It's understandable that you want to use public key encryption to separate the encrypting key from the decrypting one, but that doesn't mean you can't utilize symmetric encryption.

Probably your best option is to use something like a stream cipher (such as AES-256 in CTR mode or any other suitable algorithm you prefer) which is capable of encrypting each bit independently, but then make sure that the symmetric encryption key is protected via the public (say RSA) key.

Then, when you want to retrieve the logs and decrypt them on the machine that contains the private key, first you decrypt the symmetric key, and then use it to decrypt the logs.

Apart from that, note that in general encrypting a massive amount of information via public key encryption is undesirable due to performance and in most cases also security reasons.