{"body":"WITHDRAWN after feedback from jeffro256\n\n# Internal receipts without changing Carrot’s commitment or migration formulas\n\nThis proposal makes internal enotes support an address-bound recovery opening and a message authenticated by the recipient’s incoming-view key. It keeps the current commitment-mask formula, output extensions, external derivations, and 16-byte Janus mitigation.\n\nThe construction separates the internal secret into a wallet-secret preimage and a view-key-dependent point. A receipt reveals those two components and proves the point’s relation to the address. PQ migration continues revealing only their contextualized hash.\n\n## 1. Scope and notation\n\nThe construction applies to non-coinbase internal enotes created under the new protocol version.\n\nFor output index `i`, let:\n\n```text\ns_sr = k_v     for the legacy key hierarchy\ns_sr = s_vb    for the new key hierarchy\n```\n\nThe destination address is:\n\n```text\n(is_main, K_s^j, K_v^j)\n```\n\nwith:\n\n```text\nK_base = G          if is_main = 1\nK_base = K_s^j      if is_main = 0\n\nK_v^j = k_v K_base\n```\n\n`i` is the output’s final transaction-local index, encoded using `IntToBytes32(i)`. Output ordering must therefore be fixed before deriving the outputs.\n\nAll concatenations use unambiguous encodings. Edwards points use their full canonical compressed encoding, including the sign bit.\n\n## 2. Lift the ephemeral public key to Edwards form\n\nDefine `K_e = LiftPointM(D_e)` as follows:\n\n1. Parse `D_e` as a canonical Montgomery coordinate `u`.\n2. Reject `u = −1`.\n3. Compute the Edwards coordinate `v = (u − 1)/(u + 1)`.\n4. Decode the Edwards point with coordinate `v` and sign bit zero.\n5. Reject decoding failure, the identity, or a point outside the prime-order subgroup.\n\nThis selects one deterministic Edwards representative of `D_e`.\n\nCompute:\n\n```text\nK_sr = k_v K_e\n```\n\nSerialize `K_sr` with its **actual sign**. Do not normalize its sign or replace it with a Montgomery x-coordinate.\n\n## 3. Internal secret derivation\n\nIntroduce a per-output receipt preimage:\n\n```text\nq_i = SecretDerive(\n    \"Carrot internal receipt preimage\"\n    || s_sr\n    || D_e\n    || input_context\n    || IntToBytes32(i)\n)\n```\n\nReplace the internal contextualized secret with:\n\n```text\ns_sr^ctx = SecretDerive(\n    \"Carrot internal sender-receiver secret\"\n    || q_i\n    || K_sr\n    || D_e\n    || input_context\n    || IntToBytes32(i)\n    || IntToBytes8(is_main)\n)\n```\n\nThe context and index occur in both hashes for different reasons: the first scopes disclosure of `q_i`; the second lets a receipt verifier enforce the context and index without knowing `s_sr`.\n\nRetain the existing derivations:\n\n```text\nk_a = ScalarDerive(\n    \"Carrot commitment mask\"\n    || s_sr^ctx || a || K_s^j || enote_type\n)\n\nC_a = k_a G + a H\n\nk_g^o = ScalarDerive(\n    \"Carrot key extension G\" || s_sr^ctx || C_a\n)\n\nk_t^o = ScalarDerive(\n    \"Carrot key extension T\" || s_sr^ctx || C_a\n)\n\nK_o = K_s^j + k_g^o G + k_t^o T\n```\n\nAmount encryption remains:\n\n```text\nm_a = SecretDerive(\n    \"Carrot encryption mask a\" || s_sr^ctx || K_o\n)[:8]\n\na_enc = IntToBytes64(a) XOR m_a\n```\n\nThe internal view tag also remains unchanged:\n\n```text\nvt = SecretDerive(\n    \"Carrot view tag\" || s_sr || input_context || K_o\n)[:3]\n```\n\nThe 16-byte anchor field is not consumed by this construction. External enotes retain their existing derivation and Janus checks.\n\n## 4. Internal scanning\n\nFirst check the existing wallet-secret view tag. Reject immediately on a mismatch.\n\nAfter a match:\n\n1. Validate and lift `D_e` to `K_e`.\n2. Compute `K_sr = k_v K_e` and `q_i`.\n3. Try `is_main = 1`, followed by `is_main = 0`.\n\nFor each address-kind candidate:\n\n```text\nderive s_sr^ctx\nderive k_g^o and k_t^o from the on-chain C_a\n\nK_s^j' = K_o - k_g^o G - k_t^o T\n```\n\nValidate the recovered spend public key and require:\n\n```text\n(K_s^j' == wallet K_s) == is_main\n```\n\nThen decrypt the amount and check the existing commitment equation, trying the permitted `\"payment\"` and `\"change\"` types as usual. Accept a matching candidate; reject if neither address-kind candidate succeeds.\n\n`K_sr` is computed once and reused across both candidates. The scanner does not need to reconstruct `K_v^j` or consult a subaddress table to perform these checks. Spendability lookup remains a separate step.\n\n## 5. Receipt generation\n\nThe public statement consists of:\n\n```text\nnetwork\nprotocol version\ntransaction ID\noutput index i\nis_main\nK_s^j\nK_v^j\namount a\nenote_type\nmessage m\n```\n\nThe receipt contains:\n\n```text\n(q_i, K_sr, c, z)\n```\n\nIt includes a message-bound DLEQ proof of:\n\n```text\nK_v^j = k_v K_base\nK_sr  = k_v K_e\n```\n\nDefine an unambiguous transcript:\n\n```text\nM = Encode(\n    network, protocol version, transaction ID, i,\n    is_main, K_s^j, K_v^j, a, enote_type,\n    q_i, K_sr, m\n)\n```\n\nChoose a fresh random nonzero scalar `r`, and compute:\n\n```text\nU = r K_base\nV = r K_e\n\nc = ScalarDerive(\n    \"Carrot internal receipt proof\"\n    || M || K_base || K_e || U || V\n)\n\nz = r - c k_v mod l\n```\n\nThe nonce must not be reused across receipts or other protocols using `k_v`.\n\nWallet receipt generation rederives `q_i` from the wallet secret and checks the corresponding internal scan result before signing. It does not accept an arbitrary caller-supplied opening as a scanned receipt.\n\n## 6. Receipt verification\n\nThe verifier obtains `D_e`, `input_context`, `K_o`, `C_a`, and `a_enc` from the referenced transaction and output. These values are not supplied independently by the prover.\n\nThe verifier:\n\n1. Checks that the transaction exists, the index is valid, and this derivation version applies to the non-coinbase output.\n2. Checks canonical encodings, the amount’s 64-bit range, and the permitted `enote_type`.\n3. Validates the address keys and `K_sr` as nonidentity prime-order Edwards points; derives and validates `K_e` using the specified lift.\n4. Selects `K_base` from the claimed address kind.\n5. Derives `s_sr^ctx` from the disclosed `q_i`, `K_sr`, and the actual transaction context and index.\n6. Recomputes the existing commitment and output-key equations, requiring exact matches to `C_a` and `K_o`.\n7. Checks that amount decryption yields `a`.\n8. Checks canonical scalar encodings for `c` and `z`, reconstructs\n\n   ```text\n   U' = z K_base + c K_v^j\n   V' = z K_e    + c K_sr\n   ```\n\n   and verifies\n\n   ```text\n   c == ScalarDerive(\n       \"Carrot internal receipt proof\"\n       || M || K_base || K_e || U' || V'\n   )\n   ```\n\nThe proof is 128 bytes before its header and transport encoding: four 32-byte values.\n\n## 7. Security properties and receipt semantics\n\nAn observer who learns a receipt can recover that output, but cannot authenticate a different message without the incoming-view key.\n\nThe checked contextual hash binds the opening to the transaction context, output index, address kind, and full point `K_sr`. The existing commitment binds the amount and spend public key. The DLEQ binds `K_sr` to the address’s view public key.\n\nFull Edwards encoding matters: Montgomery x-only encoding would identify `k_v` and `−k_v`. Including `is_main` also prevents reinterpretation of the same opening under a different address kind.\n\nFor the new hierarchy, knowledge of `k_v` does not reveal `q_i`, which still requires `s_vb`. Thus the internal privacy separation is retained even when an observer can compute `K_sr`. Disclosing `q_i` does not disclose the preimages for sibling outputs.\n\nThe receipt’s precise statement is:\n\n> This output has a recovery opening for the stated amount and address, and a holder of that address’s incoming-view key authenticated the message.\n\nIt does not prove that `q_i` was derived from the wallet secret, that the raw-secret view tag is correct, or that ordinary wallet scanning discovered the output. It also makes no claim about unspentness, ownership of the transaction’s inputs, or an integrated payment ID. Proving the canonical wallet-secret derivation would require an additional proof of that hash computation.\n\n## 8. PQ migration and implementation impact\n\nMigration continues supplying `s_sr^ctx` in its existing witness field. It supplies neither `q_i` nor `K_sr`.\n\nConsequently, the commitment-mask equation, output-extension equations, migration witness format, and shared Carrot/Jamtis migration interface remain unchanged. Migration does not acquire a requirement to reveal `K_v^j` or another view-key-dependent curve point.\n\nThere are no additional on-chain bytes. The additional scanning work occurs after an internal view-tag match: point lifting and validation, a full Edwards multiplication, and potentially a second address-kind candidate. A Montgomery x-only ECDH result cannot be assumed to provide the required signed Edwards product. The lifted point and product can be cached per distinct `D_e`.\n\nExternal scanning, coinbase handling, and the external 16-byte Janus mitigation are unchanged.","name":"","extension":"txt","url":"https://www.irccloud.com/pastebin/863OFA8r","modified":1792609881,"id":"863OFA8r","size":8891,"lines":272,"own_paste":false,"theme":"","date":1792606778}