From 1a1548b8e57dbaa126e08925bea5be0027af0a62 Mon Sep 17 00:00:00 2001 From: Marcin Pawlowski Date: Wed, 5 Aug 2026 15:43:13 +0200 Subject: [PATCH] Re-check sec 8.5 against the spec: the header-padding premise is superseded Implication (i) quoted "the length of the header does not reveal how many uncles a block references" from Uncle References. That sentence was removed from the spec in b809df59 ("Making uncles variable size instead of fixed"): the field is now a variable-size unpadded list and proposal indistinguishability is preserved at the message layer, by padding every dispersed payload to Max_Body_Length. The constraint on a per-reference nephew reward therefore rests on the voucher being content-dependent -- which the Anonymous Leaders Reward Protocol still requires it not to be -- and not on header length. Implications (ii) and (iii) were re-checked against the same revision and stand unchanged: the "no incentive to deviate" sentence is still there, and the equal-share content-independent voucher is still the payout model. Co-Authored-By: Claude Opus 5 (1M context) --- reports/tsi/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reports/tsi/README.md b/reports/tsi/README.md index b1b6633..9d55a06 100644 --- a/reports/tsi/README.md +++ b/reports/tsi/README.md @@ -864,7 +864,7 @@ The deltas this report recommends, in one place (this is a parameter-selection r | uncle rewards | none (spec: uncle grants no block reward) | **soft inclusion, `w_u + w_n < 1`** | fork-safe fairness + anti-hiding ([§6.7](#s6-7)–[§6.8](#s6-8)) | | operating point | set by the Blend privacy budget | **`ρ = f·D_vis < 1`** | accuracy, weak grinding, shallow reorgs — one rule ([§6.3](#s6-3), [§6.10](#s6-10)) | -**The uncle-reward row carries three spec-level implications this report does not solve.** Rows 10–11 fix the *incentive* constraints (soft inclusion, `w_u + w_n < 1`); they do not design the *payout*, and three statements in the spec would need to be reconciled to add it. (i) **Header indistinguishability.** The `uncles` field is fixed-size and zero-padded precisely so that "the length of the header does not reveal how many uncles a block references, which preserves the indistinguishability of proposals required by the Blend Protocol" (cryptarchia-v1-protocol.md, *Uncle References*), and the Anonymous Leaders Reward Protocol (`bedrock-anonymous-leaders-reward.md`) pays "a reward that is independent of the block content to avoid de-anonymization", every voucher carrying "the same share". A *per-reference* nephew reward `w_n` is content-dependent by construction, so it must be encoded to leak nothing about the uncle count (e.g. a flat per-block nephew payout, or always-present `MAX_UNCLES` padded voucher slots) — otherwise the reward channel reintroduces exactly the leak the zero-padding removes. (ii) **A paying uncle breaks the spec's no-deviation rationale.** "Because uncle references carry no fork-choice weight and grant no reward, a proposer has no incentive to deviate" does not hold once uncles pay. Uncle selection stays *non-validity* under row 10, so it remains proposer-local and validators still do not re-check it; but the deviation incentives are then real, and [§6.7](#s6-7)–[§6.8](#s6-8) (suppression, farming, bribery) are what bounds them — that sentence should be replaced by a pointer to those bounds. (iii) **`w_u` has no payout path.** An uncle is never executed and never part of the chain, so an orphan producer's reward voucher never enters the voucher tree, and a *fractional* `w_u` cannot be expressed as an equal-share voucher. Paying orphan producers therefore requires an extension of the Anonymous Leaders Reward Protocol, which this report does not sketch. +**The uncle-reward row carries three spec-level implications this report does not solve.** Rows 10–11 fix the *incentive* constraints (soft inclusion, `w_u + w_n < 1`); they do not design the *payout*, and three statements in the spec would need to be reconciled to add it. (i) **Reward-channel indistinguishability.** The Anonymous Leaders Reward Protocol (`bedrock-anonymous-leaders-reward.md`) pays "a reward that is independent of the block content to avoid de-anonymization", every voucher carrying "the same share". A *per-reference* nephew reward `w_n` is content-dependent by construction, so it must be encoded to leak nothing about the uncle count — e.g. a flat per-block nephew payout, or always-present `MAX_UNCLES` voucher slots. Note this constraint now rests on the *reward* channel alone, not on the header: the `uncles` field carries a variable-size, unpadded list, and the spec preserves proposal indistinguishability at the message layer instead, fixing every dispersed payload to `Max_Body_Length` and padding shorter proposals with random data (cryptarchia-v1-protocol.md, *Uncle References*). An earlier revision made the field fixed-size and zero-padded so that header length would not reveal the uncle count; that is no longer the mechanism, so the objection to a per-reference `w_n` is that it makes the *voucher* content-dependent, not that it makes the header longer. (ii) **A paying uncle breaks the spec's no-deviation rationale.** "Because uncle references carry no fork-choice weight and grant no reward, a proposer has no incentive to deviate" does not hold once uncles pay. Uncle selection stays *non-validity* under row 10, so it remains proposer-local and validators still do not re-check it; but the deviation incentives are then real, and [§6.7](#s6-7)–[§6.8](#s6-8) (suppression, farming, bribery) are what bounds them — that sentence should be replaced by a pointer to those bounds. (iii) **`w_u` has no payout path.** An uncle is never executed and never part of the chain, so an orphan producer's reward voucher never enters the voucher tree, and a *fractional* `w_u` cannot be expressed as an equal-share voucher. Paying orphan producers therefore requires an extension of the Anonymous Leaders Reward Protocol, which this report does not sketch. The one input this report *assumes* rather than reads from the deployed spec is the Blend profile itself (all worked examples use 3 hops × 8 s); the recommendations are expressed in terms of the resulting load `ρ`, so they transfer to whatever hops/δ_max the deployment actually chooses — but a reader should confirm the real Blend budget keeps `ρ < 1` at the target scale, or plan the extra uncle slot.