Bring Elements up to date with Bitcoin Core 0.21

[apoelstra]

Requires a bunch of followup work which I will open other issues for. See also #743 which was our checklist for 0.19.

Then in followup PRs:

• Fix the fuzz tests; I did not test these at any point throughout the rebase Post-0.21: fix fuzz tests #936
• Update and publish the merge-prs script to run the fuzzer, linter etc., as well as do a full clean make check WIP: Add merge-prs.sh script to contrib/ #923
• Audit translations; at a couple points I took Core's translations wholesale and we will need to re-edit them to change Bitcoin to Elements Post-0.21: audit translations #937
• Audit the GUI. I have not opened the bitcoin GUI since 0.12 and not opened Elements ever, so probably I broke this. Post-0.21: audit GUI #938
• Assess wallet/node coupling; Core did some separation in the build system which I undid, to support the signblock RPC which involves both wallet and node logic. Core's solution to this for Signet may be to introduce a separate signblock tool which we may want to also do; see #bitcoin-core-dev IRC logs for the meeting on 2020-12-03. Post-0.21: Separate wallet and node #939
• Assess functional tests: chase down a couple intermittent failures, assess the new broken loadblocks test, assess the "extended tests" which are broken on master Post-0.21: functional test failures #940
• Assess bitcoin functional tests and g_con_elementsmode Assess current value of g_con_elementsmode and consider removal #929
• Strengthen the functional tests; add more thorough PAK checks (see pak= format is undocumented and there is no functional test for it #926), move computefastmerkleroot into Python rather than using the RPC; Implement fast merkleroot computations in Python #941
• Fix the bumpfee RPC to support CT. There is an existing issue for this Fix bumpfee #527
• Fix the PAK standardness bug Pegouts are blocked by standardness rules if -enforce_pak is off on a network that uses PAK proofs #925 which was discovered through the rebase.
• Followup on conversion to bilingual_str from std::string for many Core RPCs; we should follow suit for our own RPCs Post-0.21: use bilingual_str rather than std::string in RPCs and elsewhere #942
• The new avoid_reuse param to sendtoaddress and a couple other RPCs moves some Elements fields out of the way. For backward compatibility we should put avoid_reuse after these Elements fields. (I think this is the only time I did this; after talking to Glenn I tried to make future RPC extensions backward compatible)
• Rebase Redesign PSET #900 on this and un-disable the large number of lines in the PSET functional tests which are disabled (in particular around the missing fee field of the RPC output)

Then a couple large followups. Tracking issues:

• Taproot: Taproot tracking issue #943
• Descriptors: Descriptors tracking issue #944
• Simplicity: Simplicity tracking issue #945

[apoelstra]

Rebased. Removed the bitcoin PRs that were from past the 0.21 fork point, and added the most recent 6 PRs from Elements. Also removed the extraneous xx thing from the fixups.

Everything from 22cf380 (Elements #960 is new).

[gwillen]

It looks like the last commit that merges a PR into the new branch is 0699c4d, and the fixups are after that. I'm going to create a merged-master branch on this repo, pointing there. (I was using the one on the apoelstra repo before, but it looks like you didn't update it when you did more merging, and anyway we should have it in the main repo.)

[gwillen]

Looking at the newly-merged commits: copy-paste error in d891120:

             if (!proposed.m_fedpeg_program.IsWitnessProgram(fedpeg_version, fedpeg_program)) {
-                return state.Invalid(false, REJECT_INVALID, "invalid-dyna-fed", "proposed fedpegs program must be native segwit scriptPubkey");
+                return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "invalid-dyna-fed", "proposed signblockscript must be native segwit scriptPubkey");
             }

(New error message refers to signblockscript instead of fedpeg script. (I assume "fedpegs program" was a typo.))

I think it's your call whether you want to make this a fixup commit, or try to fix it in-place, given that it's fairly shallow at this point. (This would require rebasing the fixups, obviously, but the rebase should be trivial.)

I think it ought to be possible to fix this in-place with an interactive rebase, without having to redo any of the subsequent merges, as long as the fix doesn't overlap with any of them. This might be worth trying as an experiment, just to figure out whether we can, but I'm also fine with leaving that for future work. (I have never successfully rebased a merge before.)

[gwillen]

Reviewed the new Elements MR merges. Everything looks good except for the comment above.

[apoelstra]

@gwillen sounds good, re merged-master

As for the copy/paste error, oops. For what it's worth, this wasn't a traditional "copied a bunch of code then failed to edit it" error, this was me copying one of a dozen error lines and picking the wrong one :P. In any case I think we should fix it in a followup PR because this one is a giant pain in the ass to work with, run CI on, etc.

[gwillen]

For the benefit of the peanut gallery: andrew is seeing a test error that doesn't reproduce locally, so there will be some noise trying to pin it down in CI.

[stevenroose]

I looked at all the recent changes up until 291da8b and can utACK that. Good to see CI entirely working!

It's still all a bit magical, I'll go over the list of my "just check on that to make sure nothing is accidentally broken" items after this is merged.

If you can ack, I can merge it, @gwillen .

[gwillen]

utACK from me!

With the understanding that there's going to be a bunch of followup work, of course.