Wrap any exception that occurs during socket IO or within the supplied
BlockListener with a new 'BlockNotificationException'. This brings the
exception handling more in line with that of the old BtcdDaemonImpl and
makes it easier to match them downstream in FullNode.handleError.
Provide a new 'BitcoindDaemon' block notification socket server, to
replace 'com.neemre.btcdcli4j.daemon.BtcdDaemonImpl'. This starts a
single service thread to listen for raw block hashes on localhost port
512*, sent by the specified 'blocknotify' shell/batch script, delegating
to a pool of worker threads to run the supplied BlockListener handler.
Unlike the original BtcdDaemonImpl class, a call to the 'getblock' RPC
method is not made automatically to supply a complete block to the
handler, instead requiring a separate, manual BitcoindClient.getBlock
invocation from within RpcService.
Also provide unit tests using a mock ServerSocket + Socket.
TODO: Use the new Bitcoind(Client|Daemon) implementations in RpcService,
in place of btcdcli4j Btcd(Client|Daemon)Impl & remove the old library.
Create a new 'BitcoindClient' interface and a corresponding builder, to
replace the old 'com.neemre.btcdcli4j.core.client.BtcdClientImpl' class
from the btcdcli4j library. This is instantiated by jsonrpc4j using a
dynamic proxy. It provides only a cut down version of the bitcoind RPC
API, exposing the methods 'getblock', 'getblockcount' & 'getblockhash',
as they are the only ones currently being used by RpcService.
Add corresponding Jackson-annotated DTO classes to model the JSON
structures returned by bitcoind, very similar to the classes provided by
btcdcli4j. Note that we use Double instead of BigDecimal to represent
fractional fields (difficulties + coin amounts in BTC), as they have
more consistent Jackson (de)serialisation and appear to be able to
faithfully round-trip numeric fields produced by bitcoind. Also note
that doubles can faithfully represent any valid decimal BTC amount (that
is, with 8 d.p. of precision) up to 21 million.
For now, keep the old BtcdClientImpl instance used by RpcService in
place, as the btcdcli4j block notification daemon is dependent upon it
and would also need to be replaced.
Also add unit tests for BitcoindClient which test against sample regtest
responses, using a mock HttpURLConnection.
Add 'witness_v1_taproot' script type to the enum and proto.pb, so that
it doesn't cause any problems when Taproot is activated and the new
script type starts showing up in RPC getBlock(..) responses (including
possibly BSQ transactions).
Also change the Java enum order (which shouldn't cause any problems as
the ordinal isn't used directly in hashCode calculations) and add the
missing 'witness_unknown' enum value to pb.proto to bring it in sync.
Adds all the gRPC server boilerplate, and a simple help service
that serves method help in man page format. Help text is maintained
in text files located in core/src/main/resources/help.
Only some of the method help text files are defined in this
change, more to be added.
The createoffer trigger price was defined as the 0 default value
in the gRPC request object (causing the file conflict with the
main branch). This line can be removed because a protobuf
long's default value is 0.
For all MailboxMessage we want to be sure they have an expire date.
Add getTTL methods and TTL value.
We use 7 days for ChatMessages and 30 days for PrivateNotificationMessages.
All others use default 15 days.
We prefer to keep them explicit and not use a default method in
ExpirablePayload or MailboxMessage.
The value in PrefixedSealedAndSignedMessage will not be used as the
sender use the TTL of the payload and pass that to the MailboxStoragePayload
where we store it in the extraMap. That way we can use different TTL even the
payload message is encrypted and we would not be able to look it up.
instead of decryptedMessageWithPubKey.
Here we change a bit the behaviour as now we check also if the
TradeMessage is a MailboxMessage. As that method is only called
from MailboxMessageService domain we never get a non MailboxMessage
here anyway and it would have been a bug.
Remove removeMailboxMsg(DecryptedMessageWithPubKey decryptedMessageWithPubKey) as not used anymore
