DragonX/hush3
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Delete more CCs #381

Browse Source
This commit is contained in:
Duke
2024-02-10 22:37:22 -05:00
parent c6aa5e939d
commit 958bc486d4
5 changed files with 21 additions and 438 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
src/cc/CCinclude.h
View File

@@ -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 <cc/eval.h>
#include <script/cc.h>
@@ -949,11 +914,6 @@ extern void CCLogPrintStr(const char *category, int level, const std::string &st
template <class T>
void CCLogPrintStream(const char *category, int level, const char *functionName, T print_to_stream)
{
std::ostringstream stream;
print_to_stream(stream);
if (functionName != NULL)
stream << functionName << " ";
CCLogPrintStr(category, level, stream.str());
}
/// Macro for logging messages using bitcoin LogAcceptCategory and LogPrintStr functions.
/// Supports error, info and three levels of debug messages.