Beefing Up the Test Node

[contrebande-labs]

I started this discussion here. And I found the test Node.kt in this project just now. So my objectives are the following:

• Add automatic, transparent Tor support for everything except local/private addresses
• Add new JSON HTTP API : sendCustomOnionMessage(nodeId, nodeHost, nodePort, type, data)
• Add new JSON HTTP API : subscribeCustomOnionMessages(types)
• Add new JSON HTTP API : getNetworkGraphTopology()
• Add new JSON HTTP API : subscribeNetworkGraphTopologyChanges()
• Add new JSON HTTP API : getOnChainWalletAddress()
• Add new JSON HTTP API : getOnChainWalletBalance()
• Add new JSON HTTP API : sweepOnChainWalletBalance(recipientAddress)

And so, I have a some questions, if I may:

1. Do the ACINQ/endurance trampoline nodes support routing trampoline payments via Tor? If so, how dow we connect to those nodes and advertise our Tor onion v3 URI?
2. The sendCustomOnionMessage JSON HTTP API call should be straightforward enough, but for subscribeCustomOnionMessages and subscribeNetworkGraphAnnouncements, I should probably use the Secure WebSocket protocol as you do with eclair. Not really a question but a call for comments.
3. For getOnChainBalance I looked for it (probably not hard enough) but, I could not find anything. Does the node maintain an on-chain wallet balance or ledger somewhere?

Thanks!

[t-bast]

The test Node.kt is really only meant to be used for tests, this is definitely not suitable to run a node. Running a node based on lightning-kmp would require additional work, if you're interested in this don't hesitate to fork it, work on it and once you have something that works feel free to open PRs to integrate it here if they make sense.

[contrebande-labs]

Yep, I'm aware that Node.kt is in the test code base. But, before I create my own production implementation (probably in Java, probably in Vert.x or Quarkus, probably with Hazelcast caching and clustering backed with some NoSQL cloud database, probably intended for native-image compilation with GraalVM), I just want to make sure that Node.kt is covering all the features included in the lightning-kmp library (or its bitcoin-kmpdependency) or maybe even some things in phoenix-shared.

So, first things first, how do I get the on-chain wallet balance? I understand that we are getting all the on-chain data from electrum, but is there already code for getting or computing the balance, is the balance or the transactions persisted in a database somewhere in lightning-kmp, bitcoin-kmp or phoenix-shared?

Thanks.

[t-bast]

So, first things first, how do I get the on-chain wallet balance?

There is no on-chain balance in Phoenix, it's a lightning-only wallet. The only on-chain balance you may have is the result of force-closed channels (which should very rarely happen), and they can be claimed back by importing your seed on Electrum (or another on-chain wallet).

[contrebande-labs]

Ok. Get it. The use case for a server-side "light" LN wallet is to have high-availability for ecommerce payments in different data centers. For the on-chain wallet to be managed elsewhere (maybe cold storage, may even Square Subzero) is fine too. So, as long as we can import and "restore" a pre-generated seed into lightning-kmp as it is done in Node.getSeed() , we're good. I will try that on testnet with endurance and see how it goes.

And I presume there is no network graph data maintained anywhere either because it's a non-routing node and it relies exclusively on its pre-configured trampoline node for routing. So I will leave the getNetworkGraphTopology and subscribeNetworkGraphTopologyChanges operations for later. I think we can do without them for our use case at the moment.

Once I'm done testing the on-chain/off-chain wallet operations as above, I will look into the handling of odd-unreserved-typed onion messages and see if the trampoline node can be of use here too since we don't have a routing node.

And once I'm done with that, I will start my own node implementation. I will try to publish lightning-kmpand bitcoin-kmp to a local maven repository (unless you plan to publish them on a maven repo yourself) and start a new project with the clusterized server node in Java/Vert.x, inspired by Node.kt with a gRPC interface (probably taking inspiration from the lnd gRPC API for the supported operations). And if all goes well, I might make it available on Github as lightning-vertx.

I will certainly be back with some more questions. Thanks!

[sstone]

lightning-kmp and bitcoin-kmp are already available on the maven central repository.

[contrebande-labs]

Hi! Thanks. I'm using those. For the secp256k1 JNI package. If I include secp256k1-kmp-jni-jvm I'm I good on arm64 too or just amd64? I wasn't able to determine this from the Maven artifacts.

Also, there are loads of hardcoded config in Node.kt. Is there a way to compute/get these programmatically or negotiated directly with the trampoline peer? Or in the worst case, loaded from a configurable URL like the wallet context JSON in phonix-shared's WalletContext and AppConfigurationManager?

I'm merely rewriting Node.kt in Java, once I'm done, I will publish that and start introducing Vertx features.