Simon [Wed, 7 Nov 2018 01:33:27 +0000 (17:33 -0800)]
For ZEC-013. Don't propagate txs which are expiring soon in p2p messages.
When responding to "mempool" message, do not include the txid of an
expiring soon transaction in the "inv" message reply.
When responding to "getdata" message, do not reply with a "tx" message
for a transaction which is expiring soon.
Simon [Mon, 5 Nov 2018 18:24:20 +0000 (10:24 -0800)]
For ZEC-013. Mitigate potential tx expiry height related DoS vector.
Don't accept transactions which are about to expire (next 3 blocks).
Don't set a ban score if a peer does propragate these transactions.
See ZEC-013 for more detail.
Homu [Sat, 17 Nov 2018 05:07:46 +0000 (21:07 -0800)]
Auto merge of #3684 - str4d:load-sapling-chain-value, r=bitcartel
Load sapling chain value into memory
`CBlockIndex::nSaplingValue` has been correctly set and written to disk since before Sapling activated, meaning that all nodes now are correctly tracking the Sapling shielded pool value on-disk. However, on restart the per-block values are not being read into memory, and so the in-memory pool value appears to be zero on every restart. Setting `nSaplingValue` in-memory during block index loading fixes the problem.
Homu [Thu, 15 Nov 2018 20:34:11 +0000 (12:34 -0800)]
Auto merge of #3669 - charlieok:init_win_networking_in_test_setup, r=str4d
Add a call to SetupNetworking in BasicTestingSetup
In issue https://github.com/zcash/zcash/issues/3668 , the error code returned by `getaddrinfo_a` (10093) is `WSANOTINITIALISED`:
> Successful WSAStartup not yet performed. Either the application has not called WSAStartup or WSAStartup failed. The application may be accessing a socket that the current active task does not own (that is, trying to share a socket between tasks), or WSACleanup has been called too many times.
`WSAStartup` is called from the `SetupNetworking` function in `util.cpp`, but `SetupNetworking` was not being called during test setup. This pull request adds that call.
Here is a gitlab pipeline running tests in the `test_bitcoin.exe` executable before this change:
https://gitlab.com/charlieok/zcash/pipelines/36483478
...and here is the same set of tests run after this change:
https://gitlab.com/charlieok/zcash/pipelines/36485098
Homu [Thu, 15 Nov 2018 05:48:35 +0000 (21:48 -0800)]
Auto merge of #3585 - str4d:merkle-tree-test-vectors, r=bitcartel
Update IncrementalMerkleTree test vectors to use valid commitments
The original commitments were SHA256 outputs, and some were outside the
scalar field. This didn't affect the Merkle hash, which drops the high
bit from each commitment, but it does affect the creation of the Merkle
path in Rust, which requires path nodes to be valid scalars.
Here, we explicitly drop the high bit of all test vector commitments,
as well as reducing the two that remain outside the field. The test
vectors still pass, and can now also be used in the Rust implementation.
Homu [Wed, 7 Nov 2018 14:41:28 +0000 (06:41 -0800)]
Auto merge of #3649 - garethtdavies:3648-correct-param-size, r=daira
Add clarifying text for parameter size
Addresses #3648.
Parameter size was previously specified to the nearest MB so not sure if 1.7GB/800MB is not specific enough? The true figures on disk are 1647MB and 777MB.
Homu [Fri, 2 Nov 2018 19:58:24 +0000 (12:58 -0700)]
Auto merge of #3654 - charlieok:save_and_restore_current_path, r=daira
Save and restore current_path in TestingSetup constructor/destructor
In issue https://github.com/zcash/zcash/issues/3653 , the affected tests change their current working directory to a temporary directory that is created in the TestingSetup constructor and deleted in the destructor. In Windows it seems to cause a problem when a process attempts to delete its current working directory.
This change fixes the issue by saving the path of the current working directory in the constructor, and restoring the working directory to that path in the destructor before deleting the temporary directory.
Jack Grigg [Sat, 27 Oct 2018 04:03:47 +0000 (17:03 +1300)]
Migrate to current librustzcash
The only upstream change relative to the previous commit is that the
various Zcash-specific dependencies have been pulled into a cargo
workspace. The dependecies in the workspace use the same commits as the
crates we had previously vendored.
The patches are necessary to handle the fact that cargo requires that
dev dependencies are available even if not used, and we would otherwise
need to vendor all the underlying crates.
Will produce essentially the following error:
```
Assertion failed: Misspelling detected; expected: <Embarassment> but was: <Embarrassment>
File "/home/eirik/Development/zcash/qa/rpc-tests/test_framework/test_framework.py", line 121, in main
self.run_test()
File "/home/eirik/Development/zcash/qa/rpc-tests/test_spelling.py", line 13, in run_test
```
Which is misleading because the item on the left is not what is actually expected.
This PR changes the assertion failure to be displayed as:
```
Assertion failed: (left == right); Misspelling detected
left: <Embarassment>
right: <Embarrassment>
File "/home/eirik/Development/zcash/qa/rpc-tests/test_framework/test_framework.py", line 121, in main
self.run_test()
File "/home/eirik/Development/zcash/qa/rpc-tests/test_spelling.py", line 13, in run_test
```
Homu [Tue, 23 Oct 2018 05:36:05 +0000 (22:36 -0700)]
Auto merge of #3581 - Eirik0:3580-unspent-note-cleanup, r=daira
Remove GetUnspentFilteredNotes
Closes #3580
This PR generalized `GetFilteredNotes`, expanding its functionality to also do what we do in `GetUnspentFilteredNotes`. This enables us to remove the latter.
Homu [Fri, 19 Oct 2018 02:47:46 +0000 (19:47 -0700)]
Auto merge of #3579 - Eirik0:3577-generate-sprout-zkey, r=bitcartel
Make it clear that CWallet::GenerateNewZKey is Sprout specific
Closes https://github.com/zcash/zcash/issues/3577
When adding sapling support we had considered making the method `GenerateNewZKey` generic, but it ended up making more sense to add a second method `GenerateNewSaplingZKey` for sapling support.
This PR changes the name of `GenerateNewZKey` to `GenerateNewSproutZKey` and changes the return type from `libzcash::PaymentAddress` to `libzcash::SproutPaymentAddress` to make it more clear that this is what the method does.
Homu [Thu, 18 Oct 2018 22:36:34 +0000 (15:36 -0700)]
Auto merge of #3541 - leto:amount_docs, r=bitcartel
Clarify in sendmany/z_sendmany rpc docs that amounts are not FP
Fixes #3539
I clarified in the docs that only 8 digits of precision are allowed. For example, if you try 9 digits you will get:
```
zcash-cli z_sendmany $TADDR "[{\"address\":\"$ZADDR\",\"amount\":0.123456789}]"
error code: -3
error message:
Invalid amount
```
Homu [Fri, 12 Oct 2018 22:30:34 +0000 (15:30 -0700)]
Auto merge of #3592 - Eirik0:z-sendmany-better-error, r=bitcartel
Better error message when sending to both sprout and sapling
When trying to send to both Sprout and Sapling (not currently supported with z_sendmany) we were getting the following error in our operation result: `general exception: boost::bad_get: failed value get using boost::get`.
This PR changes this to fail with a better error message before the async operation begins:
```
error code: -8
error message:
Cannot send to both Sprout and Sapling addresses using z_sendmany
```
Homu [Fri, 12 Oct 2018 17:30:17 +0000 (10:30 -0700)]
Auto merge of #3590 - bitcartel:fix_nullifier_persistence, r=bitcartel
Resolves Sapling nullifier persistence issue when importing a key.
During a rescan, a CWalletTx was persisted to disk before it had its
note data set. This meant that upon restart, the CWalletTx would
potentially be missing its nullifiers causing the balance to include
notes which had already been spent.
The resolution is to force a CWalletTx to be persisted after it has had
its nullifiers set correctly, before the note witnesses are updated.
Simon [Fri, 12 Oct 2018 04:25:53 +0000 (21:25 -0700)]
Resolves Sapling nullifier persistence issue when importing a key.
During a rescan, a CWalletTx was persisted to disk before it had its
note data set. This meant that upon restart, the CWalletTx would
potentially be missing its nullifiers causing the wallet's balance
to include notes which had already been spent.
The resolution is to ensure that after a rescan, a CWalletTx is
persisted after it has had its nullifiers set correctly.
Jack Grigg [Wed, 10 Oct 2018 19:54:55 +0000 (20:54 +0100)]
Update IncrementalMerkleTree test vectors to use valid commitments
The original commitments were SHA256 outputs, and some were outside the
scalar field. This didn't affect the Merkle hash, which drops the high
bit from each commitment, but it does affect the creation of the Merkle
path in Rust, which requires path nodes to be valid scalars.
Here, we explicitly drop the high bit of all test vector commitments,
as well as reducing the two that remain outside the field. The test
vectors still pass, and can now also be used in the Rust implementation.
projects / VerusCoin.git / log