Alberta Buck -- Identity and Cryptographic Receipts (DRAFT v0.1)

If I am suspected of a crime, an Alberta court can compel me to decrypt the participants in BUCK transactions they suspect are related to that crime, and reveal the identity of counterparties I've transacted with. I may resist, and face the consequences. But the organizations that Alberta tasks with overseeing the authenticity of my Alberta issued identity must not be able to simply authorize decryption of my counterparties' identities! They can only vouch for and reveal the identities they've directly issued, just as I can vouch for my daughter's – they can't decrypt arbitrary participants in each transaction.

This is how the cryptography enforces it: each re-encrypted identity is an ElGamal ciphertext under the specific counterparty's public key. Only that counterparty's private key can recover the plaintext. The identity issuer cannot decrypt it – they signed the identity, not the ciphertext; the encryption is mine alone. The government cannot decrypt it. No registry operator, no Holochain node, no subpoena served on anyone other than a direct participant can break this. A court must compel a specific participant to decrypt a specific transaction's counterparties' identity data. Every individual's credential must be attacked separately. The cost to surveil is O(N), not O(1).

identityRegistry.registerCredential(
    alice_new_address,
    pk_new,          // identity public key
    E_new,           // ElGamal ciphertext (4 uint256)
    sigma_prime,     // rerandomized PS signature (2 G_1 points)
    pi               // NIZK proof linking sigma' to E_new
)

I may be a citizen of Alberta and have a minor child. My child's identity is vouched by me, and my identity is vouched by Alberta. I have several accounts associated with encrypted copies of my identity (income, savings, etc) and several unencrypted accounts (walking-around money). I can transfer money from my savings to my walking-around account (anonymously, via my BUCK account at ATB).

My encrypted savings account identity has been authorized by ATB to send funds. My walking-around money account has a plaintext identity, so Starbucks' BUCK account doesn't need to pre-authorize incoming transactions – it accepts BUCK transfers from any BUCK account with a public identity.

This just cuts out the middleman, and gives every citizen what government and institutions already have: knowledge of the participants in transactions with public accounts. If I prefer, I can set up a Starbucks account, and ask them to authorize me to send money to them. Again, allowing with BUCKs what is already allowed with a pre-loaded Starbucks card – private transactions with a public account. Starbucks and Visa both know who paid to fund the Visa card, and who funded their Starbucks account with that card. Now, citizens can set up similar arrangements and retain that knowledge amongst themselves.

If a court compels one of the participants (for example, as the result of an arrest in a sting operation against some members of a group performing some illicit activity), then that person's transactions with other members of the group can be discovered. Otherwise: financial activity remains confidential, at the sole choice of the participants.

The expectation that any government or bank functionary – or any random attacker exploiting government or bank incompetence – can know the details of a citizen's financial activities is unacceptable. The attack cost must be O(N), not O(1): every individual's credential must be attacked separately, not extracted from one compromised custodian.

Each transaction is between parties identified to each other by provably untampered copies of their identity, encrypted by each party specifically for that counterparty.

The identity credential lifecycle:

1. Issuance: A trusted issuer (the Alberta government, ATB Financial, etc.) verifies Alice's identity through a KYC ceremony and produces a Pointcheval-Sanders signature on her identity scalar m = H(identity_data). Alice receives (m, sigma) and stores it in her Holochain wallet. (See The Identity Fountain for the full PS construction.)
2. Derivation: For each Ethereum account, Alice's wallet rerandomizes the PS signature, generates a fresh identity key pair, encrypts her identity under the new key using ElGamal, and produces a NIZK proof linking the rerandomized signature to the ciphertext. This runs entirely offline.
3. Registration: Alice registers the derived credential (pk, E_alice, sigma', pi) in the on-chain IdentityRegistry. The contract verifies the PS signature and NIZK proof via the ecPairing precompile (200,000 gas, one-time). After registration, ~isVerified(alice) == true.
4. Re-encryption: When Alice must identify herself to counterparty Bob (e.g., during an approve call on the BUCK contract), she decrypts her credential locally (she knows sk_alice) and re-encrypts the identity under Bob's public key with fresh randomness: E_bob = (r' * G, r' * pk_bob + M) where M = m * G is the identity message point. She produces a Chaum-Pedersen proof³ pi that E_bob encrypts the same point M as her registered E_alice – without revealing m.

5. Verification: The BUCK smart contract verifies:

   • E_alice is read from the IdentityRegistry (not from Alice's calldata)
   • pi proves E_bob encrypts the same plaintext as E_alice

   Verification requires only 3-4 elliptic curve scalar multiplications (~29,000 gas via the alt_bn128 precompiles). No pairing operations at transaction time. The PS signature was verified once, at registration, and is never consulted again.

6. Decryption: Only Bob can decrypt E_bob (he has sk_bob). Only Alice can decrypt E_alice (she has sk_alice). The issuer cannot decrypt either – they signed Alice's identity scalar, they never encrypted under any key. No third party can decrypt any re-encrypted copy.

There is no need for Proxy Re-Encryption (PRE), because Alice is online when she calls approve and can perform the re-encryption directly. The Chaum-Pedersen proof is the trust anchor at transaction time: it is a mathematical guarantee – unforgeable under the discrete logarithm assumption – that Alice re-encrypted her genuine, registered identity and not a substitute. The PS signature is the trust anchor at registration time: it guarantees the credential was issued by an authorized issuer.

Alberta Buck mandates that all identity credentials, all participant key pairs, all re-encryption operations, and all issuer signatures use the alt_bn128 elliptic curve (BN254)¹ – the curve supported by Ethereum's precompiled contracts:

• ecAdd (address 0x06): point addition, 150 gas
• ecMul (address 0x07): scalar multiplication, 6,000 gas
• ecPairing (address 0x08): bilinear pairing check, 34,000 gas per pair + 45,000 base

This mandate is a design strength, not a limitation:

• Uniform proof verification: every Chaum-Pedersen proof and every Pointcheval-Sanders signature verification uses the same curve group, so a single on-chain verifier handles all identity operations.
• Precompile efficiency: per-transaction Chaum-Pedersen verification uses ecMul / ecAdd (29,000 gas). One-time credential registration uses ~ecPairing for PS signature verification (~200,000 gas).
• No cross-group compatibility issues: since all participants, issuers, and credentials use the same curve, re-encryption between any two participants is always algebraically compatible.

Participant key pairs for identity purposes are distinct from their Ethereum signing keys (which use secp256k1). The identity key pair is generated during credential derivation (not during the KYC ceremony – the KYC ceremony produces only the PS signature). The public key is registered in the IdentityRegistry alongside the participant's Ethereum address.

When Alice re-encrypts for N different counterparties, each re-encryption uses independent randomness. The resulting ciphertexts are IND-CPA secure: computationally indistinguishable from random curve points. An observer who collects all N ciphertexts cannot determine that they encrypt the same plaintext (without access to a counterparty's private key).

The Chaum-Pedersen protocol³ is a sigma protocol (Schnorr family) that proves two ElGamal ciphertexts encrypt the same message point, without revealing the message. Made non-interactive via the Fiat-Shamir heuristic, the proof is compact (~128 bytes: two scalars and two curve points) and verification requires only 3-4 multi-scalar multiplications.

Registered credential (verified at registration via PS signature + NIZK):
  E_alice = (R_a, C_a) = (r_a * G,  r_a * pk_alice + M)
  where M = m * G  (identity encoded as a curve point, m = H(identity_data))
  Rerandomized PS signature sigma' verified at registration (not consulted again)

Alice's re-encryption for Bob:
  E_bob = (R_b, C_b) = (r_b * G,  r_b * pk_bob + M)
  using the SAME message point M

"I know (sk_alice, r_b) such that:
  1. pk_alice = sk_alice * G                    -- I own this public key
  2. R_b = r_b * G                              -- I know E_bob's randomness
  3. C_a - sk_alice * R_a = C_b - r_b * pk_bob  -- same message point M"

Given public inputs:
  E_alice = (R_a, C_a)     -- from IdentityRegistry (PS-verified at
                              registration, read from storage -- NOT
                              supplied by Alice)
  E_bob   = (R_b, C_b)     -- from Alice's approve() calldata
  pk_alice                 -- from IdentityRegistry
  pk_bob                   -- from IdentityRegistry
  proof   = (e, s1, s2)    -- Fiat-Shamir challenge and responses

Verify:
  Recompute challenge e from commitments
  Check consistency of s1, s2 against e, the public keys, and ciphertexts
  3-4 ecMul + 3-4 ecAdd operations

Every attack that involves substituting false identity data fails for the same fundamental reason: the Chaum-Pedersen proof is sound. A valid proof for a false statement does not exist.

The proof asserts:  E_bob encrypts the same M as E_alice
The contract reads: E_alice from the registry (PS-verified, immutable)
Therefore:          E_bob must encrypt Alice's real identity
Alice cannot:       supply a different E_alice (contract reads from storage)
Alice cannot:       produce a valid proof for different M (soundness)
Alice cannot:       forge the issuer's PS signature (q-SDH unforgeability)
Alice cannot:       link her accounts to each other (PS rerandomization)
Bob cannot:         produce a different plaintext (ElGamal decryption is deterministic)
Eve cannot:         decrypt E_bob (she lacks sk_bob)
Eve cannot:         link Alice's accounts (statistical unlinkability)

Three independent hardness assumptions protect the system:

1. PS signature unforgeability (q-SDH assumption): prevents forged credentials
2. Discrete logarithm hardness (alt_bn128): prevents false Chaum-Pedersen proofs and unauthorized ElGamal decryption
3. ECDSA unforgeability (secp256k1): authenticates Ethereum transactions

All three assumptions also underpin Ethereum itself. If any breaks, Ethereum's own security fails first – the Alberta Buck identity system does not introduce any novel cryptographic assumptions.

Events are public. Every emit on Ethereum is readable by every node. A naive design that emits identity addresses or public keys in receipt events creates a permanent, public, linkable identity graph of every BUCK transfer – defeating the entire privacy model.

The constraints that drive the on-chain design:

1. The EVM is transparent: every contract execution, every storage slot, every emitted event is publicly reconstructible. The BUCK contract cannot hold decrypted identity data, even transiently.
2. The contract must verify, not learn: the BUCK contract enforces isVerified and verifies Chaum-Pedersen proofs. It confirms that a re-encrypted identity ciphertext is genuine. It never learns the identity itself.
3. DeFi timing: in a transferFrom call, the Uniswap router cannot pass receipt data. Identity exchange must happen earlier, at approve time.

The ElGamal Chaum-Pedersen approach resolves all three. The contract reads E_alice from the IdentityRegistry (not from calldata), verifies a compact Chaum-Pedersen proof (~29,000 gas), stores a hash of the re-encrypted ciphertext, and emits only opaque curve point coordinates. No identity content touches the EVM in any form.

The ERC-20 approve function is the natural point for identity exchange. Alice is directly calling the BUCK contract – she can provide the re-encrypted ElGamal ciphertext and the Chaum-Pedersen proof:

function approve(
    address spender,
    uint256 amount,
    uint256[4] calldata E_spender,       // ElGamal ciphertext (R.x, R.y, C.x, C.y)
    uint256[3] calldata chaumPedersen     // Fiat-Shamir proof (e, s1, s2)
) public returns (bool) {
    _approve(msg.sender, spender, amount);

    // Read the caller's registered credential from the registry
    // CRITICAL: read from storage, never from calldata
    uint256[4] memory E_caller = identityRegistry.getCredential(msg.sender);
    uint256[2] memory pk_caller = identityRegistry.getIdentityKey(msg.sender);
    uint256[2] memory pk_spender = identityRegistry.getIdentityKey(spender);

    // Verify Chaum-Pedersen proof: E_spender encrypts same M as E_caller
    require(
        _verifyChaumPedersen(
            E_caller, E_spender, pk_caller, pk_spender, chaumPedersen
        ),
        "Re-encryption proof invalid"
    );

    // Store hash of the verified re-encrypted ciphertext for this pair
    _receiptFragments[msg.sender][spender] = keccak256(
        abi.encodePacked(E_spender)
    );

    // Emit ONLY the opaque ElGamal ciphertext (4 uint256 curve coordinates)
    emit IdentityExchange(msg.sender, spender, E_spender);
    return true;
}

What the public sees in the IdentityExchange event:

• Alice's address approved a spender (same as standard ERC-20 Approval)
• Four uint256 values encoding an ElGamal ciphertext – opaque curve point coordinates that only the spender can decrypt
• No identity address, no public key, no linkable identifier

What the contract verified (in ~29,000 gas):

• The ciphertext contains Alice's real identity (Chaum-Pedersen proof passed against the registered credential read from the registry)

What the spender (Bob / pool operator) can do:

• Decrypt E_bob using sk_bob: M = C_b - sk_bob * R_b
• Decode the identity from the message point M = I * G
• Store it for receipt construction on Holochain

// Alice wants to receive BUCK from Bob (Alice has private identity):
buck.approve(bob, 0, E_alice_for_bob, chaumPedersenProof)

The BUCK contract emits a minimal event that reveals only pseudonymous addresses (which the ERC-20 Transfer event already reveals) plus a reference to the pre-stored identity fragments:

event BuckTransferReceipt(
    address indexed from,
    address indexed to,
    uint256 amount,
    bytes32 fromIdentityHash,    // keccak256 of from's ElGamal ciphertext for to
    bytes32 toIdentityHash       // keccak256 of to's ElGamal ciphertext for from
);

The fromIdentityHash and toIdentityHash are keccak256 hashes of the opaque ElGamal ciphertexts stored during approve. They add no linkability beyond what the Transfer event already provides (the addresses are the same in both events).

The actual re-encrypted identity ciphertexts are retrievable:

• From the IdentityExchange events (emitted during approve)
• From Holochain (stored on the participants' source chains)

Only the counterparty (who has the identity private key to decrypt the ElGamal ciphertext) can recover the plaintext identity.

function transfer(address to, uint256 amount) public override returns (bool) {
    require(identityRegistry.isVerified(msg.sender), "Sender not verified");
    require(identityRegistry.isVerified(to),         "Receiver not verified");
    require(compliance.canTransfer(msg.sender, to, amount), "Compliance");

    _transfer(msg.sender, to, amount);
    compliance.transferred(msg.sender, to, amount);

    // Emit minimal receipt -- no identity data, just hashes of
    // pre-stored re-encrypted ElGamal ciphertexts
    emit BuckTransferReceipt(
        msg.sender, to, amount,
        _receiptFragments[msg.sender][to],
        _receiptFragments[to][msg.sender]
    );

    return true;
}

The transferFrom path is identical: the receipt fragment hashes were stored during approve, so no additional identity data passes through the DeFi router. The Chaum-Pedersen proof was verified once (at approve time); subsequent transfers emit only the minimal receipt event (~2,000 gas).

Alice's wallet (a Holochain hApp) performs all credential derivation and transaction preparation:

• Credential derivation: Alice's PS-signed identity (m, sigma) lives on her Holochain source chain. For each new account, the hApp rerandomizes the PS signature, generates a fresh key pair, creates an ElGamal encryption, and computes the NIZK proof. This runs entirely offline and can be batched – Alice can pre-generate credentials for future accounts.
• Credential storage: Each derived credential (pk, E_alice, sigma', pi) is stored on Alice's Holochain source chain. The full identity data (name, jurisdiction, ID number, KYC documents) is encoded in the identity scalar m and encrypted in the ElGamal ciphertext, not stored separately on Ethereum.
• Re-encryption: The hApp decrypts E_alice locally (Alice has sk_alice), extracts the message point M, and re-encrypts for Bob: E_bob = (r' * G, r' * pk_bob + M). This is 2 scalar multiplications and 1 point addition – milliseconds on any device.
• Proof generation: The Chaum-Pedersen proof is a Schnorr-family sigma protocol. Generation requires 2 scalar multiplications and 1 hash – instantaneous on any modern device. Unlike Groth16 SNARK proofs (which require minutes of circuit evaluation and a trusted setup ceremony), Chaum-Pedersen proof generation is negligible.
• Receipt storage: Full encrypted receipts (with decrypted identity details, transaction metadata, purpose) are stored on both parties' Holochain source chains. The on-chain BuckTransferReceipt event provides only an anchor hash.

Holochain provides agent-centric, cryptographically auditable storage: the hApp DNA is identified by hash, so anyone can verify the exact code that runs on each participant's node. However, Holochain is not the trust anchor: Alice runs her own node and could run modified code. The on-chain verifications are the trust anchors – PS signature verification at registration and Chaum-Pedersen proof verification at transaction time are mathematically verifiable on-chain regardless of what software generated them. Holochain provides the execution environment; the proofs provide the guarantees.

For a transfer from Alice to a DeFi pool operated by Bob:

The ephemeral key k_e is derived deterministically from the on-chain receipt event data (which is immutable and publicly verifiable):

// All fields are from the on-chain BuckTransferReceipt event:
receipt_anchor = abi.encode(
    from, to, amount,
    fromIdentityHash, toIdentityHash,
    block.number
)
k_e = keccak256(receipt_anchor)    // deterministic "private key"

Note: receipt_anchor contains only pseudonymous addresses and opaque hashes – no identity content. The identity public keys K_s and K_r are looked up from the IdentityRegistry (on-chain, public), not emitted in events.

The wallet (Holochain hApp) computes the encryption key via ECDH:

// Alice's hApp computes (knows k_s, k_e; looks up K_r from registry):
K_r = identityRegistry.getIdentityKey(to)     // Bob's identity public key
shared_1 = ECDH(k_s, K_r)          // sender-receiver shared secret
shared_2 = ECDH(k_e, K_r)          // ephemeral-receiver shared secret
encryption_key = keccak256(shared_1 || shared_2)

// Construct the full receipt with decrypted identity data:
full_receipt = {
    from, to, amount, block.number, tx_hash,   // from on-chain event
    sender_identity:   decrypt(E_alice),         // from Alice's source chain
    receiver_identity: decrypt(E_bob_for_alice), // from Bob's approve
    purpose: "Uniswap V3 BUCK->USDT swap"
}

// Encrypt:
ciphertext = AES-GCM(encryption_key, encode(full_receipt))

The encrypted receipt is stored on Holochain (both parties' source chains). A commitment hash can optionally be emitted on-chain to anchor the receipt:

event ReceiptCommitment(
    bytes32 indexed transferHash,    // hash of the BuckTransferReceipt event
    bytes32 receiptHash              // hash of the encrypted full receipt
);

Alice:
  1. Completed KYC with trusted issuer (off-chain ceremony)
  2. Issuer PS-signs Alice's identity: sigma = PS.Sign(sk_issuer, m)
     where m = H(identity_data)
  3. Alice receives (m, sigma) and stores in Holochain wallet
  4. Alice's wallet derives a credential for this account (offline):
     - Rerandomizes PS signature: sigma' = (t * sigma_1, t * sigma_2)
     - Generates fresh identity key pair (sk_alice, pk_alice)
     - Encrypts: E_alice = (r * G,  m * G + r * pk_alice)
     - Computes NIZK proof pi linking sigma' to E_alice
  5. Registers on-chain (~200K gas):
     identityRegistry.registerCredential(
         alice_wallet, pk_alice, E_alice, sigma', pi)
  6. identityRegistry.isVerified(alice_wallet) == true

Bob (pool deployer):
  1. Completed KYC (same ceremony as Alice)
  2. Derived credential for his account (same offline process)
  3. Credential registered in IdentityRegistry (~200K gas)
  4. Created BUCK/USDT pool via Uniswap factory
     -> pool deployed at address 0xPOOL
  5. Derived and registered a separate credential for the pool
     (from same PS-signed identity, via the Identity Fountain):
     identityRegistry.registerCredential(
         0xPOOL, pk_bob_pool, E_bob_pool, sigma'_pool, pi_pool)
  6. identityRegistry.isVerified(0xPOOL) == true

A flash loan borrows and repays in a single transaction. The borrower's address must be verified, and the lending contract must be registered. The receipt covers the full borrow-repay cycle as a single atomic event.

A swap routed through BUCK -> WETH -> USDT involves two BUCK transfers (BUCK -> pool1, pool1 -> pool2 if intermediate). Each BUCK transfer generates its own encrypted receipt. The router contract must also be registered if it holds BUCK transiently.

When one DeFi contract sends BUCK to another (e.g., a yield aggregator moving BUCK between pools), both contracts must be registered. The receipt identifies both contracts' deployers as the parties. This creates a clear chain of custody: every BUCK movement has an identified legal operator at each end.

If BUCK is wrapped (WBUCK) for use on another chain, the wrapping contract must be registered. The wrap/unwrap generates receipts. On the destination chain, the bridged BUCK may operate under different identity rules (or no identity rules if the destination chain doesn't enforce ERC-3643). This is a known limitation – the Alberta Buck's identity guarantees only hold on chains where the IdentityRegistry is deployed.

The design has three gas-consuming identity operations:

Credential registration uses the ecPairing precompile to verify the Pointcheval-Sanders signature and NIZK proof (200,000 gas, once per account). The Chaum-Pedersen proof verification uses ~ecMul / ecAdd (~29,000 gas per counterparty pair). Subsequent transfers emit only the minimal receipt event (~2,000 gas) with no additional proof work.

All encrypted identity data and full receipts are stored on Holochain, not on Ethereum. The only identity-related data emitted on-chain is the compact ElGamal ciphertext (4 curve coordinates = 128 bytes of calldata) during approve, and two bytes32 hashes during each transfer.

The pool deployer's ElGamal credential is stored in the IdentityRegistry alongside the pool contract's address. The credential E_deployer is an opaque ciphertext – anyone can see it on-chain, but no one can decrypt it without the deployer's identity private key.

What is publicly visible: "0xPOOL is operated by a verified entity" (because isVerified(0xPOOL) == true). What is not visible: who that entity is. The deployer's real identity is revealed only in the ElGamal ciphertexts re-encrypted for specific counterparties during approve handshakes.

If a deployer wants public identification (e.g., "DeFi Ops Inc., Alberta"), they can register a separate plaintext identity claim alongside their encrypted credential. This is the expected case for commercial DeFi operators – public identity builds trust and attracts liquidity.

In this approach, the issuer stores a Pedersen commitment C = v*G + r*H on-chain. Alice proves in zero knowledge (via a Groth16 SNARK) that her re-encrypted ciphertext E_bob encrypts the same value v committed in C.

Advantages:

• Extremely flexible: the ZK circuit can prove arbitrary predicates alongside re-encryption correctness (age > 18, jurisdiction membership, credit score in range, etc.)
• Information-theoretically hiding (Pedersen commitments hide v perfectly, vs. ElGamal's computational hiding)
• Well-supported toolchain (circom, snarkjs, Hardhat plugins)

Why Chaum-Pedersen is superior for Alberta Buck:

• Gas cost: Groth16 verification requires the ecPairing precompile (~113,000 gas base + per-pair costs), totaling ~200,000-300,000 gas. Chaum-Pedersen costs ~29,000 gas – 7-10x cheaper.
• Trusted setup: Groth16 requires a multi-party computation ceremony to generate proving/verification keys. A compromised ceremony allows forged proofs – the one thing the system cannot tolerate. Chaum-Pedersen has no setup of any kind.
• Proof generation time: Groth16 proof generation takes seconds to minutes (circuit evaluation, witness computation, FFTs over large fields). Chaum-Pedersen proof generation is 2 scalar multiplications and 1 hash – milliseconds on a phone.
• Complexity: Groth16 requires circuit definition (R1CS/circom), a prover library, and careful constraint engineering. A bug in the circuit silently compromises soundness. Chaum-Pedersen is ~50 lines of elliptic curve arithmetic with a well-understood security proof.
• Unnecessary generality: Alberta Buck needs exactly one thing: proof that two ElGamal ciphertexts encrypt the same message point. Groth16 can prove anything in NP; that generality is wasted here and only adds attack surface.

In PRE, Alice generates a re-encryption key rk_{A->B} that allows an untrusted proxy to transform E_alice into E_bob without decrypting. Umbral includes NIZK proofs of correct re-encryption.

Advantages:

• Alice does not need to be online at re-encryption time (the proxy acts on her behalf)
• Threshold PRE distributes trust across multiple proxies (no single point of compromise)
• Algebraic NIZK proofs are efficient (comparable gas cost to Chaum-Pedersen)

Why Chaum-Pedersen is superior for Alberta Buck:

• Alice is always online: in the Alberta Buck model, Alice calls approve directly – she is necessarily online. The proxy delegation feature of PRE is unnecessary complexity.
• No proxy metadata leakage: even with threshold PRE, the proxies learn metadata (who is re-encrypting for whom, how often). Direct re-encryption eliminates this metadata channel entirely.
• Simpler key management: PRE requires generating and distributing re-encryption keys per counterparty pair. Direct ElGamal re-encryption uses only the existing identity key pairs already registered on-chain.
• Protocol complexity: Umbral manages capsules, key fragments, and proxy coordination. Direct re-encryption with Chaum-Pedersen is two scalar multiplications and a sigma protocol – no capsules, no fragments, no proxies.
• PRE remains valuable in other contexts (e.g., encrypted email where the sender may be offline), but Alberta Buck's on-chain interaction model makes it unnecessary.

BBS+ (pairing-based multi-message signatures) allows an issuer to sign a vector of attributes. Alice can selectively disclose specific attributes while hiding others, with ZK proofs of signature validity. The W3C Verifiable Credentials standard is converging on BBS+ for exactly this use case.

Advantages:

• Attribute-level granularity: prove "jurisdiction = Alberta" without revealing name or ID number
• Unlinkable presentations (different proofs from the same credential cannot be correlated)
• Ecosystem alignment with W3C VC / DID standards

Why Chaum-Pedersen is superior for Alberta Buck:

• Gas cost: BBS+ verification requires pairing operations (~113,000+ gas). Chaum-Pedersen uses only scalar multiplications (~29,000 gas).
• Selective disclosure is the wrong primitive: Alberta Buck transfers require the full identity to be re-encrypted for the counterparty (for court-recoverable receipts). Selective attribute hiding would defeat the purpose: the counterparty needs the whole identity, and a court needs the whole identity.
• Different trust model: BBS+ proves "I hold a valid credential with these properties." Alberta Buck needs "this ciphertext contains my specific issuer-certified identity." The latter is a re-encryption correctness proof, not a selective disclosure proof.
• Cross-account unlinkability is already solved: Pointcheval-Sanders rerandomizable signatures provide unlinkable credential derivation for different accounts. Within a single account, re-encryptions share a common Ethereum address regardless of the credential scheme, so BBS+ presentation unlinkability adds nothing.
• BBS+ could complement Chaum-Pedersen in the future – e.g., for compliance checks that verify jurisdiction eligibility without full identity disclosure. But it does not replace the core re-encryption mechanism.

A purpose-built primitive: encrypt a value and simultaneously prove that the plaintext satisfies a public relation, without revealing it.

Advantages:

• Theoretically clean: directly solves "encrypt for Bob, prove to everyone it's the right value"
• Can prove arbitrary relations on the encrypted plaintext

Why Chaum-Pedersen is superior for Alberta Buck:

• Camenisch-Shoup is the general framework; Chaum-Pedersen is its optimal specialization for the "same plaintext" relation. When the relation is "same plaintext as another ElGamal ciphertext in the same group," the Chaum-Pedersen protocol is the canonical, minimal-cost instantiation.
• General Camenisch-Shoup constructions are more complex and less efficient.

Pedersen commitments support homomorphic equality checking: given C_1 = v*G + r_1*H and C_2 = v*G + r_2*H, revealing delta_r = r_1 - r_2 lets the verifier check C_1 - C_2 == delta_r * H without learning v.

Advantages:

• Extremely cheap (1 point addition, 1 scalar multiplication)
• Information-theoretically hiding

Why this is insufficient for Alberta Buck:

• Pedersen commitments are commitments, not encryptions. They hide the value but do not allow a specific party to decrypt. Alberta Buck needs Bob to recover Alice's identity, not just to verify that two opaque commitments match. ElGamal provides both hiding and targeted decryption.
• Revealing delta_r to prove equality leaks the randomness difference, which is acceptable for on-chain verification but means the commitment scheme cannot support multiple independent equality proofs without additional blinding (each proof leaks one linear relation on the randomness).

ElGamal Chaum-Pedersen wins on per-transaction gas cost, has zero setup requirements, generates proofs instantly, supports targeted decryption, and requires minimal implementation. Combined with Pointcheval-Sanders rerandomizable signatures for credential derivation (one-time ~200K gas at registration), the system achieves both cross-account unlinkability and per-transaction re-encryption correctness – without the gas burden or trusted setup of SNARK-based alternatives.