zerocurrencycoin / zero Goto Github PK

Zero is unique in having its equihash params even now significantly harder than 144,5 that various coins are moving to. Nevertheless, let's keep track of the developments and maintain notes and links.

From Zcash team, switching params zcash#1211 (comment)
bitcartel@02397b6
https://github.com/BTCPrivate/BitcoinPrivate/pull/181

In anticipation of the hard fork, methods of controlling such behaviors within Zcash clones were reviewed.

The Zero fork will cover a number of changes, particularly how the miner block reward is computed, but also will adjust various parameters to improve resistance to various types of attacks. Nevertheless, new issues are likely to come up and we may find it necessary to tweak some of the changes, so a second fork may well take place before the year is out.

Nodes communicate to each other the feature sets they support via the initial exchange of Version information. Zcash inherited from Bitcoin some of the basic methods, like "version bits".

Around Zcash 1.0.15 was introduced a new system of tracking versions and activation height (block number), by creating struct NetworkUpgrade.
Files affected, not including a whole bunch of unit tests:

chainparams.h
chainparams.cpp
init.cpp
main.cpp
rpcblockchain.cpp
rpcrawtransaction.cpp
zcbenchmarks.cpp
consensus/params.h
consensus/upgrades.h
consensus/upgrades.cpp

ProtocolVersion values defined already:

BASE 170002
OVERWINTER 170005
SAPLING 170007
OVERWINTER nActivationHeight 347500

Clones have taken a simpler route and added specific fields directly to the consensus and ChainParams classes, say Snowgem consensus.nMasternodePaymentsStartBlock and newTimeRule eh_epoch_1_endblock. eh_epoch_2_startblock.
Files affected:

chainparams.h
chainparams.cpp
pow.cpp

BTCG similarly has added BTGZawyLWMAHeight and BTGEquihashForkHeight
Files affected:

chainparams.h
chainparams.cpp
pow.cpp
consensus/params.h

Disregard all the added complexity with versions and blocks that they have inherited from Bitcoin.
They do have test automation for the fork.

Zen has been forking since its split from Zclassic and keeps at it. They have created the most advanced system, where fork parametrization is externalized to a file, though a bunch of .CPP support is still necessary. Their case in a sense is closest to ours, as they have re-introduced the fee, after Zclassic removed it. But since they also have different kinds of nodes and been tweaking the fee allocation between them, their code is more involved than what we are going to have.

We may choose to go through two transitions in the fork, first permit new format blocks (with the fee) and later disallow the old format, to smooth out the transition. We would then want a command line option to alter this behavior, if we find the network lagging in adoption and need to delay upgraded nodes from stepping through the transitions.

Pick the level of fork code complexity that fits our anticipated requirements and implement it as a separate set of functionality within Zero codebase.

For the purposes of understanding failure modes and for forensics of attack scenarios, we should have a method to capture all arriving transactions and blocks (including the IP address of the sender). Transactions that somehow are not mined and get dropped from the mempool, and blocks that were 'reverted' or become orphans are not captured in the blockchain, but their very presence may be indicative of various failure modes and outright attacks.

So RT tracking those is likely a part of the process of detecting attacks. And having the complete record of what came when, collected on multiple friendly nodes will facilitate forensics.

Separately, should review geographic distribution, resilience and DDoS protection for the active infrastructure of seeds, explorers, pools.

Also interested in scenarios of selfish mining and lazy mining.
https://gist.github.com/shelby3
https://www.ccn.com/japanese-cryptocurrency-monacoin-hit-by-selfish-mining-attack/

Describe the issue

This repo's README is missing whether Zero has mandatory privacy enabled or not

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Navigate to https://github.com/zerocurrencycoin/Zero
2. Read the README
3. README is missing whether Zero has mandatory privacy enabled or not

Expected behaviour

README to state if Zero has mandatory privacy enabled or not

Actual behaviour + errors

README is missing whether Zero has mandatory privacy enabled or not

The version of Zcash you were using:

N/A

Machine specs:

N/A

Any extra information that might be useful in the debugging process.

README is missing whether Zero has mandatory privacy enabled or not. It is not clear from the README if transparent addresses are allowed or used or z-addresses are allowed or used only or both are allowed and used.

Do you have a back up of ~/.zero directory and/or take a VM snapshot?

N/A

Hello

We need help to run insight-ui + insight-api for zero-currency, on 2 different servers (DigitalOcean Droplets), to keep them alive for lifetime.

I will give access to the Ubuntu servers.

we need to setup public API with web-based insight-ui explorer.

we are happy to pay for your time!

thank you.

We should have a good in-depth look into RSK, learning how Zero can add "Smart Contract" functionality in the future.

RSK is the first open-source smart contract platform with a 2-way peg to Bitcoin that also rewards the Bitcoin miners via merge-mining, allowing them to actively participate in the Smart Contract revolution. RSK goal is to add value and functionality to the Bitcoin ecosystem by enabling smart-contracts, near instant payments and higher-scalability.

Parameters on transactions, blocks, mempool that could prevent or mitigate DoS or lockups under heavy load scenarios. Which of these require consensus changes is TBD.

1. Tracking of the state of DoS
   main.cpp: const int dosLevel,

2. Max Transaction size, increased from the Bitcoin value of 100,000 zcash#3212:

consensus.h:
static const unsigned int MAX_BLOCK_SIZE = 4000000;
/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = 40000;
/** The maximum size of a transaction (network rule) */
static const unsigned int MAX_TX_SIZE_BEFORE_SAPLING = 100000;
static const unsigned int MAX_TX_SIZE_AFTER_SAPLING = MAX_BLOCK_SIZE;

This should affect transactions being accepted into the mempool, not only a consensus rule. Mempool should not attempt to store more than say 100,000 pending transactions, maybe even much fewer, but do need an efficient data structure to timeout and purge. Could even keep history of rejected or purged transactions to prevent re-introduction zcash#2414

Separately, Bitcoin considered a cache to recognize transactions that have already been validated https://news.bitcoin.com/new-bitcoin-cachin-features-could-improve-block-verification/

3. Timing out transactions from the mempool. Bitcoin was 72 hours, now 7 days, which seems way way high bitcoin/bitcoin@5f0e27f
   Zcash possibly did not have a timeout initially, but after Overwinter uses block height based tracking, 20 2.5 min blocks (50 min). zcash#2874
   Seems like a very large change.
   main.h: static const unsigned int DEFAULT_TX_EXPIRY_DELTA = 20;
   Zero would be like 40 min, which is a bit short during network congestion, etc. Maybe several hours? Block height tracking is best for consensus, but wall time tracking is better for the node health, like with Bitcoin.

4. Alert system retirement zcash#3367

5. Ban score and node disconnect logic - could use a more sophisticated system zcash#2512
   Possibly use configurable white and black listing
   Track IP addresses and even subnets, maybe even geolocation zcash#3757

6. UTXO selection algo defaults to use-up smallest amounts first zcash@0afd368#diff-63ec75bfb71c2d4e26f2a95d5168f5e5R795
   That leads to unusable (effectively locked-up) wallets with addresses that accumulated too many spam or small (i.e. coinbase) transactions. Was noted to Zcash zcash#2411
   Patch pending zcash#2819

7. Min transaction fees to make spam leading to DoS more expensive. zcash#2942
   Current 0.0001 value is too small for Zero, and should be more like 0.01. That would be fine even when ZER becomes a $1 coin, but can adapt in future releases.

The node software has to adjust PoW algorithmic difficulty in response to changes in the overall hash rate and resulting changes in block production, in order to maintain the target block interval (10 min for Bitcoin, 2.5 for Zcash, 2 for Zero). Some exploits are activated via intentional sudden changes to the hash (solution) rate.

Suggested reading
Adjusting Mining Difficulty https://cryptocointalk.com/topic/9789-breakdown-of-difficulty-re-targeting-algos/
Graft Project https://www.graft.network/2018/04/06/latest-testing-results-enhanced-difficulty-adjustment-algorithm/
https://www.reddit.com/r/Digibyte/comments/213t7b/what_is_digishield_how_it_works_to_retarget/
zawy12 is a frequent contributor on the subject zawy12/difficulty-algorithms#6
seredat/karbowanec@231db52#commitcomment-22615466
Zcash difficulty adjustment algorithm zcash#147

BTCG algo changes happened across many commits, as some are Bitcoin related.
BTCGPU/BTCGPU#296
BTCGPU/BTCGPU@9207e92 BTCGPU/BTCGPU@c2f51df
BTCGPU/BTCGPU#327
BTCGPU/BTCGPU#331
Detailed discussion between @bitcartel and @zawy12 zcash#1211 (comment)

BTCG integrated a much more advanced LWMA algo from zawy12 https://github.com/BTCGPU/BTCGPU/blob/master/src/pow.cpp

A separate "time warp" exploit was addressed by Snowgem.

Zen was actually 51% attacked, and it already has a complex forking system #13

Blockchain management would benefit from better tools, starting with improved visibility.

A total view of the network, a simple and hopefully automated method for tracking on the daily or even hourly basis the hash rates and the version adoption would be useful.

In weeks prior to a fork a good understanding of the ownership and control of all the nodes on the network becomes very important, not only the IP addresses and adoption of the software versions, but specifically which ones are the mining pools and exchanges.

Blockchain-based attacks are visible by significant changes in block production, their origin, rate and distribution. 51% attacks involve deep blockchain reorganizations and disproportionally large transactions before, during, and after the reorg. Noting and alerting participants to such situations is essential.

IPs of the nodes that initially relayed transactions can be stored by friendly nodes. Recording all blocks, particularly the ones that were orphaned by a reorg, may help forensics.

Noting accidental forks would be a good idea and having tools and processes to deal with such situations may come in useful.

There are improvements and fixes from many upstream codebases, Bitcoin and Zcash and various libraries that they use. Also, fellow Z clones may post something useful or essential.

Need to track and integrate such fixes, commits, and PRs on regular basis. Currently candidate changes are tracked internally via a spreadsheet. For the ones that may benefit from public review and to encourage the entire community and contributors to submit more candidates, will list current list as a group or individually, as warranted by the subject matter and their degree of complexity.

For consideration
BTCGPU/BTCGPU@2513b61

Do we need such a tool? https://github.com/BTCGPU/equihashjs-verify

Zcash comes with several suites of tests. These may never have passed entirely on Zero, but should be engaged periodically and results reviewed. At a minimum, with upcoming changes we should not brake any tests that are passing now. Also, tests were developed for other Z coins to support recent forks and fixes. We may want to pick those up as well.

full_test_suite.py fails on 2 tests:
equihash_tests
joinsplit

It then blocks on paymentdisclosure.py

Initializing test directory /tmp/testPDw1_E
zcashd: main.cpp:1528: void InvalidChainFound(CBlockIndex*): Assertion `tip' failed.
Traceback (most recent call last):
  File "/home/devl/zero/Zero/qa/rpc-tests/paymentdisclosure.py", line 215, in <module>
  File "./full_test_suite.py", line 201, in <module>

rpc-tests.sh fails in the similar fashion, and should be re-run in the fresh build environment.

=== Running testscript paymentdisclosure.py ===
Initializing test directory /tmp/testOwML22
zcashd: main.cpp:1528: void InvalidChainFound(CBlockIndex*): Assertion `tip' failed.

Several Z coins were attacked with 51% double spend.
Partucularly, hard hit was Bitcoin Gold (BTG)
https://forum.bitcoingold.org/t/double-spend-attacks-on-exchanges/1362
https://forum.bitcoingold.org/t/anatomy-of-a-double-spend-51-attack/1398

The initial response by the exchanges is to increase the number of confirmations required, effectively buying more time against the chain reorganization. Detecting such events is crucial, though mitigation is TBD.
https://gist.github.com/gavinandresen/630d4a6c24ac6144482a
https://www.crypto51.app/

Heuristic grace period https://medium.com/@karbo.org/prevent-transaction-cancellation-in-51-attack-79ba03d191f0

Zcash makes big promises with their Sapling update, that it will improve performance and increase acceptance of shielded transactions and support adoption by payment systems and exchanges.
They have gone through a fork that enables future activation, but will not activate till some TBD date in October.

We need to understand the impact and the technical and business risks of adopting or choosing not to adopt. Certainly do not want to deploy anything till Zcash proves the claims in the field and does not get breached, but may need to follow publicly shortly thereafter and should plan and even merge beforehand.

zawy12/difficulty-algorithms#30.
We would need to reduce the fix Snowgem installed (which was for this issue) from 10 minutes to 6 minutes. The recommendation is 300 (5 min) or NT/20 (60120/20=360 or 6 min) whichever is greater.

In reviewing debug.log ERROR messages for Zero 2.0.4 on Ubuntu 18.04, found a single instance of: 2019-04-16 11:02:13 ERROR: CheckInputs(): tried to spend coinbase at depth 719

Line 2049 in main.cpp, this may be innocuous, but if not, can pursue further. This is the testnet3, and I did not generated transactions on it.

Gitian is regularly used for builds by Bitcoin, but not as much by Zcash.
At least BTCG uses it and demonstrates that a security measure can introduce its own vulnerabilities.
Need to evaluate applicability of this tech to the Zero project and size up the benefits and the effort to support it.

I use the latest zero-cli v3.3.1

When i run command:
zero-cli getrawtransaction "txid" 1

i get the transaction details but missing "size" and "fees" values.

please fix / update.

Docker images are often used by the Bitcoin and Zcash communities but not necessarily supported out-of-the-box by the official Zcash distribution. Instead they are distributed by affiliated parties, but may not track latest releases, and there could be issues of authenticity and provenance.
https://hub.docker.com/r/andyceo/zcash/
https://garanto.org/zcash-zcash-create-a-docker-image-as-a-reference-implementation-for-running-zcashd-3116.html

We anticipate that having a method to deploy quickly multiple cloud instances of the Linux node will come in useful, particularly if they can fit the AWS 'free tier'. Should evaluate applicability of Docker tech to the Zero project and size up the effort to support Docker images for the major official releases.

Document and validate OSX build

Notes from other clones
https://github.com/ZencashOfficial/zencash-apple
https://github.com/kozyilmaz/zcash-apple/releases/tag/v1.1.2a

Zcash plan to have Blossom activate approximately around October 28th, 2019 (one year after Sapling activation).

We need to understand the impact, technical and business risks of adopting or choosing not to adopt.

Here’s the current set of feature goals Zero will be looking into for Blossom.

Transaction Confirmation Usability and Security Improvements
Github: zcash #3674

What is it? Improve usability and security of fees and confirmations while accounting for growing transaction volume, demand spikes, and transaction-based DOS scenarios.

Who does this affect? Transaction senders and receivers.

Why is this a goal? We cannot prevent demand shocks or growth approaching scalability limits, but we can and should help users understand what is happening and help them protect themselves.

Light Client Protocol Dovetailing
Github: zcash #3675

What is it? Alter the base consensus protocol to reinforce light client support.

Who does this affect? (Future potential) Zcash light client end users.

Why is this a goal? We anticipate more light client users than full node users in the future (all other things being equal), so any streamlining of this use case in the base consensus protocol is potentially valuable.

Retire Sprout Addresses
Github: zcash #3677

What is it? Turn off all support for Sprout addresses and funds stored at those addresses except the ability to transfer funds out of those addresses.

Who does this affect? Sprout users.

Why is this a goal? This removes technical debt and simplifies the ecosystem moving forward. Additionally it prompts usage of the Sprout→Sapling turnstile

Rollback Protection and Hardening
Github: zcash #3678

What is it? Add protections against rollbacks larger than some predetermined length.

Who does this affect? All transactors, especially multi-user service providers.

Why is this a goal? All users would reject a large enough rollback. Some users would reject a smaller rollback. By codifying a well-known standard for the maximum acceptable rollback depth, we reduce economic uncertainty across the ecosystem. Other consensus features as well as external products and services can begin relying on this design decision. (Nuance: this does not answer the question of what people should or will do in the event of such a rollback. It simply ensures that no one will naively or accidentally proceed in a business-as-usual manner in this event thus protecting them from harm.)

Custodian Reinforcement
Github: zcash #3679

What is it? This includes a variety of potential features that can potentially protect typical end-users as well as specialized custodians. This may include recipient address verification, “vault functionality”, “I Got Burgled Button”, transaction cancellation, or transfer rate limiting functionality.
Who does this affect? All users.

Who does this affect? All users.

Why is this a goal? A substantial weakness of cryptocurrencies is how difficult self-custody is for wide user bases. By introducing protocol features that can help users protect themselves against theft or loss and/or enable custodian providers to reduce their operational risk, we aim to make Zcash safer for a larger user base.

Should have seed.zerocurrency.io, seed1, seed2 and similar configured and pointing at the instances of full nodes, preferably deployed in different geographic regions.

These addresses can be then compiled into the node code for better management.

Separately, evaluate requirements and tasks for the DNS seed nodes and open an Issue.

Describe the issue

Current block height is 1375500, current Zero Daemon version v3.3.0-1f513a61b will be deprecated at block height 1392080.

• Warning: This version will be deprecated at block height 1392080, and will automatically shut down. You should upgrade to the latest version of ZERO.

The version of Zcash you were using:

Zero Daemon version v3.3.0-1f513a61b

Please fix issues on zero-gtest

./zero-gtest 
[==========] Running 206 tests from 32 test cases.
[----------] Global test environment set-up.
[----------] 45 tests from checktransaction_tests
[ RUN      ] checktransaction_tests.check_vpub_not_both_nonzero
[       OK ] checktransaction_tests.check_vpub_not_both_nonzero (0 ms)
[ RUN      ] checktransaction_tests.valid_transaction
[       OK ] checktransaction_tests.valid_transaction (0 ms)
[ RUN      ] checktransaction_tests.BadVersionTooLow
[       OK ] checktransaction_tests.BadVersionTooLow (1 ms)
[ RUN      ] checktransaction_tests.bad_txns_vin_empty
[       OK ] checktransaction_tests.bad_txns_vin_empty (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_vout_empty
[       OK ] checktransaction_tests.bad_txns_vout_empty (0 ms)
[ RUN      ] checktransaction_tests.BadTxnsOversize
[       OK ] checktransaction_tests.BadTxnsOversize (4 ms)
[ RUN      ] checktransaction_tests.OversizeSaplingTxns
gtest/test_checktransaction.cpp:222: Failure
      Expected: ::GetSerializeSize(tx, SER_NETWORK, PROTOCOL_VERSION)
      Which is: 1999999
To be equal to: MAX_TX_SIZE_AFTER_SAPLING - 1
      Which is: 3999999
gtest/test_checktransaction.cpp:233: Failure
      Expected: ::GetSerializeSize(tx, SER_NETWORK, PROTOCOL_VERSION)
      Which is: 2000000
To be equal to: MAX_TX_SIZE_AFTER_SAPLING
      Which is: 4000000
gtest/test_checktransaction.cpp:244: Failure
      Expected: ::GetSerializeSize(tx, SER_NETWORK, PROTOCOL_VERSION)
      Which is: 2000001
To be equal to: MAX_TX_SIZE_AFTER_SAPLING + 1
      Which is: 4000001
gtest/test_checktransaction.cpp:248: Failure
Value of: CheckTransactionWithoutProofVerification(tx, state)
  Actual: true
Expected: false
gtest/test_checktransaction.cpp:247: Failure
Actual function call count doesn't match EXPECT_CALL(state, DoS(100, false, REJECT_INVALID, "bad-txns-oversize", false))...
         Expected: to be called once
           Actual: never called - unsatisfied and active
[  FAILED  ] checktransaction_tests.OversizeSaplingTxns (53 ms)
[ RUN      ] checktransaction_tests.bad_txns_vout_negative
[       OK ] checktransaction_tests.bad_txns_vout_negative (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_vout_toolarge
[       OK ] checktransaction_tests.bad_txns_vout_toolarge (1 ms)
[ RUN      ] checktransaction_tests.bad_txns_txouttotal_toolarge_outputs
[       OK ] checktransaction_tests.bad_txns_txouttotal_toolarge_outputs (0 ms)
[ RUN      ] checktransaction_tests.ValueBalanceNonZero
[       OK ] checktransaction_tests.ValueBalanceNonZero (0 ms)
[ RUN      ] checktransaction_tests.PositiveValueBalanceTooLarge
[       OK ] checktransaction_tests.PositiveValueBalanceTooLarge (0 ms)
[ RUN      ] checktransaction_tests.NegativeValueBalanceTooLarge
[       OK ] checktransaction_tests.NegativeValueBalanceTooLarge (0 ms)
[ RUN      ] checktransaction_tests.ValueBalanceOverflowsTotal
[       OK ] checktransaction_tests.ValueBalanceOverflowsTotal (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_txouttotal_toolarge_joinsplit
[       OK ] checktransaction_tests.bad_txns_txouttotal_toolarge_joinsplit (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_txintotal_toolarge_joinsplit
[       OK ] checktransaction_tests.bad_txns_txintotal_toolarge_joinsplit (1 ms)
[ RUN      ] checktransaction_tests.bad_txns_vpub_old_negative
[       OK ] checktransaction_tests.bad_txns_vpub_old_negative (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_vpub_new_negative
[       OK ] checktransaction_tests.bad_txns_vpub_new_negative (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_vpub_old_toolarge
[       OK ] checktransaction_tests.bad_txns_vpub_old_toolarge (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_vpub_new_toolarge
[       OK ] checktransaction_tests.bad_txns_vpub_new_toolarge (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_vpubs_both_nonzero
[       OK ] checktransaction_tests.bad_txns_vpubs_both_nonzero (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_inputs_duplicate
[       OK ] checktransaction_tests.bad_txns_inputs_duplicate (1 ms)
[ RUN      ] checktransaction_tests.bad_joinsplits_nullifiers_duplicate_same_joinsplit
[       OK ] checktransaction_tests.bad_joinsplits_nullifiers_duplicate_same_joinsplit (0 ms)
[ RUN      ] checktransaction_tests.bad_joinsplits_nullifiers_duplicate_different_joinsplit
[       OK ] checktransaction_tests.bad_joinsplits_nullifiers_duplicate_different_joinsplit (0 ms)
[ RUN      ] checktransaction_tests.bad_cb_has_joinsplits
[       OK ] checktransaction_tests.bad_cb_has_joinsplits (0 ms)
[ RUN      ] checktransaction_tests.bad_cb_empty_scriptsig
[       OK ] checktransaction_tests.bad_cb_empty_scriptsig (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_prevout_null
[       OK ] checktransaction_tests.bad_txns_prevout_null (0 ms)
[ RUN      ] checktransaction_tests.bad_txns_invalid_joinsplit_signature
[       OK ] checktransaction_tests.bad_txns_invalid_joinsplit_signature (1 ms)
[ RUN      ] checktransaction_tests.non_canonical_ed25519_signature
[       OK ] checktransaction_tests.non_canonical_ed25519_signature (0 ms)
[ RUN      ] checktransaction_tests.OverwinterConstructors
[       OK ] checktransaction_tests.OverwinterConstructors (0 ms)
[ RUN      ] checktransaction_tests.OverwinterSerialization
[       OK ] checktransaction_tests.OverwinterSerialization (0 ms)
[ RUN      ] checktransaction_tests.OverwinterDefaultValues
[       OK ] checktransaction_tests.OverwinterDefaultValues (0 ms)
[ RUN      ] checktransaction_tests.OverwinterValidTx
[       OK ] checktransaction_tests.OverwinterValidTx (0 ms)
[ RUN      ] checktransaction_tests.OverwinterExpiryHeight
[       OK ] checktransaction_tests.OverwinterExpiryHeight (0 ms)
[ RUN      ] checktransaction_tests.BlossomExpiryHeight
[       OK ] checktransaction_tests.BlossomExpiryHeight (0 ms)
[ RUN      ] checktransaction_tests.SproutTxVersionTooLow
[       OK ] checktransaction_tests.SproutTxVersionTooLow (1 ms)
[ RUN      ] checktransaction_tests.SaplingSproutInputSumsTooLarge
[       OK ] checktransaction_tests.SaplingSproutInputSumsTooLarge (0 ms)
[ RUN      ] checktransaction_tests.OverwinterVersionNumberLow
[       OK ] checktransaction_tests.OverwinterVersionNumberLow (0 ms)
[ RUN      ] checktransaction_tests.OverwinterVersionNumberHigh
[       OK ] checktransaction_tests.OverwinterVersionNumberHigh (0 ms)
[ RUN      ] checktransaction_tests.OverwinterBadVersionGroupId
[       OK ] checktransaction_tests.OverwinterBadVersionGroupId (1 ms)
[ RUN      ] checktransaction_tests.OverwinterNotActive
[       OK ] checktransaction_tests.OverwinterNotActive (0 ms)
[ RUN      ] checktransaction_tests.OverwinterFlagNotSet
[       OK ] checktransaction_tests.OverwinterFlagNotSet (0 ms)
[ RUN      ] checktransaction_tests.OverwinterInvalidSoftForkVersion
[       OK ] checktransaction_tests.OverwinterInvalidSoftForkVersion (0 ms)
[ RUN      ] checktransaction_tests.OverwinteredContextualCreateTx
[       OK ] checktransaction_tests.OverwinteredContextualCreateTx (0 ms)
[ RUN      ] checktransaction_tests.BadTxReceivedOverNetwork
[       OK ] checktransaction_tests.BadTxReceivedOverNetwork (0 ms)
[----------] 45 tests from checktransaction_tests (64 ms total)

[----------] 9 tests from founders_reward_test
[ RUN      ] founders_reward_test.general
[       OK ] founders_reward_test.general (640 ms)
[ RUN      ] founders_reward_test.regtest_get_last_block_blossom
[       OK ] founders_reward_test.regtest_get_last_block_blossom (0 ms)
[ RUN      ] founders_reward_test.mainnet_get_last_block
gtest/test_foundersreward.cpp:141: Failure
      Expected: 0
To be equal to: params.Halving(lastFRHeight)
      Which is: 9
gtest/test_foundersreward.cpp:142: Failure
      Expected: 1
To be equal to: params.Halving(lastFRHeight + 1)
      Which is: 10
[  FAILED  ] founders_reward_test.mainnet_get_last_block (0 ms)
[ RUN      ] founders_reward_test.mainnet
zero-gtest: chainparams.cpp:604: std::string CChainParams::GetFoundersRewardAddressAtHeight(int) const: Assertion `nHeight >= consensus.nFeeStartBlockHeight && nHeight <= maxHeight' failed.
Aborted (core dumped)

Development Fee (AKA Founder Reward) was built into the original Zcash codebase and the coins with a fee (Hush, Snowgem, Zen) all use same code structure. Zclassic and Zero have that code removed. Many places in the codebase may be affected by this change, and we need to handle the transition first to allow new blocks and then rejecting them. Nevertheless, bringing the code back, which revolves around the FoundersReward fields of the CChainParams class, is a separable task that can be validated on a dedicated testnet.

Since Zcash Reward is scheduled to end after four years, they already have a field consensus.GetLastFoundersRewardBlockHeight. We would add one for the starting height and use it in all the same places in the code.

At some point we picked-up a Zcash change around line 85 of chainparams.cpp:
bip44CoinType = 133; // As registered in https://github.com/satoshilabs/slips/blob/master/slip-0044.md

133 is a value that Zcash reserved and we should probably have one for Zero. This only affects what some wallets could learn through the RPC interface.

Evaluate situations where nodes behind a NAT have different internal and external (routable) addresses, and may get confused when connecting to themselves via the external address.

Such a situation could be generating the following error messages:

2018-04-13 06:54:07 receive version message: /MagicBean:1.0.81/: version 170002, blocks=300522, us=107.135.67.9:37730, peer=1
2018-04-13 06:54:07 Added time data, samples 2, offset +0 (+0 minutes)
2018-04-13 06:54:07 connect() to 213.32.78.132:23801 failed after select(): Connection refused (111)
2018-04-13 06:54:08 receive version message: /MagicBean:1.0.81/: version 170002, blocks=300522, us=107.135.67.9:38324, peer=2
2018-04-13 06:54:08 Added time data, samples 3, offset +0 (+0 minutes)
2018-04-13 06:54:10 ERROR: ContextualCheckBlockHeader: incorrect proof of work
2018-04-13 06:54:10 Misbehaving: 213.239.212.246:23801 (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 06:54:10 ERROR: invalid header received
2018-04-13 06:54:10 ProcessMessages(headers, 544003 bytes) FAILED peer=1
2018-04-13 06:54:12 ERROR: ContextualCheckBlockHeader: incorrect proof of work
2018-04-13 06:54:12 Misbehaving: 64.237.50.236:23801 (0 -> 100) BAN THRESHOLD EXCEEDED
2018-04-13 06:54:12 ERROR: invalid header received
2018-04-13 06:54:12 ProcessMessages(headers, 544003 bytes) FAILED peer=2

Note that the "Misbehaving" error message does not start with ERROR:

This issue tracker is only for technical issues related to zerod.

General ZERO questions and/or support requests and are best directed to the https://github.com/zerocurrency/zero

For reporting security vulnerabilities or for sensitive discussions with our security team, please contact [email protected]. You can use the GPG key (fingerprint: AF85 0445 546C 18B7 86F9 2C62 88FB 8B86 D8B5 A68C) to send an encrypted message. The key and fingerprint are duplicated on our Public Keys page.

Describe the issue

Please provide a general summary of the issue you're experiencing

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

Expected behaviour

Tell us what should happen

Actual behaviour + errors

Tell us what happens instead including any noticable error output (any messages displayed on-screen when e.g. a crash occurred)

The version of Zcash you were using:

Run zerod --version to find out

Machine specs:

• OS name + version:
• CPU:
• RAM:
• Disk size:
• Disk Type (HD/SDD):
• Linux kernel version (uname -a):
• Compiler version (gcc --version):
• Linker version (ld -v):
• Assembler version (as --version):

Any extra information that might be useful in the debugging process.

This includes the relevant contents of ~/.zero/debug.log. You can paste raw text, attach the file directly in the issue or link to the text via a pastebin type site.
Please also include any non-standard things you did during compilation (extra flags, dependency version changes etc.) if applicable.

Do you have a back up of ~/.zero directory and/or take a VM snapshot?

• Backing up / making a copy of the ~/.zero directory might help make the problem reproducible. Please redact appropriately.
• Taking a VM snapshot is really helpful for interactively testing fixes

Track and analyze the causes of the messages reported by the running full node. Many of these start with something like 2018-05-21 02:52:02 ERROR:

Following messages are common and could be related to the initial block download or otherwise acceptable:
AcceptToMemoryPool: inputs already spent
AcceptToMemoryPool: joinsplit requirements not met

However, more message types were seen, including
ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
ERROR: ContextualCheckBlockHeader: incorrect proof of work
ERROR: invalid header received

Somewhat more extensive debug messages are available by launching zcashd with -debug flag. This should be the standard deployment method for the seeds and developer nodes, and the logs should be reviewed periodically. A script that would filter out routine or acceptable messages would be useful.