How should we shape the IPC schema for #24?

[ViniciusCestarii]

Spinning this out of #24 (IPC interface for LND support) and josibake's comment.

How should a generic IPC interface look?

My sketch

A bootstrap Init hands out one capability per domain:

• Chain — tip / blocks / headers / tx lookup / utxo
• Mempool — testAccept / submit
• Fee — estimate / relay info
• Network — networks / local addresses
• Node — version / subversion
• Storage — size on disk / pruning

schemas: https://github.com/ViniciusCestarii/bitcoin-capnp-schema/tree/master/schemas

My main concern: do we return objects like a block as capabilities (blockByHash -> Block, then block.txs() / block.raw() lazily) or as flat structs + direct methods? Capability-first keeps Chain small and lets Block grow new methods without widening the top-level interface, and chain.tip().txs() is one round trip with pipelining, but it assumes consumers know what they are doing (e.g. knows how to pipeline requests).

In the schemas I made, I took the capability approach since it is cleaner and has a more capnp feel and less giant singleton interface, just like capnp docs recommend.

This is a brainstorm to react to, not a proposal I'm attached to. Feedback, and any alternative shapes are welcome!

[josibake]

First off, thanks for working on this! I'll take a look at the concrete sketch and give more detailed feedback.

but it assumes consumers know what they are doing (e.g. knows how to pipeline requests).

I think we should always assume the most capable consumer, and mitigate the risk that they use the interface incorrectly with clear documentation and toy examples. I feel its the right call to lean heavily into the Capnproto design and documentation recommendations. Glad to see you came to the same conclusion!

A few questions in my mind:

• How do expect storage to be used? Node could give config information such as: this node is running in pruned mode
• Is Fee in the interface? It certainly can be but it could also be a consumer, e.g., that reads Chain and Mempool interfaces to calculate fee estimations. There could be an argument that fee is strictly a wallet feature , so a wallet is expected to have its own fee estimator (by consuming Chain, Mempool)

I'm curious to hear your thoughts @ismaelsadeeq on the fee stuff because you've thought about this a lot more than I have

[ViniciusCestarii]

How do expect storage to be used? Node could give config information such as: this node is running in pruned mode

Mainly for clients to check data availability and capacity before they act: read Storage.pruning() to see if a block height is still on disk before requesting it, and info().sizeOnDisk for monitoring. So pruned mode is already exposed there. I put it on Storage rather than Node because it's about what's on disk and this is runtime state, not node identity.

Is Fee in the interface? It certainly can be but it could also be a consumer, e.g., that reads Chain and Mempool interfaces to calculate fee estimations. There could be an argument that fee is strictly a wallet feature , so a wallet is expected to have its own fee estimator (by consuming Chain, Mempool)

I anwered on @ismaelsadeeq reply

[ismaelsadeeq]

I'm curious to hear your thoughts @ismaelsadeeq on the fee stuff because you've thought about this a lot more than I have

The Fees could be part of the wallet, but I think that's a bit tangential, we will be baking analytics and data stuff into the wallet which can be an overkill, hence I don't think Fees logic should live there. Instead, we should have a Fees Interface that the wallet can consume, ideally as part of the node.
But if we want further separation, it's possible we'd just have to extend the Chain interface with the events the Fees needs, and for mempool fee-rate estimates it could just consume both the Chain and Mining interfaces.

As it stands, the fee estimator is a passive observer of the validation interface notifications; those notifications could just be propagated via the Chain interface, I like the initial idea from @ViniciusCestarii with this, you can basically have multiple fee estimators and remove any one when there's a better one, as long as everything is properly abstracted.

[josibake]

the fee estimator is a passive observer

This strongly indicates to me it should be a consumer of these interfaces, not a producer. As you mention, fee estimation can be experimented with , you could many hundreds of different fee estimators, etc, all without the node being aware.

I agree on your push back of putting fees into the wallet, though. Wallet is a consumer of node + fees.

[ViniciusCestarii]

Yeah, I agree that this is a consumer thing and not a producer one so we can drop Fee schema and have Chain propagating notifications and have interfaces that provide enough information so a fee estimator can be built upon.

One thing I made on the sketch is that I separated Mempool and Chain so in the interface there would be a ChainNotification (notificating about blocks) subscription on Chain and a MempoolNotification (notificating about txs on mempool) on Mempool. I did this thinking Chain is about what's confirmed and Mempool is about what's pending. What do you think?

[ismaelsadeeq]

One thing I made on the sketch is that I separated Mempool and Chain so in the interface there would be a ChainNotification (notificating about blocks) subscription on Chain and a MempoolNotification (notificating about txs on mempool) on Mempool. I did this thinking Chain is about what's confirmed and Mempool is about what's pending. What do you think?

Nice, in this case, the Fees interface would just depend on MempoolNotification and have access to MiningInterface.

[ViniciusCestarii]

Updated schemas added Chain and Mempool notifications and a Mining interface with createBlockTemplate.

I based these changes on Bitcoin Core IPC interfaces removing what didnt make sense here and adapting for a more capnp and easier to consume style.

What do you think?