As you're aware, I made a Namecoin name lookup daemon, loosely based on bitcoinj-daemon. I'd like to work toward getting it upstreamed to bitcoinj-addons, the question is what the best way to do that is, without too much maintenance complexity and code duplication.

My initial inclination is to create a new Git branch of bitcoinj-addons for this purpose, so that changes made to bitcoinj-addons can easily be merged to the Namecoin branch via standard Git merging procedures. I'm pretty sure this is how Coinomi handles altcoin support (though I haven't actually looked at Coinomi's source code for a few months).

An alternative might be to make the bitcoinj-addons programs support network parameters from libdohj via a command-line flag, so that arbitrary libdohj-supported altcoins would work with bitcoinj-addons without any additional changes. (This would still require changes to support name operations in bitcoinj-daemon, either via a Git branch or via an extra module.)

Curious what your thoughts are.

Cheers!

Refactor (move) all packages to the org.consensusj package.

It probably makes sense to do some other package and perhaps submodule changes as part of this process.

Running OmniJ RegTests against latest Omni Core / Bitcoin Core receives the following error:

    org.consensusj.jsonrpc.JsonRpcStatusException: The wallet generate rpc method is deprecated and will be fully removed in v0.19. To use generate in v0.18, restart bitcoind with -deprecatedrpc=generate.
    Clients should transition to using the node rpc method generatetoaddress

We can use the deprecatedrpc=generate workaround for now, but we need to add the new generatetoaddress RPC method to the Bitcoin JSON-RPC client and update the RegTest support (here and in OmniJ) to use the new RPC.

Is anyone using the RPC client in an environment that won't run code written with Lambdas and Default Interface Methods? I'm thinking the client can be somewhat simplified (with no loss of functionality) by using some Java 8 features.

I'd like to upgrade to Spring Boot 2.1 in order to be on the latest release and also for improvements they've made to support GraalVM.

I made an attempt at a 2.1.2 upgrade and all three Spring apps were broken.

• bitcoinj-daemon

Has a problem with a bean name being overridden (original provided by Spring, override provided by Spring Boot) the solution is to add an application.yml with the following content:

spring:
  main:
    allow-bean-definition-overriding: true

• cj-nmc-daemon

Same problem and solution as bitcoinj-daemon

• bitcoinj-peerlist

Has several issues:

1. Needs allow-bean-definition-overriding: true
2. Needs packages moved around, e.g. @ComponentScan({"com.msgilligan.bitcoinj.peerserver.config","com.msgilligan.bitcoinj.peerserver.controller"})
3. It looks like the Spring MVC auto-configuration is no longer working. Static resources (e.,g. index.html) are not being found, etc. Since all the Java configuration classes were created way back in Spring Boot 1.0 and have accumulated work-arounds and migrations since then, it's probably time to take a fresh look at how these should be set up for Spring 2.1.x and later.

So it's item (3) for bitcoinj-peerlist that is the blocker. Once we have a fix for that we should be able to upgrade to Spring Boot 2.1.x.

WIP is here: 5b3eb2c

JSON-RPC 2.0 allows the request params value to be a map (JSON object.) Supporting this option has not been critical to any of the existing use-cases for consensusj-jsonrpc but is something that should eventually be supported.

The first step in implementation might be to define a JsonRpcParams type and re-define JsonRpcRequest to use it rather than List<Object> or perhaps even define JsonRpcRequest<T extends JsonRpcParams>.

See bitcoinj/bitcoinj#895

Using annotations and an external Spock configuration file, we should be able to mark test Specs or feature tests as requiring RegTest mode or not.

A test that has a @RegTest annotation would only run if the current functional/integration test configuration was running against a server in RegTest mode.

See Spocklight: Including or Excluding Specifications Based On Annotations by @mrhaki.

So for example, the entire class BitcoinStepwiseSpec would have a @RegTest annotation. Whereas, BitcoinSpec would only user @RegTest on feature test methods that used generateBlock().

Publishing to Maven Central requires several other issues be resolved first:

• #29 - Refactor all packages to org.consensusj.*
• #38 - Add 'Automatic-Module-Name' entry to all JAR manifests
• Other?

Write a decent user guide.

The JavaDoc needs work. Writing good JavaDoc for the main RPC wrapper classes will be the focus.

I'm going to try using the AsciiDoctor AsciiDoclet so we can write JavaDoc like this:

/**
 * = JSON-RPC Client for *Bitcoin Core*
 *
 * A strongly-typed wrapper for the Bitcoin JSON-RPC API. *bitcoinj* types are used where appropriate.
 * For example, a block hash can be retrieved as follows:
 *
 * [source,java]
 * --
 * Sha256Hash hash = client.getBlockHash(342650);
 * --
 *
 * `Sha256Hash` is defined in *bitcoinj*.
 *
 * NOTE: This is still a work-in-progress and the API will change. High on the priority list is making
 * better use of https://github.com/FasterXML/jackson[Jackson] to replace some of the current `Map`-based types.
 *
 */

and get output like this.

See: Automatic-Module-Name: Calling all Java Library Maintainers

Before doing this we need to:

1. Move all classes/packages into the new org.consensusj package namespace
2. Make sure that no packages are split between JARs (so they can become modules, which don't allow split packages)

Let me quickly describe what issue I faced yesterday:

I wanted to dump some intermediate results, in particular of listUnspent, which returns a List of UnspentOutputs.

The change was basically:

@@ -166,2 +166,3 @@ class SendToOwnersReorgSpec extends BaseReorgSpec {
         when: "creating a third STO transaction"
+        println listUnspent(0, 999999)
         def thirdTxid = omniSendSTO(actorAddress, tokenID, 50.divisible)

However, the result:

[com.msgilligan.bitcoinj.json.pojo.UnspentOutput@3a13055a, ...]

It would be nice, if the UnspentOutput (and others) would be converted to something readable, such as:

[{"txid":"hex","vout":n,"address":"1base58",...}, ...]

The Groovy @ToString() class annotation may be useful?

Hello

It would be great if you provided examples on how to use the Bitconj json rpc client

thanks!

What's the best approach for implementing a NameLookupService (the Namecoin analogue of WalletAppKitService)? Since its functionality is a superset of WalletAppKitService (and most of the methods of WalletAppKitService are unlikely to need changes), my inclination is to make it a subclass of WalletAppKitService, and make it implement an extra NamecoinJsonRpc interface that includes the name-specific RPC methods. Is this a good approach, or is there a better way to do it?

The links on https://github.com/msgilligan/bitcoinj-addons/blob/master/doc/index.adoc are no longer valid:

• https://github.com/msgilligan/bitcoinj-addons/blob/master/doc/apidoc/index.html
• https://github.com/msgilligan/bitcoinj-addons/blob/master/doc/addons-user-guide.html

Currently to publish JARs to Bintray we need to disable (by commenting out subprojects in settings.gradle) the following modules:

• bitcoinj-daemon
• bitcoinj-peerserver
• cj-nmc-daemon

See possibly related Issue #61 .

It would be nice if at least some of these modules could run on iOS using Intel's Multi-OS Engine

• See this discussion on an Intel forum.
• The moe-java-samples repo is worth looking at too.

Create a deterministic build process similar to that used for Bitcoin Core. See this blog article for suggestions:
http://gary-rowe.com/agilestack/2013/08/08/how-to-create-a-deterministic-jar/

Currently all certificate checking is disabled to allow unit testing over SSL with self-signed certificates.

A relative easy and short-term fix is to read the (currently hardcoded to false) disableSslVerification from a system property.

A better solution would be to create (enable creation of) a custom SSLSocketFactory that is easily configurable at runtime. This StackOverflow Q&A looks helpful.

I upgraded to Gradle 2.7 today and discovered and reported this issue to Gradle.org:

https://discuss.gradle.org/t/distributionsha256sum-not-validating-in-gradle-2-7/11649

We can use this issue to track progress and remind us to fix it.

First off: You are boosting so many devs productivity - single-handedly. Big thank you for publishing and maintaining (!) this library.

Are there already any plans on publishing the artifacts somewhere else than Bintray?
Bintray itself will be shutting down on May 1st and I already see 403 Forbidden when accessing some packages.

All Bintray services will be deprecated and your accounts will be disabled on May 1st 2021.

Since it seems you own "msgilligan.com" Maven Central might be an alternative.
Also https://jitpack.io/#ConsensusJ/consensusj with signed packages might be an alternative.

What are your thoughts on this topic?

Read more: https://blog.gradle.org/jcenter-shutdown

edit: added link to gradle blog about jcenter shutdown
edit2: 403 Forbidden is probably caused by the "brown-out session" ("Schedule brown-out session on April 12th 6AM to 2PM Pacific Daylight Time" on https://status.bintray.com/) - artifact download should be working till February 1st 2022.

It seems reasonable to require JDK 9 (or 11) for building and running the CLI modules. The ToolProvider interface is a standard interface that is somewhat similar to the CliCommand class which would be modified to implement ToolProvider.

It would be very nice to be able to create a standalone, natively-compiled cj-bitcoin-cli command using GraalVM

I started working on this and have a successful compile as of 683a1f8

However, the executable fails as follows:

./bitcoinj-cli/build/cj-bitcoin-cli -rpcport 8080 getblockcount
Connecting to: http://127.0.0.1:8080/
[main] INFO org.bitcoinj.core.Context - Creating bitcoinj 0.14.7 context.
[main] INFO org.bitcoinj.core.Context - Creating bitcoinj 0.14.7 context.
Req json: {"method":"getblockcount","id":1,"jsonrpc":"1.0","params":[]}
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.lang.Throwable.<init>(Throwable.java:310)
	at java.lang.Exception.<init>(Exception.java:102)
	at java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:89)
	at java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72)
	at com.oracle.svm.reflect.proxies.Proxy_133_BitcoinJCli_main.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:199)
	at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0)
Caused by: java.lang.AssertionError: Should not here
	at java.lang.Throwable.<init>(Throwable.java:265)
	at java.lang.Error.<init>(Error.java:70)
	at java.lang.AssertionError.<init>(AssertionError.java:58)
	at java.lang.AssertionError.<init>(AssertionError.java:74)
	at sun.util.logging.LoggingSupport.ensureAvailable(LoggingSupport.java:76)
	at sun.util.logging.LoggingSupport.isLoggable(LoggingSupport.java:114)
	at sun.util.logging.PlatformLogger$JavaLoggerProxy.isLoggable(PlatformLogger.java:656)
	at sun.util.logging.PlatformLogger.isLoggable(PlatformLogger.java:270)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1147)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:984)
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1334)
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1309)
	at org.consensusj.jsonrpc.RPCClient.send(RPCClient.java:100)
	at org.consensusj.jsonrpc.AbstractRPCClient.sendForResult(AbstractRPCClient.java:55)
	at org.consensusj.jsonrpc.AbstractRPCClient.send(AbstractRPCClient.java:114)
	at org.consensusj.jsonrpc.AbstractRPCClient.send(AbstractRPCClient.java:143)
	at com.msgilligan.bitcoinj.cli.BitcoinJCli.runImpl(BitcoinJCli.java:47)
	at com.msgilligan.bitcoinj.cli.CliCommand.run(CliCommand.java:164)
	at com.msgilligan.bitcoinj.cli.CliCommand.run(CliCommand.java:145)
	at com.msgilligan.bitcoinj.cli.BitcoinJCli.main(BitcoinJCli.java:31)
	... 4 more

It looks like the same issue was reported here: oracle/graal#357 and fixed in: oracle/graal@767d40b but not yet released. Maybe the next release of GraalVM will have this fix.

Right now, bitcoinj-server (and, by extension, bitcoinj-daemon and cj-nmc-daemon) are using a PeerGroup. Namecoin's fork of ConsensusJ is using a WalletAppKit instead. WalletAppKit is substantially more secure since it actually does SPV validation rather than blindly trusting whatever a network peer says, but it takes a few minutes for initial sync (whereas a PeerGroup can be used instantly).

Would a PR be accepted that completely replaces PeerGroup with WalletAppKit, or does ConsensusJ aim to satisfy some use cases where PeerGroup is required?

I want to use jsonrpc to connect bitcoind. What should I do?
Can you give me an example?

many methods are missing, any eta on the implementation?

I was interested in addnode for example

thanks

AsciiDoclet is awesome, but we had to disable it (see Issue #55) to enable building with JDK 11 and later.

This is an enhancement request and reminder to possibly re-enable it later.

com.fasterxml.jackson.databind.JsonMappingException: Numeric value (2345908848) out of range of int
at [Source: sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@60940cc1; line: 1, column: 1562]
at [Source: sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@60940cc1; line: 1, column: 1552] (through reference chain: com.msgilligan.jsonrpc.JsonRpcResponse["result"]->com.msgilligan.bitcoinj.json.pojo.BlockInfo["nonce"])
at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:388)
at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:348)
at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.wrapAndThrow(BeanDeserializerBase.java:1611)
at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapping(BeanDeserializer.java:513)
at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:400)
at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1191)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:314)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:148)
at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:504)
at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:104)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:276)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:140)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3814)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2938)
at com.msgilligan.jsonrpc.RPCClient.send(RPCClient.java:119)
at com.msgilligan.jsonrpc.AbstractRPCClient.sendForResult(AbstractRPCClient.java:55)
at com.msgilligan.jsonrpc.AbstractRPCClient.send(AbstractRPCClient.java:89)
at com.msgilligan.jsonrpc.AbstractRPCClient.send(AbstractRPCClient.java:96)
at com.msgilligan.bitcoinj.rpc.BitcoinClient.getBlockInfo(BitcoinClient.java:278)

We need to upgrade AsciiDoclet for JDK 10+

I'm already having second thoughts about the project name. I'm not in a big hurry to rename it, but am opening an issue where suggestions can be made.

(In the short run I want to finish the Jackson work and then announce on but bitcoinj mailing list and see what kind of feedback and suggestions we get.)

We are currently using version 1.1, the latest version is 1.5.0.

I had opened an issue in the jsonrpc4j project about difficulties I had integrating with Spring Boot:
briandilley/jsonrpc4j#69
That issue is now closed and there is a now a [Quickstart for Spring Boot and JSON-RPC for Java ](https://github.com/briandilley/jsonrpc4j/wiki/JSON-RPC-for-Java-Client-&-Spring-Boot-(Server-example) wiki page.

There is currently a proof-of-concept Namecoin RPC client within the bitcoinj-rpcclient module. This should be moved to a separate module, named something like namecoinj-rpcclient.

If the username / password is too long, Base64.encodeToString will input a newline somewhere inside of basicAuth. This is invalid for HTTP headers. Here is the relevant stacktrace and code part.

Exception in thread "main" java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic X19jb29raWVfXzo5MjJlNDQ3MDJjYWZiYzYwMzA1ZWViMDgyMTMzYjM2MTFlYjAxNzlhYTlhMjE4
Yzk0ODU2MmEwMjk4MmU0YzA=
	at sun.net.www.protocol.http.HttpURLConnection.checkMessageHeader(HttpURLConnection.java:541)
	at sun.net.www.protocol.http.HttpURLConnection.isExternalMessageHeaderAllowed(HttpURLConnection.java:492)
	at sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(HttpURLConnection.java:3057)
	at com.msgilligan.jsonrpc.RPCClient.openConnection(RPCClient.java:175)

...
String basicAuth = "Basic " + Base64.encodeToString(auth.getBytes(), 0).trim();
connection.setRequestProperty("Authorization", basicAuth);
...

bitcoin core 0.17.0

consensusj v0.3.0

hexEncoded Parse error

testnet
txid:40d8fb846bf7d64537d63a3400dbeb5e848bd19449bf752f1582e28677f68092

The parsed transaction is not what I want

Is it because of the version of bitcoin core?

I have created a little JUnit test for BitcoinExtendedClient.getBlock. Calling this method with some blocks fails with the Exception:

[main] ERROR org.consensusj.jsonrpc.RPCClient - JsonProcessingException: {}
com.fasterxml.jackson.databind.exc.InvalidFormatException: Invalid Block
 at [Source: sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@1ee29c84; line: 1, column: 11] (through reference chain: org.consensusj.jsonrpc.JsonRpcResponse["result"])
	at com.msgilligan.bitcoinj.json.conversion.BlockHexDeserializer.deserialize(BlockHexDeserializer.java:35)
	at com.msgilligan.bitcoinj.json.conversion.BlockHexDeserializer.deserialize(BlockHexDeserializer.java:1)
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:499)
...

My guess is that the block JSON format has changed since the last changes of Bitcoin Core and not adapted with ConsensusJ.

Here is the unit test:

package com.msgilligan.bitcoinj.rpc;

import java.net.URI;
import java.util.List;

import org.bitcoinj.core.Block;
import org.bitcoinj.core.NetworkParameters;
import org.bitcoinj.core.Sha256Hash;
import org.bitcoinj.core.Transaction;
import org.bitcoinj.params.MainNetParams;
import org.bitcoinj.params.TestNet3Params;
import org.junit.BeforeClass;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class BitcoinExtendedClientTest2 {
	private static final Logger log = LoggerFactory.getLogger(BitcoinExtendedClientTest2.class);

	static BitcoinExtendedClient client;

	final static String host = "localhost";
	static String rpcuser = "test";
	static String rpcpassword = "test";

	@BeforeClass
	public static void setUpBeforeClass() throws Exception {
		if (client == null) {
			NetworkParameters netParams = TestNet3Params.get();
			// NetworkParameters netParams = MainNetParams.get();
			URI server = RPCURI.getDefaultTestNetURI();
			client = new BitcoinExtendedClient(netParams, server, rpcuser, rpcpassword);
			RPCConfig config = new RPCConfig(TestNet3Params.get(), server, rpcuser, rpcpassword);
			client = new BitcoinExtendedClient(config);
			log.info(client.getBlockChainInfo().toString());
		}
	}

	@Test
	public void testGetBlock() throws Exception {
		// get last N blocks
		// log the block and their transactions
		int currentBlockDepth = client.getBlockCount();
		int N = 100;
		int successfulBlockRetrieves = 0;
		for (int i = currentBlockDepth; i > currentBlockDepth - N; i--) {
			Block block;
			try {
				block = client.getBlock(i);
				successfulBlockRetrieves++;
			} catch (Exception e) {
				Sha256Hash hash = client.getBlockHash(i);
				log.error("error getting block: " + i + " with hash: " + hash.toString());
				continue;
			}
			log.info("block: " + i + ": " + block.toString());
			List<Transaction> txs = block.getTransactions();
			for (Transaction t : txs) {
				log.info("transaction: " + t.toString());
			}
		}
		log.info("successfulBlockRetrieve: " + successfulBlockRetrieves + " of " + N);
	}
}

The last log writes the number of successful block retrievals. When I ran it, I got:
[main] INFO com.msgilligan.bitcoinj.rpc.BitcoinExtendedClientTest2 - successfulBlockRetrieve: 24 of 100

When I try to get the same block that failed in this unit test directly from the bitcoin-core cli it works. Here's one from the testnet for verification:
[main] ERROR com.msgilligan.bitcoinj.rpc.BitcoinExtendedClientTest2 - error getting block: 1279694 with hash: 00000000000056dfdf0138c191040055c41fc7c07047ce6abb238227a2f3da6f

Or am I call stuff wrong?

I have tried to upgrade in both the bitcoinj-cli and bitcoinj-proxy modules, but get the following error when I do a gradle install:

> Could not publish configuration 'archives'
   > A POM cannot have multiple artifacts with the same type and classifier. Already have MavenArtifact bitcoinj-proxy:zip:zip:null, trying to add MavenArtifact bitcoinj-proxy:zip:zip:null.

So it looks like there's some configuration tweaking for the maven-publish plugin required.

BigDecimal is used in many places throughout the bitcoinj-rpcclient module and probably elsewhere where we should probably be using the bitcoinj Coin class.

This includes:

• Parameter and return types of BitcoinClient class.
• Parameter and return types of the BTCTestSupport trait.

we try to use bitcionj to sign the hex string from bitcoin-cli createrawtransaction and then broadcast transaction with bitcoin-cli. i wonder if there some ways?

RawTransactionInfo's constructor that takes a Transaction loops over the TransactionInputs to populate the VinList. When instantiating the Vin, it uses input.getHash() as an argument. However, TransactionInput has not overridden getHash() and therefore throws an UnsupportedOperationException from Message. It's unclear to me how this ever works. I'd put in a PR, but if I'm being honest, I don't know enough about Bitcoin to know what should be happening here.

RawTransactionInfo.java

        vin = new VinList();
        for (TransactionInput input : transaction.getInputs()) {
            vin.add(new Vin(input.getHash(),
                            input.getOutpoint().getIndex(),
                            input.getScriptSig().toString(),
                            input.getSequenceNumber()));
        }

Message.java

    public Sha256Hash getHash() {
        throw new UnsupportedOperationException();
    }

A new field "frozen" is always shown in Omni Core v0.3.1, when retrieving balances (e.g. with omni_getbalance). So far, this field was only shown, when there were actually frozen tokens.

This causes the following error:

2018-08-08 11:24:25.536 SEVERE  [org.consensusj.jsonrpc.RpcClient] (org.consensusj.jsonrpc.RpcClient sendRequestForResponse) JsonProcessingException: {} 
com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "frozen" (class foundation.omni.rpc.BalanceEntry), not marked as ignorable (2 known properties: "reserved", "balance"])

Better use of Jackson will help us to:

1. Eliminate repetitive conversion code from many methods
2. Replace remaining Maps with strongly-typed POJOs.

See bitcoinj/bitcoinj#1336

This is an issue with bitcoinj until SegWit support is implemented, but there is a workaround (using the rpcserialversion flag on bitcoind)

1. Does the BitconClient.sendToAddress method includes the txFee?

I want to remove the following three Spring Boot based (proof-of-concept) server apps (Gradle subproject):

• bitcoinj-daemon
• bitcoinj-peerserver
• cj-nmc-daemon

and the one Ratpack-based (proof-of-concept) server app (Gradle subproject)

• bitcoinj-proxy

The reasons for removal are:

1. They are only proof-of-concept implementations are not really used by anyone
2. I don't have the time to maintain them (and they're already falling behind the latest version fo Spring Boot and Ratpack)
3. The majority of their functionality is in existing library modules anyway
4. I am personally focusing on Micronaut-based servers currently
5. I think server app implementations should generally be in other repositories (e.g. https://github.com/ConsensusJ/btc-proxyd) not in the main consensusj library repository.

EchoJsonRpcService and WalletAppKitJsonRpcService are still using javax.inject because of a Micronaut issue.

Successful build with javax.inject: https://github.com/ConsensusJ/consensusj/actions/runs/640961092
Failed build with jakarta.inject: https://github.com/ConsensusJ/consensusj/actions/runs/640970666

Build scan of failure: https://scans.gradle.com/s/4doezawpjeiwq/tests

Might as well do it with Travis, since @dexX7 knows how to do it.

See the build output with (--warning-mode all):

The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.5/userguide/upgrading_version_5.html#legacy_publication_system_is_deprecated_and_replaced_with_the_publish_plugins

Once a JVM binding is available for libconsensus, Spock tests could be a very good way to test both the JVM binding and libconsensus itself.

There is not much documentation on libconsensus at this point, but it is mentioned int the Bitcoin Core 0.10.0 Release Notes

See also:

• bitcoin/bitcoin#5235 [Merged]
• bitcoin/bitcoin#5311 [Docs and Examples]

Note: Now the non-Omni-related Spock test functionality has been moved to bitcoinj-addons from OmniJ I'm opening this issue here and closing OmniLayer/OmniJ#55

I'm a bit nitpicking here, but a few quick notes about the readme.

1. The / in the build example seems twisted:

-    .\gradlew bootRun
+    ./gradlew bootRun

2. The requirements should be stated, in particular that JDK 8 is required. It could be noted that JAVA_HOME must point to the correct version, when using ./gradlew. It might be noted that [a list of packages] is downloaded, which can be relevant for someone with a mobile data connection.

3. It would be great, if there were a few lines to what could be expected, when running ./gradlew bootRun. Before doing so I was wondering, how to use the project (i.e. I missed a "first use" example, and actually assumed the project focuses on a BitcoinJ RPC server), and then I was surprised for a moment, when I saw the rather wild messages of STOMP, until I noticed they are actually network messages. It was more obvious after the first transactions were listed.

It should be stated that bootRun connects to the P2P network.

Other than that, this is really nice! :)

Edit: just found the other gems, like http://localhost:8080/listPeers (login: admin/admin).