The idea of binding to interfaces now will take into account the
interfaces maybe becoming available only after the server started.
If your server starts at machine boot, it is a 50/50 chance that the
network interfaces are already fully configured and have received
addresses. In case of dhcp, more often than not this means that your
server will not be listening at the main interface because it wasn't up
yet.
This new api allows the server to give a function to register a new
interface and we have some linux specific code that will notice changes
in the interfaces and we'll allow the app to bind to it a moment or two
after that.
We always need two random peers to download a certain merkle block, to
avoid the withholding attack.
It occurred to me that there is no need to do them one after the other,
they can both run in parallel without issues. Saving time.
This renames lots of variables to be more "correct" (call it
output instead of transaction and similar things).
This removes duplication by moving repeated into methods.
This fixes the behavior of the dsproof calls to be back to
the old unit test, while adding the new fields to the unit
test for minimal change.
This is a combination of 5 commits.
Improve AddressMonitorService
Changed double spend notifications to new format & include cashtoken data
Updated AddressMonitorService response for txs found in the mempool.
Removed duplicate BitcoinScriptHashed tags
AddressMonitorService update
This makes minor renames and cleanups.
We merge the 5 different cashtoken booleans into one, making
usage and server-code simpler.
And probably in real use not actually causing bigger messages.
Also use the more appropriate lock_guard for mutex usage.
And I noticed that in the NotificationCenter we assumed a callback would
be able to unregister itself, which requires a recursive mutex. As such
the mutex has now been elevated to be such.
Negative ban scores are a bit annoying since when a user bans the node
it gives a 1000 point punishment, assuming that this will make the ban
score be above the 1000 point limit which implies banned.
CMake details for finding boost have been shipped for years inside
of boost, this makes cmake use that upsteam info to configure boost
and avoids problems when a newer boost than cmake is found.
This is an abstract class that the application using this library needs
to subclass. Ownership and lifetime don't change, it still lies with the
app using the library and they still need to add and remove it from the
connectionManager, but this makes it much more stable for multi-
threading environments and avoids issues on misuse.
tomFlowee
John Galt