The Future of Datapay

[breavyn]

WeatherSV Requirements

BitIndex API usage
We have paid api access for bitindex, and need to utilize an api key in datapay's requests. Although we were achieving this without any modification to datapay, I've decided to replace bitcore-explorers with simple requests using axios.

Reliability
WeatherSV is broadcasting transactions around the clock so reliability is a must. I've contributed patches here previously to improve error handling, but still it is hard to reason about due to use of callbacks. I've simplified the logic flow where possible, and used async/await, to make it clear that errors will bubble back out to the application.

Fees
Low fees are a must at the volume of transactions we're making. I've recently fixed the fee calculator in the bsv library, and updated datapay to utilize it. This patch also prevents change address outputs from being below the dust limit, so I've also removed datapay's dust filter.

Other Changes

Filtering
I did replace mingo with plain javascript functions for filtering inputs, because functions are more powerful, and to reduce dependencies. The disadvantage is, the transaction spec is no longer purely declarative. I'm unsure of the best approach here and it may be best to revert. It would be good to discuss, especially with consideration to the below points.

Please also note this PR still requires updates to the tests, examples, and docs before being suitable for merge.

---

Where to from here?

Datapay is essentially a declarative wrapper for creating bsv lib transactions, and includes the convenience of retrieving utxo's and broadcasting. It would be most beneficial for datapay to implement declarative properties for the remaining transaction features. This would allow for much more powerful key/fund management strategies to be developed. Though that may be out of the scope of datapay itself, we should at least allow the option.

change
A very simple addition, such as #15 makes it trivial to avoid address re-use.

from
The from attribute, would contain a list of inputs to be used. The user may be providing inputs from multiple addresses, or maintaining their own utxo state. This could be very useful for high throughput applications.

sign
An array of private keys that are used to sign the transaction, in the case that inputs from multiple addresses were used above.

Alternatively datapay could be considered complete for simple, single address, op_return usage with the changes in this PR. A new library that doesn't utilize datapay can be developed, focusing on advanced usage patterns.

[deanmlittle]

My thoughts: Datapay is more or less complete. It should remain a simple, declarative tool that doesn't require a database solution to work (though may choose to implement it with one if you wish). As a result, it necessarily requires some API lookups. This is perhaps not the solution we should be using for enterprise, as it is more efficient to handle UTXO management, as well as the signing and storing of transactions locally, then publish them in the order of their spends on a best-effort basis. I think change addresses and using bsv.js 0.30 to handle fee calculations is a no brainer (since we've each already implemented them) but any further development efforts for a more robust (and thus complex) system may be better served by forking or creating a new project. Thoughts?