Realising.... is this going to be thread safe? As in, do we have cases where it hashes multiple blocks from different threads?

Verified with and without on Alpine Linux 3.14.0 on AWS, and looks good.

Enables unit testing for windows builds using GH Actions

In my dirty version of #2320, windows tests failed consistently, but it turns out on the clean version that we merged, they just work. So we can simply enable the tests in CI configuration :grin:

As long as we're clear this is just covering a limited amount.

work in progress

Restarting CI after the move to GitHub Actions

Description

Fix suggestion to #2282 raised by @yixiao5428 . Integrated bitcoin/bitcoin@76f7481 changes to src/validation.cpp.

Notes

make check passes all tests.

I need confirmation, but it looks like there are no unit tests for net_processing.cpp and SendMessages().

Issues Related

#2282

Nope, I misunderstood, this is a tolerance window that makes the node more patient the further back it's starting. It's fine as-is.

I'm uncertain as to what the correct solution to this one is because I'm fairly unfamiliar with building on these systems. The docs make it seem like you can specific a thread stack size, but I haven't been able to reproduce that successfully. I mainly just don't like these specific changes because they may have very unintended impacts relating to crypto stuff (mainly the scratchpad that can be modified by multiple threads at the same exact time). The lowest impact solution might just be to state that it's not supported.

As for reproduction? It might be that you're not running into the issue in the tests because they're being run on the main thread. You may need to create a thread before calling scrypt_1024_1_1_256 (or CBlockHeader::GetPoWHash()). Something simple like:

#include <iostream>
#include <thread>

static const int SCRYPT_SCRATCHPAD_SIZE = 131072 + 63;

void scrypt_1024_1_1_256(const char *input, char *output)
{
    char scratchpad[SCRYPT_SCRATCHPAD_SIZE];
    printf("Hello world");
}

int main()
{
    std::thread([] {
            char output[32] = {};
            scrypt_1024_1_1_256("Hello", output);
    }).join();

    return 0;
}

Anyone object to us enabling both Cirrus & GitHub actions? Bit of a resource waste but might find stuff we've missed elsewhere. @langerhans?

Given our headers are a LOT bigger than Bitcoin Core (because they contain a Litecoin header and a transaction), should this be higher? I think most of that time will be finding the header on disk, though, so thinking 1000-1500 range.

I'll run some experiments.

Description

From #2279,

The wallet uses ordered inputs of transactions (src/wallet/wallet.cpp, line 2628 - 2640), which may incur privacy risks like fingerprinting the wallet to observers.

This PR change the original order by shuffling the inputs.

Restarting CI

Description

Fix suggestion to #2282 raised by @yixiao5428 . Integrated bitcoin/bitcoin@76f7481 changes to src/validation.cpp.

Notes

make check passes all tests.

I need confirmation, but it looks like there are no unit tests for net_processing.cpp and SendMessages().

Issues Related

#2282

Restarting CI

@rnicoll this is just for ./qa and has always been the case on travis for 1.14, see https://travis-ci.com/github/dogecoin/dogecoin/jobs/513292292#L2911

I'm ok with enabling it if you think it adds anything?

Win tests currently disabled by default.  Use -win option to enable

https://github.com/dogecoin/dogecoin/pull/2322/checks?check_run_id=2866367839#step:10:125

Did think it was a bit fast

Enables unit testing for windows builds using GH Actions

In my dirty version of #2320, windows tests failed consistently, but it turns out on the clean version that we merged, they just work. So we can simply enable the tests in CI configuration :grin:

+1

@rnicoll on which block were you at? As far I can see here is that Dogecoin is using stable 1GB (sometimes up to 1.5 GB too) memory until at blocks ~80k hits - from there, the memory just keep growing until it's full and it crashes at around ~100k block with 8GB memory

Should we start merging them on 1.21-dev (including some refactoring PRs)?

Already part of 1.21-dev: https://github.com/dogecoin/dogecoin/commit/fd44ac1e8b

Sure. Should we start merging them on 1.21-dev (including some refactoring PRs)?

Merging this into 1.14.4 will immediately identify all 1.10.x and 1.14.x based wallets that may have vulnerabilities that we fix in 1.14.4 and any future releases. I would prefer to not merge this, but instead fix all the vulnerabilities as long as we have an active 1.14-maint, and only introduce this change in wallet behavior with 1.21. That way, we do not directly link wallet behavior to potential vulnerabilities.

Thoughts?