Topic: [ANN] Zcoin (XZC) - Implementing ZKP privacy without trusted setup - page 69. (Read 663349 times)
May 10, 2018, 02:53:24 AM
I like this project!Zcoin must be grow fast because good team develop it. I guess I will invest in this coin. Waiting for success! So.. Will see
May 10, 2018, 02:11:20 AM
zcoin is underrated. The project and dev team is strong. The masternode is quite attractive as well. A good balance between PoW and PoS.
May 10, 2018, 01:18:15 AM
i wonder where xzc hashpower comes from, as it seems it`s non profitable to mine at current prices.
Any ideas guys?
Any ideas guys?
Botnets
Actually zcoin is currently THE most profitable coin for AMD cards using tdxminer
https://bitcointalksearch.org/topic/tdxminer-lyra2zxzc-miner-for-amd-gpus-on-linux-3299496
I get ~ 3.5 MHs per rx580, which is on par as 1080ti. It is linux only so maybe that is whats keepeng people away from it.
May 10, 2018, 12:25:14 AM
I've gone through most recent pages, but none of the discord links work;;; they all expired.
(i've gone through official website and other websites that introduce zcoin.. but none worked xD
can someone please share an invite? thanks!
(i've gone through official website and other websites that introduce zcoin.. but none worked xD
can someone please share an invite? thanks!
May 09, 2018, 10:28:57 PM
Show your support for Zcoin in the t.me/setupmasternodes community!
As always! Things are looking good for ZNODES and we are excited about the movement this coin is making. Great work Devs!
May 09, 2018, 06:18:23 PM
Show your support for Zcoin in the t.me/setupmasternodes community!
May 09, 2018, 03:47:09 AM
i wonder where xzc hashpower comes from, as it seems it`s non profitable to mine at current prices.
Any ideas guys?
Any ideas guys?
Botnets
May 09, 2018, 03:46:13 AM
Hi!
I took the time to go through MTP v1.2 in-depth a few days ago from an AMD implementation perspective, posting the results below.
Cheers,
K
---------------
Static analysis of an AMD GCN assembly implementation of MTP v1.2
=================================================================
TL;DR
- MTP v1.2 will be an intensive algorithm with very high power draw and general GPU load.
- An optimized AMD miner with a similar profile is Claymore's Neoscrypt miner.
- I would suggest looking into reducing the full Blake2b used in the main rounds to the 4-round Blake2b used for Argon2d.
Analysis
========
MTP v1.2 as defined in the paper [1] pulls 70 quasi-random selections of 1024 bytes from a generated Argon2d block of 2 GB, i.e. the full block can be seen as 2097152 segments of 1024 bytes. Each of the 70 main rounds necessary for a single hash does a full Blake2b hash of 32+1024 bytes of data: the Y-1 state from the previous round (32 bytes) and the loaded Argon2d segment (1024 bytes). A single Blake2b compress call can process a block of max 128 bytes. This means we need 9 blocks to hash the full 32+1024 bytes.
Blake2b is quite trivial to implement. Assuming a fully unrolled version with no extra overhead:
- 12 rounds needed for a single block of 128 bytes to compress.
- 8 G-function calls per round.
- 26 four-cycle asm instructions per G-function call.
Expanding to MTP v1.2:
- We need 12*8*26 = 2,496 four-cycle instructions per block of 128 bytes.
- For hashing a full round in MTP v1.2, we need nine blocks to cover 32+1024 bytes, resulting in 9*2496 = 22,464 four-cycle instructions.
- For a single MTP v1.2 hash (including only the main 70 rounds of computation with random Argon2d selections) we need 1,572,480 four-cycle instructions.
A single AMD GCN Compute Unit (CU) at X MHz clk can process max X/4 * 4 SIMDs * 64 threads four-cycle instructions/sec. This means that 64X / 1572480 is the theoretical max nr of hashes possible for one CU. Note that this assumes zero cost for all setup code, initial hash, memory loads etc so it's very much a theoretical upper limit - the true number will be lower.
Reference cards max hash rates:
Vega64 @ 1408 main clk: 64 CUs * 64*1408*10^6 / 1572480 =~ 3.67 MH/s
Rx580 @ 1256 main clk: 36 CUs * 64*1256*10^6 / 1572480 =~ 1.84 MH/s
The numbers above are upper bounds for the maximum possible hashrate when each card is running with a 100% busy VALU, i.e. doing nothing but crunching numbers and never stalling for memory loads. Next, we analyze what mem bandwidth is necessary to sustain a 100% busy VALU for the above cards and clocks. If the mem controller will be able to provide enough bandwidth, the algorithm will be computationally bound, otherwise memory bound.
For a single hash, you need to process 70kb of Argon2d segments. For the Vega64, this means approx 70*1024*3.67*10^6 = 244 GB/sec. For the Rx580, it's 70*1024*1.84*10^6 = 122 GB/s.
These numbers are by no means high enough to indicate that the mem controller will be the bottleneck in MTP v1.2. Moreover, with the relatively high cost of 2496 instructions between memory loads, internal latency hiding is trivial. This means you issue the next 128 byte memory load before you do a full Blake2b hash. Hence, given this information I draw the conclusion that an optimized AMD implementation of MTP v1.2 will _not_ be memory bound and bottlenecked by available memory bandwidth. Instead, all stream processors will continuously be running at 100% with the mem controller working quite hard to keep up as well. Assuming you want maximum possible hashrate, the end result is a very high power draw and high pressure on the GPU.
Comparisons to other hash functions
===================================
For further analysis, some relevant comparisons to other memory-intensive hash functions follow below. A relevant metric used in the comparisons is the nr of four-cycle instructions of raw calculations needed per loaded cacheline before you can make further progress in the algorithm. For MTP v1.2 this is 1248 instrs/cacheline, assuming we do the natural thing and load 128 bytes at the time for Blake2b hashing.
Ethash
------
Ethash loads 128 bytes per round in its main part. It does 64 rounds instead of 70 as in MTP v1.2. For an Rx 580, we can assume a max hashrate of 30 MH/s at 1256 clk. We know that this is a low estimate of the point where memory becomes the bottleneck. The effective bandwidth is then 30*10^6 * 64 * 128 = 228 GB/s, far above the 122 GB/s necessary for MTP v1.2 running on the same card. For a Vega64, the standard ethash reference hashrate is ~40 MH/s. This means a bandwidth of 40*10^6 * 64 * 128 = 305 GB/s, again more than enough to drive MTP v1.2 as a computationally bound algorithm.
The main difference between the two hash functions (in the analyzed main parts) is the nr of four-cycle instructions necessary to process 128 bytes. A decent asm implementation will do FNV in 5 four-cycle instruction equivalents, so 64*5 = 320 instructions, then assume 10 instructions for the set up for the next round = 330 instructions. Per loaded cacheline, this means 165 instructions, or only 13.2% of the 1248 instructions necessary in MTP v1.2.
Neoscrypt
---------
Neoscrypt does 512 main rounds divided into four distinct parts: store 128 rows of 256 bytes, read 128 quasi-random rows of 256 bytes, store 128 rows of 256 bytes, read 128 quasi-random rows of 256 bytes. For simplicity, we treat reading/writing as an aggregated single bandwidth. In each of the 512 rounds, either a full salsa or chacha round is calculated on 256 bytes, 64 bytes at the time. Salsa and chacha do 10 rounds of 96 instructions, so 960 instructions per call, and there are four such calls in each of the 512 rounds, which also means 960 instructions/loaded cacheline.
Hence, this algorithm, that we know becomes computationally bound in Claymore's asm miner, still needs LESS VALU-bound work per loaded cacheline vs MTP v1.2: 960 instrs vs 1248 instrs. And, the power draw profile of Claymore's miner is well known - to maximize your hashrate, your GPU needs to be running full throttle for the VALU (main clock) and preferable also for the mem controller, the end result being a very high power draw. An optimized AMD miner for MTP v1.2 will exhibit the same characteristics and power draw profile.
Discussion
==========
I don't believe the Zcoin community is fully aware of the characteristics of the upcoming algo, hence this post. I can only speak for how this would be implemented on modern AMD GPUs, but I see no reason for why the implementation would behave differently on Nvidia cards - the issue is in the algorithm design. Imho, the main issue is the full Blake2b hash with 12 rounds requiring too much computational work to process each loaded chunk of memory. Therefore, before MTP is pushed out in its currently suggested form it would certainly be interesting to hear what the researchers behind MTP think about e.g. reducing the hash used to the same 4-round Blake2b that they suggest themselves for the first Argon2d part. If still deemed cryptograhically safe, this would reduce the key metric used above with -67%. MTP would still be above ethash in terms of computations vs memory loads and power draw characteristics, but it would significantly lower the stress on mining GPUs.
Disclaimer
==========
I might very well have made an error or two in the analysis and calculations above, like a bad assumption on the nr of instructions necessary for ethash. However, I do not believe any such error would have an impact on the drawn conclusions.
References
==========
[1] https://arxiv.org/pdf/1606.03588.pdf
I took the time to go through MTP v1.2 in-depth a few days ago from an AMD implementation perspective, posting the results below.
Cheers,
K
---------------
Static analysis of an AMD GCN assembly implementation of MTP v1.2
=================================================================
TL;DR
- MTP v1.2 will be an intensive algorithm with very high power draw and general GPU load.
- An optimized AMD miner with a similar profile is Claymore's Neoscrypt miner.
- I would suggest looking into reducing the full Blake2b used in the main rounds to the 4-round Blake2b used for Argon2d.
Analysis
========
MTP v1.2 as defined in the paper [1] pulls 70 quasi-random selections of 1024 bytes from a generated Argon2d block of 2 GB, i.e. the full block can be seen as 2097152 segments of 1024 bytes. Each of the 70 main rounds necessary for a single hash does a full Blake2b hash of 32+1024 bytes of data: the Y-1 state from the previous round (32 bytes) and the loaded Argon2d segment (1024 bytes). A single Blake2b compress call can process a block of max 128 bytes. This means we need 9 blocks to hash the full 32+1024 bytes.
Blake2b is quite trivial to implement. Assuming a fully unrolled version with no extra overhead:
- 12 rounds needed for a single block of 128 bytes to compress.
- 8 G-function calls per round.
- 26 four-cycle asm instructions per G-function call.
Expanding to MTP v1.2:
- We need 12*8*26 = 2,496 four-cycle instructions per block of 128 bytes.
- For hashing a full round in MTP v1.2, we need nine blocks to cover 32+1024 bytes, resulting in 9*2496 = 22,464 four-cycle instructions.
- For a single MTP v1.2 hash (including only the main 70 rounds of computation with random Argon2d selections) we need 1,572,480 four-cycle instructions.
A single AMD GCN Compute Unit (CU) at X MHz clk can process max X/4 * 4 SIMDs * 64 threads four-cycle instructions/sec. This means that 64X / 1572480 is the theoretical max nr of hashes possible for one CU. Note that this assumes zero cost for all setup code, initial hash, memory loads etc so it's very much a theoretical upper limit - the true number will be lower.
Reference cards max hash rates:
Vega64 @ 1408 main clk: 64 CUs * 64*1408*10^6 / 1572480 =~ 3.67 MH/s
Rx580 @ 1256 main clk: 36 CUs * 64*1256*10^6 / 1572480 =~ 1.84 MH/s
The numbers above are upper bounds for the maximum possible hashrate when each card is running with a 100% busy VALU, i.e. doing nothing but crunching numbers and never stalling for memory loads. Next, we analyze what mem bandwidth is necessary to sustain a 100% busy VALU for the above cards and clocks. If the mem controller will be able to provide enough bandwidth, the algorithm will be computationally bound, otherwise memory bound.
For a single hash, you need to process 70kb of Argon2d segments. For the Vega64, this means approx 70*1024*3.67*10^6 = 244 GB/sec. For the Rx580, it's 70*1024*1.84*10^6 = 122 GB/s.
These numbers are by no means high enough to indicate that the mem controller will be the bottleneck in MTP v1.2. Moreover, with the relatively high cost of 2496 instructions between memory loads, internal latency hiding is trivial. This means you issue the next 128 byte memory load before you do a full Blake2b hash. Hence, given this information I draw the conclusion that an optimized AMD implementation of MTP v1.2 will _not_ be memory bound and bottlenecked by available memory bandwidth. Instead, all stream processors will continuously be running at 100% with the mem controller working quite hard to keep up as well. Assuming you want maximum possible hashrate, the end result is a very high power draw and high pressure on the GPU.
Comparisons to other hash functions
===================================
For further analysis, some relevant comparisons to other memory-intensive hash functions follow below. A relevant metric used in the comparisons is the nr of four-cycle instructions of raw calculations needed per loaded cacheline before you can make further progress in the algorithm. For MTP v1.2 this is 1248 instrs/cacheline, assuming we do the natural thing and load 128 bytes at the time for Blake2b hashing.
Ethash
------
Ethash loads 128 bytes per round in its main part. It does 64 rounds instead of 70 as in MTP v1.2. For an Rx 580, we can assume a max hashrate of 30 MH/s at 1256 clk. We know that this is a low estimate of the point where memory becomes the bottleneck. The effective bandwidth is then 30*10^6 * 64 * 128 = 228 GB/s, far above the 122 GB/s necessary for MTP v1.2 running on the same card. For a Vega64, the standard ethash reference hashrate is ~40 MH/s. This means a bandwidth of 40*10^6 * 64 * 128 = 305 GB/s, again more than enough to drive MTP v1.2 as a computationally bound algorithm.
The main difference between the two hash functions (in the analyzed main parts) is the nr of four-cycle instructions necessary to process 128 bytes. A decent asm implementation will do FNV in 5 four-cycle instruction equivalents, so 64*5 = 320 instructions, then assume 10 instructions for the set up for the next round = 330 instructions. Per loaded cacheline, this means 165 instructions, or only 13.2% of the 1248 instructions necessary in MTP v1.2.
Neoscrypt
---------
Neoscrypt does 512 main rounds divided into four distinct parts: store 128 rows of 256 bytes, read 128 quasi-random rows of 256 bytes, store 128 rows of 256 bytes, read 128 quasi-random rows of 256 bytes. For simplicity, we treat reading/writing as an aggregated single bandwidth. In each of the 512 rounds, either a full salsa or chacha round is calculated on 256 bytes, 64 bytes at the time. Salsa and chacha do 10 rounds of 96 instructions, so 960 instructions per call, and there are four such calls in each of the 512 rounds, which also means 960 instructions/loaded cacheline.
Hence, this algorithm, that we know becomes computationally bound in Claymore's asm miner, still needs LESS VALU-bound work per loaded cacheline vs MTP v1.2: 960 instrs vs 1248 instrs. And, the power draw profile of Claymore's miner is well known - to maximize your hashrate, your GPU needs to be running full throttle for the VALU (main clock) and preferable also for the mem controller, the end result being a very high power draw. An optimized AMD miner for MTP v1.2 will exhibit the same characteristics and power draw profile.
Discussion
==========
I don't believe the Zcoin community is fully aware of the characteristics of the upcoming algo, hence this post. I can only speak for how this would be implemented on modern AMD GPUs, but I see no reason for why the implementation would behave differently on Nvidia cards - the issue is in the algorithm design. Imho, the main issue is the full Blake2b hash with 12 rounds requiring too much computational work to process each loaded chunk of memory. Therefore, before MTP is pushed out in its currently suggested form it would certainly be interesting to hear what the researchers behind MTP think about e.g. reducing the hash used to the same 4-round Blake2b that they suggest themselves for the first Argon2d part. If still deemed cryptograhically safe, this would reduce the key metric used above with -67%. MTP would still be above ethash in terms of computations vs memory loads and power draw characteristics, but it would significantly lower the stress on mining GPUs.
Disclaimer
==========
I might very well have made an error or two in the analysis and calculations above, like a bad assumption on the nr of instructions necessary for ethash. However, I do not believe any such error would have an impact on the drawn conclusions.
References
==========
[1] https://arxiv.org/pdf/1606.03588.pdf
May 08, 2018, 09:08:20 PM
i wonder where xzc hashpower comes from, as it seems it`s non profitable to mine at current prices.
Any ideas guys?
Because we know the pirce of the xzc will be up!It was underrated Any ideas guys?
May 08, 2018, 08:14:40 PM
i wonder where xzc hashpower comes from, as it seems it`s non profitable to mine at current prices.
Any ideas guys?
Any ideas guys?
May 08, 2018, 07:02:49 PM
What do people like the most about Zcoin's Masternodes?
May 08, 2018, 05:15:05 PM
I like the current price of the coin, but I would like to be higher, I hope soon to see the coin in the top 50 coinmarketcap
May 08, 2018, 04:58:54 PM
Do you know why the BITTREX wallet is in "Automated maintenance" ?
Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
This is the Bittrex support answer to the unavailable XZC wallet in their exchange :Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
Quote
XZC wallet will remain in maintenance until the network is determined to be stable and secure. At this time there is no ETA for when that will happen.
Is there some issues with the XZC network 
My personnal wallet is syncing well and no problem in my side...
For you, any issue ?
I suspect there was an issue with the French drop update (https://zcoin.io/zcoin-0-13-5-7-french-drop-upgrade-guide/) and many nodes were dropped from the network. All my updated nodes required a new start and then expired. I had to fully reset the VPSs and do the regular install all over again: https://zcoin.io/zcoin-znode-setup-guide/.
They are fine now.
UPDATE: it is likely many people still have version ~.7 or lower and can get their znode running again with this guide: https://zcoinkb.wordpress.com/2018/05/07/0-13-5-7-nodes-in-expired-status/ You will still need a restart of the node.
You can see the drop in this picture of about 40%:
40% of the masternodes lost their place in the masternode reward queue (because the reboot) ?
The Bittrex wallet is out since more 12 hours now : nobody to make the update and reboot of one of the top 100 crypto (my first ticket message was 12,5 hours ago).
I do not congraculate Bittrex.
May 08, 2018, 03:28:49 PM
Do you know why the BITTREX wallet is in "Automated maintenance" ?
Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
This is the Bittrex support answer to the unavailable XZC wallet in their exchange :Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
Quote
XZC wallet will remain in maintenance until the network is determined to be stable and secure. At this time there is no ETA for when that will happen.
Is there some issues with the XZC network My personnal wallet is syncing well and no problem in my side...
For you, any issue ?
I suspect there was an issue with the French drop update (https://zcoin.io/zcoin-0-13-5-7-french-drop-upgrade-guide/) and many nodes were dropped from the network. All my updated nodes required a new start and then expired. I had to fully reset the VPSs and do the regular install all over again: https://zcoin.io/zcoin-znode-setup-guide/.
They are fine now.
UPDATE: it is likely many people still have version ~.7 or lower and can get their znode running again with this guide: https://zcoinkb.wordpress.com/2018/05/07/0-13-5-7-nodes-in-expired-status/ You will still need a restart of the node.
You can see the drop in this picture of about 40%:
May 08, 2018, 02:25:03 PM
Do you know why the BITTREX wallet is in "Automated maintenance" ?
Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
This is the Bittrex support answer to the unavailable XZC wallet in their exchange :Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
Quote
XZC wallet will remain in maintenance until the network is determined to be stable and secure. At this time there is no ETA for when that will happen.
Is there some issues with the XZC network My personnal wallet is syncing well and no problem in my side...
For you, any issue ?
May 08, 2018, 11:48:38 AM
Who is this privet miner and how much hash-rate do they have to find so many blocks?
https://chainz.cryptoid.info/xzc/address.dws?a69iYfxDwwuCnYdVKqscGSaLS2xfu6hDh5.htm
I know that this is F2pool:
https://chainz.cryptoid.info/xzc/address.dws?aHBqmMiMzcHpYd9HSsGWnoLnA5GZ8Rn5KJ.htm
and MPH:
https://chainz.cryptoid.info/xzc/address.dws?a5idCcHN8WYxvFCeBXSXvMPrZHuBkZmqEJ.htm
What do you think?
https://chainz.cryptoid.info/xzc/address.dws?a69iYfxDwwuCnYdVKqscGSaLS2xfu6hDh5.htm
I know that this is F2pool:
https://chainz.cryptoid.info/xzc/address.dws?aHBqmMiMzcHpYd9HSsGWnoLnA5GZ8Rn5KJ.htm
and MPH:
https://chainz.cryptoid.info/xzc/address.dws?a5idCcHN8WYxvFCeBXSXvMPrZHuBkZmqEJ.htm
What do you think?
May 08, 2018, 07:55:24 AM
Do you know why the BITTREX wallet is in "Automated maintenance" ?
Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
Since how many time ?
For how long ?
When can I make my transfer to get my xzc out of Bittrex?
Bittrex support is bullshit today : they do not answer my question but says generalities about maintenances.
May 08, 2018, 05:13:16 AM
I'm waitting for the news of MTP everyday 
May 07, 2018, 09:56:17 PM
May 07, 2018, 04:28:36 PM
Good looking Projekt!BTCBTCBTCBTCBTCBTCBTC
Jump to: