Deferred BTG Core RPC API

[h4x3rotab]

Current State

BTG’s RCF prevents deep-chain reversion by Finalizing a block when it meets depth and time criteria; see: https://github.com/BTCGPU/BTCGPU/wiki/Release-Notes-v0.17.3#rolling-checkpoint-finalization

RPC call getfinalizedblockhash reports the best finalized block; can be used as a safe target for Exchange deposits. In normal conditions, 60% of transactions are finalized at 10 confirmations, over 99% are finalized at 16, and 99.999% are finalized at 22.

An Exchange would logically use the RPC call to accept deposits as quickly as possible with full safety - usually between 10 and 16 confirmations. However, none do so; all are using 30 confirmations (or more). They are simply setting their standard confirmation requirement to 30 to avoid a worst case scenario and paying no attention to the Finalization state.

Why?

No exchange wants to write custom code for their exchange software to check and utilize the new RPC call, nor do they want to maintain and debug new possible errors in their systems as a result of modifying their own internal software.

Solving this problem

Provide an RPC API proxy which provides a Deferred view of the BTG chain state. The Proxy would present data from the BTG node as if the most recent Finalized block were the chaintip. It would sit between an Exchange’s internal software and the Exchange’s BTG Core Full node and must provide all RPC calls used by Exchanges.

With this in place, the Exchange can simply set their Deposit Confirmation requirement at 1 and make no modifications to their own code or processes. (The BTG Core full node requires no modification and will operate normally with peers.)

Tasks

1. Make comprehensive list of all necessary RPC API calls for an Exchange
2. Write an API proxy to properly handle all such requests in an internally-consistent manner:
   1. Calls to the proxy for block info including blockheight, best chaintip, or best block should only respond with the last Finalized block.
   2. Calls to the proxy for TX info only report the block as confirmed when it's in a Finalized block; all else as unconfirmed.
   3. Other tweaks as necessary, such as configurable fallback depth: if not FInalized, the proxy will report a TX confirmed after 30 confirmations on mainchain (a necessary fallback in case of node reboot because Finalizations state is time-delay dependent and is not persistent between node reboots.)