Replies: 3 comments 2 replies
-
|
For mining, one requirement is push based mechanism. Currently, sv2 is using IPC because it needs the node to push a new template (better fees) as soon as its available. Prior to this mining was using a poll based mechanism via the getblocktemplate RPC. |
Beta Was this translation helpful? Give feedback.
-
|
see #24 |
Beta Was this translation helpful? Give feedback.
-
|
Imho, the best course of action would be to enrich IPC interface and move the other interfaces (if still used) to "IPC bridges" . If there is need for a REST interface, create a IPC to REST bridge. Keeping it modular, separated and isolated. In the case that IPC is superseded with something new, create an "something new to IPC" bridge creating a clear upgrade path with backwards compatibility. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Off the top of my head, we currently have a Rest HTTP server, an RPC interface, ZMQ, an IPC interface, and (potentially) a kernel API that allows access to the internals of a running node. Ideally, we slim this down to one.
Whatever interface chosen should support the following clients:
For each of the users mention, you can imagine both a local and remote version. Another consideration is the interface should support access in a language agnostic form, e.g. a python script for collecting some metrics about block data, a rust tui for monitoring the node, a C++ wallet + Qt GUI.
Given all of that, of the existing interfaces which makes the most sense? Or is there a better way of doing this not considered yet?
Beta Was this translation helpful? Give feedback.
All reactions