Make FindAddressInMempool also call onAddressUsedInOutput()
Make the mempool methods use better filter defaults, as the
offset in block doesn't make much sense for them.
Allow for the possibility that more than one watched address matches
the transaction we notify about and therefore make an array.
Additionally, include the block-height property when mined.
This converts more JS values to the proper NetworkManager values
and vice versa for the return message.
Return messages now have the following structure;
{
serviceId: 1,
messageId: 1,
'67': 'main',
'68': 644459,
header: {},
body: [
{ key: '67', value: 'main' },
{ key: '68', value: 644459 },
]
}
The keys in CMF are all intergers, and the 67 and 68 here are examples.
The body is now an array of properties.
For convenience each item is also set on the main return message.
Be aware, though, that for properties that are repeated only the last
one will be present on the return-message.
This commit also implements several blockchain service methods and
adds an example.
Last point is that for byte-arrays (like hashes) we produce a property
like this:
{
key: '70',
value: [Uint8Array],
string: '000000000000000001613440a154e4c35c6467f65dafd70605d5578ec00b0192'
}
Again, as convenience, we add the string version of hashes. This is also
present on the return-message as '70str' next to the '70' bytearray.
This starts a native JS lib, taking inspiration for the basics
from the Flowee-JS-pure repo.
Additionally this exposes sending of CMF messages from JS over
the connection already set up in C++.
tomFlowee
TomZ