|
Title: [BBR] Boolberry Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 02:54:25 AM Let's open hash-function discussion friends.
Just want to uncover our approach and show differences with CryptoNote that we use in our project announced here: https://bitcointalk.org/index.php?topic=577267.0 (https://bitcointalk.org/index.php?topic=577267.0) First of all I want to say that CryptoNote hash function (so called cn_slow_hash) is actually a very strong protected from ASIC's with different CPU instructions set as well as memory consuming algo. cn_slow_hash works hard on 2MB scratchpad and most of this scratchpad are fits in CPU cache. http://honeypenny.org/files/cryptonote_hash.svg For now it is difficult imagine that will be possible to make some specific hardware which will be more effective than CPU and will coast less than CPU. But world changes so fast, nobody knows what will happen in near future. We've all seen how rapid technological breakthroughs capable of performing the computer industry. ??? Since cn_slow_hash created 2MB scratchpad, it's have to cover all this data, that's why they use 220 iterations, and side-effect from this pretty slow work (about 500ms on normal laptop, twice faster on normal pc with suitable cpu cache). It may slow down synchronisation process at downloading blockchain (that is not a big problem) and theoretically it may be possible to attack network - connect and send a random block to make peer calculate slow_hash for useless fake block. So, putting all together, we want to have: 1. Wide CPU instruction set 2. Memory-oriented algo 3. Small work time. Realizing it, we've tried to take a step to the side. Idea of using blockchain data as scratchpad resulted in this hash function: http://boolberry.com/files/boolb_hash.svg Actually this is a keccak hybrid, which use external scratchpad. After each keccack round, psudo-randomly addressed[state vector used as addresses] data is taken from scratchpad and xored with state. Calculating each block PoW usualy hits about 1100 randomly addressed reading of blocks by 32 bytes. I used "performance_tests" with different scratchpad size to find out memory hardness: Quote Warm up: 2161 ms test_wild_keccak<400> - OK: loop count: 100000 elapsed: 3020 ms time per call: 0 ms/call Warm up: 2158 ms test_wild_keccak<40000> - OK: loop count: 100000 elapsed: 3060 ms time per call: 0 ms/call Warm up: 2168 ms test_wild_keccak<4000000> - OK: loop count: 100000 elapsed: 3484 ms time per call: 0 ms/call Warm up: 2156 ms test_wild_keccak<40000000> - OK: loop count: 100000 elapsed: 8119 ms time per call: 0 ms/call Warm up: 2150 ms test_wild_keccak<100000000> - OK: loop count: 100000 elapsed: 8574 ms time per call: 0 ms/call As you can see, working on small amount of memory 100000 hash operations takes 3020 ms, meanwhile work on 100Mb scratchpad with the same operations count takes 8574 ms. Such difference(caused by the cache memory overflow) points to real memory hardness we guess. Wellcome to comment. Title: Re: [HP] Hash-on-blockchain discussion Post by: digicoin on April 29, 2014, 03:10:26 AM Adam Back raises a concern on the possibility to run a SPV client on CryptoNote blockchain. He does not find a way yet. Running a full node is not an option to mobile clients like iPad or Android client. Do you have any improvement on this issue?
Title: Re: [HP] Hash-on-blockchain discussion Post by: digicoin on April 29, 2014, 03:16:40 AM Does keccak in use mean that the coin can be mined using GPU?
Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 04:13:26 AM Adam Back raises a concern on the possibility to run a SPV client on CryptoNote blockchain. He does not find a way yet. Running a full node is not an option to mobile clients like iPad or Android client. Do you have any improvement on this issue? If you don't want to mine on ipad or on android you do nod need to have a node on it - Cryptonote wallet is designed as separate process and can be connected theoretically to any daemon. (or to few daemons to be sure)Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 04:14:52 AM Does keccak in use mean that the coin can be mined using GPU? Don't think so. Keccak is only a part of hash function.Title: Re: [HP] Hash-on-blockchain discussion Post by: axo on April 29, 2014, 06:07:07 AM Using the blockchain is a good idea to prevent gpu mining in the long term (when it cannot fit in the gpu memory) because the slow transfer speed from host memory to gpu memory.
I'm not sure it could be a problem for realizing an ASIC. In the pipeline there is a step that picks up relative small amount of data from big set of data and fills the relative small pipeline memory (actually 130k is not small but in the future it could be). This is a bottleneck but not so big as for GPUs. The problem with ASIC is not only the bigger calculation power than cpu, but the better energy efficiency. The problem with ASIC remain if it is possible to realize an ASIC not faster than a cpu but that requires thousands times lesser energy. An idea: what about using the selector hash to vary the instructions sequence of second hash? In that case the ASIC pipeline becomes inefficient and similar to cpu. Title: Re: [HP] Hash-on-blockchain discussion Post by: digicoin on April 29, 2014, 06:29:58 AM Adam Back raises a concern on the possibility to run a SPV client on CryptoNote blockchain. He does not find a way yet. Running a full node is not an option to mobile clients like iPad or Android client. Do you have any improvement on this issue? If you don't want to mine on ipad or on android you do nod need to have a node on it - Cryptonote wallet is designed as separate process and can be connected theoretically to any daemon. (or to few daemons to be sure)However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device Title: Re: [HP] Hash-on-blockchain discussion Post by: kalisto on April 29, 2014, 11:55:50 AM However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device It needs the whole blockchain but it doesn't care if this is a remote blockchain like a bitcoinj implementation. Title: Re: [HP] Hash-on-blockchain discussion Post by: BitRock on April 29, 2014, 04:11:40 PM CPU coins are heaven of botnet. Does Blockchain-based hash or cryptoNote against botnet?
Title: Re: [HP] Hash-on-blockchain discussion Post by: tromp on April 29, 2014, 05:54:13 PM Let's open hash-function discussion friends. Just want to uncover our approach and show differences with CryptoNote that we use in our project announced here: https://bitcointalk.org/index.php?topic=577267.0 (https://bitcointalk.org/index.php?topic=577267.0) First of all I want to say that CryptoNote hash function (so called cn_slow_hash) is actually a very strong protected from ASIC's with different CPU instructions set as well as memory consuming algo. cn_slow_hash works hard on 2MB scratchpad and most of this scratchpad are fits in CPU cache. Shortcomings 1. H1, as well as final hash (keccak) have to be very fast, otherwise memory consuming accent will be slight. If H1 is slow than possible to implement some specific hardware working similar to Instruction pipeline (http://en.wikipedia.org/wiki/Instruction_pipeline) 2. Despite the first, H1 have to have modern cpu instructions set - 64-bits numbers multiplication, AES/SSE instructions to make ASIC engineers bloody mad. Wellcome to comment. If you want to strengthen the ASIC resistance of CryptoNight and avoid the slowness of verification, why not use an a-symmetric memory-bound proof-of-work like Momentum or my Cuckoo Cycle? Title: Re: [HP] Hash-on-blockchain discussion Post by: koop4u on April 29, 2014, 06:03:09 PM +1 Title: Re: [HP] Hash-on-blockchain discussion Post by: tacotime on April 29, 2014, 06:11:28 PM This doesn't really prevent botnets... you can just torrent the blockchain and distribute it amongst all peers in the botnet. Worse, it totally breaks any chance of having SPV clients in the future.
Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 10:41:48 PM Using the blockchain is a good idea to prevent gpu mining in the long term (when it cannot fit in the gpu memory) because the slow transfer speed from host memory to gpu memory. mmm...do you mean some kind of polymorphic hash?... I'm not sure it could be a problem for realizing an ASIC. In the pipeline there is a step that picks up relative small amount of data from big set of data and fills the relative small pipeline memory (actually 130k is not small but in the future it could be). This is a bottleneck but not so big as for GPUs. The problem with ASIC is not only the bigger calculation power than cpu, but the better energy efficiency. The problem with ASIC remain if it is possible to realize an ASIC not faster than a cpu but that requires thousands times lesser energy. An idea: what about using the selector hash to vary the instructions sequence of second hash? In that case the ASIC pipeline becomes inefficient and similar to cpu. Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 10:55:47 PM However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device Not really. When you creates a new wallet you don't need to read all blockchain that have been before, obviously there are can't be a transactions to this address you just created. (and wallet keys file actually keeps creation timestamp inside). You only need a chain of block hashes, that can be fetched very fast(Wallet data file keeps hashes chain to be able detect and handle splits in daemon). So it can be easily implemented in mobile device. Even for bytecoin huge blockchain the hashes in new just created and synchronized wallet takes about 18MB, and it can be reduced without big effort.Title: Re: [HP] Hash-on-blockchain discussion Post by: tacotime on April 29, 2014, 10:59:38 PM However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device Not really. When you creates a new wallet you don't need to read all blockchain that have been before, obviously there are can't be a transactions to this address you just created. (and wallet keys file actually keeps creation timestamp inside). You only need a chain of block hashes, that can be fetched very fast(Wallet data file keeps hashes chain to be able detect and handle splits in daemon). So it can be easily implemented in mobile device. Even for bytecoin huge blockchain the hashes in new just created and synchronized wallet takes about 18MB, and it can be reduced without big effort.Ah... I guess if you only use header data it's not much of an issue for an SPV client, but then I'm not sure if this affords additional security to the hash function. Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 11:05:13 PM CPU coins are heaven of botnet. Does Blockchain-based hash or cryptoNote against botnet? WE ARE AGAINST ANY KIND OF CRIMINAL. Probably in future, when blockchain will not fit in a memory of a typical workstation with 4GB RAM it may became not effective to mine with botnets. But not sure about this. Anyway, it can be said for any ASIC-resistent project, isn't it? Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 11:18:37 PM If you want to strengthen the ASIC resistance of CryptoNight and avoid the slowness of verification, Thank you for suggestion, will look at this. How long it do one check in microseconds? why not use an a-symmetric memory-bound proof-of-work like Momentum or my Cuckoo Cycle? Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 29, 2014, 11:23:10 PM This doesn't really prevent botnets... you can just torrent the blockchain and distribute it amongst all peers in the botnet. Worse, it totally breaks any chance of having SPV clients in the future. Not agree about SPV clients. I've posted before in this thread: https://bitcointalk.org/index.php?topic=588421.msg6464526#msg6464526 (https://bitcointalk.org/index.php?topic=588421.msg6464526#msg6464526)Title: Re: [HP] Hash-on-blockchain discussion Post by: smooth on April 29, 2014, 11:38:58 PM CPU coins are heaven of botnet. Does Blockchain-based hash or cryptoNote against botnet? Botnets mining (which is stupid for them) is a good thing longer term. Not something to be worried about. This is obvious to anyone who thinks through the economic and game theory aspects of it. Title: Re: [HP] Hash-on-blockchain discussion Post by: tromp on April 29, 2014, 11:45:56 PM If you want to strengthen the ASIC resistance of CryptoNight and avoid the slowness of verification, Thank you for suggestion, will look at this. How long it do one check in microseconds? why not use an a-symmetric memory-bound proof-of-work like Momentum or my Cuckoo Cycle? 42x2 siphashes and 2 sha256 hashes can't take more than a few microsecs... Title: Re: [HP] Hash-on-blockchain discussion Post by: smooth on April 29, 2014, 11:52:10 PM I may not understand what you are trying to accomplish.
If H1 is slow but does not require a lot of random access to memory, then you can run H1 on a GPU or ASIC, then deliver a set of indexes into the blockchain to the node. If the blockchain fits in memory then you are doing a handful of memory accesses and the other work may dominate. If the blockchain does not fit in memory, then you are giving a huge advantage to people with large solid state drives (flash or battery DRAM) or probably better the ability to store the block chain in a memory kvs across multiple servers. This may frustrate decentralization because you are better off just maintaining a connection to a node/pool with such a device than running node yourself. If you want to use the block chain for PoW like Ethereum to require miners to run nodes (but see above), then you can probably do something simple like: B = block E = hash function, such as Keccak B(i) = blockchain data at index i (mod len(blockchain) or some such) H1=E(B) H2=E(B+1) PoW= E(B(H1))+H2) Could be repeated, but not sure that adds much. Maybe that is close to what you propose, but again I don't see the point to using a scratchpad at all. The blockchain is essentially your scratchpad. Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on April 30, 2014, 10:19:39 AM I may not understand what you are trying to accomplish. That's why H1 have to be fast, as you wrote in shortcomings.If H1 is slow but does not require a lot of random access to memory, then you can run H1 on a GPU or ASIC, then deliver a set of indexes into the blockchain to the node. If the blockchain fits in memory then you are doing a handful of memory accesses and the other work may dominate. If the blockchain does not fit in memory, then you are giving a huge advantage to people with large solid state drives (flash or battery DRAM) or probably better the ability to store the block chain in a memory kvs across multiple servers. Let's do some calculations to see what we have: This may frustrate decentralization because you are better off just maintaining a connection to a node/pool with such a device than running node yourself. To get hashing data from block we use: 1. Coinbase outs: usualy 10*32 = 320 bytes. 2. Tx hashes: 32 * (from 1 to 80) (80 is current bitcoin transaction flow) = from 32 to 2560 bytes With 720 block per day we will increase scratchpad from 92 MB to 758MB per year. Enough to make ASIC's stay away but ok for normal miners. Even if we will be a very success and will get tx flow like a bitcoin in next ten years, scratchpad will be about 10GB, not a problem even now. The real problem i think is to have SPV client with this approach. What do you think ? If you want to use the block chain for PoW like Ethereum to require miners to run nodes (but see above), then you can probably do something simple like: We do very similar:B = block E = hash function, such as Keccak B(i) = blockchain data at index i (mod len(blockchain) or some such) H1=E(B) H2=E(B+1) PoW= E(B(H1))+H2) Could be repeated, but not sure that adds much. Maybe that is close to what you propose, but again I don't see the point to using a scratchpad at all. The blockchain is essentially your scratchpad. E' - first phase hash. E - final phase hash. H1' and H1' - is different parts of same hash (low and high) used to address random block H1=E'(B) PoW= E(H1 + E(B(H1')) + E(B(H1'')) ) E' can be a keccak(at least it should be as fast as keccak), but better to use some hash with more complicated instruction set as i said (64-bits numbers multiplication, AES/SSE) Title: Re: [HP] Hash-on-blockchain discussion Post by: smooth on May 01, 2014, 02:03:20 AM The real problem i think is to have SPV client with this approach. What do you think ? You most certainly can't have SPV clients if verifying the block header pow requires the entire block chain. As far as the pow itself I'm still not quite sure what you are trying to accomplish. As far as the bitcoin transaction volume you mentioned, I consider that very low if you are designing for the long term. But it seems you have through this through a fair amount and if you are launching in two days I doubt it makes sense to change the pow right before launch, so I guess we'll just see how it goes. You can always hard fork, but that gets much more difficult to accomplish over time. Title: Re: [HP] Hash-on-blockchain discussion Post by: digicoin on May 01, 2014, 09:03:37 AM Is it possible to extend daemond to return full list of block header hashes instead of the full blockchain? What is the security implications of this approach? E.x: a malicious/compromised node can response with purposefully modified hash list?
I believe that this coin can take CryptoNote as its core technology but it must separate itself from Bytecoin to make room for improvement. At least for the middle term. Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on May 02, 2014, 09:56:24 PM You most certainly can't have SPV clients if verifying the block header pow requires the entire block chain. Sorry if i'm not clear. As far as the pow itself I'm still not quite sure what you are trying to accomplish. We are looking for a way to be memory hard (at mining) on the one hand, on the other to use wider cpu instruction set (if possible). In our opinion it make sense in ASIC protection. Please correct me if i wrong. At the same time we want to have cheap PoW check operation(the reason why we changing CryptoNote PoW). As far as the bitcoin transaction volume you mentioned, I consider that very low if you are designing for the long term. Probably it's better to spend one week for discussion before launch than stress network with hard fork.But it seems you have through this through a fair amount and if you are launching in two days I doubt it makes sense to change the pow right before launch, so I guess we'll just see how it goes. You can always hard fork, but that gets much more difficult to accomplish over time. Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on May 02, 2014, 11:10:08 PM Is it possible to extend daemond to return full list of block header hashes instead of the full blockchain? What is the security implications of this approach? E.x: a malicious/compromised node can response with purposefully modified hash list? Yes, for example we can make daemon able to return randomly requested block headers. But don't think it's necessary. SPV client have to keep block id vector, like our wallet do, it is 8Mb per year. For SPV client each new block should be received with the headers required to get this PoW. To check if this supplied headers valid you just needed to get id-hash(cn_fast_hash which is actually keccak) of this header and validate if this id equal with id in SPV's vector on correspond height. Even if compromised node will make PoW with fake headers, SPV client is able to validate it. So, probably we need to extend daemon to be able work with SPV clients by making possible to send blocks coupled with related PoW headers. Think that SPV client could be done based on Wallet + p2p layer + PoW. I believe that this coin can take CryptoNote as its core technology but it must separate itself from Bytecoin to make room for improvement. At least for the middle term. Not sure that i gues what you mean about separating from Bytecoin.Title: Re: [HP] Hash-on-blockchain discussion Post by: otila on May 08, 2014, 06:16:36 PM We are looking for a way to be memory hard (at mining) on the one hand, on the other to use wider cpu instruction set (if possible). In our opinion it make sense in ASIC protection. Please correct me if i wrong. You can't make it memory-hard with 24-round non-optimized keccak, so why insist on using it? Title: Re: [HP] Hash-on-blockchain discussion Post by: superresistant on May 10, 2014, 06:48:20 AM 1. Wide CPU instruction set 2. Memory-oriented algo 3. Small work time. Memorycoin failed on the 2 first point (I don't know about the last). It was AES-NI instruction only, if you didn't have a recent CPU, you were very slow or it didn't work. It was supposed to rely on RAM amount to counter bot farming but it didn't. I think it is a great to be memory dependent. What do you think about a minimum memory amount to mine ? Title: Re: [HP] Hash-on-blockchain discussion Post by: otila on May 10, 2014, 08:21:33 AM As you can see, working on small amount of memory 100000 hash operations takes 3020 ms, meanwhile work on 100Mb scratchpad with the same operations count takes 8574 ms. Such difference(caused by the cache memory overflow) points to real memory hardness we guess. Compare memory read/written per second by the hash to memmove() speed. What do you get? Does each round of keccak read from different areas of scratchpad? Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on May 10, 2014, 10:37:33 AM 1. Wide CPU instruction set 2. Memory-oriented algo 3. Small work time. Memorycoin failed on the 2 first point (I don't know about the last). It was AES-NI instruction only, if you didn't have a recent CPU, you were very slow or it didn't work. It was supposed to rely on RAM amount to counter bot farming but it didn't. I think it is a great to be memory dependent. What do you think about a minimum memory amount to mine ? It's not about huge memory amount, scratchpad is building on blocks pseudorandom data, such as hashes and tx keys, and will grow about 90MB/year. Huge scratchpad gonna make almost impossible to have SPV-client. Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on May 10, 2014, 10:46:37 AM As you can see, working on small amount of memory 100000 hash operations takes 3020 ms, meanwhile work on 100Mb scratchpad with the same operations count takes 8574 ms. Such difference(caused by the cache memory overflow) points to real memory hardness we guess. Compare memory read/written per second by the hash to memmove() speed. What do you get? Does each round of keccak read from different areas of scratchpad? 2. yes. addressing based on state buffer. Title: Re: [HP] Hash-on-blockchain discussion Post by: hirschhornsalz on May 10, 2014, 11:52:43 AM Now lets imagine - just for a short time - this currency will be really successful. The blockchain of bitcoin grows faster thean linear in time, it does make sense to assume a slow exponential growth for a successful altcoin too.
Code: ~/.bitcoin $ du -sh blocks Now lets just assume you hit a 40 G blockchain in 3 years. Are you sure there are enough nodes left with 64 GB Ram? What about the distribution of this kind of workstations? Title: Re: [HP] Hash-on-blockchain discussion Post by: crypto_zoidberg on May 10, 2014, 02:46:26 PM Now lets imagine - just for a short time - this currency will be really successful. The blockchain of bitcoin grows faster thean linear in time, it does make sense to assume a slow exponential growth for a successful altcoin too. I feel that i need to have more clear description. Code: ~/.bitcoin $ du -sh blocks Now lets just assume you hit a 40 G blockchain in 3 years. Are you sure there are enough nodes left with 64 GB Ram? What about the distribution of this kind of workstations? Each block's entry in scratchpad is not depends of number of transactions included in it. It is fixed to about 320 bytes and use prev_id, merkle root, onetime coinbase key, and hashed coinbase outs (usually 8 ). I'll put more detailed description. Title: Re: [HP] Hash-on-blockchain discussion Post by: otila on May 11, 2014, 06:24:50 AM I feel that i need to have more clear description. Each block's entry in scratchpad is not depends of number of transactions included in it. It is fixed to about 320 bytes and use prev_id, merkle root, onetime coinbase key, and hashed coinbase outs (usually 8 ). (with mixin_t) with width=1600, rate=1536, and capacity=(1600-1536)=64, you get collision resistance=2^32, (second) preimage resistance=2^32. However, data is mixed into the state each round and you use multiply instead of xor, so security level of the construction is unknown. Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: otila on May 13, 2014, 08:50:46 AM now when mining in testnet, currency::get_blob_longhash takes 75% of CPU time, and 75% of CPU time in that function is spent in doing div instructions due to size() and operator[], not quite memory-hard :'(
Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: smooth on May 13, 2014, 09:00:45 AM now when mining in testnet, currency::get_blob_longhash takes 75% of CPU time, and 75% of CPU time in that function is spent in doing div instructions due to size() and operator[], not quite memory-hard :'( The block chain is tiny right? Probably all in near cache Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: otila on May 13, 2014, 10:22:37 AM now when mining in testnet, currency::get_blob_longhash takes 75% of CPU time, and 75% of CPU time in that function is spent in doing div instructions due to size() and operator[], not quite memory-hard :'( The block chain is tiny right? Probably all in near cache EDIT: div cycle count on Sandy Bridge depends on divisor, bigger divisors take more time (latency: 30-94 cycles). As a comparison, L2 cache minimum latency is 11 cycles. The vector size could as well be rounded up to next power of two and doing some padding, avoiding modulus by doing bitwise and operation, so instead of size() you use shift count.. I wouldn't like to uglify the code by implementing reciprocal multiplication hacks. But who knows, maybe GPUs and ASICs have slow 64 bit divide ::) Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: smooth on May 13, 2014, 11:18:44 AM now when mining in testnet, currency::get_blob_longhash takes 75% of CPU time, and 75% of CPU time in that function is spent in doing div instructions due to size() and operator[], not quite memory-hard :'( The block chain is tiny right? Probably all in near cache EDIT: div cycle count on Sandy Bridge depends on divisor, bigger divisors take more time (latency: 30-94 cycles). As a comparison, L2 cache minimum latency is 11 cycles. Right but memory is much higher latency. The idea is for the block chain data to (eventually) be in memory, not L2. I agree replacing div by something faster is probably a good idea, but I haven't looked at this code at all. Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: otila on May 14, 2014, 01:52:13 PM seems this miner stuff is obfuscated on purpose, dev is probably running 10x faster miner himself..
but I have two days to make a faster version :( Code: #0 std::vector<crypto::hash, std::allocator<crypto::hash> >::operator[] (this=0x7f837d3fb950, __n=12302) at /usr/include/c++/4.9.0/bits/stl_vector.h:780 Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: perl on May 18, 2014, 10:48:44 PM You have smoke for write algo hash or I did not understand ?
What interest is one pool not receveid more 20 personne ? Pool as need validate best resultat of miner for validate submit . Make validation 20 personne get more resources of mining directly . Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: otila on May 19, 2014, 12:49:23 PM You have smoke for write algo hash or I did not understand ? Talking to me? I don't understand you ;D Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: BitRock on May 19, 2014, 03:22:40 PM seems this miner stuff is obfuscated on purpose, dev is probably running 10x faster miner himself.. but I have two days to make a faster version :( Code: #0 std::vector<crypto::hash, std::allocator<crypto::hash> >::operator[] (this=0x7f837d3fb950, __n=12302) at /usr/include/c++/4.9.0/bits/stl_vector.h:780 Have you got a chance to optimize the miner? Title: Re: [HP] Boolberry Hash-on-blockchain discussion Post by: otila on May 19, 2014, 04:15:46 PM Have you got a chance to optimize the miner? Not much to do, since PoW still uses % operation (and gcc generates four div instructions in that function because there's also some array indexing), and I didn't figure out the C++ code with splattered-around lambda functions, callbacks and recursive macros. And then summer came in Finland and I have been out more 8) Hash rate could be two times faster if I figure out what the code does and can do with less div operations. (I have been programming in C for 20 years, maybe I should learn more C++..) However, I replaced the keccak function with a faster one, but it does not help much, because much of the CPU time is spent in div operations. Title: Re: [BBR] Boolberry Hash-on-blockchain discussion Post by: doldgigger on June 19, 2014, 08:00:47 PM Let's open hash-function discussion friends. Just want to uncover our approach and show differences with CryptoNote that we use in our project announced here: https://bitcointalk.org/index.php?topic=577267.0 (https://bitcointalk.org/index.php?topic=577267.0) First of all I want to say that CryptoNote hash function (so called cn_slow_hash) is actually a very strong protected from ASIC's with different CPU instructions set as well as memory consuming algo. cn_slow_hash works hard on 2MB scratchpad and most of this scratchpad are fits in CPU cache. http://honeypenny.org/files/cryptonote_hash.svg For now it is difficult imagine that will be possible to make some specific hardware which will be more effective than CPU and will coast less than CPU. But world changes so fast, nobody knows what will happen in near future. We've all seen how rapid technological breakthroughs capable of performing the computer industry. ??? Since cn_slow_hash created 2MB scratchpad, it's have to cover all this data, that's why they use 220 iterations, and side-effect from this pretty slow work (about 500ms on normal laptop, twice faster on normal pc with suitable cpu cache). It may slow down synchronisation process at downloading blockchain (that is not a big problem) and theoretically it may be possible to attack network - connect and send a random block to make peer calculate slow_hash for useless fake block. So, putting all together, we want to have: 1. Wide CPU instruction set 2. Memory-oriented algo 3. Small work time. Realizing it, we've tried to take a step to the side. Idea of using blockchain data as scratchpad resulted in this hash function: http://boolberry.com/files/boolb_hash.svg Actually this is a keccak hybrid, which use external scratchpad. After each keccack round, psudo-randomly addressed[state vector used as addresses] data is taken from scratchpad and xored with state. Calculating each block PoW usualy hits about 1100 randomly addressed reading of blocks by 32 bytes. I used "performance_tests" with different scratchpad size to find out memory hardness: Quote Warm up: 2161 ms test_wild_keccak<400> - OK: loop count: 100000 elapsed: 3020 ms time per call: 0 ms/call Warm up: 2158 ms test_wild_keccak<40000> - OK: loop count: 100000 elapsed: 3060 ms time per call: 0 ms/call Warm up: 2168 ms test_wild_keccak<4000000> - OK: loop count: 100000 elapsed: 3484 ms time per call: 0 ms/call Warm up: 2156 ms test_wild_keccak<40000000> - OK: loop count: 100000 elapsed: 8119 ms time per call: 0 ms/call Warm up: 2150 ms test_wild_keccak<100000000> - OK: loop count: 100000 elapsed: 8574 ms time per call: 0 ms/call As you can see, working on small amount of memory 100000 hash operations takes 3020 ms, meanwhile work on 100Mb scratchpad with the same operations count takes 8574 ms. Such difference(caused by the cache memory overflow) points to real memory hardness we guess. Wellcome to comment. Do you have some cryptography-based rationale on the "wild keccak" approach? Title: Re: [BBR] Boolberry Hash-on-blockchain discussion Post by: funnyman21 on August 27, 2015, 02:19:12 PM Are there any other coins that have copied this hash function yet?
|
