The LUCKOTTO-1 Draw Protocol

1Introduction and claims

A lottery draw is an agreement about a future random choice. LUCKOTTO-1 makes that agreement checkable: it fixes every term before the randomness exists, sources the randomness from Bitcoin proof-of-work, and makes the selection a deterministic function anyone can replay. This section fixes the parties, states the exact claim, and draws the boundary of what the protocol does not attempt to prove.

1.1Parties and trust model

Four parties matter. The operator — Luckotto — accepts funded tickets from partners, holds each round's secret, anchors commitments on Bitcoin, provides the prize bankroll, and settles prizes. Partnersfund tickets. Miners produce the blocks the draw consumes. Verifiers are anyone replaying a round from public data: a partner, a ticket holder, a stranger. The construction introduces no further party — no oracle, no randomness committee, no federation. Its external dependencies are the Bitcoin chain [1] and deterministic arithmetic.

1.2The claim, in four properties

The protocol makes four properties hold for every round.

• P1 — Terms precede entropy. Every value that can affect the outcome — the ticket set, each contribution, every partner's desired prize, the prize bankroll, the secret hash, and the VDF iteration count — is fixed in one byte-exact file and anchored on Bitcoin before the block that decides the winner exists.
• P2 — The outcome is a pure function. Winner selection is deterministic integer arithmetic over the committed file, the revealed secret, and one canonical Bitcoin block hash. The same evidence admits exactly one result.
• P3 — There is no resampling path. After the commitment confirms, no party — the operator included — retains any protocol action that can change the result. Misbehavior can stall a round; it can never re-draw one.
• P4 — Deviation is attributable. A missing commitment, missing delay work, an unrevealed secret, or a published result that does not replay are each visible from chain data and published bytes, and each is defined by the protocol as operator misbehavior rather than a valid outcome.

1.3Selection is proven; settlement is not

2The round protocol

A round passes through four irreversible events: sales close, the commitment seals, the commitment confirms on Bitcoin, and the secret is revealed. Each event exists to remove one kind of discretion. Figure 1 shows the full evidence flow; the subsections that follow define each artifact and justify its design.

2.1Lifecycle of a round

1. Sales close on the published schedule. Tickets are immutable funded receipts: a UUID, a contribution, and a partner reference. Each partner has a live desired prize that becomes immutable T when the round locks, while its tickets' contributions aggregate into A. A round with no funded tickets never closes — its close time rolls forward — so a draw can never run against an empty set. Close also freezes the prize bankroll Q.
2. The round seals. The operator generates a fresh 32-byte secret and derives the round manifest: one JSON file binding the full round state (§2.2). The file and its tagged SHA-256 hash are published immediately — before any entropy exists — so any buyer can confirm inclusion and terms while the outcome is still undetermined for everyone.
3. The hash is anchored on Bitcoin. The commitment for round N is the first confirmed transaction spending from the BIP86 Taproot address derived at commitmentXpub/N. Its output 0 must be one OP_RETURN carrying exactly the raw 32-byte manifest hash. The confirmation height H is the round's anchor point.
4. Bitcoin supplies the entropy. The draw block is the canonical block at height H + 3, always and exactly. Its hash is the one input the operator does not choose — and it does not exist yet when the ticket set, partner terms, secret, and work commitment become immutable.
5. A verifiable delay converts the block into the draw seed. The committed iteration count — a positive count that can only ratchet upward from one round to the next — turns the manifest hash and draw-block hash into a proof-carrying output. Evaluation is permissionless: anyone may compute and submit through the public API, and the server verifies the proof before accepting the first valid solution for the canonical draw block.
6. The secret and outcome publish atomically. Exactly 30 minutes after a valid solution is accepted, one transaction reveals the secret — which must match the committed hash — and records the winner or the no-winner outcome. The round is verifiable after operator reveal. If the operator does not reveal the committed secret, that is a sign of cheating, not a cancellation or valid outcome.

2.2The round manifest

The manifest is the committed definition of a round: one JSON document containing exactly six fields — protocol, roundNumber, prizeBankrollSats, roundSecretHash, vdfIterations, and partners — that binds every input the draw will consume. Table 1 lists what each committed value contributes.

Individual receipts deliberately stay out of this file: each partner entry instead carries the hash of that partner's published manifest, so the round commitment stays one small document while still binding every receipt byte-exactly (§2.6).

2.3Commitment discovery

The commitment is defined as the first confirmed spend of a per-round derived address, and this definition carries the scheme's uniqueness. Every verifier resolves the same commitment because height, then block time, then txid order the candidates, and any later spend is inert — the operator cannot show different committed files to different audiences. The address derives from a public descriptor, so discovery needs no cooperation from the operator, and no server-reported txid is trusted.

Two alternatives were rejected. Publishing a commitment txid makes the pointer itself an object of trust, and equivocation — a different txid for each audience — becomes trivial. Requiring an unbroken funding chain from a genesis outpoint makes verification cost grow with history and turns wallet operations into consensus rules. Funding ancestry, rollover outputs, and output counts are therefore deliberately not part of validity.

2.4The chain carries 32 bytes, not the round

The anchor proves which bytes were committed and when. The bytes themselves are served as a file that anyone can mirror from the moment the round seals. This split keeps the on-chain footprint at one OP_RETURN per round while making withheld or altered files detectable by hash; the availability consequence is stated honestly in §6.2.

2.5Canonical bytes

Core emits round and partner manifests with one canonical JSON encoder, so equivalent data has one stable representation: objects sort keys by ascending UTF-16 code units; arrays preserve their stored order; strings and finite numbers use ECMAScript JSON encoding; Unicode is not normalized; lone UTF-16 surrogates are rejected. Round partners sort by payout address, and each partner's tickets sort by UUID.

The Bitcoin hash still commits to the exact received bytes. Validators validate the decoded data — field set, ranges, ordering — and can check the committed bytes without re-serializing them. Canonical production makes artifacts predictable; exact-byte hashing remains the final commitment check, so formatting is never a validity rule.

2.6Ticket metadata

Individual receipts live in per-partner manifests at /rounds/N/partners/<payoutAddress>/manifest.json, bound through each partnerManifestHash rather than serialized inline: the draw needs only the committed aggregates, and the files stay auditable without inflating the round manifest. Ticket metadata is public partner-defined information for abstractions such as numbers, vouchers, and claim evidence. Core serializes it canonically beside the receipt in the partner manifest, so the round commitment binds it without interpreting it. Metadata cannot change a receipt's contribution, partner assignment, or the Core outcome; customer winners and prize tiers belong to the partner's own game.

3Randomness

A draw needs randomness that nobody can steer. Public chains offer entropy that is unpredictable but not unbiasable: the producer of a block chooses whether to publish it. Private commitments offer entropy outsiders cannot bias but the committer can grind. LUCKOTTO-1 uses both, arranged so the party who can influence the input cannot evaluate the result, and the party who can evaluate the result cannot influence the input.

3.1Influence and evaluation are split

• The operator commits blind. The secret and the full ticket set are hashed on Bitcoin before the draw block exists. Predicting that block's hash is exactly as hard as Bitcoin proof-of-work makes it.
• The miner influences blind. The final sample includes the unrevealed secret, so to a block producer every candidate hash looks identical: discarding a block buys nothing and costs the block.
• The solver adds nothing. The VDF is deterministic. Whoever evaluates it — operator, partner, stranger — produces the same 100 bytes, and the proof pins them.

vdfSeed         = SHA256(UTF8("LUCKOTTO-1/VDF-SEED") || 0x00 || drawBlockHashBytes)
discriminant    = ChiaCreateDiscriminant(vdfSeed, 1024)
vdfOutput       = repeated squaring from form 08, manifest.vdfIterations times
delayedDrawSeed = SHA256(UTF8("LUCKOTTO-1/VDF-OUTPUT") || 0x00 || canonicalVdfOutput)

Every hash in the protocol is domain-separated with a protocol tag and a zero byte, so no value can be replayed in another context, and the class-group discriminant is derived fresh from each round's draw block, so nothing about one round's VDF precomputes another's.

3.2The entropy is a block hash

The draw seed must be expensive to re-roll. A block hash is the proof-of-work output itself [1]: producing one alternative candidate costs a full block solution, and discarding a found block forfeits the full block reward. Cheaper chain values — transaction ids, merkle roots, mempool contents — can be ground for free by whoever assembles the block, and were rejected for exactly that reason.

3.3The committed secret

Without the secret, the draw would be a public function of the draw-block hash, and the block's miner could evaluate candidate blocks before publishing: withhold when unfavorable, publish when favorable, at a cost bounded by one block reward. With the secret committed inside the manifest, that evaluation requires key material no miner has. The complementary property is deliberate: the secret is worthless to its holder. Before the draw block exists it predicts nothing, and after sales close nothing can be bought or changed — so a leaked secret creates no betting edge and costs the protocol only its miner-blinding layer. Committing the secret hash inside the manifest also means one on-chain anchor covers both the ticket set and the hidden input, binding the secret to exactly one round.

3.4The verifiable delay function

The secret and the block split influence from evaluation, but those capabilities reunite if the operator colludes with a miner. The verifiable delay function [2] [3] prices that collusion: learning whether a candidate draw block is favorable costs the committed iteration count of strictly sequential class-group squarings, evaluated with the same construction and proof format as Chia's production VDF [4]. As of 2026, the fastest publicly demonstrated class-group hardware performs on the order of 7×10⁵ squarings per second, so operators must choose the committed count against plausible accelerated hardware, not local CPU timing. A colluding miner must complete that committed work before learning whether withholding was worthwhile. The VDF contributes delay, not randomness: it is deterministic, so the last mover in the pipeline has nothing left to choose, and its output feeds through a tagged hash into a uniform seed.

3.5The iteration count

The evaluator must not choose the work, so the count lives in the manifest, committed before the draw block exists. The protocol minimum is the positive count 1, and the cross-round ratchet supplies the durable safety rule: round N+1 must use at least round N's count. The operator may raise the next count before sealing but can never lower it. No measurement feeds back automatically: an auto-tuner reacting to observed solve times would hand whoever controls observed solve times a lever over future rounds.

3.6The draw height

Entropy must strictly postdate the commitment. A gap of 3 blocks guarantees the manifest is confirmed and buried before its entropy exists, tolerates shallow natural reorganizations around the commitment, and stays small enough that rounds resolve within the hour. The constant is fixed for every LUCKOTTO-1 round because any per-round or operator-chosen delay would be one more discretion to audit; a draw computed at any other height is simply invalid.

3.7The reveal delay

The one dangerous reorganization is the one that arrives after the secret is public, because a public secret makes candidate draw blocks evaluable by anyone. Before the reveal, a reorganization is harmless: derived results clear, the committed ticket set cannot move, and solutions — which are append-only and keyed by draw-block hash — reactivate automatically if their block returns to the canonical chain. The delay of 30 minutes holds the irreversible step until the draw block has typically accumulated five or more confirmations (delay work plus the waiting period), pushing a post-reveal reorganization into multi-block-reward cost. Revealing the secret and recording the outcome in one atomic step leaves no window in which partial information is public.

3.8One draw, no retry

Commit-reveal gambling schemes historically fail by resampling: peek at the result, abort, retry. LUCKOTTO-1 has no retry. The outcome is fixed the moment the draw block joins the canonical chain; the solution endpoint accepts valid work from anyone, so the operator cannot suppress the evidence; and refusing to reveal is defined as misbehavior, never as a cancellation. The draw is verifiable after operator reveal, and failure to reveal is a sign of cheating. Stalling suppresses a result that already exists and is already committed — it cannot produce a different one.

3.9A seed for downstream games

After rejection sampling accepts attempt n, Core also publishes the next domain-separated hash as drawExtensionSeed:

This value cannot change the Luckotto outcome: selection uses only accepted attempt n, and Core never feeds the extension seed back into the draw. It is stored with the outcome and shown in the round API and website so partners can domain-separate it for deterministic downstream games, such as selecting one of their own internal tickets after their partner wins.

4Draw economics

The commitment scheme proves the draw followed the rules. The rules are chosen so that no party — the operator above all — gains from bending them. Every probability below is a ratio of committed integers; Table 2 fixes the notation used for the rest of the paper.

4.1Notation and allocations

Each partner's shortfall and allocation derive from the committed integers alone. A winning partner receives P + E: the whole ticket-funded pot plus the bankroll-funded shortfall.

E = min(max(T - P, 0), floor(Q × 1/2))

S = 2^32 = 4294967296
K = S × P

v = S × A                                        when E = 0
v = floor(S × P × A × (Q - E) / (Q × (P + E)))   when E > 0

D = K - Σ v

The draw takes one uniform sample in [0, K). If sample < D the round resolves no-winner and the pot accrues to Luckotto's prize bankroll; otherwise the sample lands in exactly one partner's interval and that partner receives P + E (Figure 2).

4.2The probabilities are exact

Each partner wins with probability exactly v / K and the round resolves no-winner with probability exactly D / K. The sampler hashes the domain, secret, delayed seed, and a big-endian attempt counter with SHA-256, rejects 256-bit values at or above the largest multiple of K below 2^256, and reduces the first accepted value modulo K — uniform by construction, with no modulo bias (§8.5). The no-winner interval comes first, then positive-allocation partners in ascending payout-address order; order fixes boundary ownership without changing any width. All arithmetic is integer, so two implementations cannot round differently.

4.3The parimutuel case

With E = 0 the allocation is exactly S × A: probability A / P, prize P, expected value A. If every partner in a round has E = 0, the allocations sum to exactly K, the no-winner width is zero, and a winner is certain.

4.4Pricing a larger prize

A desired prize T above P makes the bankroll underwrite the shortfall E. Before the single floor in (3), the allocation gives probability A × (Q - E) / (Q × (P + E)) against prize P + E: expected value A × (1 - E/Q). The E/Q discount is the premium paid to the bankroll for carrying the risk. Later ticket funding raises P, shrinks E, and weakly improves the partner's terms — no purchase can worsen another committed partner's expected value.

4.5Bankroll income and the cap

Summing expected values, the bankroll's expected income per round is the total of A × E / Q across partners; the no-winner interval is that priced exposure and nothing more, up to sub-atom floor remainders. When the sample lands in it, the pot accrues to Luckotto's prize bankroll; when a partner with a shortfall wins, the bankroll pays that partner's E. The floor(Q × 1/2) cap in (1) bounds the worst single-round loss to half the bankroll, so the bankroll that backed round N still exists to back round N + 1.

4.6Self-funded volume helps other partners

Adding a self-funded receipt raises both its partner's aggregate A and the shared pot P. The funding is real, committed Bitcoin contribution; it does not manufacture a free interval or disadvantage another partner. A larger P weakly shrinks every other partner's shortfall E. Partners whose shortfalls shrink therefore receive higher expected value, while partners already atE = 0 are unaffected. Self-funded volume can only weakly improve another committed partner's terms.

4.7Scale and rounding

S = 4294967296 gives every sat 32 exact fractional bits of allocation and is itself exactly representable as a JSON number. Each partner's allocation is floored once, shedding less than one atom; an atom is worth (P + E) / K sats — far below one sat. At extreme contribution-to-desired-prize ratios an allocation can floor to zero: that partner's contribution stays in P and it is excluded from selection, and a round cannot seal without at least one positive-allocation partner.

5Adversary analysis

Each adversary below gets the strongest capabilities consistent with the assumptions of §6.1. Costs reference the full block reward — a 3.125 BTC subsidy in the 2024–2028 epoch, plus fees.

5.1The operator, acting alone

Available levers: choose the secret, choose and time the ticket set and the close, choose when to broadcast the commitment, stall at any stage. Every grinding lever fails for one reason: each choice is fixed before the draw block exists, and no earlier moment offers any information about its hash. Ticket-set manipulation is unprofitable by the corollary of §4.6. What remains is stalling — refusing to commit, to accept delay work, or to reveal — which cannot change the already-fixed result, is visible in public data, and is defined as misbehavior. Net capability: an attributable refusal to settle, nothing more.

5.2A draw-block miner, without collusion

The miner sees the manifest and the secret hash — not the secret. Candidate blocks at the draw height are unevaluable, so withholding pays the full block reward for zero information. Publishing immediately dominates. Net capability: none.

5.3Operator–miner collusion

This is the binding constraint of the design. The colluders can evaluate candidate draw blocks — they hold the secret — but each evaluation costs the committed sequential work, several block intervals on the best public hardware. A found block must be withheld, unpaid, for that long before its favorability is known; the chain has almost certainly moved on, so each effective outcome sample costs at least one full block reward, on top of owning enough hashpower to mine the draw height at all. Rounds whose manipulable value sits below block-reward scale — hundreds of millions of sats — are uneconomic to attack even with full collusion, and the committed iteration count can be raised for rounds that are not.

5.4A deep reorganization after the reveal

Once the secret is public, draw blocks become evaluable by anyone, so the residual attack is to reorganize Bitcoin from before the draw height and grind replacement blocks. By reveal time the draw block typically has five or more confirmations, so this costs a deliberate multi-block reorganization — several full block rewards — plus one full VDF evaluation per candidate. The protocol additionally halts automatic processing on reorganizations beyond its configured depth and requires manual reconciliation; that halt is operational protection, not a finality claim. Named because it bounds the design, not because it is expected at lottery scale.

5.5An insider who leaks the secret

In-protocol value: none. Before the draw block exists the secret predicts nothing; after the close nothing can be bought or changed. What a leak actually does is restore a miner's ability to evaluate candidate blocks — it downgrades the analysis to the collusion case of §5.3 without requiring the operator's cooperation. Secret handling is therefore operational security for the miner-blinding layer, not for player odds.

5.6A proof forger

Claiming a false VDF output means defeating nested Wesolowski soundness [3] in a class group whose discriminant is freshly derived from the round's manifest and draw-block hashes — nothing precomputes across rounds, and class groups have no trusted setup to subvert. That absence is why they were chosen over RSA groups, where a known factorization silently forges proofs. A forged output is also caught by any verifier who re-runs the evaluation, hours later at worst. This adversary is cryptanalytic, not economic, and is covered by the assumptions of §6.1.

6Assumptions and non-goals

6.1The construction assumes

• A1. SHA-256 is preimage- and collision-resistant [5].
• A2. Class-group squaring at 1024-bit discriminants is inherently sequential with bounded hardware advantage, and nested Wesolowski proofs are sound [3].
• A3. The pinned Bitcoin network's canonical chain stays expensive to reorganize; the draw follows it at every depth.
• A4. The round secret carries 32 bytes of real entropy. A guessable secret would be recoverable offline from its committed hash and would silently restore miner evaluability — this one assumption is not externally checkable.

6.2What is not proven

• N1 — Settlement. Proven: which partner must be paid, how much, and its committed payout address. Not proven: that payment happens. Prizes are manual cold-storage transactions recorded by txid and checkable on-chain after the fact.
• N2 — Manifest availability. The chain commits 32 bytes; the file is served by the operator and by anyone who mirrors it. It is published at seal time precisely so interested parties can archive it before the draw — an archived copy proves misbehavior later without anyone's cooperation.
• N3 — Deployment identity. The Bitcoin network, the LUCKOTTO-1 rules, and the raw commitment account xpub must be pinned from a source other than the server being verified. A server can always describe itself consistently; only external pinning lets two verifiers know they are checking the same deployment.
• N4 — The partner retail layer. The protocol commits funded receipt UUIDs, their contributions, and their partner assignments. It does not enforce the partner's customer prize tiers, exclusivity, delivery, pricing, or payouts. Partners must publish enough rules and evidence for customers to verify their own game. Canonical public ticket metadata is committed through the partner manifest, but Core does not enforce its meaning.

7Independent verification

The reference replayer is Luckotto Calc, a standalone Go implementation maintained separately from the production draw code; the round verifier runs the same checks in a browser. The procedure, in evidence order:

1. Pin the deployment identity. The Bitcoin network, the exact LUCKOTTO-1 rules through a reviewed implementation, and the commitment Taproot descriptor — /api/constants restates them for convenience but cannot vouch for itself.
2. Locate the commitment. Derive BIP86 Taproot address at commitmentXpub/N, find the first confirmed spend from that address on your own chain view, and read the 32-byte OP_RETURN at output 0. Ignore funding ancestry, other outputs, and any txid the server reports.
3. Authenticate the manifest. Fetch /rounds/N/manifest.json — from the operator or any mirror — hash the exact bytes with the manifest tag, compare against the chain, then validate the decoded data rules.
4. Derive the draw block. Commitment confirmation height plus 3 on the canonical chain. Decode the displayed hash left to right as 32 bytes; do not reverse it.
5. Verify the delay work. Take the published solution from GET /api/rounds/N/vdf or evaluate it yourself, check the nested proof against the seed and the committed iteration count, and tagged-hash the output into the delayed draw seed.
6. Replay the draw. After the reveal, check the secret against the committed hash, derive the allocations from the committed integers, run the SHA-256 rejection sampler, derive the extension seed from attempt n + 1, and compare both with the published result.

Disagreements resolve by the evidence precedence of §8.7: the canonical chain locates the commitment and draw block, the manifest bytes define the round, the proof authenticates the delayed output, and the revealed secret authenticates against the manifest. API responses and this page describe those artifacts; they never override them.

8Specification

This section is normative. Where earlier sections explain, the rules below define validity; a verifier implements exactly these.

8.1Deployment identity

Independent trust begins with three externally pinned values: the Bitcoin network, the protocol name LUCKOTTO-1, and the commitment Taproot descriptor. The initial funding outpoint, previous-round outputs, recorded transaction ids, and API metadata are not part of this identity.

8.2Round manifest

• The JSON object contains exactly protocol, roundNumber, prizeBankrollSats, roundSecretHash, vdfIterations, and partners.
• protocol is LUCKOTTO-1; roundNumber equals the round being verified.
• partners is a non-empty array of exactly the participating partners in strictly ascending payoutAddress order — the array order is a validity rule. Each entry contains exactly payoutAddress, desiredPrizeSats, totalContributedSats, and partnerManifestHash, with a distinct payout address per entry.
• totalContributedSats is the partner's exact aggregate contribution and is positive. The ticket-funded pot P is the sum of every totalContributedSats. These committed aggregates alone drive the draw.
• partnerManifestHash is the plain (untagged) SHA-256 of the exact bytes of the published partner manifest at /rounds/N/partners/<payoutAddress>/manifest.json, listing that partner's funded receipt UUIDs, contributions, and canonical public metadata for audit. The partner manifest's own format is application data, not part of this protocol; only its exact bytes are bound.
• Amounts are safe-integer JSON number literals in sats: partner desired prize and prize bankroll are non-negative. Ticket metadata objects use the canonical partner-manifest encoding of §2.5.
• roundSecretHash = SHA256(UTF8("LUCKOTTO-1/ROUND-SECRET") || 0x00 || roundSecretBytes)
• roundManifestHash = SHA256(UTF8("LUCKOTTO-1/MANIFEST") || 0x00 || exactManifestBytes) Validate the decoded data; hash the exact received bytes. Formatting is not a validity rule.

8.3Bitcoin commitment

For round N, derive non-hardened child /N from the pinned raw depth-3 commitment account xpub and encode it as a BIP86 key-path Taproot address. On the pinned canonical network, the commitment is the first confirmed transaction spending from that address, ordered by block height, then block time, then txid. Output 0 must be one OP_RETURN carrying exactly the raw 32-byte tagged manifest hash and must be the transaction's only OP_RETURN. Funding ancestry, output 1, total output count, and rollover shape do not affect validity. The manifest bytes and hash are published when the round seals, before the commitment broadcasts.

8.4Draw block and delay function

• The draw block is the canonical block at the commitment confirmation height plus exactly 3. Any other delay is invalid.
• Decode the 64-character displayed draw-block hash left to right as 32 bytes without reversing. Decode the tagged round manifest hash as 32 bytes, then derive the seed and discriminant as in Listing 1: vdfSeed = SHA256(UTF8("LUCKOTTO-1/VDF-SEED") || 0x00 || roundManifestHashBytes || drawBlockHashBytes) with ChiaCreateDiscriminant(vdfSeed, 1024).
• One evaluation: class-group repeated squaring from starting element 08 for the manifest's positive iteration count. Round N+1's count must be at least round N's.
• The output is one canonical 100-byte BQFC value. Witness type is 0–64. Proof bytes are the final 100-byte proof followed by exactly witnessType records of uint64_be(segmentIterations) || B[33] || segmentProof[100], so proof length is 100 + witnessType × 141 bytes.
• Solutions are submitted through the public unauthenticated VDF API and are keyed by round and draw-block hash. The server strictly parses and reserializes every BQFC form, verifies the proof against the manifest hash, draw block, and committed iteration count, and hashes the output itself. The first valid solution for the canonical draw block starts the reveal clock; the secret and outcome publish atomically 30 minutes after acceptance. The delayed draw seed is delayedDrawSeed = SHA256(UTF8("LUCKOTTO-1/VDF-OUTPUT") || 0x00 || canonicalVdfOutput)

8.5Selection

Derive E, v, K, and D with the exact integer formulas of §4.1, equations (1)–(4). Place the no-winner interval of width D first, then every positive-allocation partner in ascending Luckotto payout-address order with its exact width; zero-allocation partners receive no interval. Attempt n is SHA256(UTF8("LUCKOTTO-1/DRAW") || 0x00 || roundSecret || delayedDrawSeed || uint32_be(n)) With limit = 2^256 - (2^256 mod K), reject samples at or above limit and reduce the first accepted sample modulo K. The only valid outcomes are won with the selected partner payout address or noWinner with no address; every sealed round contains at least one positive-allocation partner. Attempts are restricted to 0..2^32 - 2. If n is accepted, publish drawExtensionSeed = SHA256(UTF8("LUCKOTTO-1/DRAW") || 0x00 || roundSecret || delayedDrawSeed || uint32_be(n + 1)) with the result. Core must not use that value to select or alter the Luckotto outcome.

8.6Reorganization

The canonical chain is authoritative at every depth. If a reorganization changes the commitment confirmation or the draw block before the reveal, derived results clear and the draw re-derives from the replacement chain. Verified solutions are never updated or deleted; the active solution is the one whose draw-block hash matches the current canonical draw block, and an orphaned solution reactivates if its block returns. A published secret remains public, and a valid replacement solution then resolves the round immediately. Reorganizations beyond the configured depth halt automatic processing for manual reconciliation; the halt is operational, not protocol finality.

8.7Evidence precedence

The canonical Bitcoin chain locates the commitment and the draw block. The exact manifest bytes supply the committed round state. The VDF proof authenticates the delayed output. The revealed secret authenticates against the manifest. API fields, response headers, and website copy are comparison and display values only; they never override those artifacts or locate the commitment.

8.8Parameters

References

1. [1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
2. [2] D. Boneh, J. Bonneau, B. Bünz, and B. Fisch. Verifiable Delay Functions. CRYPTO 2018.
3. [3] B. Wesolowski. Efficient Verifiable Delay Functions. EUROCRYPT 2019.
4. [4] Chia Network. chiavdf: class-group VDF and nested Wesolowski proofs. github.com/Chia-Network/chiavdf.
5. [5] National Institute of Standards and Technology. Secure Hash Standard. FIPS PUB 180-4, 2015.