Currently, the pendingchannels RPC will only display information drawn from the utxoNursery for pending force close channels. However, for a channel that was forced closed with active HTLCs, the HTLC outputs won't be sent to the nursery until they're fully mature. As a result, atm, there's a gap where all information isn't displayed on the RPC layer. This should be reconciled by having the pendingchannels RPC query the chainArbitrator to obtain information regarding all active contractResolvers for a particular channel point.
There are currently four types of contractResolvers: timeout, success, timeout contest, and success contest. The first two are terminal states and will result in outputs being swept on chain by the utxoNursery or the resolver directly. The latter two, are indeterminate states. In this state we're either waiting for an HTLC to timeout, a pre-image to be discovered off-chain, or a pre-image to be discovered on-chain. During this period of time (before expiry or sweeping), there's no information available on the RPC layer concerning these HTLCs. In order to reconcile this, we'll need to extend the pendingchannels RPC call to also pull in information concerning these HTLCs.
One possible path would be to extend the HTLC with a new enum showing the current status of the HTLC itself.
Currently, the
pendingchannelsRPC will only display information drawn from theutxoNurseryfor pending force close channels. However, for a channel that was forced closed with active HTLCs, the HTLC outputs won't be sent to the nursery until they're fully mature. As a result, atm, there's a gap where all information isn't displayed on the RPC layer. This should be reconciled by having thependingchannelsRPC query thechainArbitratorto obtain information regarding all activecontractResolversfor a particular channel point.There are currently four types of
contractResolvers: timeout, success, timeout contest, and success contest. The first two are terminal states and will result in outputs being swept on chain by theutxoNurseryor the resolver directly. The latter two, are indeterminate states. In this state we're either waiting for an HTLC to timeout, a pre-image to be discovered off-chain, or a pre-image to be discovered on-chain. During this period of time (before expiry or sweeping), there's no information available on the RPC layer concerning these HTLCs. In order to reconcile this, we'll need to extend thependingchannelsRPC call to also pull in information concerning these HTLCs.One possible path would be to extend the
HTLCwith a new enum showing the current status of the HTLC itself.