This allows other elements chains as parent chains for pegs, for testing purposes
for now it also assumes that the parent chain has CT/CA tx format,
which is orthogonal to the parent chain having pow or signed blocks
It would be nice to also test bitcoin-like chains with signed blocks
instead of pow by adding another parameter -con_parent_chain_has_CT or
similar and decouple the logic
Introduce -con_parent_pegged_asset option to check the asset in the
peg-in txs from the parent chains.
CT: Introduce GetAmountFromParentChainPegin for CT txs
RPC: Adapt rpcwallet to initial -con_parent_chain_has_pow
Introduce CheckProofGeneric
Introduce pow::CheckProofParent
a20986b 2WP: Refactor out GetAmountFromParentChainPegin (Jorge Timón)
2be9cae Refactor: Validation: Make parts of IsValidPeginWitness templated (Jorge Timón)
The checks are redudant because too large range proofs and surjection
proofs will be rejected by libsecp256k1. Furthermore, the checks are not
precise, and they are anyway not present in other similar code locations.
05602ed Improve comments for VerifyAmount() (Tim Ruffing)
42b62ac Ensure that input witness is present before accessing range proofs (Tim Ruffing)
670229e Use new helper function to verify issuance of re-issuance tokens (Tim Ruffing)
d7abf18 Extract helper function from VerifyAmount() (Tim Ruffing)
e183868 Forbid explicit issuance of 0 asset units (Tim Ruffing)
bef2760 Assert return value of secp256k1_pedersen_commit() for issuances (Tim Ruffing)
46f2416 Remove old testing code (Tim Ruffing)
This removes checks from the pre-asset era that reject amounts on the
input side of a transaction if these amounts overflow. The checks are
superficial because VerifyAmounts() already rejects input amounts that
could potentially overflow.
One of the removed checks is wrong because it rejects legitimate
transactions that spend more than MAX_MONEY asset units altogether,
even if those units belong to different assets. For example, a
transaction spending MAX_MONEY units of an asset "apple" and MAX_MONEY
units of an asset "orange" was previously rejected because the code
literally added apples and oranges in this case.
This forbids the explicit issuance of 0 re-issuance tokens (like for the issuance of
normal assets. The proper way to issue no re-issuance tokens is to use a
null commitment for the amount.
The proper way to issue 0 units of an asset is a null commitment but not
an explicit commitment to 0.
This commit eliminates the issue that some checks in the verification of
the issuance of re-issuance tokes were skipped when issuing 0 asset units
explicitly. This commit also simplifies the control flow of the relevant
code locations.
