Topic: Vertcoin - First Scrypt N | First Stealth Address - Privacy without mixer - page 457. (Read 1232701 times)
February 08, 2014, 08:28:38 PM
If VTC is not really a full asic resistant then that would still make the coin be at least a year better than any other scrypt coins out there.
February 08, 2014, 08:26:40 PM
Guys,
Dont forget to vote there
Friendly reminder to vote this up (you have multiple votes)
February 08, 2014, 08:24:45 PM
scrypt is based mostly around a tradeoff for memory usage. That is, if you use less memory to generate the hash, more integer operations are required because you have to redo the salsa20/8 (or whatever stream cipher) loops for a specific value that you didn't bother to store in your scratchpad. scrypt functions such that as memory decreases logarithmically, the number of operations required increases exponentially.
Exactly, so you either need more memory on your ASIC which is impractically expensive, or you suffer from an exponential decrease in hashrate because you have to do so many more operations.
Quote
ideally you aren't using massive quantities of SRAM, so you just make a bunch more scrypt processors with smaller amounts of SRAM than would be required in the original implementation of the paper, that are then ran in parallel.
Increasing die-size, decreasing yield and driving up cost per unit. Yeah, for sure, you can trade memory for computation, but you can't do it in a commercially viable way, with any reasonable hashrate for a reasonable cost, which is why we're only just now seeing the beginnings of scrypt ASICs for litecoin and it's clones.
February 08, 2014, 08:18:28 PM
Vtc.Kilovolt.co.uk is back and running on high voltage! Trusted pool run by Aleks_N.
Traditional pool available for VTC, running vardiff and prop payout.
MPOS pool: http://vtc.kilovolt.co.uk
We are back and running at 0% fees to bring users back. Also will offer a 10VTC block finders bonus for the next 10 blocks found. So point your miners back to us and reap the rewards.
Find me on the #vertcoin IRC channel on freenode. Username Aleks_N.
February 08, 2014, 08:14:05 PM
Thanks tacotime for starting this. I would love to see more opinions.
If we got an ASIC designed for N-factor x and the N-factor changes to y. Would the N-factor x ASIC still be efficent on N-facot y?
Not being smart enough makes this 'seem' interesting to me, but to me it just doesn't compute. At best it sounds like it would need to be a brand new, purpose built ASIC to attack N-factor chips, that could be many millions of dollars. Until I see a road map even starting to form, or preferably a working model asic that threatens VTC I think its a non-issue.
February 08, 2014, 08:12:28 PM
February 08, 2014, 08:08:02 PM
Ive been waiting on a deposit on crapsy since 9am yesterday. This is the response support just gave me.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
Yeah i was waiting about 4 hours earlier...when i saw someone post they had been waiting 10 hours for their deposit i said f this and sent them a harsh message with a lot of swearing, they sent me the same email as you, then i got my vert mins later...
Had 20+ h delays on cryptsy... had issues with other coins (lol like if i was the only one over there) BUT!!!!
i found out that their ticketing systems has something maybe built in to for deposit issues...
Everytime something is not depositing, i fill up the ticket form, make sure to specify the coin in the selectable list, and then HOP about 10 minutes later the deposit appairs into the account, but no agent or no reply to the ticket... just go in and mark it as Closed myself, and that's it... been doing this for the past 2-3 weeks and works everytime for me.
Nice. Gonna try that next time...
February 08, 2014, 08:06:00 PM
Thanks tacotime for starting this. I would love to see more opinions.
If we got an ASIC designed for N-factor x and the N-factor changes to y. Would the N-factor x ASIC still be efficent on N-facot y?
If we got an ASIC designed for N-factor x and the N-factor changes to y. Would the N-factor x ASIC still be efficent on N-facot y?
Yes. Adjusting N-factor will not help very much so long as the ASIC already has N-factor set up to be dynamic, which should not be expensive to implement. Making it larger is ideal, but the problem is that GPUs themselves use the same trick ASICs do to calculate hashes for larger N-factors in parallel, so it's not really a huge help.
It's part of the reason I'm dropping scrypt from the next MC2 whitepaper, most likely.
February 08, 2014, 07:51:00 PM
Ive been waiting on a deposit on crapsy since 9am yesterday. This is the response support just gave me.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
Yeah i was waiting about 4 hours earlier...when i saw someone post they had been waiting 10 hours for their deposit i said f this and sent them a harsh message with a lot of swearing, they sent me the same email as you, then i got my vert mins later...
Had 20+ h delays on cryptsy... had issues with other coins (lol like if i was the only one over there) BUT!!!!
i found out that their ticketing systems has something maybe built in to for deposit issues...
Everytime something is not depositing, i fill up the ticket form, make sure to specify the coin in the selectable list, and then HOP about 10 minutes later the deposit appairs into the account, but no agent or no reply to the ticket... just go in and mark it as Closed myself, and that's it... been doing this for the past 2-3 weeks and works everytime for me.
February 08, 2014, 07:50:34 PM
I think you need to break this down for me in-detail. I don't understand chip design. However my brain is computing what you are saying as "solder on some doo-hickies and make go faster". I was under the understanding that aspects of the hash equation are being stored (floating?) in active memory waiting to be re-addressed or re-utilized or whatever is going on. Less memory, less-computational storage, less speed/fewer threads/streams to get the hash IN and OUT complete. Therefore no amount of additional circuitry that regenerates anything is going to help you. Its simply down to transistor/die count and the amount of fast-access memory close by to be the sandbox. The bigger the sandbox the better.
If there was this simple short-cut to undermine N-factor, N-factor would be useless. I thought that using lookup-Gap to hash in less memory would require more hash cycles, if that is what 'this circuitry' is doing.
If there was this simple short-cut to undermine N-factor, N-factor would be useless. I thought that using lookup-Gap to hash in less memory would require more hash cycles, if that is what 'this circuitry' is doing.
scrypt is based mostly around a tradeoff for memory usage. That is, if you use less memory to generate the hash, more integer operations are required because you have to redo the salsa20/8 (or whatever stream cipher) loops for a specific value that you didn't bother to store in your scratchpad. scrypt functions such that as memory decreases logarithmically, the number of operations required increases exponentially.
I guess the ELI5 would be: you can run scrypt in log(x) many clock cycles with memory x, or you can run scrypt in x many clock cycles with memory log(x). For ASICs, ideally you aren't using massive quantities of SRAM, so you just make a bunch more scrypt processors with smaller amounts of SRAM than would be required in the original implementation of the paper, that are then ran in parallel. FPGA still struggles with this implementation, but then when you push it to an ASIC, it functions fairly efficiently (it's been suspected that the GridSeed chips are simply using a direct synthesis of one of the fast published FPGA code available on GitHub).
Thanks tacotime for starting this. I would love to see more opinions.
If we got an ASIC designed for N-factor x and the N-factor changes to y. Would the N-factor x ASIC still be efficent on N-facot y?
February 08, 2014, 07:45:30 PM
I think you need to break this down for me in-detail. I don't understand chip design. However my brain is computing what you are saying as "solder on some doo-hickies and make go faster". I was under the understanding that aspects of the hash equation are being stored (floating?) in active memory waiting to be re-addressed or re-utilized or whatever is going on. Less memory, less-computational storage, less speed/fewer threads/streams to get the hash IN and OUT complete. Therefore no amount of additional circuitry that regenerates anything is going to help you. Its simply down to transistor/die count and the amount of fast-access memory close by to be the sandbox. The bigger the sandbox the better.
If there was this simple short-cut to undermine N-factor, N-factor would be useless. I thought that using lookup-Gap to hash in less memory would require more hash cycles, if that is what 'this circuitry' is doing.
If there was this simple short-cut to undermine N-factor, N-factor would be useless. I thought that using lookup-Gap to hash in less memory would require more hash cycles, if that is what 'this circuitry' is doing.
scrypt is based mostly around a tradeoff for memory usage. That is, if you use less memory to generate the hash, more integer operations are required because you have to redo the salsa20/8 (or whatever stream cipher) loops for a specific value that you didn't bother to store in your scratchpad. scrypt functions such that as memory decreases logarithmically, the number of operations required increases exponentially.
I guess the ELI5 would be: you can run scrypt in log(x) many clock cycles with memory x, or you can run scrypt in x many clock cycles with memory log(x). For ASICs, ideally you aren't using massive quantities of SRAM, so you just make a bunch more scrypt processors with smaller amounts of SRAM than would be required in the original implementation of the paper, that are then ran in parallel. FPGA still struggles with this implementation to provide performance in any cost reasonable sense (it's still more efficient), but then when you push it to an ASIC, it functions fairly efficiently (it's been suspected that the GridSeed chips are simply using a direct synthesis of one of the fast published FPGA code available on GitHub).
February 08, 2014, 07:38:10 PM
Yes and just to clarify, I was being dumb - it's actually ZeroCash we're looking at, not ZeroCoin.
Are you sure? AFAIK Zerocash is the altcoin Matt will release while Zerocoin is the library already released that ANC want to implement. As far as I have understood what he said in Real World Cryptography Workshop 13-15 january 2014 the design of Zerocash completely remove the bitcoin blockchain like we know it replacing it by zk-Snark in a different implementation to hide every transactions while verifying sums and differences to have correct count of coins. This is not adaptable IMHO to a bitcoin-like blockchain such as vertcoin one. Only Zerocoin which is token based can be implemented as a library but by itself it also suffer some defect like Matt said in his presentation. Hence I think what you want to implement is the Zerocoin library and not the Zerocash altcoin. Libzerocoin as found on Github https://github.com/zerocoin.
Or am I wrong?
February 08, 2014, 07:36:10 PM
The ASICs themselves don't need more than 64-128 KB of SRAM per circuit to be able to hash much more efficiently than a GPU for any N.
Sure, so would FPGA's but at what cost? I mean really at what cost?
Gen1 Grid seed and Alpha T will suck at VTC mining, Yeah they might do it at a better Hash/KWh out of the gate but there is much more to consider. Such as re-sale value (in case of crypto-crash) and the premium needed to aquire the ASIC's to start off with.
So, fast forward to Gen 2, or more preferably Gen 3, GridSeed. Its got more ram, Its faster, its 24nm or whatever. Its pretty sweet for mining VTC by todays standards. But what about AMD/Nvidia/Intels next chips, The ones that are still just multi-million dollar computer models at the moment. Those are getting faster too.
Unless scrypt ASIC rolls out way different than BTC asic in some way. I don't forecast a point I can forsee where I would rather have some $7,000K Propriety black box to get 30Mhash Scrypt (15Mhash VTC) When I can buy AMD R11 980X Ultra's for $499 MSRP. For all we know these future serious cards might hash at 2Mhs scrypt.
I'm betting my money that GPU's will need to run, One way or another for a *long* time. Regardless of grid-seed or whomever is doing behind closed doors at the moment.
You don't need more RAM; at the current level of RAM it is possible to mine VertCoin with approximately the same efficiency as LTC. This is true for the upcoming adjustments in N values, too. You just need to add a few circuits to regenerate some values on the fly when necessary, for whatever N value.
Which means that when Joe the ASIC wafer designer who makes ASICs for Litecoin sees that VertCoin has some value, he can add these circuits for barely any design overhead to his next generation of ASICs and then we're left with very early ASIC adoption for VertCoin, which is exactly what you guys sought to avoid.
I think you need to break this down for me in-detail. I don't understand chip design. However my brain is computing what you are saying as "solder on some doo-hickies and make go faster". I was under the understanding that aspects of the hash equation are being stored (floating?) in active memory waiting to be re-addressed or re-utilized or whatever is going on. Less memory, less-computational storage, less speed/fewer threads/streams to get the hash IN and OUT complete. Therefore no amount of additional circuitry that regenerates anything is going to help you. Its simply down to transistor/die count and the amount of fast-access memory close by to be the sandbox. The bigger the sandbox the better.
If there was this simple short-cut to undermine N-factor, N-factor would be useless. I thought that using lookup-Gap to hash in less memory would require more hash cycles, if that is what 'this circuitry' is doing.
February 08, 2014, 07:29:20 PM
Ive been waiting on a deposit on crapsy since 9am yesterday. This is the response support just gave me.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
Yeah i was waiting about 4 hours earlier...when i saw someone post they had been waiting 10 hours for their deposit i said f this and sent them a harsh message with a lot of swearing, they sent me the same email as you, then i got my vert mins later...
February 08, 2014, 07:26:21 PM
Exactly what are "just a few circuits"? Relatively technical so don't hold back, you seem extremely familiar w/ vlsi design and it would be great to elaborate. And why would these values be calculated on the fly, rather than flipping a hard switch to set your iterations?
It's the implementation of the function reported below in cl code. All you have to do is make N, LOOKUP_GAP, and CONCURRENT_THREADS dynamic.
Code:
void scrypt_core(uint4 X[8], __global uint4*restrict lookup)
{
shittify(X);
const uint zSIZE = 8;
const uint ySIZE = (N/LOOKUP_GAP+(N%LOOKUP_GAP>0));
const uint xSIZE = CONCURRENT_THREADS;
uint x = get_global_id(0)%xSIZE;
for(uint y=0; y
#pragma unroll
for(uint z=0; z
for(uint i=0; i
}
#if (LOOKUP_GAP != 1) && (LOOKUP_GAP != 2) && (LOOKUP_GAP != 4) && (LOOKUP_GAP != 8)
{
uint y = (N/LOOKUP_GAP);
#pragma unroll
for(uint z=0; z
for(uint i=0; i
}
#endif
for (uint i=0; i
uint4 V[8];
uint j = X[7].x & K[85];
uint y = (j/LOOKUP_GAP);
#pragma unroll
for(uint z=0; z
#if (LOOKUP_GAP == 1)
#elif (LOOKUP_GAP == 2)
if (j&1)
salsa(V);
#else
uint val = j%LOOKUP_GAP;
for (uint z=0; z
#endif
#pragma unroll
for(uint z=0; z
salsa(X);
}
unshittify(X);
}
{
shittify(X);
const uint zSIZE = 8;
const uint ySIZE = (N/LOOKUP_GAP+(N%LOOKUP_GAP>0));
const uint xSIZE = CONCURRENT_THREADS;
uint x = get_global_id(0)%xSIZE;
for(uint y=0; y
#pragma unroll
for(uint z=0; z
for(uint i=0; i
}
#if (LOOKUP_GAP != 1) && (LOOKUP_GAP != 2) && (LOOKUP_GAP != 4) && (LOOKUP_GAP != 8)
{
uint y = (N/LOOKUP_GAP);
#pragma unroll
for(uint z=0; z
for(uint i=0; i
}
#endif
for (uint i=0; i
uint4 V[8];
uint j = X[7].x & K[85];
uint y = (j/LOOKUP_GAP);
#pragma unroll
for(uint z=0; z
#if (LOOKUP_GAP == 1)
#elif (LOOKUP_GAP == 2)
if (j&1)
salsa(V);
#else
uint val = j%LOOKUP_GAP;
for (uint z=0; z
#endif
#pragma unroll
for(uint z=0; z
salsa(X);
}
unshittify(X);
}
It's not a leap of faith to see this hard coded into an ASIC, though I'm not overly familiar with FPGA/ASIC design, Verilog synthesis, etc. (talk to Peter Todd about that, ideally)
Why I say "on-the-fly" I'm referring to the way the TMTO algorithms usually work... You write every nth value to the table (scratchpad) where n is the LOOKUP_GAP, and execute it on c many CONCURRENT_THREADS. When you need a value that hasn't been stored in the partially generated scratchpad, you generate it as necessary.
February 08, 2014, 07:25:35 PM
I've got 16,8VTC on p2p in 24hours with 30min downtime at 2,152Mh/s... P2p rocks, it's more than predicted..it's due to optimized settings so I get 10% less rejects than network, so it's like 10% more payment...Just heads up for everyone struggling with normal pools...I guess results would be even better if I knew how to setup own nod 
Try this manual http://www.reddit.com/r/dogemining/comments/1wmw3j/how_to_setup_p2pool_locally_windows/ and if you success, then try with your working knowledge setup this https://github.com/donSchoe/p2pool-vtc and its done. I made my own VTC p2pool just a little while ago.
February 08, 2014, 07:16:53 PM
Ive been waiting on a deposit on crapsy since 9am yesterday. This is the response support just gave me.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
VertCoin (VTC) is under maintenance. It will return soon and deposits will then go through.
Sorry for the delay and thank you kindly for your patience.
February 08, 2014, 07:13:26 PM
The ASICs themselves don't need more than 64-128 KB of SRAM per circuit to be able to hash much more efficiently than a GPU for any N.
Sure, so would FPGA's but at what cost? I mean really at what cost?
Gen1 Grid seed and Alpha T will suck at VTC mining, Yeah they might do it at a better Hash/KWh out of the gate but there is much more to consider. Such as re-sale value (in case of crypto-crash) and the premium needed to aquire the ASIC's to start off with.
So, fast forward to Gen 2, or more preferably Gen 3, GridSeed. Its got more ram, Its faster, its 24nm or whatever. Its pretty sweet for mining VTC by todays standards. But what about AMD/Nvidia/Intels next chips, The ones that are still just multi-million dollar computer models at the moment. Those are getting faster too.
Unless scrypt ASIC rolls out way different than BTC asic in some way. I don't forecast a point I can forsee where I would rather have some $7,000K Propriety black box to get 30Mhash Scrypt (15Mhash VTC) When I can buy AMD R11 980X Ultra's for $499 MSRP. For all we know these future serious cards might hash at 2Mhs scrypt.
I'm betting my money that GPU's will need to run, One way or another for a *long* time. Regardless of grid-seed or whomever is doing behind closed doors at the moment.
You don't need more RAM; at the current level of RAM it is possible to mine VertCoin with approximately the same efficiency as LTC. This is true for the upcoming adjustments in N values, too. You just need to add a few circuits to regenerate some values on the fly when necessary, for whatever N value.
Which means that when Joe the ASIC wafer designer who makes ASICs for Litecoin sees that VertCoin has some value, he can add these circuits for barely any design overhead to his next generation of ASICs and then we're left with very early ASIC adoption for VertCoin, which is exactly what you guys sought to avoid.
Exactly what are "just a few circuits"? Relatively technical so don't hold back, you seem extremely familiar w/ vlsi design and it would be great to elaborate. And why would these values be calculated on the fly, rather than flipping a hard switch to set your iterations?
February 08, 2014, 07:11:57 PM
Damn .... down to 0.00450000
Where at? I'm hoarding at that price. Certainly not at crapsy...it's still over .005 there....0049 at the lowest.
February 08, 2014, 07:10:49 PM
Thank you. Finally someone is having a discussion about whether or not Adaptive N-factor is truly the answer to ASICs. I definitely want to hear more of this. I myself have no clue and am far from being a programmer. But this seems like something to discuss because people and competitors to this coin are going to start questioning the authenticity of the claim that it is basically ASIC proof. I must admit I am waiting to see which way the wind blows, yet am mining a few for myself.
Jump to: