Add a regression test for https://github.com/ElementsProject/elements/issues/891 .
This checks that we can sync successfully when making a bunch of new blocks
just as we have transient loss of parent daemon connectivity. This reliably
fails without the fix, and reliably succeeds with it. (It stands in for the
situation, more common in production, where we sync faster than the parent
daemon can keep up after a long outage.)
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.
Note that this is a breaking change in Core's RPC -- if you add pegins
to createfundedpsbt then it won't do coin selection unless you provide
the additional new add_inputs option.
This Elements PR includes components of Core PR #17211, which since the
refactors to use effective value landed, no longer provides the right
error message when a user provides an unowned input from a wallet tx.
See https://github.com/bitcoin/bitcoin/pull/17211#pullrequestreview-528389011
This breaks a functional test which was included in this PR, but which
conveniently has been changed in the current version of the Core PR. I
fixed the behavior (commented, in SelectCoins) rather than updating the
test to the most recent version.
To resolve the `ConstructTransaction` conflict I reverted to the existing code
then manually applied the diff (it adds a parameter then adds a giant pile of
code to the input loop).
FIXME: we disable standardness checks for the non-PAK node in the PAK tests.
This is because of a bug in Elements which causes non-PAK nodes to reject
pegouts for standardness reasons. Need to fix it after the rebase.
Fix multiple issues with claimpegin and createrawpegin support for
multiple loaded wallets:
- Failure to call EnsureWalletIsAvailable would cause a crash when multiple
wallets were loaded, but one was not specified in the RPC call.
- Failure to propagate the request URL from claimpegin when making an
internal call to another RPC would result in failure when multiple
wallets were loaded, by failing to specify one for that call.
Add a regression test to the feature_fedpeg.py test: at a critical point,
create a second wallet on the sidechaind, and set up the RPC client to
use the first one, to check that it still works correctly.
5a4d61169 Test raw transaction peg-in (Andrew Chow)
ac6f052a6 Have find_vout_for_address only get non-confidential address when using elements chain (Andrew Chow)
cefe40767 Allow specifying peg-in info in raw transaction RPC inputs (Andrew Chow)
42babb81f Refactor peg-in input construction into its own function in rpc/rawtransaction.cpp (Andrew Chow)
a90d1521c Refactor peg-in witness construction to it's own function (Andrew Chow)
Pull request description:
Adds to `createrawtransaction` the fields `pegin_bitcoin_tx`, `pegin_txout_proof`, and `pegin_claim_script` so that raw transactions can contain peg-in inputs too.
Since `ConstructTransaction` is used by `createpsbt` and `walletcreatefundedpsbt` but those should not support peg-ins yet (the peg-in data should go into PSBT fields for peg-ins but those don't exist yet), an argument is added to it to optionally reject peg-in data.
Tree-SHA512: fcf3e4be87f92bfc5b00321bec405001d98615cefb76118345e0c759c6bfcb90b6050735960b6fbdbe26479fa11c9273f9963873a8adc1fbad9ed31dc7953ee0
- changes the expected behavior of claimpegin to fail on double spend
- adds extra test to make sure a block with a double spend is also not
accepted:
1. a tx with two identical pegin inputs (mempool & block)
2. a tx claiming a pegin that another mempool tx also claims
3. a tx claiming a pegin that a confirmed tx already claimed (mempool
& block)
30eb323e9 ensure pak wallet is returning right kind of addresses (Gregory Sanders)
9e56c87ec have validateaddress give useful parent chain addr info (Gregory Sanders)
894d76e7c test all single-key pegout address types (Gregory Sanders)
40a62a151 DestinationEncoder: don't assert when a parent destination is unblinded (Gregory Sanders)
Pull request description:
Added more utility to `validateaddress` for parent addresses by returning an additional object `parent_address_info`, then used it to enhance various tests.
Tree-SHA512: 941ef1dc8b7469c3274a50907ea788fe520398809d5c4ac901ef057dfa688f63b45f0be298de14c07c250015d02de8f2f4687e430da121fba759e3879823947f
91294ca01 Adapt Elements default adress prefix bytes to elements-0.14 style (Gregory Sanders)
410d5fa08 sendtomainchain_base should be decoding parent destination (Gregory Sanders)
Pull request description:
Also chose `ert` as bech32 hrp, just to make it distinct.
Clustered the various address parameters for ease of the reader.
resolves https://github.com/ElementsProject/elements/issues/567
Tree-SHA512: aae4b31b0c5ead9801dad13a50ddfc934216df783d6294bb4e2ae515bba27960a9643ccaae87a60c9637c44aeb6d4b0329eeb70846b07e6e88e9133edcd74315
5acc42e4e feature_fedpeg.py: remove the spam output (Gregory Sanders)
870e41609 Enforce coinbase maturity on bitcoin peg-ins (Gregory Sanders)
Pull request description:
resolves https://github.com/ElementsProject/elements/issues/14
Technically a softfork but not really since the elements chain would eventually become valid anyways.
Tree-SHA512: bfdf404f7056e6b16adde3a82b0e11839b921fd08063ae6415d207b553e1a19c5f5a76cb308af1ca63164c001eb59b5874fe33160f7bf87061a6a4a507aa9241
