We wait until the chain is synched and then we check for and broadcast
unconfirmed transactions.
This essentially means that every single block we receive will trigger
this code. In BCH I think that is just fine since all we really do is
send an INV.
When a transaction is received by the p2pnet layer via a simple INV/
GetData we now process this and properly lock the outputs it spent to
avoid creating double spending transactions.
One task is left: properly recognize when a mined transaction
invalidates another transaction (like an unconfirmed one) and update the
datastructures.
This provides code for creating the transaction, selecting the UTXOs and
signing the transaction.
Essentially everything except the handling of final tx (like sending it
to a peer).
For maintainability the pair of tx-index/output-index are now stored in
a simple class.
Additionally the calls to the privacyFilter have been upgraded to follow
the API fix in Flowee the Hub.
This is clearly beta-level quality, it won't lose your money, but
kittens can be killed if you use this in production! Don't do that!
This payment client uses the proper P2P client and does not require
any additional indexing services and therefor is very much geared
towards the most private it can be with SPV, while staying scalable and
nible.
The only GUI available right now is for the desktop, it should be pretty
simple to re-do a nice GUI for some mobile or similar form-factors.
That is one area that QML simply rocks in.
TomZ