JerzyStanislawski

Thank you, good points, I'll try to work on that.

@clemahieu do we want to introduce sorting field in wallet_receivable?

PR updated, following your suggestion I used strategy pattern on two layers - for sorting/non-sorting and for response format (which fields to use in response). I unified all three receivable...

I was thinking about this one but have doubts with using IPC connection. What if running node has RPC disabled in config? Or connection would be created to nano_rpc process...

Hi @clemahieu, I know it's been a long time and it's not a priority now, however would you be able to take a look at changes here and comment if...

Sure, so the issue is related to 3 methods - receivable, accounts_receivable and wallet_receivable, in which we apply pretty similar algorithm. In current solution we iterate through pending blocks and...

Yeah, happy to rework that. My initial understanding is that we should first filter `pending` transactions to get confirmed blocks for the account then apply other `ranges` functions according to...

The plan is to add 2 wrapper classes around pending_store to enable interaction with ranges. They must satisfy concepts required by ranges, something like: ``` class pending_store_iterator_wrapper { public: nano::pending_store_iterator_wrapper(nano::store_iterator...

There is a lot of overhead with adapting so I'd be happy to avoid that, but can we afford that in terms of performance? Correct me if I'm wrong but...

Hey Dimitrios, thanks for the feedback. So do we still stick to C++ 20 ranges?