djg

That sounds reasonable. Its also has the benefit of being extremely similar to how data offsets are handled. If a connection/stream is initially configured with `receiveMax=Infinity` would it be allowed...

Right now the connection allows the data offset to be decreased in some cases -- is that a bug? (https://github.com/interledgerjs/ilp-protocol-stream/blob/afd51baadbdf422e2fe550e3a97ce5546c09d353/src/connection.ts#L634-L635) .. or is it different since one side assumed that...

That solution sounds good. --- Re: the data offsets, it is a bit different from money -- if one side sends too much data it's a flow control error and...

@emschwartz thinking about this some more, won't this be a breaking change? The current implementation of stream is expecting a MaxMoneyFrame, and if it doesn't get one from the new...

Could you add a test that exercises the case described in the PR description?

Hi @flsusp, Check out [`reference/requests/get_account_transfers`](https://docs.tigerbeetle.com/reference/requests/get_account_transfers/)! This fetches the transfers that were executed in a particular timestamp range. Timestamps are assigned to transfers by the TigerBeetle cluster, and are guaranteed to...

(Though, `get_account_transfers` is just for one account, so maybe that doesn't work for your use case. We will support a more general CDC in the (near) future, though.)

CDC falls under `StateMachine: Query API`. It isn't close enough to completion that I can give a date estimate, but it _is_ being actively worked on.

(1) is already complete and will be part of the next release: https://github.com/tigerbeetle/tigerbeetle/issues/1884

> Another change: where previously the "hot" accounts would be selected for only the debit side of a transfer, and credit accounts would be selected uniformly, now both sides of...