// Copyright (c) 2016-2020 The Hush developers // Distributed under the GPLv3 software license, see the accompanying // file COPYING or https://www.gnu.org/licenses/gpl-3.0.en.html /****************************************************************************** * Copyright © 2014-2019 The SuperNET Developers. * * * * See the AUTHORS, DEVELOPER-AGREEMENT and LICENSE files at * * the top-level directory of this distribution for the individual copyright * * holder information and the developer policies on copyright and licensing. * * * * Unless otherwise agreed in a custom licensing agreement, no part of the * * SuperNET software, including this file may be copied, modified, propagated * * or distributed except according to the terms contained in the LICENSE file * * * * Removal or modification of this copyright notice is prohibited. * * * ******************************************************************************/ #ifndef CC_INCLUDE_H #define CC_INCLUDE_H /*! \file CCinclude.h \brief A Documented file. Details. */ /// \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. /// #include #include