Sapling address encodings
This PR enables Sapling keys and addresses to be passed in anywhere Sprout keys
and addresses are used. Doing so will cause crashes until those places are updated
with Sapling support.
Includes code cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#11167
- Only the `ConvertBits()` function.
- bitcoin/bitcoin#11630
Closes#3058.
Bech32 encoding support
Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#8578
- bitcoin/bitcoin#11167
- Only the second and third commits (first is in #3228, fourth depends on #2390, later ones are SegWit-specific).
- bitcoin/bitcoin#12757
- Only the change to `src/bech32.h`
Part of #3058.
Continues Johnathan Corgan's work.
Publishing multipart messages
Bugfix: Add missing zmq header includes
Bugfix: Adjust build system to link ZeroMQ code for Qt binaries
Fix issue #717 t
Fix issue #717 where if addrman is starved of addresses (e.g. on testnet)
the Select_() function will loop endlessly trying to find an address,
and therefore eat up 100% cpu time on the 'opencon' thread.
Solution is to (1) add a delay to the loop and (2) restrict the number
of attempts to find an address. On exiting the loop, we return
to an outer loop in net.cpp which will sleep, add seed nodes and
calculate new addresses.
Adds several unittests for addrman to verify it works as expected.
Makes small modifications to addrman to allow deterministic and targeted tests.
Signed-off-by: Simon <simon@bitcartel.com>
This is a new implementation of the incremental merkle tree used by our
scheme to witness commitments to spendable value. It serves as a fixed-sized
accumulator.
This new construction has a much simpler API surface area, avoids memory
safety issues, remains pruned at all times, avoids serialization edge cases,
has more efficient insertion, and is abstract over the depth and hash
function used at the type level.
Further, it lays the groundwork for efficient "fast-forwarding" of witnesses
into the tree as the treestate is updated.
This class groups transactions that have been confirmed in blocks into buckets, based on either their fee or their priority. Then for each bucket, the class calculates what percentage of the transactions were confirmed within various numbers of blocks. It does this by keeping an exponentially decaying moving history for each bucket and confirm block count of the percentage of transactions in that bucket that were confirmed within that number of blocks.
-Eliminate txs which didn't have all inputs available at entry from fee/pri calcs
-Add dynamic breakpoints and tracking of confirmation delays in mempool transactions
-Remove old CMinerPolicyEstimator and CBlockAverage code
-New smartfees.py
-Pass a flag to the estimation code, using IsInitialBlockDownload as a proxy for when we are still catching up and we shouldn't be counting how many blocks it takes for transactions to be included.
-Add a policyestimator unit test
This fixes a subtle bug involving block re-orgs and non-standard transactions.
Start with a block containing a non-standard transaction, and
one or more transactions spending it in the memory pool.
Then re-org away from that block to another chain that does
not contain the non-standard transaction.
Result before this fix: the dependent transactions get stuck
in the mempool without their parent, putting the mempool
in an inconsistent state.
Tested with a new unit test.
Split GetNextWorkRequired() into two functions to allow the difficulty calculations to
be tested without requiring a full blockchain.
Add unit tests to cover basic difficulty calculation, plus each of the min/max actual
time, and maximum difficulty target conditions.
Chethan Krishna
Braydon Fuller
Jonas Schnelli
Homu
Jay Graber
Jack Grigg
Sean Bowe
Pieter Wuille
Jeff Garzik
James O'Beirne
Cory Fields
Daira Hopwood
Simon
Karl-Johan Alm
Jonas Schnelli
Jeff Garzik
zkbot
EthanHeilman
Alfie John
Taylor Hornby
Nathan Wilcox
Casey Rodarmor
Gavin Andresen
Wladimir J. van der Laan
Alex Morcos
Ross Nicoll