7595e7cf47 Ergonomic + other improvements to review-prs.py (Glenn Willen)
7163ec023f Add semi-automated merge-review tool for Elements upstream merge process. (Glenn Willen)
Pull request description:
Note: I'm doing this a bit backwards, in that the script which _generates_ these merges, as well as the documentation of how they are done, is not yet PR'ed. Hopefully that will come next.
Top commit has no ACKs.
Tree-SHA512: 931ccb5d7aeba8738ec7f8f7dff36293bc9a0a5833edddd15c5e5253358a575a4b473a2e4cbbdc4282f8c64a56cc29324e440c868ed10e51a347541eee333578
bf7f050aeb Raise max P2P message size to account for larger elements dynafed header size (Glenn Willen)
Pull request description:
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
ACKs for top commit:
psgreco:
ACK bf7f050aeb
Tree-SHA512: 96936872c9daa8317562bcf47ced1f7a3cb61f8fb7171ac693f91b10a36af50aecabb343fcf14b0917af5116236a06fe2e1c59a80c51254763838dddf36c7b6b
a58b3b7ab3 Remove obsolete comment after a06aac152a (Pablo Greco)
Pull request description:
Leftover change from https://github.com/ElementsProject/elements/pull/1062
Top commit has no ACKs.
Tree-SHA512: 6334848e697cf7d0a0b4aeb9d224994924338fb242c9fca0b280a8db71225d7eea976f606cf9a300d70aa26b38a361f0b44edb69e337e438fc6b4d25e143bd7b
cdfb4c9c6c Fix elements multiple-header-download issue. (Glenn Willen)
Pull request description:
This fixes an issue which causes Elements to download the blockchain headers
multiple times during initial block download.
In particular: each time we receive an INV P2P message with a new block
(about once a minute), we start downloading the headers, again, in parallel
with any existing download(s) in progress.
With this change, after we receive each batch of headers, we check whether
any of the headers in it were new to us. If not (they were all duplicates),
we stop there, and do not ask the peer for another batch. This reduces the
maximum amount of duplication to about 2x, which is not ideal, but a HUGE
improvement.
With luck, this may help with #1013. But it's primarily directed at fixing slow initial block download, which I can't immediately find an open issue for on this repo, but has been a long-standing problem.
ACKs for top commit:
stevenroose:
looks good, utACK cdfb4c9c6c
Tree-SHA512: 693a8f89cae1819292146b5bc676e34cd9045bf3a771d78959d8f704072020d5ccb073d6d5b89786598129fd9fd4f80d2c207a2db29597984fcae774cbfacadb
6c1d0d3ca8 Re-evaluate peg-out descriptor if wallet is reparsed (Jeff Frontz)
Pull request description:
In `sendtomainchain_pak()` a check is made if the associated `descriptor` is null and an attempt to remedy is made -- but the remedy is never applied to `descriptor` (which results in a SEGV later). This code fixes that.
Note: unfortunately it also removes the `const` qualifier. I'm not sure what/if there are conventions for dealing with that (e.g., creating a new `const` of, like, `sanitized_descriptor` for subsequent use in the function?).
Top commit has no ACKs.
Tree-SHA512: 8fb4a28ebd0d76647c1b0ecf98f3e18905c880a9562caa1b02ca66647dcbe00b2a6bd91da7ce6a61bd34bb3096030714417170badccdaeaa4c0a03e8704f8ca1
e72544da90 Mark pegin-related args to createrawtransaction as optional. (Glenn Willen)
Pull request description:
Fixes#1064 .
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
Top commit has no ACKs.
Tree-SHA512: a901c4bd65fbd7fceebe39cca9f8e377741e61ef2968bc3c955e26bffb2b371a342b49a09f76696ac45f047d8c410500f5872fb722007fb92b17d0bca97d69dc
3c911a7ed7 Typos in pset doc (Riccardo Casatta)
Pull request description:
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
Top commit has no ACKs.
Tree-SHA512: 02f07fd5938f2ffe26a79aeaed673274f8cf18879eae2e8ee1e0a3c650232083545cbb7ee07a5f7e53cb756782b8a5a36201992c16d3b268fb0e73828419bfd5
b2dd758ce4 Remove redundant log message in IsValidPeginWitness (Glenn Willen)
Pull request description:
The value it logs, very frequently, is essentially static, coming straight from the chainparams, and should never change during runtime anyway. (With a small exception that doesn't really matter and is probably not the reason for the log.)
Top commit has no ACKs.
Tree-SHA512: 5cda28c850a808a8a0d43bd3369a0a18817e774d35e4c7605e3e4ffe7746f192a603c031413286a9b5c8d557f9b1807ba5ac236d8ecef9f9b64517446b788f80
This fixes an issue which causes Elements to download the blockchain headers
multiple times during initial block download.
In particular: each time we receive an INV P2P message with a new block
(about once a minute), we start downloading the headers, again, in parallel
with any existing download(s) in progress.
With this change, after we receive each batch of headers, we check whether
any of the headers in it were new to us. If not (they were all duplicates),
we stop there, and do not ask the peer for another batch. This reduces the
maximum amount of duplication to about 2x, which is not ideal, but a HUGE
improvement.
cfed38503e Make error messages when talking to parent chain daemon more useful. (Glenn Willen)
Pull request description:
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
ACKs for top commit:
stevenroose:
utACK cfed38503e
Tree-SHA512: 1b76d50516bdc809d652e932f1336a8d17c51aae1094a664b3098cdd63ce0826175f25cb64539c6b3cf0ad086ccce4d883600ab960010fd9a0401c557a562e82
0e1007fa7b minor PSET fix (Andrew Poelstra)
Pull request description:
Noticed because it triggered a compiler warning.
No test -- we will add one in a future "end-to-end issuance via PSET" tutorial script which is out of scope for the 0.21 release.
ACKs for top commit:
achow101:
ACK 0e1007fa7b
Tree-SHA512: c90427fd74c84bdee6940d2148818793e4641e6dd12dd4855a229afb6b725313c6074fc14171c911e5a541e252dd4027e65521c7fe5c62e265fb38076c1d5ca4
a4b66a24b7 Update hardcoded PAK list for Liquid v1 (Glenn Willen)
Pull request description:
Forward-port of #892
Confirmed that no other 0.18 PRs need a forward-port.
ACKs for top commit:
gwillen:
utACK a4b66a2 , thanks.
Tree-SHA512: 4f621cd93ee79faeb2080e0dccbf587d071d7777848915b21f3d281ad28a0151756cc4a16b383caa4c0184f2348cd1cc843e1d87a8d94a1f99068ff1b36f615f
a67a2df330 pset: remove one more intermediate-zero check from the blinding logic (Andrew Poelstra)
9eb285c19d test: add test for confidential non-wallet-owned change (Andrew Poelstra)
185d473fe8 walletcreatefundedpsbt: add functional test for blinding edge cases (Andrew Poelstra)
533da12c2c wallet: make sure extra OP_RETURN output is blinded when called from fundraw (Andrew Poelstra)
b09b63bd1b pset: allow input blinding factors to sum to zero, or value to be 0 (Andrew Poelstra)
9afcb83baf wallet: correctly handle blinding of manually-set change addresses (Andrew Poelstra)
9813c3e74a wallet: fix "cannot unblind IsMine output" check in SignPSBT (Andrew Poelstra)
7103471fd5 walletcreatefundedpsbt: signal blinding data correctly to `FundTransaction` (Andrew Poelstra)
Pull request description:
Fixes#1049
Needs backport to 0.21 (and a new rc).
Although there are several bugs here, none affect the functionaries. There is a more thorough summary in the second-to-last commit message.
ACKs for top commit:
achow101:
ACK a67a2df330
Tree-SHA512: 25066c29f080e43cd00c5b33c60a986a8cb5bbf4ca01ceb3b4182c5b8f61979a1d6d946b8f28fa871ec90f44bdb6fc22014b5c11280cf081181db102cd588cdf
0628311b53 chainparams: change magic bytes for liquidv1test (Andrew Poelstra)
Pull request description:
This is basically a Liquid-prod-ish version of regtest. Its default magic should not collide with that for Liquid prod.
ACKs for top commit:
psgreco:
UTACK 0628311b53
Tree-SHA512: 50c387ffeb62d42ffd0b42d0f43335966feb64a50140159c615474b9c864222e2a7510bb3b07aa95f62a977d0e7472d905bc97a06a3ace80aae0a519031c446e
This test actually hits almost all of the edge cases covered by the
previous commits.
1. The "`walletcreatefundedpsbt` does not propagate blinding factors"
issue is actually covered by several existing tests, which did not
fail, but which revealed other bugs as soon as I fixed the issue.
2. Similarly, the "properly blind (or don't blind) explicit change
addresses" issue was covered by existing tests, but was revealed
upon fixing the issue with verifying unblindability in SignPSBT,
since it resulted in using the wrong blinding key to produce
rangeproofs for change.
2a. (While addressing this, I was able to test the SignPSBT checks
extensively, because the code was producing bad rangeproofs. But
in the final result this is *not* covered, since it is hard, or
hopefully impossible, to cajole the wallet into producing outputs
that can't be unblinded now.)
3. Once that was fixed, the existing tests create an output whose
total blinding factor (`v_b + v*a_b`) is zero, which it does by
having no blinded inputs, explicit change/fee, and a single
blinded output. This output is spent in the new test. This tests
one of the "blinding may fail due to zero intermediate values"
cases.
4. The new test then intentionally tests that `walletcreatefundedpsbt`
creates OP_RETURN outputs only when it is legitimately given a
"blinded inputs, no blinded outputs" transaction, which tests the
original bug (that blinding factors were propagated correctly from
`walletfundpsbt`).
5. In doing so, it hit the "OP_RETURN outputs are not blinded when
called from fundrawtransaction" bug.
6. And once this was fixed, `BlindPSBT` has to blind a zero-valued
output, which triggers the other "blinding may fail due to zero
intermediate values" case.
For purposes of assigning blame, I'd say that half of this omnibug came
from the new PSET logic and half was latent in Elements for years. The
most concerning thing, I'd say, is the "explicit change addresses cause
outputs to be blinded to the wrong key" bug, which I believe has been
around for the entire history of Elements.
There are a number of special cases (and inconsistencies with wallet.cpp)
in the blinding logic that can prevent blinding from succeeding when various
intermediate values are zero. This fixes two of them.
A proper fix would involve adding new APIs to secp-zkp and then overhauling
all of the wallet blinding code. But for now let's get the tests working.
When the user specifies a change address manually, use the change address
to obtain blinding parameters (either extract the blinding key from the
address or don't blind the change).
The previous behavior would assume that the change address was owned by
the wallet and always generate a blinding key internally. If the user
were to pass a non-wallet-owned change address, the result would be an
output that could not be unblinded by its owner.
d1a1d19113 test: add decodepsbt and analyzepsbt tests for blinding proofs (Andrew Poelstra)
03b835c887 PSET: output warnings in decodepsbt and analyzepsbt about blinding status (Andrew Poelstra)
694ec795e4 PSET: fix asset proof generation and verification (Andrew Poelstra)
c6f801d4ce PSET: encapsulate blind proof checks into one method (Andrew Poelstra)
35cfda73b9 PSET: do not assume in GetUnsignedTx that explicit amounts/assets are available (Andrew Poelstra)
c88eb96e74 pset: check that we can get the blinding factors from any IsMine outputs before signing (Andrew Poelstra)
9c55d0a175 pset: only check asset/amount proofs in case both explicit+blinded values are provided (Andrew Poelstra)
Pull request description:
After conversation with @stepansnigirev in #1026 I realize we need to adjust our sanity checks on asset proofs. In particular,
* Rather than enforcing that all confidential values have corresponding explicit values with proofs, we should only check that **if** both confidential and explicit values are present, they are connected by a proof.
* Further, the wallet should check before signing that any `IsMine` scripts have confidential values that we are actually able to spend (i.e. rewinding works).
This PR implements these two things, and also extends the `analyzepsbt` and `decodepsbt` RPC calls to provide more information if the amount/asset proofs are missing or invalid. It adds tests for these and also demonstrates that `combinepsbt` does not really work without explicit data present.
`walletprocesspsbt`, when blinding, will still produce these proofs and there is currently no way to disable this behavior.
ACKs for top commit:
achow101:
ACK d1a1d19113
Tree-SHA512: 472ee0fe285308e803cbc3f5885e513ec91d1b3f18a2973772cd5a88d29fa4dba9441d9b3bd58847564e43d9a7478bbc75af62d9326c727709b5ff2dc646714a
