{"post_stream":{"posts":[{"id":62802,"name":"aryaethn","username":"arianaraghi","avatar_template":"/user_avatar/ethresear.ch/arianaraghi/{size}/23511_2.png","created_at":"2026-10-22T05:07:16.662Z","cooked":"\u003cp\u003eHi all,\u003c/p\u003e\n\u003cp\u003eThanks to \u003ca class=\"mention\" href=\"/u/aelowsson\"\u003e@aelowsson\u003c/a\u003e \u003ca class=\"mention\" href=\"/u/julian\"\u003e@julian\u003c/a\u003e \u003ca class=\"mention\" href=\"/u/b-wagn\"\u003e@b-wagn\u003c/a\u003e \u003ca class=\"mention\" href=\"/u/gottfriedherold\"\u003e@GottfriedHerold\u003c/a\u003e, since this builds directly on LUCID, the criticism thread and the ticket-first threshold IBE design. Also a kind request for review on this work.\u003c/p\u003e\n\u003cp\u003eI’ve been wondering how much the “free option” in encrypted mempools is actually worth, and what happens if you try to take it away. The short version is in the TL;DR. The full treatment, with proofs, is in the paper, and the Lean 4 formalization is linked below.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eEdit (Oct 28): BSR is now instantiated on Gottfried’s ticket-first threshold IBE design, and the timing numbers are corrected for the ePBS bid commitment. Details in the reply below.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTL;DR\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIf a sender can decide whether to reveal after seeing new information, they hold a free option. I bound its value and show what happens when you try to remove it.\u003c/li\u003e\n\u003cli\u003eFees alone don’t price it well, because senders can use many conditional commitments.\u003c/li\u003e\n\u003cli\u003eTaking the option from senders just moves it to committee members.\u003c/li\u003e\n\u003cli\u003eI propose Blind Simultaneous Release (BSR), which fixes the executed set before anyone can condition on new information. It uses only hashes, so it is post-quantum. It plugs into the ticket-first threshold IBE design as a release layer for the committee’s key shares.\u003c/li\u003e\n\u003cli\u003ePaper: \u003ca class=\"attachment\" href=\"/uploads/short-url/68zvjyWrThJSUEM4gxs06ygUcGF.pdf\"\u003eReveal-Optionality-BSR.pdf\u003c/a\u003e (395.8 KB), or you can simply check it on the GitHub repo. All theorems are machine-checked in Lean 4 (116 theorems, standard axioms only): \u003ca href=\"https://github.com/aryaethn/optionality\" class=\"inline-onebox\" rel=\"noopener nofollow ugc\"\u003eGitHub - aryaethn/optionality: Lean 4 formalization and numerics for 'Reveal Optionality in Encrypted Mempools, Separation, Pricing, and Blind Simultaneous Release with Post-Quantum Time-Locks' · GitHub\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eThe setup\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLet G be the information everyone gets anyway, and F the information a sender who controls the reveal has. The endogenous option is V^endo = V^F − V^G: what control over the reveal adds on top of what the market gives you for free.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. How big is it?\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eV^endo is exactly a Jensen gap, and it is strictly positive under a simple criterion.\u003c/li\u003e\n\u003cli\u003eIt is bounded by ‖D‖_p (2ε)^(1−1/p) when the option is exercised with probability ε.\u003c/li\u003e\n\u003cli\u003eWith ETH implied vol around 51% and an 8 s window, the exogenous option is about 1 bp. A fee of about 6 bp is enough to cap exercise at 1%.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e2. Can forced opening fix it?\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMaking decryption mandatory with a time-lock helps, but hardware speed matters. Let γ be how much faster an attacker computes the sequential function than an honest solver.\u003c/li\u003e\n\u003cli\u003eSound, timely forced opening needs γ ≤ (t2 − t_h)/(t1 − t_pub). With one slot of mempool wait, that ceiling is below 2.\u003c/li\u003e\n\u003cli\u003eTicket-first designs avoid the mempool wait, but if availability is fixed in an extra consensus round, the ciphertext still has to stay private for about a slot, and the ceiling is again about 2. So the time-lock belongs on the committee’s shares, not on transactions.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e3. Does the LUCID fee price it?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIn LUCID (EIP-8184), a revealed transaction pays f/F of its top-of-block fee and a non-revealed one forfeits f, with F = 128. The idea is that the fee prices probabilistic frontrunning. It stops working once a sender uses many conditional commitments. One selector plus one executor is enough for any cap m ≥ 2. A hit costs f(1+1/F) and a miss costs only 2f/F, so the break-even fee is\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ef_inv = pΛ / (p(1+1/F) + 2(1−p)/F)\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eand it is at least Λ/2 whenever p1 ≥ 2/(F+1). With Λ = 50 bp and p1 = 1/64, that is about 25 bp. A single commitment would need only about 0.8 bp, so the multi-commitment attack is roughly 30 times more expensive to deter.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4. Where does the option go?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIf you take it away from the sender, a blocking coalition of |W| ≥ n−t+1 committee members inherits it. For any threshold t, the smallest coalition that can either block or decrypt early has size min(t, n−t+1) ≤ ⌈n/2⌉. Deterrence works iff the coalition’s net penalty β is at least the essential supremum of the option payoff. Hybrid designs without independence still leave an induced-unavailability term. In a ticket-first design with signed refusals, a coalition of n−t+1 members can see the plaintexts and then refuse at no cost.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eBSR in a nutshell\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eInstead of fighting the option after the fact, BSR makes everyone commit before they can know anything useful.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDuring a short window ω after the set of ciphertexts is fixed, each releaser (a committee member or a key publisher) posts an escrow: a signed commitment to its release value, plus the value masked by a long sequential hash chain (about 0.9e8 to 1.6e8 steps at 70 ns/step).\u003c/li\u003e\n\u003cli\u003eNormally the releaser just reveals quickly.\u003c/li\u003e\n\u003cli\u003eIf they withhold, anyone can compute the pad and force the opening.\u003c/li\u003e\n\u003cli\u003eIf the releaser withholds and the forced opening doesn’t match the commitment, the deposit S is slashed and the value is dropped.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWhat you get (Theorem 5):\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eBefore the escrow deadline d, the endogenous option is exactly zero.\u003c/li\u003e\n\u003cli\u003eAfter d, no deviation pays when S covers the largest gain from changing the executed set. Under the paper’s assumption A2, the fee f1 deters at any cap on commitments.\u003c/li\u003e\n\u003cli\u003eInformed blocking after d costs the coalition at least S.\u003c/li\u003e\n\u003cli\u003eWith t = ⌈2n/3⌉, the smallest coalition that can block is never smaller than under any threshold without BSR, and strictly larger for n = 2 and n ≥ 4.\u003c/li\u003e\n\u003cli\u003eEverything is hash-based, so there are no pairings or discrete-log assumptions in the timing mechanism.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eWhere it plugs in on Ethereum\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe natural host is the ticket-first threshold IBE design: the ticket lands in B[n], the PTC votes on which encrypted transactions were available and B[n+1] records \u003ccode\u003eetx_seen\u003c/code\u003e, the committee releases shares of the key for blockhash(B[n]), and B[n+2]’s beacon block must carry the key.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eReleasers are the committee members. Each escrows its share once B[n+1] is fast-confirmed, and the PTC also attests to the escrows it saw by d.\u003c/li\u003e\n\u003cli\u003eRefusing becomes not escrowing, which is decided blind. Withholding after d either gets force-opened or costs S.\u003c/li\u003e\n\u003cli\u003eEscrows are signed over the block, so they are void on any other fork.\u003c/li\u003e\n\u003cli\u003eUnder ePBS the next builder commits to its payload hash at the slot start, so the window runs from fast confirmation of B[n+1] (about 3 to 4 s into the slot, my estimate) to the start of slot n+2: W ≈ 8 to 9 s.\u003c/li\u003e\n\u003cli\u003eSince a broadcast escrow can be opened on every fork, escrowing on receipt of B[n+1] (W ≈ 12 s) would give up the members’ refusal on an unconfirmed block.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor key publishers, LUCID is the natural host, but its spec doesn’t fix numeric deadlines yet, so I haven’t instantiated it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat I’m assuming, and what’s open\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eHardware gap.\u003c/strong\u003e BSR needs γ ≤ (W − ω)/ω. On the ticket-first instantiation with 12 s slots that is γ_max = 3 to 3.5 (ω = 2 s) or 7 to 8 (ω = 1 s); escrowing on block receipt gives 5 or 11. With 6 s slots it drops to about 1 to 1.25 or 3 to 3.5. This is an explicit assumption, not something I measured. Real numbers on sequential-hash ASIC speedups would settle it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePost-quantum scope.\u003c/strong\u003e The pads and commitments are post-quantum; the whole stack is post-quantum only once a suitable threshold IBE is.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNot yet analysed.\u003c/strong\u003e The bisection dispute game for inconsistent escrows, a full equilibrium analysis for non-colluding releasers, verifiable escrows, batched post-quantum forced opening, and end-user escrows.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eI’d love feedback, especially on the hardware assumption and on whether the committee model matches what you expect in deployed designs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eReferences\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLUCID encrypted mempool (EIP-8184): \u003ca href=\"https://eips.ethereum.org/EIPS/eip-8184\" class=\"inline-onebox\" rel=\"noopener nofollow ugc\"\u003eEIP-8184: LUCID encrypted mempool\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eA Criticism of LUCID and Encryption-Scheme-Agnostic Encrypted Mempool Designs: \u003ca href=\"https://ethresear.ch/t/a-criticism-of-lucid-and-encryption-scheme-agnostic-encrypted-mempool-designs/25210\" class=\"inline-onebox\"\u003eA Criticism of LUCID and Encryption-Scheme-Agnostic Encrypted Mempool Designs\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eTowards Encrypted Mempools from Threshold IBE without Batching: \u003ca href=\"https://ethresear.ch/t/towards-encrypted-mempools-from-threshold-ibe-without-batching/26040\" class=\"inline-onebox\"\u003eTowards Encrypted Mempools from Threshold IBE without Batching\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eePBS, distilled: \u003ca href=\"https://ethresear.ch/t/epbs-distilled/25800\" class=\"inline-onebox\"\u003eePBS, distilled\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","post_number":1,"post_type":1,"posts_count":2,"updated_at":"2026-10-28T16:44:51.994Z","reply_count":0,"reply_to_post_number":null,"quote_count":0,"incoming_link_count":26,"reads":20,"readers_count":19,"score":118.4,"yours":false,"topic_id":26169,"topic_slug":"reveal-optionality-in-encrypted-mempools-how-big-is-the-sender-s-free-option-and-a-post-quantum-way-to-remove-it","display_username":"aryaethn","primary_group_name":null,"flair_name":null,"flair_url":null,"flair_bg_color":null,"flair_color":null,"flair_group_id":null,"badges_granted":[],"version":3,"can_edit":false,"can_delete":false,"can_recover":false,"can_see_hidden_post":false,"can_wiki":false,"link_counts":[{"url":"https://github.com/aryaethn/optionality","internal":false,"reflection":false,"title":"GitHub - aryaethn/optionality: Lean 4 formalization and numerics for 'Reveal Optionality in Encrypted Mempools, Separation, Pricing, and Blind Simultaneous Release with Post-Quantum Time-Locks' · GitHub","clicks":0},{"url":"https://eips.ethereum.org/EIPS/eip-8184","internal":false,"reflection":false,"title":"EIP-8184: LUCID encrypted mempool","clicks":0},{"url":"https://ethresear.ch/t/a-criticism-of-lucid-and-encryption-scheme-agnostic-encrypted-mempool-designs/25210","internal":true,"reflection":false,"title":"A Criticism of LUCID and Encryption-Scheme-Agnostic Encrypted Mempool Designs","clicks":0},{"url":"https://ethresear.ch/t/towards-encrypted-mempools-from-threshold-ibe-without-batching/26040","internal":true,"reflection":false,"title":"Towards Encrypted Mempools from Threshold IBE without Batching","clicks":0},{"url":"https://ethresear.ch/t/epbs-distilled/25800","internal":true,"reflection":false,"title":"ePBS, distilled","clicks":0}],"read":true,"user_title":"","bookmarked":false,"actions_summary":[],"moderator":false,"admin":false,"staff":false,"user_id":10056,"hidden":false,"trust_level":2,"deleted_at":null,"user_deleted":false,"edit_reason":null,"can_view_edit_history":true,"wiki":false,"post_url":"/t/reveal-optionality-in-encrypted-mempools-how-big-is-the-sender-s-free-option-and-a-post-quantum-way-to-remove-it/26169/1","reactions":[],"current_user_reaction":null,"reaction_users_count":0,"current_user_used_main_reaction":false,"can_accept_answer":false,"can_unaccept_answer":false,"accepted_answer":false,"topic_accepted_answer":null,"can_vote":false},{"id":62897,"name":"aryaethn","username":"arianaraghi","avatar_template":"/user_avatar/ethresear.ch/arianaraghi/{size}/23511_2.png","created_at":"2026-10-28T16:45:59.288Z","cooked":"\u003cp\u003e\u003cstrong\u003eUpdate (Oct 28):\u003c/strong\u003e I’ve revised the paper and edited the post above. What changed:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInstantiation.\u003c/strong\u003e BSR is now instantiated on \u003ca class=\"mention\" href=\"/u/gottfriedherold\"\u003e@GottfriedHerold\u003c/a\u003e’s ticket-first threshold IBE design. Committee members escrow their key shares once B[n+1] is fast-confirmed, the PTC attests to the escrows it saw by the deadline, and refusing becomes not escrowing, which is decided blind. In the original design, a coalition of n−t+1 members could see the plaintexts and then refuse at no cost; under BSR that costs the deposit S.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTiming correction.\u003c/strong\u003e Under ePBS the builder commits to its payload hash at the slot start, so the window is about 8 to 9 s rather than a full slot. The ceilings drop from 5 (or 11) to 3 to 3.5 (or 7 to 8). Escrowing on block receipt recovers 5 (or 11), but then members can’t refuse on an unconfirmed block.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTicket-first sender time-locks.\u003c/strong\u003e If availability is fixed in an extra consensus round, time-locking the transactions themselves has a ceiling of about 2. That’s why BSR puts the time-lock on the shares.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLean.\u003c/strong\u003e The development is now at 116 audited theorems, covering the new ceilings and pad lengths.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003ePaper and repo are updated with the most findings and assumptions in the post above.\u003c/p\u003e","post_number":2,"post_type":1,"posts_count":2,"updated_at":"2026-10-28T16:45:59.288Z","reply_count":0,"reply_to_post_number":null,"quote_count":0,"incoming_link_count":0,"reads":6,"readers_count":5,"score":0.6,"yours":false,"topic_id":26169,"topic_slug":"reveal-optionality-in-encrypted-mempools-how-big-is-the-sender-s-free-option-and-a-post-quantum-way-to-remove-it","display_username":"aryaethn","primary_group_name":null,"flair_name":null,"flair_url":null,"flair_bg_color":null,"flair_color":null,"flair_group_id":null,"badges_granted":[],"version":1,"can_edit":false,"can_delete":false,"can_recover":false,"can_see_hidden_post":false,"can_wiki":false,"read":true,"user_title":"","bookmarked":false,"actions_summary":[],"moderator":false,"admin":false,"staff":false,"user_id":10056,"hidden":false,"trust_level":2,"deleted_at":null,"user_deleted":false,"edit_reason":null,"can_view_edit_history":true,"wiki":false,"post_url":"/t/reveal-optionality-in-encrypted-mempools-how-big-is-the-sender-s-free-option-and-a-post-quantum-way-to-remove-it/26169/2","reactions":[],"current_user_reaction":null,"reaction_users_count":0,"current_user_used_main_reaction":false,"can_accept_answer":false,"can_unaccept_answer":false,"accepted_answer":false,"topic_accepted_answer":null}],"stream":[62802,62897]},"timeline_lookup":[[1,9],[2,3]],"suggested_topics":[],"tags":[{"id":90,"name":"mev","slug":"mev"},{"id":67,"name":"transaction-privacy","slug":"transaction-privacy"},{"id":19,"name":"post-quantum","slug":"post-quantum"}],"tags_descriptions":{},"fancy_title":"Reveal optionality in encrypted mempools: how big is the sender’s free option, and a post-quantum way to remove it","id":26169,"title":"Reveal optionality in encrypted mempools: how big is the sender’s free option, and a post-quantum way to remove it","posts_count":2,"created_at":"2026-10-22T05:07:16.494Z","views":93,"reply_count":0,"like_count":0,"last_posted_at":"2026-10-28T16:45:59.288Z","visible":true,"closed":false,"archived":false,"has_summary":false,"archetype":"regular","slug":"reveal-optionality-in-encrypted-mempools-how-big-is-the-sender-s-free-option-and-a-post-quantum-way-to-remove-it","category_id":28,"word_count":1614,"deleted_at":null,"user_id":10056,"featured_link":null,"pinned_globally":false,"pinned_at":null,"pinned_until":null,"image_url":null,"slow_mode_seconds":0,"draft":null,"draft_key":"topic_26169","draft_sequence":null,"unpinned":null,"pinned":false,"current_post_number":1,"highest_post_number":2,"deleted_by":null,"actions_summary":[{"id":4,"count":0,"hidden":false,"can_act":false},{"id":8,"count":0,"hidden":false,"can_act":false},{"id":10,"count":0,"hidden":false,"can_act":false},{"id":7,"count":0,"hidden":false,"can_act":false}],"chunk_size":20,"bookmarked":false,"topic_timer":null,"message_bus_last_id":24,"participant_count":1,"show_read_indicator":false,"thumbnails":null,"slow_mode_enabled_until":null,"valid_reactions":["heart","+1","laughing","open_mouth","clap","confetti_ball","hugs"],"has_accepted_answer":false,"can_create_shared_issue":false,"shared_issue_visible":false,"can_vote":false,"vote_count":0,"user_voted":false,"discourse_zendesk_plugin_zendesk_id":null,"discourse_zendesk_plugin_zendesk_url":"https://your-url.zendesk.com/agent/tickets/","details":{"can_edit":false,"notification_level":1,"participants":[{"id":10056,"username":"arianaraghi","name":"aryaethn","avatar_template":"/user_avatar/ethresear.ch/arianaraghi/{size}/23511_2.png","post_count":2,"primary_group_name":null,"flair_name":null,"flair_url":null,"flair_color":null,"flair_bg_color":null,"flair_group_id":null,"trust_level":2}],"created_by":{"id":10056,"username":"arianaraghi","name":"aryaethn","avatar_template":"/user_avatar/ethresear.ch/arianaraghi/{size}/23511_2.png"},"last_poster":{"id":10056,"username":"arianaraghi","name":"aryaethn","avatar_template":"/user_avatar/ethresear.ch/arianaraghi/{size}/23511_2.png"}},"bookmarks":[]}