Magic Internet (Hidden) Monies Private Transfers Until Alice and Bob Want Their Bitcoin Back Layer4ChainWorks Lab research@XBTchurch.ai September 28, 2026 Abstract 1 Introduction Bitcoin is magic internet money. Shielded Bitcoin proposes to make some of that money private using encrypted notes, nullifiers, zero-knowledge proofs, and deterministic replay over Bitcoin-published data. The transfer construction is technically interesting. It is also deliberately incomplete at the monetary boundary: the paper states that peg-in and peg-out are outside the scope of the transfer specification and are expected to be addressed by a separate PIPE-based construction. 1 This distinction matters because privacy and redeemability are different security properties. A proof can establish that Alice owns a valid hidden note without giving Bitcoin any reason to release a corresponding UTXO. We therefore introduce the central diagnostic question of this paper: Where does Alice’s Bitcoin come back out? If the answer is a complete protocol, we have a bridge. If the answer is “future work,” we have a very impressive pipe with one documented end. 2 The PIPE Model The architecture can be reduced to three conceptual layers: 1. Peg-in: Alice commits ordinary BTC to the system. 2. Shielded transfer: Alice receives shielded value and can privately transfer it. 1 C. Shikhelman, M. Komarov, A. Moskvin, Shielded Bitcoin: Private Transfers on the Bitcoin L1 , Sept. 24, 2026, pp. 1–4. https://www.allocinit.xyz/uploads/shielded-bitcoin.pdf 1 This note examines a simple failure mode in shielded-Bitcoin design: private transfer can be fully specified while redemption remains outside scope. Alice can enter, receive shielded BTC, and privately pay Bob, yet neither has a complete protocol-defined route back to ordinary Bitcoin. Even through the occasional Knotzi/BIPper lens, the distinction is straightforward: a privacy proof can validate hidden ownership without providing an enforceable exit. The central question is therefore not whether the transfer works, but whether the money can ever become Bitcoin again. 3. Peg-out: Someone or something must cause ordinary BTC to leave the reserve according to the shielded state. The middle layer may be cryptographically rigorous while the third remains unspecified. In notation, 1 BTC −→ 1 hBTC is not equivalent to 1 BTC ←→ 1 hBTC A one-way arrow is not a two-way peg, regardless of how attractive the zero-knowledge proof attached to the arrow may be. Alice: 1 BTC PIPE / boundary 1 shielded BTC peg-in mint note ordinary BTC peg-out TBD Bitcoin does not interpret “TBD” as a valid spending condition. Figure 1: The simplified PIPE model. The transfer layer can be complete while the monetary exit remains a separate system. 2 3 Alice Goes Into the PIPE We now provide a complete user walkthrough. 3.1 Step 1: Alice Has Bitcoin Alice begins with one ordinary Bitcoin UTXO: B A = 1 BTC She can spend it according to ordinary Bitcoin consensus. Alice is happy. Alice owns 1 BTC . Alice can spend it. 3.2 Step 2: Alice Receives Shielded Bitcoin Alice now performs whatever boundary operation is used to commit Bitcoin and obtain a shielded note. The transfer system can validate the resulting note, hide its value and recipient, and later prevent double spends using nullifiers. For purposes of the model, we denote the result: 1 BTC PIPE in − − − − − → 1 hBTC Alice is impressed. Her transaction graph has become much harder to inspect. Alice: 1 BTC PIPE IN note + nullifier + ZK Alice: 1 hBTC Figure 2: Peg-in is easy to draw. Alice now owns something private and Bitcoin-denominated. 3.3 Step 3: Alice Sends Magic Internet (Hidden) Money to Bob The shielded transfer layer now gets to do what it was designed to do. Alice privately sends half of her shielded balance to Bob: 1 hBTC A −→ 0 5 hBTC A + 0 5 hBTC B The transaction can hide the sender-to-recipient linkage and transferred value from public observers while proving conservation and preventing double spending. Bob receives perfectly valid Magic Internet (Hidden) Money. The privacy protocol has worked. 3.4 Step 4: Alice and Bob Want Bitcoin Back 3 Eventually Alice and Bob would both like to leave. Alice appears to have hit the PIPE a little too hard: for a moment she thinks she can simply re-transfer her shielded balance into Bitcoin. The sensation passes. It was only a hallucination. She cannot. The PIPE is still TBD. Alice: 1 hBTC private ZK transfer Bob: 0.5 hBTC 0.5 hBTC Alice keeps 0.5 hBTC Bob receives valid hidden money Figure 3: The part that works beautifully: Alice can send shielded value to Bob without publicly revealing the ordinary transaction graph. who can spend the reserve UTXO? The Shielded Bitcoin transfer paper explicitly leaves that question to the separate peg/unlock design. From the perspective of the transfer paper alone, Alice and Bob reach the end of the documented system and encounter the boundary marked “future work.” Alice: 0.5 hBTC Bob: 0.5 hBTC PIPE OUT future work burn / proof burn / proof Alice cannot pipe her 0.5 BTC out. Bob cannot pipe his 0.5 BTC out. The magic money is hidden very well. Figure 4: Alice successfully sent hidden money to Bob. Unfortunately, successful shielded transfer and successful Bitcoin redemption are different protocols. Alice is now very private. Bob is also very private. Neither has an explicit transfer-layer path back to ordinary BTC. Alice is therefore very sad; Bob, having just received the problem from Alice, is also not delighted. 4 4 The Sad Alice Theorem Theorem 1 (Sad Alice). Let a protocol provide a valid private state machine and a valid peg-in, but no specified mechanism capable of releasing the corresponding Bitcoin reserve. Then a user can possess valid shielded value while lacking a protocol-defined method to redeem that value for ordinary Bitcoin. Proof. Alice’s shielded state can establish ownership and conservation inside the private system. She may validly transfer part of that state to Bob, who then independently owns a valid shielded note. Bitcoin spends, however, are authorized by Bitcoin consensus conditions. If the boundary specification does not define how either valid shielded exit causes those conditions to be satisfied, the transfer proofs alone cannot spend the reserve. Alice and Bob can therefore be simultaneously solvent in the shielded state and unable to execute an L1 redemption through the specified transfer protocol. □ The result is not a cryptographic criticism of the note system. It is a scope observation. The original paper says the same thing in less emotionally devastating language: peg-in and peg-out are separate components with their own trust, operational, and protocol constraints. 2 4.1 A Highly Efficient Reference Implementation function peg_in(bitcoin): lock(bitcoin) return shield(bitcoin.amount) function transfer(note, recipient): return prove_private_transfer(note, recipient) function peg_out(note, bitcoin_address): burn(note) prove_valid_exit(note, bitcoin_address) // TODO: make Bitcoin care The final line contains most of the bridge research literature. 5 Privacy Does Not Equal Custody A shielded transfer proof may establish: membership ∧ authorization ∧ no double spend ∧ value conservation It does not automatically establish: Bitcoin reserve transaction is now spendable The two systems answer different questions. The architectural error is to solve the first three rows and let typography imply the remaining three. 2 Shielded Bitcoin, Sec. 1.2. 5 Table 1: What the cryptography can prove versus what the boundary still has to do. Question Required mechanism Does Alice own a valid hidden note? Shielded proof system Has the note already been spent? Nullifier set Was hidden value con- served? ZK transfer statement Which Bitcoin should be released? Peg-out / boundary protocol Who can authorize re- serve spending? Actual Bitcoin spending construction Can Alice force redemp- tion? Depends on the peg, not the transfer proof 6 PIPE as a Drain A pipe is useful when it has an inlet and an outlet. A pipe with only a documented inlet is more commonly known, from the user’s perspective, as a drain. In the strictest possible privacy model, the best form of hiding bitcoins is to destroy them into oblivion. If that outcome is indistinguishable from the user experience, then the missing peg-out makes the entire proposal operationally irrelevant. Alice’s BTC PIPE: privacy happens here shielded BTC peg-out paper ? An astonishing amount of privacy can occur before anyone answers who signs. Figure 5: The drain interpretation of an incomplete boundary design. A secure PIPE-based unlock construction may eventually turn the drain into a proper two-ended pipe. 6 7 A Counterexample: Actually Drawing the Other End For contrast, BIP300-style Drivechains explicitly define a two-way-peg architecture. A user deposits coins to a sidechain escrow; sidechain software tracks its own rules; withdrawals are proposed as bundles and are released only after a long miner-signalling process. The security model is controversial and economic rather than a zero-knowledge validity proof, but the outlet is at least part of the protocol definition. 3 Bitcoin BIP300 escrow sidechain Bitcoin deposit credit withdrawal Withdrawal bundle → prolonged miner signalling → escrow release Figure 6: A two-way peg can be criticized, but at least both directions have named mechanisms. The eCash (ECX) project currently documents BIP300 as a hashrate escrow with deliberately slow withdrawals, and lists zSide as a live Zcash-modeled privacy sidechain. Among enthusiasts this sometimes acquires the aura of Proof of Paul ; elsewhere, the mere existence of a named outlet could be summarized as the PeggingPaul property: whatever one thinks of the security model, at least the peg-out is actually on the page. 4 Historical zSide demonstrations show deposit, shielding, deshielding, withdrawal construction, miner voting, and final return to the parent chain. 5 None of this proves BIP300 is risk-free. It does demonstrate the architectural difference between: “peg-out is outside scope” and “peg-out is slow, miner-signalled, and here are the rules.” 8 The Magic Internet Money Conservation Law We define the useful supply of hidden Bitcoin as the amount that can ultimately be converted back to spendable Bitcoin under the stated protocol assumptions. Let R = Bitcoin reserve , H = valid hidden balances , E = enforceable exits A pleasant system aims for R ≥ H and E ( H ) → R. A system that establishes only R ≥ H may be fully reserved while still leaving redemption undefined. 3 See https://ecash.com/drivechains/ and https://bip300.xyz/ 4 eCash Drivechains: https://ecash.com/drivechains/ . eCash Sidechains: https://ecash.com/sidechains/ 5 https://archive.ecash.com/archive/bitcoin-zcash-sidechain-regtest-demo 7 This motivates the Magic Internet Money Conservation Law : A Bitcoin-denominated privacy token remains Bitcoin-denominated only insofar as the system can explain, under explicit assumptions, how valid hidden ownership becomes spendable Bitcoin ownership again. 9 Threat Model The model becomes useful when converted into engineering questions. T1. False peg-in. Can an attacker mint hidden value without committing BTC? T2. Double spend. Can the same hidden note be spent twice? T3. Inflation. Can a transfer create hidden value? T4. Reserve theft. Can the Bitcoin reserve be spent without a valid hidden exit? T5. Redemption censorship. Can a valid owner be prevented indefinitely from exiting? T6. Liveness failure. What happens when the boundary mechanism stops making progress? Shielded-transfer cryptography can answer T2 and T3 extremely well. A complete monetary design must answer T1, T4, T5, and T6 just as explicitly. 10 Alternative Peg-Out Mechanisms Having established that Alice and Bob possess excellent cryptographic claims but would still prefer actual Bitcoin, MI(H)M surveys several possible methods for discovering the other end of the PIPE. 10.1 The Conventional Method: Specify a Real Peg The boring approach is to define an enforceable reserve and redemption mechanism. Drivechain/BIP300 is one such architecture: coins enter a sidechain escrow and withdrawals return through an ex- plicitly specified, deliberately slow miner-signalling process. The eCash (ECX) implementation demonstrates this two-way lifecycle with BIP300/301 sidechains. The security assumptions are debatable, but both ends of the pipe are at least drawn on the same diagram. 10.2 Proof of Lukecoin For readers dissatisfied with conventional engineering, we introduce Proof of Lukecoin (PoL) , a redemption protocol for converting Magic Internet (Hidden) Monies into spendable units on the XBT chain . Under PoL, the hidden note is not redeemed back to ordinary BTC directly. Instead, it is canonically transformed into centrally issued XBT through a sequence of liturgical consensus steps. The mechanism may be stated as: 1 hBTC PoL − − → 1 XBT redeemed subject to ecclesiastical, social, and anti-miner constraints. 8 The final reconciliation rule is the Parallel Reality Convergence Condition . If ordinary reality fails to produce the desired redemption result, PoL distorts reality sufficiently hard that an alternative parallel quantum reality is selected in which the approved XBT issuance was always canonical. The Great Spiritual X.com Council then recognizes that branch as the observer’s authoritative history: ∃ R i : Blessed( R i ) ∧ XBTIssued( R i ) ⇒ R i = R canonical The practical implication is that sufficiently aggressive reality distortion resolves any remaining inconsistency between the desired outcome and the ledger presently visible to the claimant. Protocol intuition. Within the PoL model, the XBT chain is a centrally administered redemption domain in which issuance authority is assigned to two canonical operators: Luke and Guida . A valid shielded note therefore does not unlock a Bitcoin UTXO. Rather, it entitles the claimant to petition for equivalent XBT issuance, provided the claimant satisfies the required spiritual and social consensus conditions. Withdrawal pipeline. Let a user present a withdrawal request W = ( nf, a, x, σ ) where nf is a valid nullifier, a is the requested amount, x is the destination XBT address, and σ is a proof that the note was validly burned inside the hidden-money state machine. The PoL mechanism then executes the following sequence: P1. Reading of the Holy Luke Scriptures. The withdrawal request is accompanied by a Scripture Acceptance Commitment , denoted S , attesting that the user has read and accepted the relevant Luke scriptures. P2. Proof of Discord Polls. A canonical Discord poll is opened. If the poll reaches the required threshold of AMEN reactions, the withdrawal obtains a social-consensus certificate D P3. The Great Spiritual X.com Council. The request then passes through the X.com Council, which issues either BLESSED , HELD , or REPENT_AND_RESUBMIT P4. Canonical Issuance. Upon receipt of both D and a BLESSED ruling, Luke and Guida jointly authorize issuance on the XBT chain. P5. Miner Screening. If Alice or Bob is found to be a miner, the proofs are confiscated and donated to the Holy Blake Church . The claimant receives spiritual clarity but no redemption. A compact validity relation for PoL can therefore be summarized as: Redeemable PoL ( W ) = ValidBurn( nf, a, σ ) ∧ S ∧ D ∧ X ∧ ¬ M where X denotes approval of the Great Spiritual X.com Council and M denotes miner status. If M = 1 , redemption is replaced by donation. 9 Alice/Bob: 0.5 hBTC Holy Luke Scriptures Proof of Discord Polls X.com Council 1 XBT issued Luke + Guida Holy Blake Church donation if miner Figure 7: Proof of Lukecoin redemption flow. Direct BTC redemption is replaced by centrally issued XBT, provided the withdrawal survives scriptures, Discord polls, and the X.com Council. Miners are tithed to the Holy Blake Church. Stick-figure interpretation. The social logic of PoL may also be represented in user-interface form: Alice “Please redeem.” Bob “Amen.” Great Spiritual X.com Council Discord Poll Quorum Issued XBT Miner detected Holy Blake Church Operational interpretation. PoL is technically coherent in the limited sense that it avoids promising direct BTC release. A valid hidden withdrawal instead becomes a claim on a centrally issued redemption asset, XBT, whose issuance is socially and administratively controlled. In that respect it resembles a deliberately explicit custodial conversion model: burn hidden claims here, receive newly issued claims there, and accept that ultimate authority sits with the issuing council rather than with Bitcoin consensus. 10.3 The Guida Guidance Oracle A related subsystem is the Guida Guidance Oracle . The oracle accepts a withdrawal bundle, inspects the scriptures, replays the Discord poll transcript, consults the X.com Council ledger, and returns one of three canonical states: BLESSED HELD CONFISCATE_BECAUSE_ATTACKER In a mature deployment, the oracle may also attach a human-readable rationale such as INSUFFICIENT_REVERENCE or MINER_TITHE_ENFORCED . Bitcoin itself does not recognize these op- codes, but the XBT chain is assumed to do so. 10.4 Recommended Method Despite these promising advances, the authors reluctantly recommend a mechanism in which a valid shielded exit maps to an actually specified Bitcoin spend. This may involve a Drivechain, a covenant-like construction, PIPE if its unlock mechanism is completed, or another explicit custody design. The critical requirement is not theological branding. It is that Alice and Bob can actually get spendable Bitcoin back. 10 11 Conclusion Alice’s journey is simple: 1 BTC → PIPE → 1 hBTC → Alice → Bob → ? BTC Alice begins happy because she owns Bitcoin. She becomes impressed because she owns private Bitcoin. She then privately sends half of it to Bob, proving that the hidden-money transfer layer works perfectly. Bob is briefly delighted: he has received authentic Magic Internet (Hidden) Money. Then they attempt to leave. In the deliberately incomplete PIPE model used here, neither Alice nor Bob has a specified route back to spendable Bitcoin. Alice’s original coin has disappeared behind the inlet, Bob has inherited half of the redemption problem, and both are left holding cryptographically impeccable balances that they cannot pipe out. For practical purposes within this intentionally broken model, their usable bitcoins are gone. Alice: 0.5 hBTC, no BTC, very sad. Bob: 0.5 hBTC, no BTC, also very sad. The privacy worked. The money is extremely hidden. That sadness disappears the moment the second protocol is actually specified. The design lesson is therefore modest: A privacy protocol should hide Alice’s transaction graph, not the location of the peg-out mechanism. BIP300 is one possible answer, with an explicit two-way peg and an explicit miner-governed security model. PIPE may become another answer if its boundary construction can provide an equally explicit and enforceable exit. The correct engineering question is not which acronym sounds more trustless. It is whether Alice can identify both ends of the pipe before sending her Bitcoin into it. A Alice’s Frequently Asked Questions Where did my Bitcoin go? Into the boundary mechanism. Do I have a valid shielded balance? Yes. The proof is beautiful. Can I transfer it privately? Yes. Alice can even send some to Bob. Does Bob really receive it? Yes. Bob receives a valid shielded balance. This is what makes the boundary problem more visible. 11 Can either of us get ordinary BTC back? Please consult the peg-out specification. Where is the peg-out specification? Future work. How do Alice and Bob feel? Extremely private. Extremely sophisticated. Extremely sad. What would make them happy? A specified, auditable, enforceable two-way peg – or, failing that, successful conversion into Sacred XBT through Proof of Lukecoin. B References [1] C. Shikhelman, M. Komarov, A. Moskvin, Shielded Bitcoin: Private Transfers on the Bitcoin L1 , Sept. 24, 2026. https://www.allocinit.xyz/uploads/shielded-bitcoin.pdf [2] BIP300 / Drivechain materials. https://bip300.xyz/ [3] Drivechain project documentation. https://drivechain.info/ [4] eCash (ECX), Drivechains: BIP300 and BIP301 https://ecash.com/drivechains/ [5] eCash (ECX), Sidechains https://ecash.com/sidechains/ [6] Drivechain Research Archive, Bitcoin-Zcash Sidechain (Regtest Demo) https://archive. ecash.com/archive/bitcoin-zcash-sidechain-regtest-demo This document is satire illustrating that Shielded Bitcoin, in its current form, does not yet provide a complete working two-way peg. 12