From 958bc486d4acf4e445a00aeff28098ce012e229a Mon Sep 17 00:00:00 2001 From: Duke Date: Sat, 10 Feb 2024 22:37:22 -0500 Subject: [PATCH] Delete more CCs #381 --- src/cc/CCinclude.h | 40 ------- src/cc/CCtokenutils.cpp | 236 ++-------------------------------------- src/cc/CCutils.cpp | 121 ++------------------ src/cc/customcc.cpp | 22 +--- src/script/cc.cpp | 40 +------ 5 files changed, 21 insertions(+), 438 deletions(-) diff --git a/src/cc/CCinclude.h b/src/cc/CCinclude.h index 3af9e0711..9846939fb 100644 --- a/src/cc/CCinclude.h +++ b/src/cc/CCinclude.h @@ -18,41 +18,6 @@ #ifndef CC_INCLUDE_H #define CC_INCLUDE_H -/*! \file CCinclude.h -\brief Cryptoconditions - -CCs for teh lulz - -*/ - -/// \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