Skip to content

Conversation

zhangcongrong
Copy link

Upgrade odo algorithm

@mctrivia
Copy link

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.

@barrystyle
Copy link

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?

@mctrivia
Copy link

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.
As for not using the built in SHA256 algo is because we don't know how the ASICS are built so using a modified SHA256 algo garentees they can't keep using the existing ASICS by piping the output to the sha256 core they may have on the chip.

@barrystyle
Copy link

barrystyle commented Jan 28, 2021

https://github.com/barrystyle/odocrypt adds a expand/compress round of 256kb, just as a suggestion

@SmartArray SmartArray changed the title Leo dev Odocrypt V1.1 Apr 12, 2021
@gto90
Copy link
Member

gto90 commented Jul 11, 2021

Hello @zhangcongrong and thank you for your contribution. At your convenience, can you update your pull request with the following:

  1. Update the title to reflect the nature and type of change this PR represents per the Contributor Workflow. For example, if this is a change to mining code, a title could be Mining: Upgrade to Odocrypt to improve ASIC resistance
  2. To help community review this code please update the description of the pull request with a detailed description of what this PR does and what it's justification is. More specifically, please provide information on what the general problem is and how this PR solves that problem. Additionally it will be very helpful to the reviewers to provide per file comments on how each change maps to the proposed solution.
  3. Please provide a detailed explanation for how the reviewers should review the changes to existing code and any new code added.
  4. Please ensure that this PR is accompanied by a unit test or tests which demonstrates the issue with the current Odocrypt implementation and validates that the solution satisfies the tests. Please note that all code changes per our documentation requires new unit tests for all changes to existing code and all new code. See automated testing.

Thank you again for your contributions!

cc: @MentalCollatz

@gto90 gto90 changed the base branch from feature/8.21.1 to develop August 2, 2021 14:45
@gto90 gto90 changed the base branch from develop to feature/8.21.1 August 2, 2021 14:45
@gto90
Copy link
Member

gto90 commented Aug 2, 2021

@zhangcongrong,

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 develop once the upstream merge of BTC v22 is completed.

@windflood
Copy link

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

@mctrivia
Copy link

mctrivia commented Sep 5, 2021

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
@mctrivia
Copy link

mctrivia commented Sep 5, 2021

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

@gto90
Copy link
Member

gto90 commented Sep 5, 2021

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:

  • Could this evidence not be collected and researched without deploying this change?
  • What are the broader impacts of this change?
  • How does this change "brick any existing ASICs"?
  • How does this PR address the concerns raised by @barrystyle ?
  • Would it not be more prudent to propose an improved Odocrypt algorithm with exhaustive documentation and rationale before deploying unproven "instrumentation" for the purpose of "bricking ASICs" whilst there is no evidence that this change would achieve that goal?

@mctrivia
Copy link

mctrivia commented Sep 5, 2021

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.

@digicontributer
Copy link

Oh come on. First off there is a considerable amount of circumstantial evidence that the ASIC exists.

Can you provide this evidence in a concise and clear form or walk through it here for the benefit of everyone?

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.

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?

@xsover
Copy link

xsover commented Sep 7, 2021

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.
Some details about these two whale solo-miners:

  1. https://chainz.cryptoid.info/dgb/address.dws?DBV5a82LJjoszXRxctiHz3v7gBMTXf3TbK.htm

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.
Which indirectly indicates that a new batch of unknown multi-algorithm capable ASICs has appeared on the network.

Guess these graphs speak for themselves.
DGB Qubit, Skein, Odocrypt chains were hit by unknown multi-algo ASICs at the same timeframe ~10Mil DGB block height
Multialgo_asic_qubit_skein_odo

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

  1. https://chainz.cryptoid.info/dgb/address.dws?D8aqBgYRNeLgdJ6i3sF9arFTkbtsY9NLvR.htm
    https://chainz.cryptoid.info/dgb/extraction.dws?22368458.htm

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.
One more thing - this whale miner literally from the very first days had approx 15Th/s of Odocrypt hashrate, this is an equivalent of ~2500 Blackminer F1U, F2 or similar fpga miners ($1500/unit).
A fairly large amount of new hardware, which didn't generating noticeable profit at the time of its appearance on the DGB Odo network (at period from November 2020 to March 2021)
This whale miner is still online and represents roughly half of the Odo chain hashrate atm. For instance, over the past day this miner has found 529 Odocrypt blocks out of 1152 possible (~46%).

@gto90
Copy link
Member

gto90 commented Sep 9, 2021

@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.

@mctrivia
Copy link

mctrivia commented Sep 9, 2021

@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.

@digicontributer
Copy link

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.

@JaredTate
Copy link

@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

@xsover
Copy link

xsover commented Oct 1, 2021

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.

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.

@gto90 I want to add some details:

qubit_ZMVr
https://chainz.cryptoid.info/dgb/address.dws?DFf3P5fE4ckcQnCTdvNtbmUjdL24gXZMVr.htm
extraction data from this wallet https://chainz.cryptoid.info/dgb/extraction.dws?20796638.htm

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).
"Transfer" wallet https://chainz.cryptoid.info/dgb/address.dws?DFZJBUqDJihcrXMzLHNh9UJjimXMH6iXd5.htm
https://chainz.cryptoid.info/dgb/tx.dws?35969500.htm
Take a look at those transactions, it's clearly seen that the freshly mined DGB coins are immediately transferred in one transaction from both Quibit (wallet ends ...XZMVr) and Odocrypt (wallet ends ...3TbK) wallets.

https://chainz.cryptoid.info/dgb/address.dws?DBV5a82LJjoszXRxctiHz3v7gBMTXf3TbK.htm
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. Which indirectly indicates that a new batch of unknown multi-algorithm capable ASICs has appeared on the network.

@xsover
Copy link

xsover commented Oct 5, 2021

It seems like Odocrypt mining very soon become unprofitable with any FPGA hardware.
One more chain in the Digibyte network becomes monopolized by just a few whale miners/farms.
Network hashrate growth from ~33Th week ago to the current ~50Th. and all that hashrate came from two solo-miners. one of them ( with 20TH hashrate) most likely uses specialized hardware/ASIC

https://chainz.cryptoid.info/dgb/address.dws?D8aqBgYRNeLgdJ6i3sF9arFTkbtsY9NLvR.htm
https://chainz.cryptoid.info/dgb/extraction.dws?22368458.htm

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.
One more thing - this whale miner literally from the very first days had approx 15Th/s of Odocrypt hashrate, this is an equivalent of ~2500 Blackminer F1U, F2 or similar fpga miners ($1500/unit).
A fairly large amount of new hardware, which didn't generating noticeable profit at the time of its appearance on the DGB Odo network (at period from November 2020 to March 2021)
This whale miner is still online and represents roughly half of the Odo chain hashrate atm. For instance, over the past day this miner has found 529 Odocrypt blocks out of 1152 possible (~46%).

@xsover
Copy link

xsover commented Oct 5, 2021

@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.

@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

@mctrivia @gto90
3 months for ASIC development and tapeout in the current market state? May I ask where those very optimistic numbers came from.?
For instance, development of ASIC miner for the Nervos CKB coin has took about 6 months.
It's also worth noting that the daily POW emission of Nervos CKB coin at the time of ASIC release was about 6 times higher than the daily emission of the DGB Odocript chain.
The higher the emission of the coin, algorithm, the more the interest of ASIC manufacturers, the greater the financial interest on their part.

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
in the NIST hash function competition) are ones of the oldest and most proven hash algorithms in crypto mining sphere.
Secondly, implementaton of such changes in the hashing algorithm will render obsolete the specialized hardware(ASIC) w that appears to exist on the Odocrypt chain network. Which in turn will give more time to develop a more ASIC-resistant hashing algo for Odo 2.0

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.
Now we are seeing the following - several miners with unknown hardware represents more than 2/3 of the entire Odocrypt chain, and they are constantly increasing their hashrate.

@BigslimVdub
Copy link

Another solution:
Fast and easy- switch to k12 that is already supported by most all FPGA devs and has no known ASICS and immediately prove out any ASICS. Would only require a miner to simply load the k12 bit.

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?

@xsover
Copy link

xsover commented Oct 6, 2021

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

@mctrivia
Copy link

mctrivia commented Oct 6, 2021

Another solution: Fast and easy- switch to k12 that is already supported by most all FPGA devs and has no known ASICS and immediately prove out any ASICS. Would only require a miner to simply load the k12 bit.

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?

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)

@xsover
Copy link

xsover commented Dec 22, 2021

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.
Currently this miner accounts for ~64% of the total DGB Odocrypt hashrate.
Over the past day this miner has found 733 Odo blocks out of 1152 possible (~64%).
42TH * 0.64 ~27TH/s (approx 8Th/s rise over the past week)
https://chainz.cryptoid.info/dgb/extraction.dws?22368458.htm

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

@ycagel
Copy link
Member

ycagel commented Mar 21, 2024

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.

@ycagel ycagel closed this Mar 21, 2024
JaredTate pushed a commit that referenced this pull request Jul 9, 2025
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants