-
Notifications
You must be signed in to change notification settings - Fork 74
Odocrypt V1.1 #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Odocrypt V1.1 #10
Conversation
Small modification to odocrypt algo to brick any existing ASICs. I call it odocrypt 1.1 an odocrypt 2.0 is already in planning stage should ASIC developers chose to make an ASIC for this algo. The basic principle is to replace the kececk portion of odocrypt with a modified version of SHA256. The original SHA256 algo uses the decimal portion of the first 8 primes for h and the decimal portion of the first 64 primes for k. This uses a modified form of Blum Blum Shub to pick from the first 16384 primes in a pseudo random order based on the epoch time. Causing it to change every 10 days. |
This PR will cause issues during synchronization as it replaces the existing Odocrypt implementation, which is required to validate existing Odocrypt blocks. For it to work correctly, the original algorithm must be preserved in place and a newer variant included alongside (with the new changes), along with a mechanism to 'switch over' between the two. Additionally, none of these changes would prevent the manufacture of an ASIC regardless. The given changes would also allow for a faster bitstream to be written for existing FPGA units, resulting in higher hashrate. @zhangcongrong was there a reason bitcoin's internal sha256 calls could not be used? bigint could not be replaced with native uint256/arith_uint256 variables? |
Good points. This will not stop an ASIC any more then the original odocrypt. The point is 1) to see for sure if they exist and 2) to give a stop gap while a newer better algo is designed that would give better ASIC protection. |
https://github.com/barrystyle/odocrypt adds a expand/compress round of 256kb, just as a suggestion |
Hello @zhangcongrong and thank you for your contribution. At your convenience, can you update your pull request with the following:
Thank you again for your contributions! cc: @MentalCollatz |
Just following up on this PR. When you get a free moment, can you comment on the points shared above. Additionally, this PR will ultimately need to retarget against |
As far as I know, @zhangcongrong just Implemented the code of this PR. @mctrivia was leading this PR. The main consideration of this PR was the assumption of ASIC miner already exists on odocrypt. But there is no conclusive evidence |
This would provide the conclusive evidence needed to spend time on making a truly asic resistant algo. Odocrypt is known not to be resistant to asics. What we don't know is if there are any |
1 similar comment
This would provide the conclusive evidence needed to spend time on making a truly asic resistant algo. Odocrypt is known not to be resistant to asics. What we don't know is if there are any |
This PR lacks enough detail for a review per my comments here: #10 (comment) There is shared concern about Odocrypt being dominated by a single miner, but this PR does not go into enough detail to explain how it achieves the purpose of "providing conclusive evidence" for the purpose of making a "Small modification to odocrypt algo to brick any existing ASICs" as stated by @mctrivia . For me, this PR still begs the following questions:
|
Oh come on. First off there is a considerable amount of circumstantial evidence that the ASIC exists. The hash rate on odocrypt is ridiculously high when other FPGA minable coins would be way more profitable. By the very nature of how mining works conclusive evidence is just not possible without Breckinridge the ASICS As for documentation all the reason and methodology to why this changed would work where documented. The poll had to be redone several times because it kept getting deleted thus it may not have made it. The changed assumes the most likely way to build an ASIC(unrolled kececk with large ram chip to hold the modified tables) and bricks it by moving to a different algo entirely. The same method of making an ASIC for new algo would work but completely new hardware would need to be made. How we can tell if there are ASICS is by looking at the hash power after fork. FPGA miners would not be effected but ASICS would be offline for at least 3 months while new silicone was made. The changes still use tried and true hashing algorithms and even uses the original methodology of these algorithms just uses a different space for the tables. |
Can you provide this evidence in a concise and clear form or walk through it here for the benefit of everyone?
Merging this PR is easy but preparing for a hard fork could take a couple of months, if you are suggesting that this fix would only be effective for 3 months then on that basis alone I have concerns. Is @zhangcongrong available at all for follow-up? |
I'll quote some of my posts regarding the possible existence of specialized mining hardware (ASICs) on the Digibyte Odocrypt chain. Observations which I've posting on the DGB Odocrypt fpga miners Discord server over the past time. Till July 2021 roughly 75 to 80% of the entire DGB Odocrypt chain hashrate were represented by two mysterious solo-miners with huge hashrate. Over the past year and during different periods of time, public pools hashrate was fluctuating at ~10 to 20% of the entire Odocrypt chain's hashrate. Since this miner first appearance on the Odocrypt network in January 2020, he never ever switched to mining other FPGA-mineable coins and algorithms, even during a long period of ~5 months (in 2020), when large crypto projects (in terms of daily emission) such as CKB (Nervos), HNS (Handshake), TRB (Tellor) were generating a stable high profit, which on average was 2.5 to 3 times higher than the profitability of mining DGB Odocrypt on the same FPGA hardware. Later ASICs for CKB and HNS were publicly released. Also, as noted by some DGB Odocrypt community members, the moment this mysterious miner has appeared coincided with a simultaneous sharp hashrate increase of the other DGB chains - Skein and Qubit (ASIC mineable). Timeframe ~10Mil DGB block height. Guess these graphs speak for themselves. This miner's hashrate was quite stable at 9 to 10Th/s level since its appearence on Odocrypt chan and it has fell down only after large ASIC mining farms were shut down in China's Inner Mongolia region this June (so called mining ban). I'm assuming that he is currently in the process of hardware relocation
This miner has appeared on the DGB Odocrypt network at a period when FPGA miners, namely Blackminers and SQRL BCU-1525 did not earn profit mining DGB Odo even with quite low electricity rates (6 cents kW/h). To be more precise, he firstly appeared on the Odocrypt chain in February 2021 - the forth month when Blackminers (F1 Ultra, F2) were barely covering electricity bills mining DGB Odocrypt. |
@xsover , thank you for sharing your analysis. I think we all agree that the accumulation of Odocrypt hashrate by a single miner is concerning, and we are interested in finding a solution. What we are trying to determine is precisely how this PR addresses the issue. @zhangcongrong , can you provide code comments on how these changes explicitly addresses the ASIC issue? Can you comment on whether or not this PR is isolated to only Odocrypt? @mctrivia , are @digicontributer and I correct in understanding that you are saying this proposed change would only alleviate the problem for approximately three months? If so, do we have a proposed long term solution to this issue? It can take as much time simply to propagate the update out through the network. |
@gto90 the code change eliminates the ASIC issue by swapping the hashing algorithm from a modified keccak to a modified sha256. This is a trivial change for FPGA but requires trashing millions of dollars worth of hardware for an ASIC. Yes a new ASIC could be online in 3 months at a cost of over $1 million dollars. If we see tell tale signs that an ASIC did exist an ODO 2.0 could be developed that would be much more expensive to make an ASIC for. The ASIC manufacturer may chose not to bother trying again if we show we will brick there investment again. So even though we would need to develop ODO 2.0 we may never need to release it. |
Thanks, @xsover that is exactly the sort of discussion I wanted to open. I am going to review it over the weekend but there's certainly enough to be concerned about there. @mctrivia That is a lot of unknowns to risk what could be a very temporary hard fork on. I personally think we are probably better off attempting to 'develop ODO 2.0' should we move forward with changes to the algorithm so we aren't potentially in the same boat 3 months down the line. |
@xsover Thanks for providing the analysis. We definitely do not want to do something that results in us being in the same situation 3 months from now. I am on board for a more permanent solution, but am not sure of what that might be at the moment. We definitely want to explore a deeper analysis on all 5 mining algos, and it would be great to have some real-time analysis metrics defined. One metric I have checked every morning for years is the orphan rate. What I find surprising is over the past month our daily orphans have dropped to about 1/3 of where they have been for the past couple of years. Does anyone have any ideas on this and how it might relate to these miners? https://chainz.cryptoid.info/dgb/orphans.dws |
@gto90 I want to add some details:
According to chain stats, this miner currently represents about 75% of the whole Qubit DGB chain (15% x5 since the DGB network consists of 5 chains, algorithms) . He uses the same "transfer" wallet (not exchange wallet) along with another huge miner mentioned in my previous post (who is mining solely on the Odocrypt chain).
|
It seems like Odocrypt mining very soon become unprofitable with any FPGA hardware.
|
@mctrivia @gto90 Implementing small changes to the current version of the Odocrypt hash algorithm by replacing Kecak portion with sha256 (as suggested in this PR) in no way can harm the chain integrity in particular and the entire DGB coin as a whole. Since, this do not compromise the security of the encryption algorithm. Keccak and SHA256 (both are so called SHA3-candidates Afaik. Odocrypt hashing algorithm initially was implemented and adopted by the DGB developers in order to attract FPGA-miners community to the DGB crypto project as a whole and make the network less monopolized. |
Another solution: Or if DGB switched to RandomX it would eliminate asics And fpga all together creating a possible more “anyone can mine it” decentralized coin. Isn’t that what DGB wants or are they financially tied to fpga developers in some way? |
As far as i'm concerned, it's planned to implement Randomx and Progpow hashing algorithms, replacing other chains in the DGB network, perhaps these are Skein and Qubit or SHA256. Four out of five chains in the DGB network are pure ASIC algos |
There are many miners that are invested in FPGA that we wish to keep happy so they approve upgrade. But more importantly, the ideal is that each of the 5 algorithms is mined on different hardware types. So we don't want all cpu, all gpu, or all asic. Ideal would be 1x cpu, 1 gpu, 1 fpga, 1 asic and 1 other(proof of stake or proof of capacity) |
A mysterious miner with unknown hardware (probably some sort asic) continues to ramp up hashrate on the Odocrypt DGB chain, while the coin price collapsing. Congrats to the DGB community, one more chain in the entire DGB network has turned into highly monopolized. Like happened with other DGB chains (where just one miner accounts for ~70% of Skein chain hashrate, another miner on private pool accounts ~50% of Qubit hashrate. Time after time this situation is only getting worse, while developers don't take any action to change this unhealthy situation |
There has been no work on this for over 2 years and this PR is far from finished. Currently there are no active efforts to finish this PR. Closing for the time being, but can be reopened if ever finished. |
fa7e147 test: Fix intermittent Tsan issue (MarcoFalke) Pull request description: Fix https://cirrus-ci.com/task/5176769937408000?logs=ci#L5161 ``` WARNING: ThreadSanitizer: data race (pid=22965) Write of size 8 at 0x7f74d5e21f50 by main thread: #0 std::__1::ios_base::precision(long) /usr/lib/llvm-13/bin/../include/c++/v1/ios:513:18 (test_bitcoin+0x1a8366) #1 boost::io::ios_base_all_saver::restore() /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/io/ios_state.hpp:341:17 (test_bitcoin+0x1a8366) #2 boost::unit_test::unit_test_log_t::operator<<(boost::unit_test::log::begin const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_log.ipp:336:55 (test_bitcoin+0x1a8366) #3 boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/test_tools.ipp:359:19 (test_bitcoin+0x1b3b9b) #4 txindex_tests::txindex_initial_sync::test_method() src/test/txindex_tests.cpp:31:5 (test_bitcoin+0x78aebc) #5 txindex_tests::txindex_initial_sync_invoker() src/test/txindex_tests.cpp:16:1 (test_bitcoin+0x78a384) #6 boost::detail::function::void_function_invoker0<void (*)(), void>::invoke(boost::detail::function::function_buffer&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:117:11 (test_bitcoin+0x2bf30d) #7 boost::function0<void>::operator()() const /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:763:14 (test_bitcoin+0x224027) #8 boost::detail::forward::operator()() /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:1368:32 (test_bitcoin+0x224027) #9 boost::detail::function::function_obj_invoker0<boost::detail::forward, int>::invoke(boost::detail::function::function_buffer&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:137:18 (test_bitcoin+0x224027) #10 boost::function0<int>::operator()() const /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:763:14 (test_bitcoin+0x1ac66c) #11 int boost::detail::do_invoke<boost::shared_ptr<boost::detail::translator_holder_base>, boost::function<int ()> >(boost::shared_ptr<boost::detail::translator_holder_base> const&, boost::function<int ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:290:30 (test_bitcoin+0x1ac66c) #12 boost::execution_monitor::catch_signals(boost::function<int ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:879:16 (test_bitcoin+0x1ac66c) #13 boost::execution_monitor::execute(boost::function<int ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:1277:16 (test_bitcoin+0x1ac980) #14 boost::execution_monitor::vexecute(boost::function<void ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:1377:5 (test_bitcoin+0x1a7f9b) #15 boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::function<void ()> const&, unsigned long) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_monitor.ipp:49:9 (test_bitcoin+0x1a7f9b) #16 boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:823:44 (test_bitcoin+0x1e0d5c) #17 boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:792:58 (test_bitcoin+0x1e14a6) #18 boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:792:58 (test_bitcoin+0x1e14a6) #19 boost::unit_test::framework::run(unsigned long, bool) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:1696:29 (test_bitcoin+0x1a6bfb) #20 boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_main.ipp:248:9 (test_bitcoin+0x1c4ed6) #21 main /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_main.ipp:304:12 (test_bitcoin+0x1c5506) Previous write of size 8 at 0x7f74d5e21f50 by thread T4: [failed to restore the stack] Location is global 'std::__1::cout' of size 160 at 0x7f74d5e21f30 (libc++.so.1+0x0000000cdf50) Thread T4 'b-txindex' (tid=22989, running) created by main thread at: #0 pthread_create <null> (test_bitcoin+0x1184cd) #1 std::__1::__libcpp_thread_create(unsigned long*, void* (*)(void*), void*) /usr/lib/llvm-13/bin/../include/c++/v1/__threading_support:514:10 (test_bitcoin+0xa23f1b) #2 std::__1::thread::thread<void (*)(char const*, std::__1::function<void ()>), char const*, BaseIndex::Start(CChainState&)::$_0, void>(void (*&&)(char const*, std::__1::function<void ()>), char const*&&, BaseIndex::Start(CChainState&)::$_0&&) /usr/lib/llvm-13/bin/../include/c++/v1/thread:307:16 (test_bitcoin+0xa23f1b) #3 BaseIndex::Start(CChainState&) src/index/base.cpp:363:21 (test_bitcoin+0xa23f1b) #4 txindex_tests::txindex_initial_sync::test_method() src/test/txindex_tests.cpp:31:5 (test_bitcoin+0x78adfa) #5 txindex_tests::txindex_initial_sync_invoker() src/test/txindex_tests.cpp:16:1 (test_bitcoin+0x78a384) #6 boost::detail::function::void_function_invoker0<void (*)(), void>::invoke(boost::detail::function::function_buffer&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:117:11 (test_bitcoin+0x2bf30d) #7 boost::function0<void>::operator()() const /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:763:14 (test_bitcoin+0x224027) #8 boost::detail::forward::operator()() /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:1368:32 (test_bitcoin+0x224027) #9 boost::detail::function::function_obj_invoker0<boost::detail::forward, int>::invoke(boost::detail::function::function_buffer&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:137:18 (test_bitcoin+0x224027) #10 boost::function0<int>::operator()() const /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/function/function_template.hpp:763:14 (test_bitcoin+0x1ac66c) #11 int boost::detail::do_invoke<boost::shared_ptr<boost::detail::translator_holder_base>, boost::function<int ()> >(boost::shared_ptr<boost::detail::translator_holder_base> const&, boost::function<int ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:290:30 (test_bitcoin+0x1ac66c) #12 boost::execution_monitor::catch_signals(boost::function<int ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:879:16 (test_bitcoin+0x1ac66c) #13 boost::execution_monitor::execute(boost::function<int ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:1277:16 (test_bitcoin+0x1ac980) #14 boost::execution_monitor::vexecute(boost::function<void ()> const&) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/execution_monitor.ipp:1377:5 (test_bitcoin+0x1a7f9b) #15 boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::function<void ()> const&, unsigned long) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_monitor.ipp:49:9 (test_bitcoin+0x1a7f9b) #16 boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:823:44 (test_bitcoin+0x1e0d5c) #17 boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:792:58 (test_bitcoin+0x1e14a6) #18 boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:792:58 (test_bitcoin+0x1e14a6) #19 boost::unit_test::framework::run(unsigned long, bool) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/framework.ipp:1696:29 (test_bitcoin+0x1a6bfb) #20 boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**) /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_main.ipp:248:9 (test_bitcoin+0x1c4ed6) #21 main /tmp/cirrus-ci-build/depends/x86_64-pc-linux-gnu/include/boost/test/impl/unit_test_main.ipp:304:12 (test_bitcoin+0x1c5506) SUMMARY: ThreadSanitizer: data race /usr/lib/llvm-13/bin/../include/c++/v1/ios:513:18 in std::__1::ios_base::precision(long) ================== Exit status: 2 ACKs for top commit: fanquake: CI ignored ACK fa7e147 Tree-SHA512: 5194e026410b96ad3c8addeecce0a55ee0271c3cfac9fa0715345b1a50d59925549cee0a3e415e5837ae6d2f214a7b622c73cfc7fdf41d5e55c24fb87fddb9d1
Upgrade odo algorithm