Feature/p2ah 2miners - #1
Open
Tylerlhess wants to merge 10 commits into
Open
Tylerlhess wants to merge 10 commits into
Tylerlhess wants to merge 10 commits into
Conversation
Author
|
extensive testing found a bug in the chained auth inputs against the altered branch code. fixed and repushed. building an extensive test chain with redundant and consistent pushes of every possible transaction now. |
Replace APIs removed in newer Boost versions: - path::is_complete() -> path::is_absolute() - fs::basename()/fs::extension() -> path::filename() - fs::copy_option::overwrite_if_exists -> fs::copy_options::overwrite_existing Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
KAWPOWHash() caches the ethash epoch context in a function-local static unique_ptr shared by every thread that verifies a KAWPOW proof. Reassigning it on an epoch change frees the previous context, so a concurrent verifier can dereference freed memory inside progpow::hash(). Serialize context creation and use with a mutex.
P2AH is a new output type whose spending authorization is the movement of one or more asset owner tokens (admin assets) through the spending transaction, rather than an ECDSA signature. This generalizes the existing sub-asset issuance pattern (owner token must be present in inputs and outputs) into a spending condition for arbitrary UTXOs. - New 25-byte base script: OP_DUP OP_HASH160 <hash160(preimage)> OP_EQUAL OP_NIP where preimage = serialized (m, sorted owner asset names). Spending reveals the preimage in the scriptSig; consensus requires >= m of the named owner tokens to move through the tx. Asset transfer data can be appended to the base script exactly like P2PKH, so P2AH outputs can hold assets too. - New address type (CAssetAuthID / TX_ASSET_AUTH) with base58 prefixes: mainnet 'H', testnet/regtest 'J'. - Consensus check CheckTxAssetAuthInputs with iterative authorization, enabling chains (key -> moves A! -> authorizes B! -> spends P2AH(B!)) while rejecting authorization cycles. - SCRIPT_VERIFY_REQUIRE_SIGHASH_ALL: txs spending P2AH inputs require all signatures to be SIGHASH_ALL so outputs can't be rewritten by miners. - BIP9 deployment DEPLOYMENT_P2AH (bit 11): regtest/testnet only; mainnet start time set far in the future. - Wallet/keystore storage for P2AH preimages (assetauthpre wallet records). - Policy: P2AH outputs/inputs nonstandard until deployment activates. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
New RPC commands in src/rpc/assetauth.cpp: - createassetauthaddress: create a P2AH address from m-of-n owner asset names - addassetauthaddress: same + store preimage in wallet and watch the address - getassetauthinfo: decode a P2AH address or preimage - spendassetauth: wallet spend from a P2AH address (auto-selects owner tokens, moves them to fresh addresses, builds/signs/broadcasts) - verifyassetauth: verify the P2AH authorization of a raw transaction using the same consensus check (CheckTxAssetAuthInputs) - listassetauthutxos: list UTXOs at a watched P2AH address Raw transaction support: - signrawtransaction prevtxs accepts assetAuthPreimage for P2AH inputs - decoderawtransaction/gettxout show assetauth info on outputs and decode preimages on inputs - SignStep handles asset-carrying P2AH scripts (preimage instead of key sig) Verified end-to-end on regtest: 1-of-1 spends, 2-of-3 multisig, chained authorization (ROOT! -> LEAF! -> RVN in one tx), and rejection of spends without owner-token movement. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Unit tests (src/test/assets/assetauth_tests.cpp, 11 cases): - Preimage validation, serialization, and canonical hashing - Script recognition (Solver, ExtractDestination, address round-trip) - ScriptSig preimage parsing - Consensus authorization: valid spends, missing movement, wrong preimage, m-of-n thresholds, chained authorization, cycle rejection, and one token authorizing multiple inputs Functional test (test/functional/feature_assetauth.py, 12 scenarios): - Pre-activation policy rejection and BIP9 activation - Address creation, canonicalization, and validation - 1-of-1 and 2-of-3 spends via spendassetauth - Consensus rejection of spends without owner-token movement - P2AH outputs holding assets - Chained authorization across P2AH addresses (and rejection without root) - verifyassetauth reporting, wallet preimage persistence across restart Also updates one base58_keys_invalid.json vector whose version byte (40) is now the valid mainnet P2AH address prefix; the replacement uses unused version byte 41 to preserve the test's intent. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Resolve parent P2AH inputs when owner tokens sit upstream, move key roots to fresh addresses, and return chained tokens to the parent P2AH so the leaf chain can be spent again. Co-authored-by: Cursor <cursoragent@cursor.com>
ResolveAssetAuth already marks key and P2AH inputs in the shared used sets during recursion; re-checking insert on merge skipped ROOT! and broke chained P2AH spends. Also fix feature_assetauth test helpers for chaining. Co-authored-by: Cursor <cursoragent@cursor.com>
Includes a flock-protected cron runner for unit/functional batteries and feature_assetauth_stress.py for repeated chaining, multisig, and rejection scenarios on every scheduled run. Co-authored-by: Cursor <cursoragent@cursor.com>
Use a fixed datadir across cron runs with height-based unique asset tags, mempool recovery, nested multisig scenarios, and a subpoena recovery seizure chain that walks three layers of 2-of-3 P2AH authorization. Co-authored-by: Cursor <cursoragent@cursor.com>
Tylerlhess
force-pushed
the
feature/p2ah-2miners
branch
from
August 17, 2026 21:02
e11a7e9 to
01db553
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a request to add the P2AH functionality to the branch.
This adds the ability to send transactions to admin assets. P2AH uses the sub-asset creation authorization path to authorize the spend of the UTXO's assigned to the admin asset. Mainly by having the admin asset as part of the transaction.
By holding an admin asset (Holder asset) in a multi-sig 1 of X address for multiple P2AH assets you can create a joint account where either admin asset (Signing asset) can sign the transaction to use the joint account Holder asset transferring the Holder asset back into the joint address.
As the underlying signing asset is moving to a new address and needs to be part of any further authorization transaction this keeps the signature cryptographically safe as there is no replay attack possible from the new address. The signatures are layered such that each UTXO Holder is signed by a Signer which can itself also be a Holder asset. Since the assets can be chained they have to ultimately be signed by a Signer asset that is transferred to a new address with an unused key.
This adds the ability to offer KYC, Joint accounts for custodial or Shared asset access (spouse), Joint custody of exchange assets, Recoverability through trusted parties each Holding a multi-sig x of y Signer asset to sign the transfer of a Holder asset that you have lost access to into a new address with a new set of Signer assets. This also opens up a pathway for government seizure through subpoena to KYC/Recovery service providers which should ease any regulatory bodies hesitance of cryptographically signed assets.
All of the above features are completely opt in and intentional but allow for regulatory control and parity with current banking systems.
This is the chain enhancement that will put Ravencoin back on the map for its forward thinking and asset management capabilities.