Modifies the getnewblockhex json rpc call to accept an array of
commitments instead of a single commitment.
Backwards compatibility is maintained by first attempting to parse as a
string for a singular commitment.
(cherry picked from commit 661c6c7094)
This commit addresses #20809.
We add an additional 'error' property in the result of 'validateaddress' in case the address is not valid that gives a short description of why the address in invalid. We also change the error message returned by 'getaddressinfo' in case the address is invalid.
https://github.com/bitcoin/bitcoin/pull/20832 (1/1)
ELEMENTS: Merge conflicts resolved based on d6c85c5620 (from 22.0 rebase)
Should revisit; I am not sure whether we have a long-term stable
URL for prebuilt past Elements releases, but we should be able
to just point test/get-previous-releases.py at that, and change
the set of versions (since we do not have 0.15, 0.19, etc), and
we're good to go.
It may be that we just need to recompute some numbers because our
block limits are different. But this test takes 20 minutes to
fail and it would take some time to understand what the expected
behavior is.
Several conflicts in the C++ code related to the new `flags` parameter
to `CheckSignature` and the corresponding function being renamed upstream
to `CheckSignatureECDSA`.
Several conflicts in the test harness as Steven sorta pulled the new
upstream ECKey module into the Python code, and the actual upstream
code was slightly different. Also needed to update the feature_taproot
code to always use the non-RANGEPROOF sighash since dynafed is not
enabled in the Taproot test.
Also had to pull the `set_wif` method out of `ECKey` and inline it because
otherwise it triggers a "circular inclusion" error between script.py (which
would pull in `base58_to_bytes` from address.py) and address.py (which now
pulls in some taproot EC related stuff from script.py).
Noticed that #960 does not test the "sighash rangeproof flag set but no
witnesses" case.
This one was pretty brutal, but ultimately nothing too surprising.
Just had to keep track of which wallets owned which blinding keys,
and in wallet_importprunedfunds.py I had to manually create a
Liquid address.
This commit adds signet support, which is a little bit silly/redundant for us :)
Was a surprisingly easy merge to handle, and hopefully in future Core is more
mindful of signed blocks when they are changing code architecture.
I had to change a couple lines of src/signet.cpp to add blank assets to the
CTxOuts and to find transaction input scriptWitnesses. No need to add any
other tx witness data (and the CAsset()s that I did add to make things compile
won't be used..) because signet will always have g_con_elementsmode off.
Adds a new "send" RPC which I didn't really look at too closely to match
our other RPC modifications. In particular our backport of #17211 adds a
"solving_data" field to other transaction-creation RPCs, but not this
one. (But I checked the current status of #17211 and Andy hasn't updated
upstream either, just passes NullUniValue to FundTransaction from `send`.
So that's what I did here.)
This is the 43-commit descriptor wallet PR. It was remarkably easy to merge, given
its magnitude. With this commit Elements supports importing Bitcoin descriptors
and deriving (Bitcoin) addresses, though of course it does not support blinding
yet. That is a post-rebase project.
The material changes were:
1. Changing constants in the tests (super annoying but nothing surprising)
2. Adding a missing "skip if this coin is not ours" check in src/script/sign.cpp
which was causing us to erroneously remove existing witnesses from transactions.
This wasn't a problem before this commit since we would only ask specific
scriptpubkeymans to sign, and we'd never ask any to sign inputs we didn't
own. Andy simplified the logic here to always try every scriptpubkeyman,
which means they have to play a bit more nicely with each other.
Other than that, this was a big diff with many conflicts but literally all of
them were "we both added code" and the resolution was to take both sides.
