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.
A couple issues with this -- one is that it was verifying the asset
commitment against itself, rather than against the explicit asset,
and the other is that the verification logic had an extra `== 0` at
the end which inverted the verification check.
Both pretty embarassing to have not caught in review..
Currently when a user uses `signrawtransaction` on a transaction that is
already partially signed with SIGHASH_RANGEPROOF signatures, the existing
signatures will be deleted because they are not recognized as valid. This
makes it impossible to collabratively sign transactions using this RPC.
Fix this.
The logic for computing the uncached version of the sighash changed during
the 0.21 rebase, such that it no longer matched the cached version. As the
changed hash is used during signing (not verification!), this was not a
forking change (and our existing functional test would have caught such a
forking change since it uses Python to independently compute the hash).
But it still broke signing.
Test in next commit.
3cb9612faa test: add test for Taproot activation (Andrew Poelstra)
5291c0d9d9 chainparams: add undocumented regtest/testnet only -con_taproot_signal_start option (Andrew Poelstra)
cc6b933478 add missing taproot activation params for Liquid v1 (Andrew Poelstra)
bec6bcf31b versionbits: allow specific deployments to override the signalling/threshold values (Andrew Poelstra)
Pull request description:
Sets Taproot to start signalling around noon (California time) on Nov 1, 2021, assuming 95% of blocks are produced between now and then.
Will activate after one week of 100% signalling. If we can pull this off on the first or second try, we will beat Bitcoin which currently looks like it will activate on Nov 16.
**Edit:** actually, even without Speedy Trial, there is one full period (week) where Taproot will be "locked in" but not "active". So it will activate on Nov 15 at the earliest.
ACKs for top commit:
achow101:
ACK 3cb9612faa
Tree-SHA512: c3a80d39ba86a0d762a3057cb9c45e379c70c2daee8ff2e54978a4c32118c935c8909d872ac9f873e283441c52c1974c06268f10dc7bf9e9e000c21063ac84d7
1204b91c2d re-enable fallbackfee by default (Andrew Poelstra)
Pull request description:
Upstream disabled the default `fallbackfee` option in 0.17, which caused us some user error reports in 0.18. Re-enable the option in 0.21.
ACKs for top commit:
stevenroose:
utACK 1204b91c2d
Tree-SHA512: 62d053405c00f5ca31ae3fb24ab8def2c9e3bd52909dfac57e65224947295a56f0b8a322ffeb0dfcdcb3103fcaf310a9554f3ed3a8490859ca82aaeae26c7fb2
e57b4c51ad regtest: change network magic away from liquid v1 (Andrew Poelstra)
Pull request description:
We don't want connectivity issues between Liquid and custom test networks.
ACKs for top commit:
stevenroose:
ACK e57b4c51ad
Tree-SHA512: 3ddd626496d7877551c41b089932784bcb752962089fd3e6baa5e9ea6acac44b1b4c5c915b061892b712849d12455fae00347885cecb0e0a3b59a134d91d4014
fc8bfc1f2c claimpegin: add regression test for behavior when fallbackfee is disabled (Andrew Poelstra)
fd520079a1 claimpegin: sanity-check fee in case fallbackfee is disabled, throw explicit exception (Andrew Poelstra)
Pull request description:
Produce a much less confusing error message in `claimpegin` in the case that estimatesmartfee fails and no fallbackfee is set.
ACKs for top commit:
stevenroose:
ACK fc8bfc1f2c
Tree-SHA512: 2ae658ab3dc90b7319d047c192401a0dcc97e015e45b5b0db71db1d89d63605ba107312d8b4cf1c4aaef72437aa20aa33b442744f64fc08535b15610e6f4a526
bcd7de55a4 fuzz: update psbt fuzztest for PSBT2 changes (Andrew Poelstra)
Pull request description:
The `psbt.tx` Optional is no longer safe to dereference just because decoding succeeded.
ACKs for top commit:
achow101:
ACK bcd7de55a4
Tree-SHA512: 701ace683a2615a944903ec69a20d1808da03009bec6e7af76954476d4e66b122fe01657285252b90fad92cc8aadd46095c80a1ccf454ae11f0e86a550ce1a0b
048ca4a550 pset: fix logic bug in `analyzepsbt` so that the "blinder" role may be returned (Andrew Poelstra)
ec27e74f21 pset_tutorial: write 2-party PSET coinjoin demo (Andrew Poelstra)
a7643260a4 assets_tutorial: move Daemon into its own file (Andrew Poelstra)
Pull request description:
Adds a second executable tutorial which uses the PSET API to produce a swap transaction.
ACKs for top commit:
achow101:
ACK 048ca4a550
Tree-SHA512: 61720d905401a79dc9b6d6ae20a69b6216592e6b5b245c7e11c0b8323ff125a27a9d4eb1ba5b76b7024c91dc3dd0765c19ec7ae06315f5e719758d3569b0cb6f
b2e1cc38de Regression test for pegin validation issues during sync (Glenn Willen)
d5042b41c8 Finish removing 'recheckpeginblockinterval'; move MainchainRPCCheck (Glenn Willen)
313f73d5b2 When validation is waiting for parent chain daemon, "stall". (Andrew Poelstra)
Pull request description:
Forward-port of #1022
ACKs for top commit:
gwillen:
utACK b2e1cc38de, verified that it contains only the requested changes from da11d7b6fd.
Tree-SHA512: 971b6a137efdc54f84995b17595346bf3d3ebd5a04eef1676225c664923e0b52393550bc51ea366c4d3010aa35a9de16da0643bb5bfb40c7eb788a180c99b1a0
3ac7e78a84 pset, rpc: Better error messages for imbalance failure conditions (Andrew Chow)
b2a7007961 pset: verify blind value and asset proofs when signing (Andrew Chow)
a7ef9f325d pset, test: Test a PSET coinjoin workflow (Andrew Chow)
ac580db4ec pset, rpc: Do not fail walletprocesspsbt if missing utxos when blinding (Andrew Chow)
9f94966581 pset: Allow GetUnsignedTx to force unblinded values (Andrew Chow)
f9f084f785 pset: Add missing fields to merging and fix combinepsbt (Andrew Chow)
59f65a3f73 rpc, pset: Include blinded value and asset proofs in decodepsbt (Andrew Chow)
941c54fcda pset: Create explicit value and asset proofs during blinding (Andrew Chow)
63c007dd6b pset: blind commitment proofs de/ser (Andrew Chow)
b9a08f3773 doc, pset: Add blind commitment proofs (Andrew Chow)
9856f2caa2 pset, doc: Remove requirement to remove blinded amounts and assets (Andrew Chow)
37c925f472 pset: Do not remove amounts after blinding (Andrew Chow)
Pull request description:
In order for blinded coinjoins with 3 or more parties to work, some fields need to be added, amounts cannot be removed, and some bugs need fixing.
First and foremost is to no longer remove amounts after blinding. Due to a miscommunication, I had believed that part of the goal of PSET was to hide semi private information (such as output amounts) from other parties in the transaction. However this causes the combiner to fail because the unique ID is dependent on those amounts and their commitments. If multiple parties had blinded just their own outputs, then the resulting PSETs would not combine because the amounts had be removed and so the unique ID calculated was incorrect. In order for this combining to work, amounts must be kept after blinding and the unique ID calculation must only use the computed unblinded transaction. This change has also been made to the spec document.
Second is the addition of explicit value and asset proofs. In order to prove that the commitments commit to the given explicit value or asset, explicit value rangeproofs and explicit asset surjection proofs are added to PSET. Each blinded output must have an explicit value rangeproof and explict asset surjection proof after blinding. For issuances, explicit issuance value proofs and explicit reissuance value proofs must be added after blinding. These proofs are verified prior to signing.
Thirdly, in order to make the coinjoin workflow work, a `blind` option is added `walletprocesspsbt` so that users can tell `walletprocesspsbt` to not attempt to blind. This is important because blinding requires all UTXOs to be present, and UTXOs can only be added via a call to `walletprocesspsbt`. Error messages have been added and improved so that users who do things in the wrong order will be less likely to end up with an unusable PSET.
Lastly, a test case has been added for a 3 party coinjoin workflow.
Fixes#1037
ACKs for top commit:
apoelstra:
ACK 3ac7e78a84
Tree-SHA512: b1fd848c72d8dd779b0f0640d9321b8085d62db494d25f81e3ec90e43c4a4edbe537dec404d8170a7ad057027c07f2b948980907d0849da693b2ca1bf0cf81f6
Instead of not failing and silently allowing bad PSETs to be created,
provide error messages that explain why the operation the user did was
wrong. Specifically for combining PSETs such that they would become
fully blinded but have imbalanced values and blinders, and for blinding
a PSET when the wallet has a blind input but no outputs to blind (would
result in an imbalance).
- Finish removing all references to 'recheckpeginblockinterval', including
documentation and tests.
- Remove periodic calls to MainchainRPCCheck; use it only at startup (and
refactor accordingly to simplify logic.)
- Move MainchainRPCCheck from validation.h/cpp (public) to an internal
helper function of init.cpp.
- Comment out definition of 'revalidation queue' type in txdb, to suppress
"unused variable" warning. (Leave it visible to avoid future reuse.)
Currently, if -validatepegin is given, and block validation can't proceed
because the parent chain is not synced, we mark the block invalid and put
it in a queue to be "revalidated" later. Unfortunately, marking a block
invalid has downstream consequences, in particular causing descendant blocks
to be marked invalid, which are not currently fixed by the queue.
Instead, we'll use a different strategy: if the mainchain daemon isn't
sufficiently synced to validate a block, we will "stall" connecting that
block to the chain, and have ActivateBestChain simply keep the tip at the
previous block until we're ready.
We can still download and validate (partly) blocks past this point while
we're waiting. They will be connected once the parent chain daemon catches
up.
Instead of discarding a PSET when the UTXOs are missing and the blinding
step fails in walletprocesspsbt, just ignore a missing UTXOs error and
don't blind.
In order to get the Unique id for a PSET, the explicit values and assets
need to be used. Since GetUnsignedTx is used to create the tx that is
hashed, modify GetUnsignedTx so that the explicit values and assets are
used when requested.
* Add some fields that were missing in PSBTInput::Merge and PSBTOutput::Merge
* Remove incorrect check that explicit values and assets aren't present
when blinded
* Fix bug in combinepsbt where the condition was inverted
Core's fee logic has a special case where it will give a zero fee estimate
if fallbackfee is disabled and it has no good data from estimatesmartfee.
If it gets a nonzero value below the min relay fee, it'll instead use the
min relay fee ... but zero is special. I think this is a bug. Regardless,
it was causing confusing error messages in `claimpegin`, especially as
the fallbackfee is no longer set by default as of 0.21
6f428ecf8a ci: fix intermittent failure in feature_block_subsidy.py (Andrew Poelstra)
abb52c861c rpc: specify that `witnessScript` is optional for `signblock` and `combineblocksigs` RPC call (Andrew Poelstra)
88edb9f9ff rpc: correct type in `calculateasset` (Andrew Poelstra)
b4369c06a2 rpc: change walletprocesspsbt help text to match upstream (Andrew Poelstra)
Pull request description:
.
ACKs for top commit:
achow101:
ACK 6f428ecf8a
Tree-SHA512: 38afb0d1f3e4a7839ecea7dccb996f1d996d037e14f630d8cc943bd5f34fbc7d510f9c2d4fbb5fb1eb3435f4a9a602a9ff9635ecd8c2a8d8adcccf7dd4b7c0cb
How to review this PR:
* Skim the description of https://github.com/bitcoin/bitcoin/issues/20347
to see that it's roughly "when pick_new_inputs is unset but bnb_used is
set, one the next iteration of the loop an assumption may be wrong"
* See that in this case, we just add another iteration to the loop...
* ...in exactly the same way as the other place that pick_new_inputs is
turned off, I just missed this one before
* Observe that the regression test fails before the patch but passes after.
