Seems like your users are redirect to a different repository (Copay) for support requests. Can you please check it?

Thanks in advance.

Hi, I am trying to install a pool and am getting these errors:

[Payments] [bitcoinz] Error with RPC call listunspent undefined {"code":-1,"message":"JSON value is not a string as expected"}

Cant see where I am going wrong, I have tripple checked everything but cant find the problem

Thanks

Hi, I made a shipment to an android wallet and even that the transaction appears as completed, the wallet does not appear

https://btczexplorer.blockhub.info/tx/a8d99d5f07eb3d7f55770710a32518b874d3d3cee2e50374b2534ebccf287fab

After some time, eg. 20 hours daemon freezes. There is no screen updates like "since starting this node" and it is not responding to rpc requests. What's wrong?

Hi,

The founder reward amount is listed in getblocktemplate however the current address is not. Can you please add this into the gbt results?

Thanks

root@-Virtual-Machine:~/bitcoinz/zcutil# ./build-win.sh
+++ readlink -f ./build-win.sh
++ dirname /home/mikhail/bitcoinz/zcutil/build-win.sh

• cd /home/mikhail/bitcoinz/zcutil/..
• cd depends/
• make HOST=x86_64-w64-mingw32 V=1 NO_QT=1
  echo Extracting rust...
  Extracting rust...
  mkdir -p /home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a
  cd /home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a; mkdir -p /home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a && echo " /home/mikhail/bitcoinz/depends/sources/" > /home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a/..hash && sha256sum -c /home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a/..hash && tar --strip-components=1 -xf /home/mikhail/bitcoinz/depends/sources/
  sha256sum: /home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a/..hash: no properly formatted SHA256 checksum lines found
  funcs.mk:242: recipe for target '/home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a/.stamp_extracted' failed
  make: *** [/home/mikhail/bitcoinz/depends/work/build/x86_64-w64-mingw32/rust/1.16.0-3285257568a/.stamp_extracted] Error 1
• ./autogen.sh
  ./build-win.sh: line 44: ./autogen.sh: No such file or directory

I check files sha256 is ok.
I dont know thats a problem =(

I was doing some research on BTCZ transactions and upon looking at:

https://explorer.btcz.rocks/tx/91d53d7d9163926c60f66d4be150f550798736b99eb0f5599aa2121b4304e456

it seems it is a z2z and has no joinsplits because it's not sprout, but shielded spends and outputs are not being shown. Your insight explorer probably needs to be updated to understand Sapling

Encountered an issue while setting up Block Explorer. During attempt to synchronize the indexes the sync.js script errored on trying to import block 113.

Upon further investigation there are two TX ids for block 113:

8d192f56c30bd033804e2bd468295b86f549fececf7354bad76db008cfeafecd
263e164138360953880f0f7ac928b1002a01b7140d9c8e2c2b64148425cb580a

txid 1 has the following output:

./zcash-cli gettxout 8d192f56c30bd033804e2bd468295b86f549fececf7354bad76db008cfeafecd 0
{
"bestblock": "000000eb029dfb9b804db0ba75d3276d4e3415cc9ba6c92f5d03bbccb0feb27a",
"confirmations": 5715,
"value": 12500.00010000,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 9b9c7276a3faf4b679fb41d45a237ba958e00b78 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9149b9c7276a3faf4b679fb41d45a237ba958e00b7888ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"t1Y4QACu5S6udREAEjNZgEFWLT6TASncfcL"
]
},
"version": 1,
"coinbase": true
}

txid 2 has no output:
./zcash-cli gettxout 263e164138360953880f0f7ac928b1002a01b7140d9c8e2c2b64148425cb580a 0

txid1 has a raw transaction of:
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff300171005a2d4e4f4d50212068747470733a2f2f6769746875622e636f6d2f6a6f7368756179616275742f7a2d6e6f6d70ffffffff01107bce09230100001976a9149b9c7276a3faf4b679fb41d45a237ba958e00b7888ac00000000

txid2 has a raw transaction of:

0200000002d7579ce4520da515758ecd399e9c1ae6fc2ca01ec48cbe3504195ad935d1700a000000006a473044022022e7e51e9b3904086bc393c2d3625e9dd301cd4cec4a742b9444acf66190557202202546a876cc275a0c700f7ade3f0f7012698e9a7d9b8a4afda42b09daea84ff20012103efd805143c8302f882892ebbda620d4935d50aa5ccc0e7760de7df7b0f7ddbffffffffff0a7f6cd1b6ce6e793e5b35d754456eaea9d8fb874b082bf18e1ef65cb84ac390000000006b4830450221009dc8460c18dfe9cffc9b5bd459d673e77d999dbe8c3e947d8a6bd1a553b2f2fb0220738c668320ce54014e55301b47608d7685a3df75e9afb4fe255fc1ee5fe944f0012103efd805143c8302f882892ebbda620d4935d50aa5ccc0e7760de7df7b0f7ddbffffffffff000000000001f02cce09230100000000000000000000d7c612c817793191a1e68652121876d6b3bde40f4fa52bc314145ce6e5cdd259c59b32c0a79922a9f257c53a00c49d18df36ae235aed8dce33e21434dadb6a86cca0316e761661a49b570109d1c9208bdab4e6ebdbb106e22e8dd7a392c53db7bf12e7ec2e38e0696f4ede913151bccde639bccfce9c5dbe83ec8a98787bc99ecf6fc41c9f5324df56a7a539eadc52a9c9660a7cc0ba02fa51bad5d513715f465894aac8c2bb56a1fa3191ca8347cc60bce29e09fd329519fcbae7af435b8b546ff89aa7bb2ec0c4ecae912cfed731042e2e66c7c43f070545dabff7600b39e23c163d456f3a69c1383ae2408e0dbecc2ab74f6b05578aa646b0d726bc22d3a3cf2c3c9339269ea64365e95c491e62c520947b66d1a041be9382b2dd2c1e623a031cb4116977600ef1c3af2b9c1edd132cc42ec8e45b4a8c31de23ae936ee19c79031861048b88c10d7f97bb1af3d657d7a389b89bd2582a9b24d8beae5c785cbab10a0512fa7a6962ce2c34c4ee089daf0b8f4464e195a81ce5300742c197a8c2ecc036aecc5434d66f4a1d0bbb570a9d20232abc865e0a8b852384866da7eb1339d90302dcf254a0b42f2991c0de8c0c9b8facaeb49b65cf280a6109e65ce6d63a13530202d04558962b2b45182acd0364d67c26ab168f50ce0c9e6341b13b4967aedafe030ed2c399f82ed29e8dfcfd1239ec602f6be2d7a4f8ff1bd69050eb1dd12fc29d03151304e1fafd0570e72fb18d6e8221ce1117c905a790f67bc28931b1168961800324b3f2e5f32e799b38df2eb10de29a43958a5b4d2e22eebedcbf4a9b08dd8c6559c7432a6f11b936c576339204690f791def980b604cf0138f293c2bc8d1592ba9e6a41e174066af1f0c076f6c5741561317d5b8c5357c93b9a177132371ee5e29008ddd673dd22c8eca2a02e1da04eeab0f00a39e114fc4da9e00c9d979f2d3379cb8e7f02db1af171ab230858895420012924d05c6ff7b36f0b197a2e0ea98a5acbd8782c6eec04b7f70f9f29516f6edca9df56624ffb3e290bba8caeba2995ddaa6ca6d804bd9b07cace376095ed2b474012015228635411d6b35448ca85fbcd4417586f98cd36ed7207cfa1efbefec2d87001d6a5d6f66737f88e60b83d83978d5ab2214d13827918491b860769e59a3151a82c46d0d9450ecfa6d3c5b0a5bef65961640688ec95db0e51cf40f7ecfd8842e39005f414f956fabc68efc9002b697a9f5466bafd73d387ea1df28e298182fa8d4386149e5e7f917cf21829a79abf4c4ad297beae49ec5a425f4e0af0d36defb17ac95f41ff04703ca7c0e07302d1b3ef2167df1ab68ecf084d8e52fda123731a9bec639f962c7902112e0046cc37b4f8ba264f91f89cdb338473e4a23d4fe6ed232aaa9bf0bb3e39f53ecd851c55ef6c02c2b6122478ea3277c91508862bc9208dfacce1bb31745dd4ad83df14aca952c277bb50ee224a354524a558d5612f04789da8533645ee2a5e31ebc5c2782fda5859068aa0c0eb7937978ad576c0df5650ebbfd0a7eaea93d6e9aaecf06f211ded67a3f91a4caeff59902ebde46bbc7d683a4461ab352d2caad98b13205e38f9b257b32325e894c3cddcefc4ca0d4529744074fd241aa51fbdea3bbd9afe846891117b15429ee37b2a3ed7aaa4019f27b2d38c1117671ce0f521a000418afa8e224afc5a0a7ca458cc2ab7e5f8820f15a77070c0a0a6808665e1a5d737c30bb8813cdefc54e5e225c51c3f9dce0e615358d620fa39259807ea27d0a2d6815541bcb88bd037bf8d01515bcc7ad89ee07d01581ae2debd337d27f7f0483f14600b68cf4e2d9270ce9656c1e7c6ec20fd1b22b863529bfa25449e113a52fbb35c02e651158875f70a442a1132b8b4aa72c48ed71698a456387820dd5788f2e823fe78884be88909aa760218979fce06e6f429d257d802e1c11cf74fec79f135960e7304510f247dcfdf3b7d7e35ec763f6a360214859d15aa0b76ef6500385f2dd59645688f9969ed5b4737fc68eeb92b1a6916f557740d756f7baf406b4c52747066a54ecd635b00548caaf6585edb7a8e19d9cf9fc5b5b7bc327e30d4709e28e04663a3e54dae26102a075c0579daca5ab90154694327df0f8fa534056263ed3143eb29f2fc65ba5080170befd313fae09a7a265f571edc9d2aa362a55b47f4589fffb10d6d54f7c8d91f19b10a0d7c8dfc49be37e86ab9922b58b28e6869c95f08444feb368b01eb7d04ccaf2146d37bb1e73e6e053422d329712a0811fdedc64714c2625342b7af66f8edd879d41b9af7956424567d8f28d6b783072bb7360fdff9fb3433a204ab518fb42a6f52e904e64d27545dcba090c5745cb3f965e601c64ccbf32744665be57061321539c8b673bfd0c0e12ee8dd5b3aa6c7080ef728cd35a1348f1fc685d1ad0755184683c74b0c4218eebfee384232e4fdebf3162d4328a290b0ef1fe5313cb8ad08038c9aa12a35b1561860389c7fd3a9d15f2353963c05467339037aefca2e4b1660233301b74961cbe1dfa5ccbff0d829a94af83869ab05825d17e16697eddd572a6335ea460207f5a4c66fc1f503d46d3846d12445743135986922ace0d2b396a39f59fb120f25f5a4d3c50721ce87d6ecbe2c77a076b533037a9fbbd6be8940f

txid 2 seems to have no transaction results but contains raw data. Any ideas?

Fetching libsnark...
https://z.cash/depends-sources/libsnark-3854b20c25e8bc567aab2b558dec84d45f4a3e73.tar.gz:
2017-09-12 05:26:46 ERROR 404: Not Found.
2017-09-12 05:26:46 URL:https://codeload.github.com/z-classic/libsnark/tar.gz/3854b20c25e8bc567aab2b558dec84d45f4a3e73 [144924/144924] -> "/home/pooladmin/bitcoinz/depends/work/download/libsnark-/libsnark-3854b20c25e8bc567aab2b558dec84d45f4a3e73.tar.gz.temp" [1]
/home/pooladmin/bitcoinz/depends/work/download/libsnark-/libsnark-3854b20c25e8bc567aab2b558dec84d45f4a3e73.tar.gz.temp: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
funcs.mk:242: recipe for target '/home/pooladmin/bitcoinz/depends/sources/download-stamps/.stamp_fetched-libsnark-libsnark-3854b20c25e8bc567aab2b558dec84d45f4a3e73.tar.gz.hash' failed
make: *** [/home/pooladmin/bitcoinz/depends/sources/download-stamps/.stamp_fetched-libsnark-libsnark-3854b20c25e8bc567aab2b558dec84d45f4a3e73.tar.gz.hash] Error 1

We just added Bitcoinz to our pool. Come mine with us¡ https://equihashing.com

BTCZ went thru halving but btcz.rocks still saying reads "Current supply: 12,500 coins every 2.5 minutes"

So my node and wallet are working on Ubuntu 16.04.3. Bitcoinz installed from 1.0.11...
When trying to get backup of wallet or to export keys:
./src/zcash-cli z_exportwallet "filename=backup" "exportdir=/home/username/backup"
error code: -1
error message:
z_exportwallet "filename"
Now both parameters (filename and exportdir are also stated in bitcoinz.conf: exportdir=/home/username/backup
filename=backup )
For backup looks like this:
./src/zcash-cli dumpwallet "mybitcoinzhwallet"
error code: -4
error message:
Cannot export wallet until the zcashd -exportdir option has been set
Any ideas how to solve this?

Yet another BtcZ pool. 0% fee until january, then 0.5%
http://igloopool.org/

By the node version 2.0.7-10 we added the possibility to add an OP code with an Hex encoded string in the transactions that also give an unexpected output format if it is used. This unexpected output format is OP_RETURN _<HEX-STRING>_ .

This was added in the Raw Transaction class:

An example of the Raw DATA can be found in this transaction :
https://explorer.btcz.app/tx/b8b29ff7f76e40d01990fad1a8d51d830a66c9f533c3b1768f78fcaf26888ef4

Now, when the Insight option is activated, the node try to find the spent index information about this OP_RETURN code that are not existing as the spent amount is zero (0). And this trigger an error in the debug.log file for each Raw DATA.

Error in the log file for Insight : ERROR: Unable to get spent index information
Triggered here:

Also a similar error happen in the wallet functions.
Error for the Wallet functions : CWalletTx::GetAmounts: Unknown transaction type found, txid <The_TX_ID>
Triggered here:

After some time, the log is flooded by this badly returned error information's !

The solution is to check if the output is encoded as usually, with an OP_DUP OP_HASH160 scriptPubKey, or with an Raw DATA field with OP_RETURN . This should be done before calling the function that trigger the error. A check could also be done just before the error is triggered but I guess this will probably have an affect on the performance.

My pool uses Z-NOMP for algo equihash.
I tried installing btcz on my pool. But it still only runs at the default algo equihash. Not algo equihash 145_5. So I want to run btcz on my pool. I have consulted through https://github.com/NickRHill/zh-nomp
I find the libraries here to be the default alog equihash unchanged from the Z-NOMP source code. Do not know if the developer made any suggestions for me? My experiment pool: https://super.mine-vn.com
Thank you!

Why btcz daemon is so bad? I have other daemons on the same server and they work fine, but btcz daemon freezes for up to 2 minutes many times per day. It also needs 10 minutes (!) to load! What is wrong with it?

Hi there,

running some the gtest I have an error on the joinsplit.full_api_test:

[s0n1k@morpheus src]$ pwd
/home/s0n1k/bitcoinz/src

[s0n1k@morpheus src]$ ./zcash-gtest --gtest_filter=joinsplit.full_api_test
Note: Google Test filter = joinsplit.full_api_test
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from joinsplit
[ RUN ] joinsplit.full_api_test

• QAP number of variables: 1887090
• QAP pre degree: 2068650
• QAP degree: 2097152
• QAP number of input variables: 9
• G1 window: 20
• G2 window: 17
• G1 elements in PK: 13419707
• Non-zero G1 elements in PK: 11258422
• G2 elements in PK: 1887092
• Non-zero G2 elements in PK: 1141155
• PK size in bits: 3721036065
• G1 elements in VK: 11
• G2 elements in VK: 5
• VK size in bits: 6181
  gtest/test_joinsplit.cpp:214: Failure
  Value of: reason
  Actual: "nonsensical vpub_old value"
  Expected: err.what()
  Which is: "invalid joinsplit balance"
  gtest/test_joinsplit.cpp:214: Failure
  Value of: reason
  Actual: "nonsensical vpub_new value"
  Expected: err.what()
  Which is: "invalid joinsplit balance"
  gtest/test_joinsplit.cpp:214: Failure
  Value of: reason
  Actual: "nonsensical input note value"
  Expected: err.what()
  Which is: "invalid joinsplit balance"
  gtest/test_joinsplit.cpp:214: Failure
  Value of: reason
  Actual: "nonsensical left hand size of joinsplit balance"
  Expected: err.what()
  Which is: "invalid joinsplit balance"
  gtest/test_joinsplit.cpp:214: Failure
  Value of: reason
  Actual: "nonsensical output value"
  Expected: err.what()
  Which is: "invalid joinsplit balance"
  gtest/test_joinsplit.cpp:214: Failure
  Value of: reason
  Actual: "nonsensical right hand side of joinsplit balance"
  Expected: err.what()
  Which is: "invalid joinsplit balance"
  [ FAILED ] joinsplit.full_api_test (378468 ms)
  [----------] 1 test from joinsplit (378468 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (378468 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] joinsplit.full_api_test

1 FAILED TEST

Could someone fix it?

Thanks,
Marco

It seams the wallet gets this error randomly when using Z addresses.
The error below is the error from the node.
Reference attached image for more info.

This could be the solution (recheck of the sapling notes witness height):
https://github.com/zcash/zcash/blob/c791f0a770c832c8f8dd20c62091781a276858e9/src/wallet/wallet.cpp#L3923

Feb 27 15:20:50 bitcoinzd[2062777]: bitcoinzd: wallet/wallet.cpp:1971: void CWallet::GetSaplingNoteWitnesses(std::vector, std::vector<boost::optional<libzcash::IncrementalWitness<32, libzcash::PedersenHash> > >&, uint256&): Assertion `*rt == witnesses[i]->root()' failed

how is curl missing from base image?

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

General Zcash questions and/or support requests and are best directed to the Zcash Forums or Community Rocket.Chat.

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 zcashd --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):

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

This includes the relevant contents of ~/.zcash/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 ~/.zcash directory and/or take a VM snapshot?

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

Hi there running the test/test_bitcoin executable I have the following errors:

[s0n1k@morpheus src]$ pwd
/home/s0n1k/bitcoinz/src/test

[s0n1k@morpheus src]$ ./test_bitcoin
Running 194 test cases...
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(290): error: in "Alert_tests/AlertApplies": check alert.CheckSignature(alertKey) has failed
test/alert_tests.cpp(296): error: in "Alert_tests/AlertApplies": check alerts[0].AppliesTo(1, "") has failed
test/alert_tests.cpp(297): error: in "Alert_tests/AlertApplies": check alerts[0].AppliesTo(999001, "") has failed
test/alert_tests.cpp(298): error: in "Alert_tests/AlertApplies": check alerts[0].AppliesTo(1, "/MagicBean:11.11.11/") has failed
test/alert_tests.cpp(300): error: in "Alert_tests/AlertApplies": check alerts[1].AppliesTo(1, "/MagicBean:0.1.0/") has failed
test/alert_tests.cpp(301): error: in "Alert_tests/AlertApplies": check alerts[1].AppliesTo(999001, "/MagicBean:0.1.0/") has failed
test/alert_tests.cpp(303): error: in "Alert_tests/AlertApplies": check alerts[2].AppliesTo(1, "/MagicBean:0.1.0/") has failed
test/alert_tests.cpp(304): error: in "Alert_tests/AlertApplies": check alerts[2].AppliesTo(1, "/MagicBean:0.2.0/") has failed
test/alert_tests.cpp(338): error: in "Alert_tests/AlertNotify": check r.size() == 6u has failed [0 != 6]
unknown location(0): fatal error: in "Alert_tests/AlertNotify": memory access violation at address: 0x00000008: no mapping at fault address
test/alert_tests.cpp(344): last checkpoint

*** 19 failures are detected in the test module "Bitcoin Test Suite"
test_bitcoin: /home/s0n1k/bitcoinz/depends/x86_64-unknown-linux-gnu/share/../include/boost/thread/pthread/condition_variable_fwd.hpp:102: boost::condition_variable::~condition_variable(): Assertion `!ret' failed.
Aborted (core dumped)

Could someone fix it, please?

Thanks,
Marco

Are you minig on your website? CPU fan goes up on your site. You should not copy paste some "cool" JS - it is only really cool if the CPU stays cool, too ;)

I want to make block explorer , but to compile bitcore i need to know on wich zcash version you based bitcoinz

Lower blocktime ,halving period,reward, max supply @sapling update

Integration of BTCZ is horrible in terms of CPU, the node takes 3-8% CPU after BC sync completed, like someone does the mining behind the scenes. (The idea as I type, I remember I have gen=0 in Hush conf, so maybe this is needed in BTCZ)

Hush daemon for contrast takes only 0.03-0.04% CPU sometimes drops to 0.02% so basically Hush runs close to idle.

I can't image having BTCZ daemon deployed to VPS and have constantly consumed CPU at 3-8% level, why would pulling BC data from P2P network (after full sync) take that much CPU?

please specify the default rpc and p2p port and change from zcl/zcash if necessary

Mining Pools
BTCZ Mining guide: http://bitcoinz.global/media/BitcoinZ_WALLET+MINING_GUIDE.pdf or https://t.co/NIHzRmPK0C
http://pool.miningspeed.com
https://pool.cryptobroker.io/btcz/
http://www.zpool.ca/site/mining
http://equi.mining4.co.uk
http://btz.pool.sexy
https://btcz.suprnova.cc
https://equipool.1ds.us
https://alphacentauri.science/
http://pool.coinminer.space:8090
http://www.pcmining.xyz/
https://aikapool.com/btcz
http://miningpool.io
http://luckpool.org
http://hashgate.eu/
https://bitcoinz.getpool.network/
https://zsolo.bid
https://equihashing.com
https://btczpool.com
http://www.mineflowpool.pl [PL]
https://multipool.es [ES]
http://btcz.minertopia.org
http://owlminingclub.com

Mining software:
https://minez.zone/getting_started

Solo mining
https://github.com/z-classic/z-nomp
https://github.com/Austin-Williams/zcash-guides/wiki/Guide-to-Solo-Mining-Zcash

Introducing ZHash, a new hashing algorithm with the goal of hardening the Equihash protocol to be more ASIC resistant. The ZHash algorithm works by increasing the hardware requirements of Equihash to make development of an ASIC appliance less viable. The goal of ZHash is to put GPU mining on a level playing field with ASICs and FPGAs as far as hashing rates and costs are concerned so that they do not get too much of an advantage.

On block 160,000 around June 15th ~ 16th BitcoinZ will fork to the ZHash algorithm to prevent ASIC miners on the network. Before the fork, all nodes and wallets should be updated to the latest version to help support the new algorithm.

List of things that are needed:

• Updated BitcoinZ node - https://github.com/btcz/bitcoinz
• Updated BitcoinZ Windows Wallet - https://github.com/btcz/bitcoinz-wallet
• Optimized GPU miner for Cuda - https://github.com/btcz/zhasher
• Modified z-nomp to support the ZHash algorithm "NickNomp" - https://github.com/NickRHill/zh-nomp
• Optimized GPU miner for AMD
• Testers

Let us know how you can help!

The ZHash algorithm is based on the Equihash 144,5 variant and was primarily based on the development of @tromp, The BitcoinZ project, and The ASIC Resistance consortium.

Run your BitcoinZ seeder and post your DNS here.
We need a lot of seed nodes to be fully decentralized!

Seed nodes will be added to BitcoinZ source code.

The requirement is to have bitcoinz full node running & seeder at the same machine.
Test your seeder from other machine. It should get the same output as test to current seeders:
Full node test (open 1989 port TCP):

telnet dnsseed.kemperink.org 1989

and
Seeder test (Open port 53 UDP) - should return list of IPs:

nslookup seed.btcz.life

Post TOR nodes here.
Tutorial: https://bitcoinzguiding.ovh/pdf/tornodetuto.pdf

Nodes:
sp6lvlurevy4fplr.onion
xiv7crijwn4i4hwj.onion

Submissions Tracker to Pools, Exchanges, Sites

Please submit sites not listed here in comments section.
Please submit requests to the sites listed below. This will be a community effort.

Exchanges to Submit To

Kucoin: https://drive.google.com/open?id=1yhsPyrXQGHj6q4r2i-aNTv2sppKCFmAMW6aduA0TSXQ
Binance: https://drive.google.com/open?id=1EHpvQRWh_MKiYFw0PPQPAIMVDCGUgpPy4pk6EHBJljQ
Coss.io: https://drive.google.com/open?id=1gnod_vj0N0u1f93TGq24DePtPIN9TRublQO7Kv26L78
Poloniex: https://drive.google.com/open?id=1-oTYDSzbf5icg9tOvtnzRWuyifoLlGYTLIyczFhXvuY

https://abucoins.com/ Submit Requests
https://support.bittrex.com/hc/en-us/requests/new?ticket_form_id=114093958872 Submitted Please submit more requests
https://www.cryptopia.co.nz/Paytopia cost 5million DOT
https://evercoin.com/ Similar to shapeshift, changelly.
https://www.livecoin.net/
https://novaexchange.com/addcoin/ Submitted Please submit more requests
https://tidex.com/
https://yobit.net/en/addcoin/ Submitted Please submit more requests

Pools

https://www.nanopool.org email: [email protected] In Process Please submit more requests
https://www.f2pool.com email: [email protected] In Process Please submit more requests
https://miningpoolhub.com/ email: [email protected] In Process Please submit more requests
https://coinotron.com email: [email protected] In Process Please submit more requests
http://miningpools.cloud/ email: [email protected] In Process Please submit more requests
http://dwarfpool.com/contact/ email: [email protected] In Process Please submit more requests

Sites

Sites: https://www.crypto-coinz.net/crypto-calculator
Sites: https://whattomine.com/coins/207-btcz-equihash
Sites: https://www.cryptocompare.com/coins/btcz/overview
Sites: https://coinmarketcap.com/currencies/bitcoinz

Wallets

https://jaxx.io/ Submit requests to show support
https://trezor.io/ Submit requests to show support

Completed Listings

Exchanges: https://coinmarketcap.com/currencies/bitcoinz/#markets
C-cex, Stocks.Exchange, TradeSatoshi, BTC-Alpha, BarterDEX, Exrates

Pool: https://bitcoinz.getpool.network/ DONATING 1.0% TO BTCZ PROJECT
Pool: https://equipool.1ds.us DONATING 2% TO BTCZ PROJECT
Pool: http://pool.bitcoinzguiding.ovh/ DONATING 0.2% to BTCZ PROJECT & BTCZ GIVEAWAYS
Pool: https://zpool.wfmpools.com/ DONATING 0.4% to BTCZ PROJECT
Pool: https://lambomoon.club/ DONATING 0.5% to BTCZ PROJECT
Pool: https://worldminer.net DONATING 0.3% to BTCZ PROJECT
Pool: http://www.abakus.gemini.net.pl DONATING 0.8% to BTCZ PROJECT
Pool: https://pool.w00t.xyz/workers DONATING 0.3% to BTCZ PROJECT
Pool: http://45.77.41.80:8080/ DONATING 0.7% to BTCZ PROJECT
Pool: http://www.pcmining.xyz DONATING 0.5% TO BTCZ PROJECT
Pool: https://axepool.com/getting_started DONATING 0.33% TO BTCZ PROJECT
Pool: https://minez.zone
Pool: http://equi.mining4.co.uk
Pool: http://btz.pool.sexy
Pool: http://pool.miningspeed.com
Pool: http://miningpool.io
Pool: http://pool.coinminer.space:8090
Pool: http://www.zpool.ca/site/gomining?algo=equihash
Pool: https://btcz.suprnova.cc
Pool: https://pool.cryptobroker.io/btcz/
Pool: https://aikapool.com/btcz
Pool: https://luckpool.org/
Pool: https://zsolo.bid/ Solo Mining Pool
Pool: https://btczpool.com/
Pool: http://www.mineflowpool.pl/ [EN] [PL]
Pool: https://multipool.es/ [ES]
Pool: http://btcz.minertopia.org
Pool: http://owlminingclub.com/
Pool: http://eqpool.com/
Pool: http://z-traffic-pool.eu/

Hello. Is merged mining's feature exists in BitcoinZ blockchain?

Add nodes to your bitcoinz.config:

addnode=52.207.253.9
addnode=34.211.79.94
addnode=62.12.7.151
addnode=37.148.210.108
addnode=123.30.249.195
addnode=144.217.169.194
addnode=51.15.215.235
addnode=51.15.52.15
addnode=btzseed.blockhub.info
addnode=dnsseed.kemperink.org
addnode=seed.btcz.life
addnode=btcz.vnminers.com
addnode=node-am1.btcz.pro
addnode=node-fr1.btcz.pro
addnode=btcz-us.crypt29.net
addnode=sp6lvlurevy4fplr.onion
addnode=xiv7crijwn4i4hwj.onion

https://c-cex.com/?id=ws&shownodes=btcz
http://www.zpool.ca/explorer/peers?id=2520

can you commit centos for bitcoinz release ?

Hey. I think you should look at this to see if you're vulnerable. I've raised a ticket with github to let you know through their notification system. The CVE details were submitted this morning but haven't been changed at the mitre end yet.

Title

BCTV14 setup produces elements that violate soundness leading to Counterfeiting Vulnerability in Zcash and others

Description

The construction described by [BCTV14] in Appendix B, is a variant of the [PGHR13] zk-SNARK scheme with modifications to improve performance. This scheme was used in the original 2016 launch of Zcash and has been independently implemented by several other projects.

Ariel Gabizon, while working for the Zcash company, discovered a soundness bug in [BCTV14] that is described in this security notice:

The key generation procedure of [BCTV14], in step 3, produces various elements that are the result of evaluating polynomials related to the statement being proven. Some of these elements are unused by the prover and were included by mistake; but their presence allows a cheating prover to circumvent a consistency check, and thereby transform the proof of one statement into a valid-looking proof of a different statement. This breaks the soundness of the proof system. We refer to these elements as “bypass elements.”

The [BGG17] multi-party computation (MPC) protocol that produces parameters for the [BCTV14] construction follows the setup procedure closely, and so the bypass elements are produced. They are not included in the actual proving key distributed to Zcash nodes since they are explicitly excluded from the parameter file format used by the proving routine implementation of [BCTV14] in the “libsnark” library (used by Sprout). However, these elements do appear in the MPC ceremony transcript. Consequently, anyone with access to the ceremony transcript would have been able to create false proofs.

The vulnerability also affects an older MPC scheme [BCGTV15]. This vulnerability was also included in some independent implementations of [BCTV14], such as [snarkjs], even though they do not require an MPC. Similar flaws can be found in the [BBFR14] and [Fuchsbauer17] zk-SNARK schemes, which are adaptations of [BCTV14].

Impact

The ability to break soundness in the proving system permits the creation of false proofs. Zero-knowledge proofs are used in a system like Zcash to ensure that transactions are valid, so this bug this implies the ability to create an unlimited amount of shielded coins where the verifier is affected by this bug.

Credit

This vulnerability was discovered by Ariel Gabizon while he was working for the Zerocoin Electric Coin Company.

What is affected?

Any project that implements [BCTV14] and does not completely dispose of the bypass elements as part of the setup process.

That includes but is not limited to any project that depends on the trusted setup used by the original Sprout system that was distributed in the initial 2016 launch of Zcash. This original Sprout system for shielded funds is comprised of the original Sprout circuit, the [BCTV14] proving system using libsnark, and the parameters generated by an MPC ceremony [BGG17]. It was used by the 1.x series of Zcash software (which also carried the “Sprout” name).

[BCTV14] is available at https://eprint.iacr.org/2013/879

The original Sprout circuit implementation is here: https://github.com/zcash/zcash/tree/32d3a3352e45457f689585cc49d554599583bbd0/src/zcash/circuit

The original Sprout zk-SNARK parameters are here: https://z.cash/downloads/sprout-proving.key (sha256sum: 8bc20a7f013b2b58970cddd2e7ea028975c88ae7ceb9259a5344a16bc2c0eef7) and https://z.cash/downloads/sprout-verifying.key (sha256sum: 4bd498dae0aacfd8e98dc306338d017d9c08dd0918ead18172bd0aec2fc5df82)

The Sprout proving and verifying routines are here: https://github.com/zcash/zcash/blob/685c0ab07fd90b244dac5e2cb1f069ac6151ec5c/src/zcash/JoinSplit.cpp

The BCTV14 proving system implementation (in libsnark) is here: https://github.com/zcash/zcash/tree/c938fb1f179d9bdefc5bc7e55fc6330a8b8d3713/src/snark/libsnark/zk_proof_systems/ppzksnark/r1cs_ppzksnark

What is not affected?

The newer Sprout-on-Groth16 system used by Zcash mainnet for Sprout addresses ever since the Sapling activation (block 419200 at 28 Oct 2018) is not affected by the counterfeiting vulnerability. It uses a new Sprout circuit, that runs on the Groth16 proving system, with new parameters, and operates on the BLS12-381 curve implemented in the Bellman library. The newer Sapling system for shielded funds, activated at the same time and using a new address format, is not vulnerable either.

The vulnerability is not present in the algorithms of [PGHR13] (which underlies [BCTV14]), nor in [BCGTV13], which used similar techniques. It is also not present in other zk-SNARKs constructions, such as [GM17] or [BG18], or in zero-knowledge proof systems that do not rely on a structured reference string. It is not present in libsnark when used with its built-in parameter generator.

The new Sprout-on-Groth16 circuit implementation is located here at time of publishing this information: https://github.com/zcash-hackworks/sapling-crypto/tree/master/src/circuit

The new Sprout-on-Groth16 zk-SNARK parameters are located here at time of publishing this information: https://z.cash/downloads/sprout-groth16.params

The new Sprout-on-Groth16 proving and verifying routines are located in the librustzcash library (at time of publishing): https://github.com/zcash/librustzcash

The Groth16 proving system is implemented in the Bellman Rust library: https://github.com/zkcrypto/bellman

Mitigation

Users of projects still affected by this issue should change the zk-SNARK parameters to some that are not affected by this bug. Zcash switched to new parameters using a new “Sprout-on-Groth16” proving system as of the Sapling network upgrade on October 28th 2018, and so is not affected by the bug.

Therefore, users of Zcash do not need to take any action.

Projects still affected by this vulnerability that do not wish to switch proving systems might instead wish to perform their own parameter setup to produce replacement parameters. Projects following this path are strongly encouraged to use a large, public MPC with thorough security analysis. In the interim, they are advised to disable functionality (e.g., shielded transactions) that relies on the affected proof system.

References

[BCTV14] https://eprint.iacr.org/2013/879

[PGHR13] https://eprint.iacr.org/2013/279

[BGG17] https://eprint.iacr.org/2017/602

[Parno15] https://eprint.iacr.org/2015/437

[BCGTV15] https://www.ieee-security.org/TC/SP2015/papers-archived/6949a287.pdf

[snarkjs] https://github.com/iden3/snarkjs

Papers inheriting this issue from [BCTV14]:

[BBFR14] https://eprint.iacr.org/2014/617

[Fuchsbauer17] https://eprint.iacr.org/2017/587

I went to install BitcoinZ in Linux and I got an error when compiling saying 'Invalid_argument' undefined or something. I also noticed the 'curl' dependency on the directions wasn't listed which was an easy one, but I Googled about the 'Invalid_argument' and someone on Stack Overflow said "it is defined in the header stdexcept Include it..." So I went into crypto/equihash.h and added " #include stdexcept.h " and saved it and it built successfully.

I actually used the greater than and less than signs without the .h Github seemed not to like the greater than and less than signs

1PP8xQSapxb6tJUx7B4Jd7HBhoodmNCVBc

I used https://github.com/litecoinz-project/equihashverify.git verifier, the solutions from zhasher are invalid there but blocks accepted on testnet.

    it('should return true for correct solution test', function(){
          const header = Buffer('04000000c74e2b08bdd2d49b3ec0739b8e52e010fc1c27549c03a5acfb4f05c087f5370076b3691647afcc3911e194b0025186cdee91a7a3b6a6245cc512e843a82b370a0000000000000000000000000000000000000000000000000000000000000000c9a41c5bf6fb4c1f0000040000000000000000019400000000000000000000000000000000000000', 'hex');
          const solution = Buffer('05403bb2784090209e6c5dd90275cde96423c0a595ccfaf0450977494eb94087c17eee0b88c84df606c316def16465a611be0b4a50c4689e498bb8e51a0002506493a0a18a7f43b357baf71565d6f5b245296c2a1fed12c1cb9fc351ac9cae9aff6229eb', 'hex');

          var isValid = equihash.verify(header, solution, 144, 5);

          assert.equal(isValid, true);
      });

The block on testnet with this solution is 18756.

Please clarify how you solutions are special and how to verify them.

Running sudo dpkg -i bitcoinz-1.1.1-a88eb5d-amd64.deb on a system with Zcash node already present gives the following error:

dpkg: error processing archive bitcoinz-1.1.1-a88eb5d-amd64.deb (--install):
trying to overwrite '/usr/bin/zcash-fetch-params', which is also in package zcash 1.0.12