/// \mainpage Brief introduction into cryptocondition contracts
/// There are only a very few types in bitcoin: pay to pubkey, pay to pubkey hash and pay to script hash (p2pk, p2pkh, p2sh).
/// There are actually more that are possible, but those three are 99%+ of bitcoin transactions.
/// So you can pay to a pubkey, or to its hash or to a script's hash. The last is how most of the more complex scripts are invoked. To spend a p2sh vout, you need to provide the redeemscript,
/// this script's hash is what the p2sh address was.
/// All of the above are the standard bitcoin vout types and there should be plenty of materials about it.
///
/// Cryptoconditions (CC) contracts created a fourth type of vout, the CC vout. This is using the cryptoconditions standard and it is even a different signature mechanism,
/// ed25519 instead of secp256k1. It is basically a big extension to the bitcoin script. There is a special opcode that is added that says it is a CC script.
///
/// But it gets more interesting. Each CC script has an evalcode.
/// This is just an arbitrary number but what it does is allows to create a self-contained universe of CC utxo that all have the same evalcode and that is
/// how a faucet CC contract differentiates itself from a dice CC contract, the eval code is different.
///
/// One effect from using a different eval code is that even if the rest of the CC script is the same, the bitcoin address that is calculated is different.
/// What this means is that for each pubkey, there is a unique address for each different eval code!
/// And this allows efficient segregation of one CC contracts transactions from another.
/// The final part that will make it all clear how the funds can be locked inside the contract.
/// This is what makes a contract, a contract.
/// I put both the privkey and pubkey for a randomly chosen address and associate it with each CC contract.
/// That means anybody can sign outputs for that privkey.
/// However, it is a CC output, so in addition to the signature, whatever constraints a CC contract implements must also be satistifed.
/// This allows funds to be locked and yet anybody is able to spend it, assuming they satisfy the CC's rules.
///
/// One other technical note is that Hush has the insight-explorer extensions built in
/// so it can lookup directly all transactions to any address.
/// This is a key performance boosting thing as if it wasnt there, trying to get all the utxo for an address not in the wallet is quite time consuming.
if(foundOldstyle){//patch for old-style opret data with no opretid
LOGSTREAM((char*)"cctokens",CCLOG_DEBUG1,stream<<"DecodeTokenOpRet() found old-style rogue/asset data, evalcode="<<(int)voldstyledata.begin()[0]<<" funcid="<<(char)voldstyledata.begin()[1]<<" for tokenid="<<revuint256(tokenid).GetHex()<<std::endl);
if((payoutCond=MakeTokensCCcond1of2(cp->evalcode,cp->additionalTokensEvalcode2,pk,pk2))!=0)// if additionalTokensEvalcode2 not set then it is dual-eval cc else three-eval cc