Andrew Poelstra

Which version of Elements are you using? I'm not surprised this is broken on 0.18, but a little bit surprised about 0.21 or master.

* support schnorr/taproot in block headers for CProof * add sighashflag to signatures in CProof solutions

Can you describe on a high level what you're doing with your node? Lots of RPC calls? Creating new transactions? There are definitely memory leaks in the RPC interface, which...

Which version of Elements are you running? This is a surprising amount of memory usage after less than a day.

You shouldn't need to compile a new version of Elements, but if you can run the binary with `daemon=0` inside [valgrind --tool=massif](https://www.valgrind.org/docs/manual/ms-manual.html) that would be super helpful.

Ah! So, Elements has a very weird initial block download pattern because its block headers are significantly more expensive to validate than bitcoin blocks (11 sig checks vs a couple...

My guess, by the way, is that this isn't actually a memory leak, but us just incorrectly enforcing memory limits (allocating extra Elements-specific things and then not scaling our limits...

I agree, I think during IBD we should (by default) validate only every 2000th block header, and dynafed transition blocks, or something like that. In principle we could get away...

After doing some investigation I think we do actually have an unreasonable memory spike during startup, which on my system hits 5-6Gb. The reason is than when loading the block...

@tiero my understanding is that your other issue is caused by the `blindrawtransaction` RPC doing dumb stuff and not having enough flexibility. The PSET also has these problems :) but...