Age | Commit message (Collapse) | Author |
|
FastMod
9aac9f90d5e56752cc6cbfac48063ad29a01143c replace modulus with FastMod (Martin Ankerl)
Pull request description:
Not sure if this is optimization is necessary, but anyway I have some spare time so here it is. This replaces the slow modulo operation with a much faster 64bit multiplication & shift. This works when the hash is uniformly distributed between 0 and 2^32-1. This speeds up the benchmark by a factor of about 1.3:
```
RollingBloom, 5, 1500000, 3.73733, 4.97569e-07, 4.99002e-07, 4.98372e-07 # before
RollingBloom, 5, 1500000, 2.86842, 3.81630e-07, 3.83730e-07, 3.82473e-07 # FastMod
```
Be aware that this changes the internal data of the filter, so this should probably
not be used for CBloomFilter because of interoperability problems.
Tree-SHA512: 04104f3fb09f56c9d14458a6aad919aeb0a5af944e8ee6a31f00e93c753e22004648c1cd65bf36752b6addec528d19fb665c27b955ce1666a85a928e17afa47a
|
|
b0d2ca9fb66d793e3c0f2e6ede811f1b16c33a9f wallet: Exit SyncMetaData if there are no transactions to sync (Wladimir J. van der Laan)
Pull request description:
Instead of crash with an assertion error, simply exit the function `SyncMetaData` if there is no metadata to sync.
Fixes #13110.
Tree-SHA512: 44c4789497b5b63963bef66d8b695987dde80764199f6ea0f2c974be19d29c2663f32446a663a2ee9029e143e5d1d9e8a591e52e6e7e795b982782626bec25bb
|
|
2e7513471 fixup! ui: Support wallets loaded dynamically (João Barbosa)
0e674ba55 ui: Support wallets loaded dynamically (João Barbosa)
1c8fe0bf9 ui: Remove unnecessary variable fFirstWallet (João Barbosa)
Pull request description:
Add support in the UI for wallets loaded dynamically.
Tree-SHA512: 4016d61580b31e28c49861b1cb0e77fac5417f9676a6ce6156be28cb6059fdf3d3dd4d57dbbc22a574ad428c2a4a3702aedca596a84e644ce148e1084feb29c9
|
|
c722f00a7 [qt] Added satoshi unit "Satoshi (sat)" will be displayed in dropdowns and status bars. "sat" will be used when appended to numbers. (GreatSock)
4ddbcbf8c [qt] BitcoinUnits::format with zero decimals Formatting with zero decimals will now result in 123 instead of 123.0 (GreatSock)
Pull request description:
This adds satoshi as an additional amount unit for the GUI.
Tree-SHA512: c166c96c9a434b6ac700e1628e54f2dbb132c5232d949c0b464f61276a91d56f9bab4a62d50780535f1d34eaac6484f693a1e0611cd7c9d1ed5ebee066c0dd08
|
|
|
|
Instead of crash with an assertion error, simply exit the function
`SyncMetaData` if there is no metadata to sync.
Fixes #13110.
|
|
84f41946b9 break circular dependency: random/sync -> util -> random/sync (Chun Kuan Lee)
Pull request description:
LogPrintf has acutally been moved to logging.h
Tree-SHA512: a7135f5fea421e62f010f2e434873bd1c1738f115453377dada7d24900b3b095535d8aa0462c3acffdacf2f4e819e05ad39b13f2de5a36ac8f7b8467c639a0db
|
|
"Satoshi (sat)" will be displayed in dropdowns and status bars.
"sat" will be used when appended to numbers.
|
|
Formatting with zero decimals will now result in 123 instead of 123.0
|
|
|
|
|
|
- "Bech32" isn't very user-friendly
- You don't spend from addresses
|
|
|
|
|
|
cd53981 [docs] Add release notes for `loadwallet` RPC. (John Newbery)
a46aeb6 [wallet] [tests] Test loadwallet (John Newbery)
5d15260 [wallet] [rpc] Add loadwallet RPC (John Newbery)
876eb64 [wallet] Pass error message back from CWallet::Verify() (John Newbery)
e0e90db [wallet] Add CWallet::Verify function (John Newbery)
470316c [wallet] setup wallet background flushing in WalletInit directly (John Newbery)
59b87a2 [wallet] Fix potential memory leak in CreateWalletFromFile (John Newbery)
Pull request description:
Adds a `loadwallet` RPCs. This allows wallets to be loaded dynamically during runtime without having to stop-start the node with new `-wallet` params.
Includes functional tests and release notes.
Limitations:
- currently this functionality is only available through the RPC interface.
- wallets loaded in this way will not be displayed in the GUI.
Tree-SHA512: f80dfe32b77f5c97ea3732ac538de7d6ed7e7cd0413c2ec91096bb652ad9bccf05d847ddbe81e7cd3cd44eb8030a51a5f00083871228b1b9b0b8398994f6f9f1
|
|
dd435ad Add unit tests for signals generated by ProcessNewBlock() (Jesse Cohen)
a3ae8e6 Fix concurrency-related bugs in ActivateBestChain (Jesse Cohen)
ecc3c4a Do not unlock cs_main in ABC unless we've actually made progress. (Matt Corallo)
Pull request description:
Originally this PR was just to add tests around concurrency in block validation - those tests seem to have uncovered another bug in ActivateBestChain - this now fixes that bug and adds tests.
ActivateBestChain (invoked after a new block is validated) proceeds in steps - acquiring and releasing cs_main while incrementally disconnecting and connecting blocks to sync to the most work chain known (FindMostWorkChain()). Every time cs_main is released the result of FindMostWorkChain() can change - but currently that value is cached across acquisitions of cs_main and only refreshed when an invalid chain is explored. It needs to be refreshed every time cs_main is reacquired. The test added in https://github.com/bitcoin/bitcoin/pull/13023/commits/6094ce73045fe0b4654ff94327c2059512af88fb will occasionally fail without the commit fixing this issue https://github.com/bitcoin/bitcoin/pull/13023/commits/26bfdbaddbb9f13864deb7241c6d513f22c5ab62
Original description below
--
After a bug discovered where UpdatedBlockTip() notifications could be triggered out of order (#12978), these unit tests check certain invariants about these signals.
The scheduler test asserts that a SingleThreadedSchedulerClient processes callbacks fully and sequentially.
The block validation test generates a random chain and calls ProcessNewBlock from multiple threads at random and in parallel. ValidationInterface callbacks verify that the ordering of BlockConnected BlockDisconnected and UpdatedBlockTip events occur as expected.
Tree-SHA512: 4102423a03d2ea28580c7a70add8a6bdb22ef9e33b107c3aadef80d5af02644cdfaae516c44933924717599c81701e0b96fbf9cf38696e9e41372401a5ee1f3c
|
|
The new `loadwallet` RPC method allows an existing wallet to be loaded
dynamically at runtime.
`unloadwallet` and `createwallet` are not implemented. Notably,
`loadwallet` can only be used to load existing wallets, not to create a
new wallet.
|
|
Pass an error message back from CWallet::Verify(), and call
InitError/InitWarning from WalletInit::Verify().
This means that we can call CWallet::Verify() independently from
WalletInit and not have InitErrors printed to stdout. It also means that
the error can be reported to the user if dynamic wallet load fails.
|
|
This allows a single wallet to be verified. Prior to this commit, all
wallets were verified together by the WalletInit::Verify() function at
start-up.
Individual wallet verification will be done when loading wallets
dynamically at runtime.
|
|
After a recent bug discovered in callback ordering in MainSignals,
this test checks invariants in ordering of
BlockConnected / BlockDisconnected / UpdatedChainTip signals
|
|
|
|
WalletInit::Start calls postInitProcess() for each wallet. Previously
each call to postInitProcess() would attempt to schedule wallet
background flushing.
Just start wallet background flushing once from WalletInit::Start().
|
|
Fix proposed by ryanofsky in
https://github.com/bitcoin/bitcoin/pull/12647#discussion_r174875670
|
|
guarded by m_cs_callbacks_pending
244f4baf0f scheduler: Add Clang thread safety annotations for variables guarded by m_cs_callbacks_pending (practicalswift)
Pull request description:
Add Clang thread safety annotations for variables guarded by `m_cs_callbacks_pending`.
Tree-SHA512: 5c4aa14d1918ff119f945084820f7c1c5618e2a38d8bea8ebbfa6acddbccdacfea81fa61f1f796f8b1fcf57f5e3112da63b9bd0fa97fc9a9ef427fc361945e02
|
|
60f61f9 Tighten up bech32::Decode(); add tests. (murrayn)
Pull request description:
Just a few minor optimizations to bech32::Decode():
1) optimize the order and logic of the conditionals
2) get rid of subsequent '(c < 33 || c > 126)' check which is redundant (already performed above)
3) add a couple more bech32 tests (mixed-case)
Tree-SHA512: e41af834c8f6b7d34c22c28b724df42c60f72e00df616e70a12efbc4271d15d80627fe1bc36845caf29f615c238499a566298a863cbe119fef457287231053c8
|
|
chain.h does not actually depend on the methods defined in pow.h, just its
include of consensus/params.h, which is standalone and can be included instead.
Confirmed by inspection and successful build.
|
|
f08a385590 [qt]: changes sendcoinsdialog's box layout for improved readability. (marcoagner)
Pull request description:
I'm addressing two (probably duplicate) issues: https://github.com/bitcoin/bitcoin/issues/11606 and https://github.com/bitcoin/bitcoin/issues/10613.
Some points worth noting:
- I've tried to balance the proposed changes on both issues without going too far and remaining a bit conservative. It will be easier to improve based on suggestions where necessary.
- I preferred to maintain a layout that doesn't ask for an address truncation because, in my view, this wallet should be conservative on this.
- I didn't follow the idea of aligning the amounts to the right for finding it more natural (and minimalist) to read the information without having to map alignments. Additionally, that approach seems to need more `<hr />`'s (or similar) in order to help the user to map information, which ended up cluttering the box too much (specially with multiple recipients). Thus, I preferred to just give some more space between recipients. Let me know if there are better ideas on this.
Visually, I went from this (current):
![screenshot from 2018-05-03 15-11-30](https://user-images.githubusercontent.com/5016303/39581859-16abec82-4edc-11e8-86d3-eb722f8a7ed6.png)
To this:
![screenshot from 2018-05-03 15-15-41](https://user-images.githubusercontent.com/5016303/39582066-96856adc-4edc-11e8-804c-468aec44cc8d.png)
As a side note, while doing this, I thought about a better way to show fees and found there's already a PR on this (https://github.com/bitcoin/bitcoin/pull/12189) and thought it is
Tree-SHA512: e94b740fab6c1babd853a97be65c3b6f86ec174c975a926fde66b147f7a47e0cf0fa10f7255ba92aaba68c76a80dde8c688008179a34705a9799bf24d3c5cd46
|
|
159c32d1f1 Add assertion to guide static analyzers. Clang Static Analyzer needs this guidance. (practicalswift)
fd447a6efe Fix dead stores. Values were stored but never read. Limit scope. (practicalswift)
Pull request description:
Fix Clang Static Analyzer warnings reported by @kallewoof in #12961:
* Fix dead stores. Values were stored but never read.
* Add assertion to guide static analyzers. See #12961 for details.
Tree-SHA512: 83dbec821f45217637316bee978e7543f2d2caeb7f7b0b3aec107fede0fff8baa756da8f6b761ae0d38537740839ac9752f6689109c38a4b05c0c041aaa3a1fb
|
|
2352aa9 test: Ensure that recursive -includeconf produces appropriate warnings (Karl-Johan Alm)
c5bcc7d util: warn about recursive -includeconf arguments in configuration files (Karl-Johan Alm)
Pull request description:
This is a follow-up PR to #10267, and addresses https://github.com/bitcoin/bitcoin/pull/10267#issuecomment-387546144.
~~I am adding extra work for @jnewbery in #12755 here -- maybe I should just rebase on top of that, but not sure what the appropriate approach is here.~~
Tree-SHA512: 87f0c32436b70424e33616ffb88d7cb699f90d6a583a10237e224b28fc936d6a9df95536c8c52ee8546b3942da92b2a357e61bf87e00d1462bc10d46d3bee352
|
|
CTxMemPool::setSanityCheck(…)
47782b49e6 Add Clang thread safety analysis annotations (practicalswift)
0e2dfa8a65 Fix missing locking in CTxMemPool::setSanityCheck(double dFrequency) (practicalswift)
6bc5b7100b Fix missing locking in CTxMemPool::check(const CCoinsViewCache *pcoins) (practicalswift)
Pull request description:
Fix missing locking in `CTxMemPool::check(const CCoinsViewCache *pcoins)`:
* reading variable `mapTx` requires holding mutex `cs`
* reading variable `mapNextTx` requires holding mutex `cs`
* reading variable `nCheckFrequency` requires holding mutex `cs`
Fix missing locking in `CTxMemPool::setSanityCheck(double dFrequency)`:
* writing variable `nCheckFrequency` requires holding mutex `cs`
Tree-SHA512: ce7c365ac89225223fb06e6f469451b121acaa499f35b21ad8a6d2a266c91194639b3703c5428871be033d4f5f7be790cc297bd8c25b2e0c59345ef09c3693d0
|
|
guarded by cs_db
56921f9369 wallet: Add Clang thread safety annotations for variables guarded by cs_db (practicalswift)
Pull request description:
Add Clang thread safety annotations for variables guarded by `cs_db`.
Tree-SHA512: d59723598e918143f36408b4f49d31138b5d8968ba191472f6a207a63af147627f21e48fd6cc1606dd901d8a58183271e65ea4346a380db3c09e404764a28063
|
|
9e49db2 Make --enable-debug to pick better options (Evan Klitzke)
Pull request description:
Cherry-picked (and rebased) 94189645e67f364c4445d62e2b00c282d885cbbf from the "up for grabs" PR: "[build] Make --enable-debug pick better options" (#12695).
See previous review in #12695.
Tree-SHA512: a93cdadcf13e2ef8519acb1ce4f41ce95057a388347bb0a86a5c164dc7d0b0d14d4bb2a466082d5a100b8d50de65c605c40abaed555e8ea77c99e28800a34439
|
|
locking assertions
66b0b1b2a6 Add compile time checking for all cs_wallet runtime locking assertions (practicalswift)
Pull request description:
Add compile time checking for `cs_wallet` runtime locking assertions.
This PR is a subset of #12665. The PR was broken up to make reviewing easier.
The intention is that literally all `EXCLUSIVE_LOCKS_REQUIRED`/`LOCKS_EXCLUDED`:s added in this PR should follow either directly or indirectly from `AssertLockHeld(…)`/`AssertLockNotHeld(…)`:s already existing in the repo.
Consider the case where function `A(…)` contains `AssertLockHeld(cs_foo)` (without
first locking `cs_foo` in `A`), and that `B(…)` calls `A(…)` (without first locking `cs_main`):
* It _directly_ follows that: `A(…)` should have an `EXCLUSIVE_LOCKS_REQUIRED(cs_foo)` annotation.
* It _indirectly_ follows that: `B(…)` should have an `EXCLUSIVE_LOCKS_REQUIRED(cs_foo)` annotation.
Tree-SHA512: d561d89e98a823922107e56dbd493f0f82e22edac91e51e6422f17daf2b446a70c143b7b157ca618fadd33d0ec63eb7a57dde5a83bfdf1fc19d71459b43e21fd
|
|
b6f0b4d wallet: Improve logging when BerkeleyDB environment fails to close (Tim Ruffing)
264c643 wallet: Reset BerkeleyDB handle after connection fails (Tim Ruffing)
Pull request description:
According to the BerkeleyDB docs, the DbEnv handle may not be accessed
after close() has been called. This change ensures that we create a new
handle after close() is called. This avoids a segfault when the first
connection attempt fails and then a second connection attempt tries to
call open() on the already closed DbEnv handle.
Without the patch, bitcoindd reliably crashes in the second call to `set_lg_dir()` after `close()` if
there is an issue with the database:
```
2018-05-03T13:27:21Z Bitcoin Core version v0.16.99.0-a024a1841-dirty (debug build)
[...]
2018-05-03T13:27:21Z Using wallet directory /home/tim/.bitcoin
2018-05-03T13:27:21Z init message: Verifying wallet(s)...
2018-05-03T13:27:21Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2018-05-03T13:27:21Z Using wallet wallet.dat
2018-05-03T13:27:21Z BerkeleyEnvironment::Open: LogDir=/home/tim/.bitcoin/database
2018-05-03T13:27:21Z BerkeleyEnvironment::Open: Error -30974 opening database environment: DB_RUNRECOVERY: Fatal error, run database recovery
2018-05-03T13:27:21Z Moved old /home/tim/.bitcoin/database to /home/tim/.bitcoin/database.1525354041.bak. Retrying.
2018-05-03T13:27:21Z BerkeleyEnvironment::Open: LogDir=/home/tim/.bitcoin/database ErrorFile=/home/tim/.bitcoin/db.log
[1] 14533 segmentation fault (core dumped) ./src/bitcoind
```
After the fix:
```
2018-05-03T17:19:32Z Bitcoin Core version v0.16.99.0-cc09e3bd0-dirty (release build)
[...]
2018-05-03T17:19:32Z Using wallet directory /home/tim/.bitcoin
2018-05-03T17:19:32Z init message: Verifying wallet(s)...
2018-05-03T17:19:32Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2018-05-03T17:19:32Z Using wallet wallet.dat
2018-05-03T17:19:32Z BerkeleyEnvironment::Open: LogDir=/home/tim/.bitcoin/database ErrorFile=/home/tim/.bitcoin/db.log
2018-05-03T17:19:32Z scheduler thread start
2018-05-03T17:19:32Z BerkeleyEnvironment::Open: Error -30974 opening database environment: DB_RUNRECOVERY: Fatal error, run database recovery
2018-05-03T17:19:32Z Moved old /home/tim/.bitcoin/database to /home/tim/.bitcoin/database.1525367972.bak. Retrying.
2018-05-03T17:19:32Z BerkeleyEnvironment::Open: LogDir=/home/tim/.bitcoin/database ErrorFile=/home/tim/.bitcoin/db.log
2018-05-03T17:19:32Z Cache configuration:
2018-05-03T17:19:32Z * Using 2.0MiB for block index database
2018-05-03T17:19:32Z * Using 8.0MiB for chain state database
2018-05-03T17:19:32Z * Using 440.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2018-05-03T17:19:32Z init message: Loading block index..
[...]
```
Tree-SHA512: b809b318e5014ec47d023dc3dc40826b9706bfb211fa08bc2d29f36971b96caa10ad48d9a3f96c03933be46fa4ff7e00e952ac77bfffb6563767fb08aa4f23d6
|
|
|
|
cs_{rpcWarmup,nTimeOffset,warnings}
8499f15e67 Add Clang thread safety annotations for variables guarded by cs_warnings (practicalswift)
cf13ad23d4 Add Clang thread safety annotations for variables guarded by cs_nTimeOffset (practicalswift)
012dec0347 Add Clang thread safety annotations for variables guarded by cs_rpcWarmup (practicalswift)
Pull request description:
Add Clang thread safety annotations for variables guarded by `cs_{rpcWarmup,nTimeOffset,warnings}`.
Tree-SHA512: 8e0a4b9e36a4450bd75ad32c21d813bb572aaaa5b4a4cbdcbf4678e58ade6265c0b275352391168930a63fcbd09caa3b76e74595a7b14646054c52870c46d007
|
|
a8da482 Bump wallet version for pre split keypool (Andrew Chow)
dfcd9f3 Use a keypool of presplit keys after upgrading to hd chain split (Andrew Chow)
5c50e93 Allow -upgradewallet to upgradewallets to HD (Andrew Chow)
2bcf2b5 Test sethdseed (Andrew Chow)
b5ba01a Add 'sethdseed' RPC to initialize or replace HD seed (Chris Moore)
dd3c07a Separate HaveKey function that checks whether a key is in a keystore (Andrew Chow)
Pull request description:
Revival/rebase of #11085
Adds a new command `sethdseed` which allows you to either set or generate a new HD seed to be used. A new keypool can be generated or the original one kept and new keys added to the keypool will come from the new HD seed.
Wallets that are not HD will be upgraded to be version FEATURE_HD_SPLIT when the `sethdseed` RPC command is used.
I have also add some tests for this.
Additionally `-upgradewallet` can now be used to upgrade a wallet from non-HD to HD. When it is used for such an upgrade, the keypool will be regenerated.
Tree-SHA512: e56c792e150590429ac4a1061e8d6f7b20cca06366e184eb9bbade4cd6ae82699a28fe84f87031eadba97ad2c1606517a105f00fb7b45779c979243020071adb
|
|
reconsiderblock
11fa6bb66e Bugfix: ensure consistency of m_failed_blocks after reconsiderblock (Suhas Daftuar)
Pull request description:
This was introduced in 015a5258adffb0cf394f387a95ac9c8afc34cfc3 and could cause a node to crash (due to assertion failure) when using the `reconsiderblock` rpc.
Tree-SHA512: 820dcd761bf983e36f5d0f16777ed75c833daaf62a6b3a4dbd17f6caaf9287223e3a202d06540ac62f8ba72926b73b0873bb76c6273ddcb19d9408f4c1cd325e
|
|
Bump the wallet version to indicate support for the pre split keypool.
Also prevents any wallets from upgrading to versions between HD_SPLIT
and PRE_SPLIT_KEYPOOL.
|
|
After upgrading to HD chain split, we want to continue to use keys
from the old keypool. To do this, before we generate any new keys after
upgrading, we mark all of the keypool entries as being pre-chain
split and move them to a separate pre chain split keypool. Keys are
fetched from that keypool until it is emptied. Only then are the new
internal and external keypools used.
|
|
Changes the maximum upgradewallet version to the latest wallet version
number, 159900. Non-HD wallets will be upgraded to use HD derivation.
Non HD chain split wallets will be upgraded to HD chain split.
If a non-HD wallet is upgraded to HD, the keypool will be entirely
regenerated.
Since upgradewallet is effectively run during a first run, all of the
first run initial setup stuff is combined with the upgrade to HD
|
|
|
|
If multiple threads are invoking ActivateBestChain, it was possible to have
them working towards different tips, and we could arrive at a less work tip
than we should. Fix this by introducing a ChainState lock which must
be held for the entire duration of ActivateBestChain to enforce
exclusion in ABC.
|
|
Technically, some internal datastructures may be in an inconsistent
state if we do this, though there are no known bugs there. Still,
for future safety, its much better to only unlock cs_main if we've
made progress (not just tried a reorg which may make progress).
|
|
364bae5 qa: Pad scriptPubKeys to get minimum sized txs (MarcoFalke)
7485488 Policy to reject extremely small transactions (Johnson Lau)
0f8719b Add transaction tests for constant scriptCode (Johnson Lau)
9dabfe4 Add constant scriptCode policy in non-segwit scripts (Johnson Lau)
Pull request description:
This disables `OP_CODESEPARATOR` in non-segwit scripts (even in an unexecuted branch), and makes a positive `FindAndDelete` result invalid. This ensures that the `scriptCode` serialized in `SignatureHash` is always the same as the script passing to the `EvalScript`.
Tree-SHA512: a0552cb920294d130251c48053fa2ff1fbdd26332e62b52147d918837852750f0ce35ce2cd1cbdb86588943312f8154ccb4925e850dbb7c2254bc353070cd5f8
|
|
Since -includeconf cannot be used recursively, the user would not see feedback that an -includeconf
in an -includeconf'd file was silently ignored.
|
|
gArgs knows what the available arguments are and their help. Getting
the help message is moved to gArgs and HelpMessage() is removed
|
|
a2f678d Bugfix: the end of a reorged chain is invalid when connect fails (Pieter Wuille)
Pull request description:
Introduced in 4e0eed88acdd41826868c151373068bfad18b84d
When an invalid block is found during a reorg, we know the last of the blocks in the was-to-be-connected chain is invalid, but not necessarily the first. As `vpIndexToConnect` is ordered in decreasing height, the end of the reorg is the front of the vector, and not the back.
This only affected the warning system.
Tree-SHA512: ddf749f8a78083811a5a17152723f545c1463768d09dc9832ec3682e803a3c106fb768de9fa91c03aa95e644d4e41361a7e4ee791940fd7d51cdefea90de31fc
|
|
|
|
|