Adding BitCore-Proxy and double-spend-proofs
- Allow the API for UTXO lookups to not just take TxID, but also allow blockheight/offset-in-block based transaction-identification.
- Add double-spend proof support in the AddressMonitor API service.
- Usage of a static code checker to fix lots of potential issues with regards to variable typing.
- Make compile on MacOS
- Remove overhead and functionality which used to guess required fees.
- Fix various util libraries to stop depending on openssl with some refactors.
- Avoid doing a DNS lookup when user connects to an IP address.
- Specialize SQL statements for postgresql to make it faster when we detect that SQL engine.
- Make Indexer bind to localhost when no
--bindarguments were given.
- Fix engine defaults. This solves the issue that unless you explicitly turn off the txdb you still got it.
The 2019.08.1 release introduces a new service that further continues the trend of cloud-native design that you see in all Flowee products.
Additionally the non-final version of the double spend proof is included in the Hub and the node will now react and send out double spend proofs over the global p2p network.
A web-API services is added which does not require any storage. It is just an application you can run in a Docker container. It connects to the existing Flowee services the Hub and Indexer over the super fast native APIs that Flowee uses.
In order to create this webservice new libraries have been created that makes accessing multiple Flowee services easy and fast.
This creates a platform that should spawn various other Flowee services, unique to a domain, with relatively low effort. The main benefit is that they reuse running Hub and Indexer services and as such pose very little overhead to your setup. This is what “cloud-native” was about.
Double Spend Proof
For more than a year there have been discussions and proposals around the double spend proofs and while there has been little to no movement in implementing it, Flowee the Hub went and created a working implementation including a specification for this.
The double spend proof is a new network message that is created by the Hub when it detects two transactions spending the same money. The proof is unique in that any network node can quickly validate it is valid and not faked by a malicious party.
The proof is useful especially for merchants in that they will get a notification that their incoming payment may not actually be confirmed by the network. This is almost always due to the customer trying to cheat the merchant, and as such this kind of detection is useful to create real consequences to such behavior.
The proof will become more useful as more nodes implement and/or forward it over the peer to peer network. Other node operators have shown a real interest in doing so. As a benchmark a minimum 12.5% of the nodes forwarding these proofs will be enough to make this robust.
Naturally, merchants using Flowee will likely not need this proof as Flowee will detect almost all double spends without it just fine.
Bitcore is a product from BitPay and it is known to be slow to setup and hard to maintain. It is a historically important component, however, and there are quite some tools that use it.
In Flowee we now ship a bitcore-proxy. This component doesn’t hold any data, and thus is trivial to setup. For its data it uses already running the Hub and Indexer services.
Docker Containers documentation
As we add more containers, the documentation becomes more important. For that reason a new article is started on the website that detail how to use and setup your Flowee services.
This doc can be found here: https://flowee.org/docs/deployment/.