MORPHiS: A Peer-to-Peer Electronic Privacy System Samuel Maloney (1981–2016) and Mael Emilyah Gaulinus Version 1.0 - 2 January 2026 ------------------------------------------------------------------------ Abstract A purely peer-to-peer messaging system would allow messages to be sent directly from one party to another without going through a centralized provider. Digital signatures provide authentication, but the main benefits are lost if spam filtering still requires a trusted third party. We propose a solution to the spam problem using a peer-to-peer network where senders perform proof-of-work bound to each recipient’s address. Work cannot be amortized across recipients; at practical difficulty levels, spam requires approximately 200 days of computation per sale. The same network provides the missing coordination layer for privacy-preserving Bitcoin transactions. Strangers who wish to mix their coins can find each other through the distributed hash table, negotiate through encrypted channels, and construct joint transactions, all without centralized servers vulnerable to censorship or surveillance. The combination of spam-resistant messaging and decentralized coordination creates infrastructure for a new kind of economy: one where communication is private, identity is self-sovereign, and financial privacy is a right rather than a privilege. ------------------------------------------------------------------------ 1. Introduction Communication on the Internet has come to rely almost exclusively on centralized providers serving as trusted third parties. While the system works well enough for most users, it suffers from the inherent weaknesses of the trust-based model. Providers can read, censor, or monetize message contents. Users have no guarantee their communications remain confidential. The same centralization problem affects financial privacy: Bitcoin transactions are traceable, and techniques to improve privacy, such as CoinJoin mixing, require coordination among strangers, which has historically depended on centralized servers vulnerable to the same censorship and surveillance. What is needed is infrastructure based on cryptographic proof instead of trust. A messaging system where computational proof-of-work protects recipients from spam. A coordination layer where strangers can find each other, negotiate, and transact without revealing their identities to any central party. A storage network where data is owned by cryptographic keys rather than service agreements. In this paper, we propose such a system. Messages are stored in a distributed hash table with proof-of-work bound to each recipient’s address. The same network enables privacy-preserving coordination for Bitcoin transactions: liquidity providers publish mixing offers, seekers discover them through the DHT, and all negotiation occurs over encrypted channels with spam resistance. The system requires no trusted third party. As long as the cost of proof-of-work exceeds the economic value of spam, and as long as honest nodes control sufficient storage capacity, the network provides both private communication and the foundation for financial privacy at scale. ------------------------------------------------------------------------ 2. Transactions We define a message as a digital envelope containing encrypted content addressed to a recipient. Each recipient publishes a target key in the DHT, a 512-bit address where messages should be delivered. The sender transfers a message to the recipient by creating a block containing the target key and a nonce, then hashing this block until the hash falls within a valid region near the target. +----------------+ | | +------------+ +-----------+ | Recipient | | | | | | Target Key | | Sender |--->| Block |--->| | | | | | | stored in | +------------+ +-----------+ | DHT nodes | | | | v +----------------+ +-----------+ | SHA-512 | | Hash | +-----------+ | v +-----------+ | Block ID | | must fall | | near | | Target | +-----------+ The problem of course is that anyone can send unlimited messages at zero cost. A common solution is to introduce a trusted third party, or filter, that decides which messages are spam. After each message, the recipient must rely on the filter’s judgment, and only messages approved by the filter are delivered. The problem with this solution is that the fate of the entire communication depends on the operator running the filter, with every message having to go through them. We need a way for the recipient to know that the sender expended computational effort. For our purposes, the proof-of-work is what counts. The only way to confirm that effort was expended is to verify the hash satisfies the difficulty condition. To accomplish this without a trusted party, the proof must be publicly verifiable, and we need a system where the cost of sending scales with the number of recipients. 2.1 Proof-of-Work To implement spam resistance on a peer-to-peer basis, we use a proof-of-work system similar to Adam Back’s Hashcash [1]. The proof-of-work involves finding a nonce such that when the block is hashed with SHA-512, the resulting hash falls within a specific region of the 512-bit keyspace defined by the target key. 0 2^512 | | | Target Key | | | | | [ Valid Region ] | | | |<-- 2^(512-d) ->| | | | | | +---------+################+---------------------------------+ ^ ^ | | Block ID must Target Key fall in here (recipient's address) The average work required is exponential in the difficulty parameter d and can be verified by executing a single hash. For difficulty d, the expected number of hash attempts is 2^(d+1). Once the CPU effort has been expended to satisfy the proof-of-work, the message cannot be forged without redoing the work. The proof-of-work also solves the problem of determining cost in bulk messaging. If the cost were based on one-message-one-fee, it could be subverted by anyone able to pay. Proof-of-work is essentially one-CPU-cycle-one-message. The cost is represented by computation, which has the greatest proof-of-work effort invested in it. 2.2 Spam Economics The key insight is that proof-of-work must be performed independently for each recipient’s target key. Work done for recipient A cannot be reused for recipient B. This is because the valid region is defined relative to each target key; different targets have different valid regions. Empirical research on spam economics [4] found that among 350 million spam messages, there were only 28 conversions, approximately 12,500,000 messages per sale. At difficulty 22, each message requires approximately 1.4 seconds of computation on modern hardware: Messages required per sale: 12,500,000 Computation time per message: 1.4 seconds Total computation time: 17,500,000 seconds = 202 days of continuous hashing A single computer can achieve fewer than 2 sales per year through spam. The economics become progressively worse at higher difficulties. At difficulty 25, a sale requires 4.4 years of computation. At difficulty 28, it requires 35 years. Even with dedicated GPU farms, the cost of computation exceeds any plausible return from spam. 2.3 Sending and Receiving The steps to send a message are as follows: Sender DHT Receiver | | | | 1. Fetch recipient's site | | |------------------------------>| | |<------------------------------| | | (target key, difficulty) | | | | | | 2. Create encrypted block | | | 3. Find nonce (PoW) | | | | | | 4. Store TargetedBlock | | |------------------------------>| | | | | | | 5. Query target prefix | | |<---------------------------| | |--------------------------->| | | (matching blocks) | | | | | | 6. Validate PoW | | | 7. Decrypt messages | | | | The receiver need not be online when the message is sent. The DHT stores messages until retrieval. At any later time, the receiver queries nodes near their target key. Nodes return all blocks matching the target prefix. The receiver validates the proof-of-work on each block, and invalid blocks are discarded. Valid blocks are decrypted using the receiver’s private key. 2.4 Difficulty The proof-of-work difficulty is determined by the recipient. Each recipient publishes their preferred difficulty in their site, allowing them to set the computational cost required to reach them. To compensate for changing conditions, the difficulty can be adjusted over time. If a recipient experiences a spam attack, they can increase difficulty. For trusted correspondents, they may publish alternative target keys with lower difficulty. The incentive to set appropriate difficulty comes from the trade-off between accessibility and protection. Too high a difficulty discourages legitimate messages. Too low a difficulty invites spam. Recipients find it in their interest to set difficulty at a level where the cost of proof-of-work exceeds the expected value of spam but remains acceptable for genuine communication. ------------------------------------------------------------------------ 3. Network The steps to run the network are as follows: new messages are validated by proof-of-work and broadcast to nodes near the recipient’s address. Each node stores messages it receives if they fall within its keyspace responsibility. Nodes express their acceptance by storing valid messages and rejecting invalid ones. The network uses a distributed hash table where distance is measured by XOR of node identifiers. 3.1 XOR Distance Nodes and data are identified by 512-bit keys. Distance between any two keys is defined as their bitwise exclusive-or, interpreted as an integer. This metric has useful properties: it is symmetric, the distance from any key to itself is zero, and for any key A and distance D there exists exactly one key B at that distance. 512-bit Keyspace 0x00... 0xFF... | | +--------+--------+--------+--------+--------+--------+--+ | | | Node A Node B Node C | | | +---d1---+ | | | +------------d2------------+ d1 = A XOR B (small distance, nodes are "close") d2 = A XOR C (large distance, nodes are "far") The XOR metric creates a natural partitioning where each node is responsible for storing keys “close” to its own identifier. When data is stored to the network, it is placed on nodes whose identifiers are nearest to the data’s key. 3.2 Routing To find a key, a node queries the closest nodes it knows. Each query approximately halves the remaining distance in the keyspace. For a network of N nodes, lookups complete in O(log N) hops: Query for key K, starting from Node A Node A Node B Node C | | | | "Find K" | | |------------------------>| | | (B is closer to K) | | | | "Find K" | | |------------------------>| | | (C is closest to K) | | | | | |<------------------------| | | "I have K" | |<------------------------| | | (returns data) | | For seven billion nodes, queries complete in approximately 33 hops. The logarithmic scaling ensures that network size does not significantly impact lookup latency. 3.3 Sybil Resistance A Sybil attack creates many false identities to gain disproportionate influence over the network. The defense is to make identity creation expensive. Each node’s identifier is derived from its public key through a double hash: RSA-4096 Key Generation Identity Derivation +-------------------+ +------------------+ | Generate 4096-bit | | | | RSA keypair |------------>| SHA-512(pubkey) | | (~100ms) | | | +-------------------+ +--------+---------+ | v +------------------+ | | | SHA-512(hash) | | | +--------+---------+ | v +------------------+ | Node ID | | (512 bits) | +------------------+ To position a node at a specific location in keyspace, an attacker must brute-force keypair generation until the resulting identifier is sufficiently close. Matching 32 bits of prefix requires approximately 4 billion keypair generations, requiring 13 years of continuous computation on modern hardware. 3.4 Replication Data is stored on multiple nodes near its key. The k closest nodes to any key all maintain copies. When a node fails, the remaining k-1 copies ensure availability. Joining nodes receive data they should hold from their neighbors. Data with key K stored on k=3 closest nodes K | +----+---------+--------+----+ | | | Node 1 Node 2 Node 3 | | | [copy] [copy] [copy] Node 2 fails: K | +----+---------+--------+----+ | X | Node 1 Node 3 | | [copy] [copy] | | +---> Replicate -->+---> Node 4 [new copy] The probability that data becomes unavailable equals the probability that all k replicas fail simultaneously. With k=8 replicas and 10% node failure rate, availability exceeds 99.999999%. 3.5 Anti-Entrapment A concern in any storage network is that nodes might be compelled to store content without their knowledge or consent. An attacker knowing that certain content hashes to H might request nodes store arbitrary data at address H, creating false association with illegal material. The defense is a double-hash construction for storage addresses: Single Hash (vulnerable) Double Hash (secure) Content C Content C | | v v H = SHA-512(C) H1 = SHA-512(C) | | v v Store at address H H2 = SHA-512(H1) | v Store at address H2 Attack scenario: Attacker knows: H = SHA-512(illegal_content) Attacker wants: Node to store data at address H Single hash: Attacker stores arbitrary data D at H Node now "holds" the hash of illegal content Double hash: Attacker must find D where SHA-512(SHA-512(D)) = H2 This requires knowing D (the content itself) Attacker cannot force storage without possessing content The double-hash ensures that to store data at a particular address, the sender must possess data that hashes to that address. An attacker cannot frame a node without first obtaining the content. 3.6 Plausible Deniability Nodes store encrypted blocks without knowledge of their contents. The storage address SHA-512(SHA-512(data)) reveals nothing about the plaintext. A node cannot distinguish between: What a node sees: What it might be: +-------------------+ - Encrypted personal message | Address: 0x7f3... | - Fragment of a larger file | Data: [encrypted] | - Random test data | Size: 64KB | - Part of a hash tree +-------------------+ - Mixing coordination message All appear identical: opaque encrypted blocks at computed hash addresses Messages are encrypted before storage. Large files are split into chunks organized as hash trees. Each chunk is independently encrypted and stored. The node operator cannot determine what data their node holds, only that it holds encrypted blocks at addresses determined by their content hashes. 3.7 Traffic Analysis Resistance Queries are relayed through intermediate nodes rather than sent directly to data holders: Direct query (vulnerable) Relayed query (private) Requester -----> Holder Requester --> Relay1 --> Relay2 --> Holder | | | | (IP visible) (knows who (origin (doesn't know is asking) hidden) who asked) The relaying node cannot inspect payloads; all communication is end-to-end encrypted. Network observers see encrypted traffic between peers but cannot correlate queries with originators. For defense against global passive adversaries, the transport layer may operate over external anonymity networks. ------------------------------------------------------------------------ 4. Privacy The messaging layer provides automatic encryption and inherent authentication. The protocol requires no key exchange ceremony between parties; encryption happens automatically using public keys retrievable from the DHT. These same primitives enable privacy-preserving coordination for Bitcoin transactions through CoinJoin mixing. 4.1 Inherent Authentication Each user’s address is a hash of their public key: Address = SHA-512(Public Key) When a message claims to be from a certain address, the recipient can verify that the controller of that address sent it, because the signature must be valid under the key whose hash equals that address. No separate key exchange or certificate authority is required; the two participants need only know each other’s addresses. 4.2 Ephemeral Key Exchange The receiver publishes an ephemeral Diffie-Hellman public value in the DHT. The sender uses this to generate a shared secret for symmetric encryption. The sender includes their own ephemeral public value in the encrypted message, allowing the receiver to derive the same shared secret: Receiver (Site published in DHT) Sender | | | e = g^x mod p | |------------------------------>| | (ephemeral DH value) | | | | | f = g^y mod p | | K = e^y mod p | | |<------------------------------| | [f, Enc_K(message, sig)] | | | | K = f^x mod p | | (derives same secret) | Keys are derived via HKDF-SHA256 with domain separation, binding derived keys to the specific recipient. The encrypted message contains a signature using the sender’s private key, providing authentication within the encrypted envelope. 4.3 Blinded Credentials For CoinJoin coordination, participants must register outputs without revealing the link between their input and output addresses. Blind signatures [16] solve this problem. A participant blinds their output address before sending it for signing: Participant Coordinator | | | 1. Prove ownership of input | |--------------------------------------->| | | | 2. Submit blinded output | | B = blind(output, r) | |--------------------------------------->| | | | 3. Receive blind signature | | S = sign(B) | |<---------------------------------------| | | | 4. Unblind signature | | sig = unblind(S, r) | | | | 5. Submit output + signature | | (output, sig) via new identity | |--------------------------------------->| | | | verify(output, sig) = valid | | (cannot link to step 1) | The coordinator verifies the output is legitimately signed without learning which participant owns it. Even a malicious coordinator cannot correlate inputs with outputs. The DHT stores these blind commitments; participants later reveal their unblinded outputs, which can be verified as authentic without revealing the blinding factor. 4.4 Mixing Rounds A CoinJoin transaction combines multiple participants’ inputs and outputs into a single transaction. Each equal-sized output becomes indistinguishable from the others: Inputs Transaction Outputs Alice: 0.5 BTC ----+ +----> 0.1 BTC (?) | | Bob: 0.3 BTC ----+----> CoinJoin Tx ------+----> 0.1 BTC (?) | | Carol: 0.2 BTC ----+ +----> 0.1 BTC (?) | +----> 0.1 BTC (?) | +----> change... Anonymity set = 3 (impossible to determine which input corresponds to which 0.1 BTC output) The coordination problem is how strangers who wish to mix find each other and negotiate transaction parameters without revealing their identities. Existing solutions use centralized IRC servers, fragile infrastructure vulnerable to censorship and surveillance. 4.5 Decentralized Coordination MORPHiS provides a natural replacement for centralized mixing coordinators. The Dpush protocol enables spam-resistant coordination without central servers: Maker DHT Taker | | | | Publish order | | | (amounts, fees) | | |------------------------>| | | | | | | Query available orders | | |<-------------------------| | |------------------------->| | | | | | Initiate via Dmail | |<---------------------------------------------------| | | (encrypted, PoW) | | | | | Exchange blinded outputs via encrypted channel | |<-------------------------------------------------->| | | | | Construct and sign transaction | |<-------------------------------------------------->| | | | | Broadcast to Bitcoin network | | | | Liquidity providers (makers) publish orders to the DHT specifying their mixing parameters. Users seeking to mix (takers) query the DHT for available makers and initiate encrypted communication via Dmail. The entire negotiation occurs over spam-resistant, end-to-end encrypted channels without any central server. 4.6 Offline Capability The protocol requires no simultaneous presence. The DHT acts as a decentralized intermediary: Time | | Receiver publishes site to DHT v (target key, difficulty, DH value) | | Receiver goes offline | ~~~~~~~~~~~~~~~~~~~~~~~~ | | Sender retrieves site | Sender encrypts message | Sender performs PoW | Sender stores to DHT | | ~~~~~~~~~~~~~~~~~~~~~~~~ | Receiver comes online | v Receiver queries target_key Receiver retrieves messages Neither party needs to be online simultaneously. Messages and mixing coordination requests accumulate in the DHT until retrieved. ------------------------------------------------------------------------ 5. Incentive The primitives presented, including DHT storage, proof-of-work validation, and cryptographic identity, form the foundation for a broader decentralized infrastructure. We consider the emergent properties when economic incentives are introduced through integration with Bitcoin. 5.1 The Symbiont Architecture MORPHiS operates independently but is designed as a symbiont with Bitcoin. Neither system’s security depends on the other; rather, each augments the other’s capabilities. Bitcoin provides a settlement layer for economic incentives. MORPHiS provides a communication and storage layer that Bitcoin lacks. The key insight is that hash power cannot be split without diluting security. Unlike systems that create separate proof-of-work chains, MORPHiS leverages Bitcoin’s existing hash power for settlement while using its own proof-of-work solely for spam resistance, a fundamentally different purpose that creates no competition for miners. 5.2 CoinJoin Mixing Network Bitcoin transactions are pseudonymous, not anonymous. Address reuse, taint analysis, and payment tracking erode privacy. CoinJoin addresses this by allowing multiple users to combine their transactions: N users contribute inputs and receive equal-sized outputs, making it impossible to determine which input corresponds to which output. The coordination problem is: how do strangers who wish to mix find each other without revealing their identities? Existing implementations rely on centralized IRC servers over Tor, fragile infrastructure vulnerable to censorship and surveillance. MORPHiS provides a natural replacement. The Dpush protocol enables spam-resistant coordination without central servers: Maker Announcement: Liquidity providers publish orders to the DHT specifying their mixing parameters (minimum/maximum amounts, fees). These orders are updateable keys signed by the maker’s identity, retrievable by any potential taker. Taker Discovery: Users seeking to mix query the DHT for available makers, select counterparties based on fees and amounts, and initiate encrypted communication via Dmail. Blinded Output Registration: To prevent even the coordinator from linking inputs to outputs, participants submit cryptographically blinded output addresses. The DHT stores these blindly signed commitments. Participants later reveal their unblinded outputs, which can be verified as authentic without revealing the blinding factor. Transaction Assembly: Once all parties have registered inputs and blinded outputs, the taker constructs the transaction template. Each maker signs their inputs. The fully signed transaction is broadcast to the Bitcoin network. The advantages over IRC-based coordination: Property IRC + Tor MORPHiS DHT ----------------- ------------------ ------------------- Centralization Server operators None Censorship Server takedown Impossible Spam resistance Weak Per-recipient PoW Anonymity Requires Tor Built-in relay Availability Server uptime DHT redundancy 5.3 Sovereign Data Ownership The updateable key primitive establishes a new model of data sovereignty. A user controlling private key sk can perform all operations on data stored under ID = H(pk): - Create: Publish new signed data to the DHT - Read: Retrieve data (available to all) - Update: Replace with newly signed version (higher version number) - Delete: Publish tombstone record or let data expire No other party can modify this data. The DHT enforces signature verification; unsigned or incorrectly signed updates are rejected network-wide. This creates self-sovereign storage: users own their data through cryptographic proof rather than contractual agreement with service providers. When combined with payment channels, storage nodes can require micropayments for hosting data beyond baseline quotas. The market determines storage prices. Users retain full control: they can migrate data, revoke access, or let storage contracts expire. No central authority can censor, modify, or hold data hostage. 5.4 Economic Spam Resistance The proof-of-work mechanism converts computational cost into an economic signal. At difficulty d, sending a message costs approximately 2^(d+1) hash operations. This cost is: - Non-transferable: Work done for recipient A cannot be reused for recipient B - Verifiable: Any node can validate the proof in constant time - Configurable: Each recipient sets their own difficulty When Bitcoin integration is complete, recipients may accept payment as an alternative to proof-of-work. A sender could pay 1 satoshi instead of computing 2^23 hashes. This creates a market for attention: recipients set prices, senders choose between computation and payment, and the spam problem reduces to economics. For CoinJoin coordination, proof-of-work prevents denial-of-service attacks. A malicious actor who repeatedly joins mixing rounds but refuses to sign wastes their own computation. At difficulty 20, disrupting 1000 mixing rounds requires approximately 23 minutes of dedicated hashing, an expensive attack with no financial gain. 5.5 Emergent Network Effects Consider the dynamics as adoption grows: 1. Storage supply increases: More nodes join, providing redundant storage capacity 2. Payment channels form: Frequent communicators establish direct channels 3. Routing networks emerge: Multi-hop payments enable any-to-any transfers 4. Mixing pools deepen: Larger anonymity sets improve transaction privacy Each participant’s value increases with network size, the classic network effect. But unlike centralized platforms that capture this value, the decentralized architecture distributes it among participants. Storage providers earn fees. Routing nodes earn forwarding fees. Mixing makers earn coinjoin fees. No single entity extracts monopoly rents. The mixing network exhibits particularly strong network effects. The anonymity set of a CoinJoin transaction is bounded by the number of participants. With more makers advertising liquidity on the DHT, takers can construct larger transactions with more counterparties. Larger anonymity sets attract privacy-conscious users, who in turn may become makers, deepening liquidity further. 5.6 A Platform for Decentralized Applications The resulting infrastructure supports applications beyond messaging: - Decentralized discussion: Forum-like systems where posts require proof-of-work, eliminating bot armies and spam campaigns - Authenticated publishing: Content signed by cryptographic identity, unforgeable and attributable - Private file sharing: Encrypted storage accessible only to key holders - Censorship-resistant hosting: Data replicated across jurisdictions, retrievable from any available node - Micropayment-gated content: Pay-per-view without subscription services or payment processors - Privacy-preserving payments: CoinJoin mixing without centralized coordinators Each application inherits the platform’s properties: spam resistance, Sybil resistance, encryption, authentication, and offline capability. Developers build on proven primitives rather than reimplementing security from scratch. The vision is not merely a messaging system but a foundation for sovereignty in the digital realm, where individuals control their data, their identity, their financial privacy, and their economic relationships without intermediaries extracting value or exerting control. ------------------------------------------------------------------------ 6. Conclusion We have proposed a system for electronic messaging without relying on trust. We started with the usual framework of public key cryptography, which provides strong authentication, but is incomplete without a way to prevent spam. To solve this, we proposed a peer-to-peer network using proof-of-work bound to each recipient’s address. The network is robust in its unstructured simplicity. Nodes work with little coordination. They do not need to be identified, since messages are routed by XOR distance and only need to be delivered to nodes near the target address. Nodes can leave and rejoin the network at will, accepting valid messages and rejecting invalid ones. The same infrastructure solves the coordination problem for privacy-preserving Bitcoin transactions. Strangers who wish to mix their coins can discover each other through the DHT, negotiate through encrypted spam-resistant channels, and construct joint transactions without any central server. The network provides what centralized mixing coordinators cannot: censorship resistance, plausible deniability, and trustless coordination. The implications extend beyond messaging and mixing. What we have described is infrastructure for a parallel economy, one that operates on cryptographic proof rather than institutional trust. In this economy, identity derives from keys rather than documents. Storage is owned through signatures rather than contracts. Privacy is enforced by mathematics rather than policy. The question is not whether such an economy will emerge, but whether it will emerge in time. The tools of surveillance grow more powerful each year. The window for establishing private, decentralized alternatives may not remain open indefinitely. The network we propose requires no permission to join, no authority to operate, and no trust to use. It exists as long as participants choose to run it. That choice, made by enough individuals, becomes infrastructure. And infrastructure, once established, is difficult to dismantle. ------------------------------------------------------------------------ References 1. Back, A. (1997). Hashcash - A Denial of Service Counter-Measure. 2. Dwork, C. & Naor, M. (1992). Pricing via Processing or Combatting Junk Mail. CRYPTO. 3. Wang, L. & Kangasharju, J. (2013). Real-World Sybil Attacks in BitTorrent Mainline DHT. GLOBECOM. 4. Kanich, C., Kreibich, C., Levchenko, K., Enright, B., Voelker, G.M., Paxson, V. & Savage, S. (2008). Spamalytics: An Empirical Analysis of Spam Marketing Conversion. CCS. 5. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. 6. Maymounkov, P. & Mazieres, D. (2002). Kademlia: A Peer-to-peer Information System Based on the XOR Metric. 7. Douceur, J. (2002). The Sybil Attack. IPTPS. 8. RFC 3526. More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). 9. RFC 8017. PKCS #1: RSA Cryptography Specifications Version 2.2. 10. FIPS 197. Advanced Encryption Standard (AES). 11. RFC 5869. HMAC-based Extract-and-Expand Key Derivation Function (HKDF). 12. RFC 8731. Secure Shell (SSH) Key Exchange Method Using Curve25519. 13. Bellare, M. & Namprempre, C. (2000). Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm. ASIACRYPT. 14. Poon, J. & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 15. Maxwell, G. (2013). CoinJoin: Bitcoin Privacy for the Real World. bitcointalk.org. 16. Chaum, D. (1983). Blind Signatures for Untraceable Payments. CRYPTO.