Current: Set key pool size to <n> (default: %u),
New maybe something like: Set key pool size to <n> (default: %u, does not refill keypool if wallet already exists).
Current: Set key pool size to <n> (default: %u),
New maybe something like: Set key pool size to <n> (default: %u, does not refill keypool if wallet already exists).
Bump version from 0.11.99 to 0.12.0 so that we don't forget to do this
when rc1 is released.
Rebased-From: b4404090259be4e34ef5dba33e47a41e7d9acc03
Github-Pull: #7152
Mempool requests use a fair amount of bandwidth when the mempool is large,
disconnecting peers using them follows the same logic as disconnecting
peers fetching historical blocks.
Rebased-From: 6aadc7557823b7673b8f661b3d41cf867e2936a3
Github-Pull: #7166
Github-Pull: #7133
Rebased-From: ec73ef37eccfeda76de55c4ff93ea54d4e69e1ec e20672479ef7f2048c2e27494397641d47a4d88d 6b849350ab074a7ccb80ecbef387f59e1271ded6 b6a0da45db8d534e7a77d1cebe382cd5d83ba9b8 d41e44c9accb3df84e0abbc602cc76b72754d382 aa4b0c26b0a94ca6164c441aae723e118554d214
Github-Pull: #7174
Rebased-From: 96918a2f0990a8207d7631b8de73af8ae5d24aeb
Remove necessity to call create_callback_map (as well as the function
itself) from the Python P2P test framework. Invoke the appropriate
methods directly.
- Easy to forget to call it and wonder why it doesn't work
- Simplifies the code
- This makes it easier to handle new messages in subclasses
Github-Pull: #7171
Rebased-From: 2f601d215da1683ae99ab9973219044c32fa2093
This is a combination of 3 commits.
- Coinselection prunes extraneous inputs from ApproximateBestSubset
A further pass over the available inputs has been added to ApproximateBestSubset after a candidate set has been found. It will prune any extraneous inputs in the selected subset, in order to decrease the number of input and the resulting change.
- Moved set reduction to the end of ApproximateBestSubset to reduce performance impact
- Added a test for the pruning of extraneous inputs after ApproximateBestSet
Github-Pull: #4906
Rebased-From: 5c03483e26ab414d22ef192691b2336c1bb3cb02 af9510e0374443b093d633a91c4f1f8bf5071292 fc0f52d78085b6ef97d6821fc7592326c2d9b495
Ever since we #5913 have been sending invalid reject messages
for transactions and blocks.
test: Add basic test for `reject` code
Extend P2P test framework to make it possible to expect reject
codes for transactions and blocks.
Github-Pull: #7179
Rebased-From: 9fc6ed6003da42f035309240c715ce0fd063ec03 20411903d7b356ebb174df2daad1dcd5d6117f79
- Avoids string typos (by making the compiler check)
- Makes it easier to grep for handling/generation of a certain message type
- Refer directly to documentation by following the symbol in IDE
- Move list of valid message types to protocol.cpp:
protocol.cpp is a more appropriate place for this, and having
the array there makes it easier to keep things consistent.
Github-Pull: #7181
Rebased-From: 9bbe71b641e2fc985daf127988a14a67c99da50a
Rebased-From: daf6466330d9d3e4d9034fd316cded192d2a7d67
Github-Pull: #7206
CWalletTx::GetAmounts could not find output address for null data transactions, thus issuing an error in debug.log. This change checks to see if the transaction is OP_RETURN before issuing error.
resolves #6142
Github-Pull: #7200
Rebased-From: b6915b82398d2e1d1f888b3816adfaf06d9a450e c611acc38a95d336a824b632823aa1b652e570df d812daf967ba4173bfa1c37eeb4ab7a0ccc4df25
We used to have a trickle node, a node which was chosen in each iteration of
the send loop that was privileged and allowed to send out queued up non-time
critical messages. Since the removal of the fixed sleeps in the network code,
this resulted in fast and attackable treatment of such broadcasts.
This pull request changes the 3 remaining trickle use cases by random delays:
* Local address broadcast (while also removing the the wiping of the seen filter)
* Address relay
* Inv relay (for transactions; blocks are always relayed immediately)
The code is based on older commits by Patrick Strateman.
Github-Pull: #7125
Rebased-From: 5400ef6bcb9d243b2b21697775aa6491115420f3
Github-Pull: #7216
Rebased-From: e18378e53fb71c39236db35ab2d560b43602b1be
In rpc-tests.py, don't override BITCOIND and BITCOINCLI if they're
already set. Makes it possible to run the tests with either another tree
or the GUI.
Github-Pull: #7209
Rebased-From: 83cdcbdca41583a5a754a89f45b04b56cd0df627
Bring dependencies up to date with master:
[depends] Boost 1.59.0
[depends] miniupnpc 1.9.20151026
[depends] native ccache 3.2.4
[depends] zeromq 4.0.7
[depends] Latest config.guess & config.sub
[depends] Fix miniupnpc compilation on osx
Github-Pull: #6980
Rebased-From: 9e940fa4c650dd31c39dbc8ed4038e131c19d59c 17ad964c2ff8f9be62a6826012b565843d3d72ba 26f8ea5342994bc3dcc22163b86f086328b50769 10d3c77644d894338a02b05f64ba822f3a516401 23a3c47f95c9c7c1778c488be6ea9ebbef2311ea e0769e1928f892fb16f851991d8e09a90587a1f4
1) Fix mempool limiting for PrioritiseTransaction
Redo the feerate index to be based on mining score, rather than fee.
Update mempool_packages.py to test prioritisetransaction's effect on
package scores.
2) Update replace-by-fee logic to use fee deltas
3) Use fee deltas for determining mempool acceptance
4) Remove GetMinRelayFee
One test in AcceptToMemoryPool was to compare a transaction's fee
agains the value returned by GetMinRelayFee. This value was zero for
all small transactions. For larger transactions (between
DEFAULT_BLOCK_PRIORITY_SIZE and MAX_STANDARD_TX_SIZE), this function
was preventing low fee transactions from ever being accepted.
With this function removed, we will now allow transactions in that range
with fees (including modifications via PrioritiseTransaction) below
the minRelayTxFee, provided that they have sufficient priority.
Github-Pull: #7062
Rebased-From: eb306664e786ae43d539fde66f0fbe2a3e89d910 9ef2a25603c9ec4e44c4f45c6a5d4e4386ec86d3 27fae3484cdb21b0d24face833b966fce5926be5 901b01d674031f9aca717deeb372bafa160a24af
I think you need to rebase against master or clean up your git history.
I'd prefer not putting the extra text in the parenthesis. It has nothing to do with the default and looks circuitous. Maybe:
Set key pool size. Passing this option does not trigger a keypool refill. (default: %u),
Also: pull requests should be against master, not 0.12
Github-Pull: #7226
Rebased-From: 9b41a5fba278e9ab56a9b86e7a5fe195dcad0b7a
The trigger for this issue was that I was use -keypool when the wallet.dat exist but there was no message at all that the wallet.dat was unchanged. It was only because I was monitor the size of wallet.dat that I was realise that notting happen. I error message will be nice a la: -keypool can not be use on a already existed wallet.dat. You can type keypoolrefill into the console (Help->Debug window->Console).
Right now notting happen at all. No message or warning to the user.
I am not sure about: Also: pull requests should be against master, not 0.12 Do I have to do more then change the subject?
The trigger for this issue was that I was use -keypool when the wallet.dat exist but there was no message at all that the wallet.dat was unchanged. It was only because I was monitor the size og wallet.dat that I was realise that notting happen. I error message will be nice a la: -keypool can not be use on a already existed wallet.dat. You can type keypoolrefill into the console (Help->Debug window->Console).
I understand, makes sense to add this statement.
I have to close this PR though, please create a new pull that starts from master instead of the 0.12 branch.
@bom64 https://www.google.com/#q=git+101 Might come in handy. ;)
Yes! :-) But more generel: User input have to be more easy.