Wie funktioniert eine transparente Raffle? Das Winbase-Prinzip erklärt

Was macht eine Verlosung wirklich fair?

Viele Online-Gewinnspiele versprechen Fairness — aber können sie sie beweisen? Bei Winbase ist die Antwort ein klares Ja. Jede Verlosung auf unserer Plattform ist vollständig reproduzierbar und für alle nachprüfbar. Kein Betreiber, kein Creator und kein Algorithmus-Geheimnis steht zwischen dir und dem Ergebnis.

Der Ablauf: Von der Teilnahme zur Ziehung

1. Teilnahmephase

Während einer aktiven Raffle können Nutzer teilnehmen. Alle Teilnehmer sind öffentlich einsehbar — mit Zeitstempel, in chronologischer Reihenfolge. Es gibt keine versteckten Teilnehmer.

2. Einfrieren der Teilnehmerliste

Sobald eine Raffle endet, wird die Teilnehmerliste eingefroren. Keine nachträglichen Änderungen sind mehr möglich — weder durch Winbase noch durch den Creator.

Als kryptografischer Integritätsbeweis berechnet Winbase in diesem Moment einen Teilnehmerlisten-Hash: SHA-256 aller Teilnehmer-IDs in Ziehungsreihenfolge (sortiert nach Einschreibezeitpunkt). Dieser Hash wird im öffentlichen Draw Proof veröffentlicht. Würde danach auch nur ein einziger Teilnehmer hinzugefügt, entfernt oder umgeordnet, würde sich der Hash komplett ändern — sichtbar für jeden, der nachprüft.

3. Externe Entropie: Was ist ein Bitcoin-Block-Hash?

Der entscheidende Zufallswert kommt nicht von Winbase, sondern vom Bitcoin-Netzwerk. Jeder Bitcoin-Block enthält einen kryptografischen Hash — eine 64-stellige Hexadezimalzahl, die aus dem gesamten Block-Inhalt berechnet wird. Dieser Hash ist:

• Öffentlich: Jeder kann ihn auf Blockchain-Explorern wie blockstream.info einsehen
• Nicht vorhersagbar: Kein Miner und kein Unternehmen kann den Hash eines zukünftigen Blocks berechnen
• Nicht von Winbase kontrollierbar: Das Bitcoin-Netzwerk ist dezentral und unabhängig

Winbase verwendet ausschließlich den ersten Bitcoin-Block, dessen Zeitstempel nach dem Raffle-Ende liegt. Da dieser Block erst nach Raffle-Ende gemined wurde, war sein Hash beim letzten Teilnehmer-Join noch nicht öffentlich bekannt. Das schließt aus, dass jemand die Entropie vorab kennen und ausnutzen konnte. Welcher Block verwendet wird, ist damit vor der Ziehung eindeutig und deterministisch festgelegt — ohne jede Entscheidungsmöglichkeit für Winbase.

4. Seed-Generierung

Winbase kombiniert vier öffentliche Faktoren zu einem eindeutigen Seed:

Diese vier Werte werden als Text zusammengefügt und durch den SHA-256-Algorithmus gehasht. Das Ergebnis ist ein deterministischer Hex-String.

seed_input = "raffle-id:47:2026-05-11T13:00:00Z:0000000000abc123..."
seed_hash  = SHA-256(seed_input)

Es gibt keine versteckten Inputs, keinen geheimen Salt und keine internen Zufallswerte. Alle Komponenten sind veröffentlicht.

5. Gewinner-Ermittlung

Aus dem Seed wird ein numerischer Index berechnet:

index = BigInt("0x" + seed_hash) % BigInt(participantCount)
winner = participants[index]

Die Teilnehmerliste ist nach Einschreibezeitpunkt sortiert (participated_at aufsteigend) — deterministisch und für jeden nachvollziehbar. Der Index zeigt immer auf dieselbe Person.

6. Veröffentlichung des Draw Proof

Nach der Ziehung wird der vollständige Draw Proof öffentlich auf der Ergebnis-Seite angezeigt:

• Alle Seed-Komponenten (Raffle-ID, Teilnehmeranzahl, letzter Zeitstempel)
• Bitcoin-Block-Hash + Blockhöhe
• Berechneter SHA-256-Seed
• Gewinner-Index in der Teilnehmerliste
• SHA-256-Hash der eingefrorenen Teilnehmerliste (participants_hash)
• Gewinner-Profil

Über den eingebauten Verifikations-Button kannst du die Ziehung direkt im Browser in Sekunden selbst nachrechnen.

Manipulationsschutz: Alle bekannten Angriffsvektoren

Transparenz bedeutet nicht nur "der Algorithmus ist bekannt" — sie bedeutet auch, ehrlich über mögliche Schwachstellen zu sein und zu erklären, wie sie geschlossen werden. Hier sind die fünf relevanten Angriffsvektoren und wie Winbase sie verhindert:

Angriffsvektor 1: Reihenfolge der Teilnehmerliste nachträglich ändern

Das Problem: Wenn der Betreiber die Sortierung der Teilnehmer vor der Ziehung noch ändern könnte, ließe sich gezielt beeinflussen, wer unter Index i landet — und damit, wer gewinnt.

Die Lösung: Der Teilnehmerlisten-Hash (participants_hash) beweist die Integrität der Liste. SHA-256 aller Teilnehmer-IDs in exakter Ziehungsreihenfolge wird beim Einfrieren berechnet und öffentlich veröffentlicht. Jede Veränderung der Reihenfolge würde den Hash sichtbar verändern. Sortierung ist unveränderlich: participated_at ASC.

Angriffsvektor 2: Teilnehmer nach Schluss hinzufügen oder entfernen

Das Problem: Wenn nach Teilnahmeschluss noch Accounts eingefügt oder gelöscht werden könnten, würde sich die Listenlänge ändern — und damit über index = seed % n der Gewinner.

Die Lösung: Zwei unabhängige Schutzebenen greifen gleichzeitig. Erstens sperrt eine harte Datenbankbeschränkung Schreibzugriffe auf raffle_participants, sobald status = 'drawn' gesetzt ist. Zweitens würde der participants_hash im Draw Proof nicht mehr zur veröffentlichten Teilnehmerliste passen — ein Widerspruch, den jeder Dritte sofort erkennen kann.

Angriffsvektor 3: Bitcoin-Block frei auswählen

Das Problem: Wenn der Betreiber nach Raffle-Ende mehrere verfügbare Blockhashes testen und den "günstigsten" wählen könnte, wäre die externe Entropie nicht mehr neutral.

Die Lösung: Die Blockauswahl ist deterministisch und vorab vollständig definiert: Verwendet wird immer der erste Bitcoin-Block, dessen Zeitstempel nach ends_at liegt. Kein Mensch und kein Code auf Winbase trifft eine Entscheidung über den Block. Wer auch immer die Ziehung ausführt — Cron-Job, API oder ein unabhängiger Dritter — bekommt exakt denselben Hash.

Angriffsvektor 4: Versteckte Seed-Inputs einbauen

Das Problem: Wenn der Betreiber geheime Werte (einen privaten Salt, eine versteckte Zufallszahl) in die Seed-Berechnung einbauen würde, könnte er so lange verschiedene Kombinationen testen, bis sein Wunschgewinner herauskommt.

Die Lösung: Alle Seed-Inputs sind öffentlich und im Draw Proof einsehbar: Raffle-ID, Teilnehmeranzahl, letzter Zeitstempel, Bitcoin-Block-Hash. Die Formel ist bekannt. Es gibt keine versteckten Parameter. Jeder kann mit exakt diesen vier Werten denselben SHA-256-Hash berechnen.

Angriffsvektor 5: Teilnehmerliste unterschiedlich sortieren

Das Problem: Wenn die im Frontend angezeigte Liste nach Zeit sortiert wäre, die interne Berechnungsliste aber nach UUID, wäre die Ziehung für Nutzer nicht reproduzierbar — obwohl sie mathematisch korrekt wäre.

Die Lösung: Frontend und Backend verwenden exakt dieselbe Sortierung: Einschreibezeitpunkt aufsteigend (participated_at ASC). Der participants_hash im Draw Proof ist der Hash genau dieser sortierten Liste. Im Participant-Pool auf der Ergebnis-Seite wird dieselbe Reihenfolge angezeigt — inklusive Index-Nummern, damit jeder participants[index] nachvollziehen kann.

Warum dieser Ansatz fair ist

Vertrauen ist gut — Nachprüfbarkeit ist besser.

Drei Garantien gelten für jede Winbase-Raffle:

Winbase kann das Ergebnis nicht manipulieren. Der Bitcoin-Block-Hash ist nicht vorhersagbar und nicht kontrollierbar. Alle anderen Seed-Inputs sind öffentlich und unveränderlich nach Teilnahmeschluss.

Der Creator kann nicht eingreifen. Nach dem Ende der Raffle sind Teilnehmerliste und Draw Proof unveränderlich in der Datenbank gespeichert. Bearbeitungen sind durch Constraints gesperrt.

Jeder kann die Ziehung nachrechnen. Alle Eingaben sind öffentlich. Jede Person kann mit einem SHA-256-Tool dasselbe Ergebnis berechnen — und mit dem participants_hash zusätzlich prüfen, ob die gezeigte Teilnehmerliste identisch mit der verwendeten ist.

So verifizierst du selbst

Besuche eine abgeschlossene Raffle und öffne den Abschnitt Draw Proof. Dort siehst du alle Eingabeparameter und kannst alles selbst berechnen:

import hashlib

# Schritt 0: Teilnehmerlisten-Hash prüfen
participants = ["user_id_1", "user_id_2", "user_id_3"]  # aus dem Draw Proof
ph = hashlib.sha256(":".join(participants).encode()).hexdigest()
print("Participants hash:", ph)  # muss mit participants_hash im Proof übereinstimmen

# Schritt 1: Seed berechnen
seed_input = "raffle-123:3:2026-03-15T12:00:00Z:0000000000abc123def456"
seed = hashlib.sha256(seed_input.encode()).hexdigest()
print("Seed:", seed)

# Schritt 2: Gewinner-Index ableiten
index = int(seed, 16) % len(participants)
print("Winner:", participants[index])

Alternativ direkt im Browser (F12 → Konsole):

// Schritt 0: Teilnehmerlisten-Hash prüfen
const participants = ["user_id_1", "user_id_2", "user_id_3"];
const phBuf = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(participants.join(':')));
const pHash = Array.from(new Uint8Array(phBuf)).map(b => b.toString(16).padStart(2,'0')).join('');
console.log('Participants hash:', pHash);

// Schritt 1: Seed berechnen
const input = "raffle-123:3:2026-03-15T12:00:00Z:0000000000abc123def456";
const buf = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(input));
const seed = Array.from(new Uint8Array(buf)).map(b => b.toString(16).padStart(2,'0')).join('');
const index = Number(BigInt('0x' + seed) % BigInt(participants.length));
console.log('Seed:', seed);
console.log('Winner:', participants[index]);

Der eingebaute "Jetzt prüfen"-Button im Draw Proof führt genau diese Berechnung im Browser aus — inklusive participants_hash-Verifikation.

Warum der Block nach Raffle-Ende entscheidend ist

Bitcoin-Block-Hashes sind nicht vorhersagbar — aber ein Block, der bereits vor Raffle-Ende gemined wurde, war in dem Moment öffentlich bekannt. Theoretisch könnte jemand diese Information nutzen, um seine Teilnahme strategisch zu platzieren.

Winbase löst das, indem die Ziehung ausschließlich den ersten Block nach Raffle-Ende verwendet. Dieser Block existiert zum Zeitpunkt des letzten Teilnehmer-Joins noch nicht — sein Hash kann also von niemandem im Voraus berechnet oder eingesehen werden. Das Fairness-Versprechen gilt damit ohne Einschränkung.

Fazit

Transparente Verlosungen sind kein Hexenwerk — sie erfordern nur den Willen zur Offenheit. Winbase setzt diesen Standard für alle Raffles auf der Plattform verbindlich um:

• Externer, unkontrollierbarer Zufallswert aus dem Bitcoin-Netzwerk
• Kryptografischer Beweis der eingefrorenen Teilnehmerliste (participants_hash)
• Alle Seed-Inputs öffentlich und vollständig verifizierbar
• Deterministischer, vorab definierter Bitcoin-Block — keine Auswahlmöglichkeit
• Konsistente Sortierung in Frontend und Backend

Fairness ist bei uns keine Marketingaussage, sondern nachprüfbare Realität.

Noch Fragen? Sieh dir unsere Wie funktioniert's? Seite an oder nimm an einer aktiven Raffle teil und verfolge die Ziehung live.