Confirmation requirement API handling

[theoreticalbts]

#233 introduces a new user requirement which has not been incorporated into our API so far. Specifically, users want the ability to filter chain activity based on confirmations. For example, an exchange which wants to monitor confirmed deposits to its account cannot use subscription to its account to monitor the deposits, as the subscription notifications will include deposits that have not been sufficiently confirmed.

There are several possible architectures which can be used to monitor confirmations.

• (1) No architecture. The API client is responsible for any confirmation handling. For example, "get most recent operations with N confirmations" might be implemented by listening for blocks, then filtering get_account_history() results by block number. This multiplies the load on the node by N times for N confirmations, as the first N-1 times a record is obtained, it is filtered away due to insufficient confirmations. It is also tricky to get the client logic exactly right, and because each developer who interfaces with the witness node would have to do the client logic themselves, this presents a barrier to entry for exchanges and developers.
• (2) Dual witness node architecture. Start two witness nodes, a front-end node connected to the network and a back-end node connected to the client. The front-end node only supplies blocks to the back-end node if they are sufficiently confirmed.
• (3) Delayed-block single-witness. A single witness node which verifies the signature on each block, but does not apply the block until it is buried under at least n blocks. It does header-only verification (including witness signature) on incoming blocks until they are buried deeply enough.
• (4) API call revisions. Each individual API call is revised, for example get_account_history() and subscription methods would take a confirmation requirement number. The subscription semantics might be implemented by queueing subscription notifications and discarding queued notifications when the chain rewinds, but it could be implemented in a different way (for example, account subscriptions might leverage the account history to provide the same semantics as queueing without actually maintaining the queue).

The purpose of this ticket is to get comments on these approaches and build consensus for an architecture recommendation for exchanges and other users who desire to only process confirmed transactions.

[theoreticalbts]

As this is implemented by the delayed_node I am closing this.