- There is a new signal called TxToMemPool
- This signal will connect to the bindings slot, queueTx
- When a tx is accepted into the memory pool, the tx will be queued and the tx_notifier will be scheduled
- The ProcessMessages signal was scheduling/connecting its slots slightly out of order for what we need
- First, the scan_messages needs to run and copy out the stream
- Second, Bitcoin's ProcessMessages needs to run in order to run AcceptToMemoryPool
- Third, scan_messages_after needs to run in order to signal our tx_monitor
- In order to make this happen, we need to pair ProcessMessages slot to the scan_messages slot and order that
- Then, AFTER those two complete, we can schedule scan_messages_after
- There is a comments section that can be used in the FormatSubVersion string for the user agent that is exchanged between peers
- The comments section allows arbitrary strings to be added per the client
- This is the most appropriate place to include the bitcore-node message
- A string similar to: "/Satoshi:0.11.0(bitcorenode)/" will be passed as a response to getpeerinfo or getnetworkinfo
- Removed the platform directory
- renamed the platform/os.sh script to varaibles.sh
- realigned the calls to os.sh
- changed where the patch_ha.txt was being written to
- changed the name of the binary to bitcoind.node
- when performing nom install (which calls build-libbitcoind), the diff from PATCH_VERSION is taken and compared to what's in etc/bitcoin.patch. If there are differences, then the user is asked if they would like to re-patch with what's in etc/bitcoin.patch or not.
- using ASSUME_YES=true env variable will allow the patch to be replaced automatically without user intervention
- Answering anything but 'y' or 'Y' will leaving the user's libbitcoind alone.
2. Updated bindings to cover the changes to bitcoin
3. Added some file matchers to gitignore for Qt Creator
4. Fixed platform lib path for Mac OS X
5. Removed unneeded methods in bindings (they will be re-added later
