Koch Laboratory

Linia TimeVault, rewizja: przeszłość poświadczona, przyszłość wymuszana przez zewnętrzne kworum czasu

Kontynuuje wpis z 2026-07-14: wymuszanie przyszłości istnieje już dla pojedynczych wpisów — przez zewnętrzne kworum czasu zamiast time-lock puzzle, z jawnie podanymi granicami zaufania — warunek miejsca przeszedł z polityki aplikacji do klucza, a wyniki negatywne od lipca publikujemy razem z korektami nieaktualnych stwierdzeń wpisu lipcowego.

Koch Laboratory — linia TimeVault, rewizja: przeszłość poświadczona, przyszłość wymuszana przez zewnętrzne kworum czasu

Wpis z 2026-07-14 zamykał się tezą, że znakowanie czasem dowodzi przeszłości, ale nie wymusza przyszłości. Od tamtej pory linia TimeVault wymusza przyszłość dla pojedynczych wpisów — zewnętrznym kworum czasu, nie obliczeniami — a warunek miejsca przeszedł z polityki aplikacji do wyprowadzenia klucza.

Metodyka. Problem → stan techniki → falsyfikowalne kryterium → metoda → wynik z warunkami brzegowymi → następny krok. Konstrukcji tu nie opisujemy.

1. Kierunek 3 po rewizji: wymuszanie przyszłości przez zewnętrzne kworum czasu

Problem. Wpis ma pozostać nieczytelny do wskazanej chwili — także dla właściciela, autora aplikacji i operatora usługi — bez względu na zegar urządzenia. Stan techniki (publikowany). Time-lock puzzles (Rivest–Shamir–Wagner, 1996) i VDF (Boneh i in., 2018) wymagają pracy sekwencyjnej, więc chwila otwarcia zależy od sprzętu; przy blokadzie czasowej wobec progowego beacona losowości (drand, tlock) zależy od podpisu publikowanego dopiero w danej rundzie — za cenę zaufania do beacona. Kryterium (falsyfikowalne). Przed wskazaną chwilą żaden pojedynczy posiadacz klucza — operator, autor aplikacji ani właściciel — nie otworzy wpisu, a zegar urządzenia nie ma znaczenia; potem wpis otwiera się z danych uwolnionych publicznie, a koperta z jednej implementacji formatu — w drugiej i odwrotnie. Metoda. Publiczny format koperty beattime-seal-v1: kworum złożone z publicznego beacona losowości, serwerów klucza operatorów i kodu odzyskiwania właściciela; wpis pozostaje w zaszyfrowanym sejfie. Interoperacyjność sprawdzana warstwami, w obu kierunkach: wobec biblioteki referencyjnej, rzeczywiście opublikowanego podpisu beacona i drugiej implementacji formatu. Wynik. Potwierdzony w zakresie kryterium dla pojedynczych wpisów w aplikacji mobilnej linii, także łącznie z warunkiem miejsca; wobec pytania z lipca — częściowy: zaufaną stronę zastąpiło kworum o niezależności organizacyjnej. Granice.

Następny krok. Więcej operatorów — odrębnych podmiotów na odrębnej infrastrukturze — by otwarcie przed czasem wymagało zmowy większej liczby stron. Status: zaimplementowane + testy interoperacyjności; puzzle i VDF — poza implementacją; wymuszanie bez zaufanych stron — pytanie otwarte.

2. Miejsce: od polityki aplikacji do wiązania kryptograficznego

Problem. Warunek „otwórz tylko tutaj” sprawdzany przez aplikację po odszyfrowaniu jest polityką — omija go zmieniona aplikacja albo podstawiona lokalizacja. Tak działał warunek miejsca w linii TimeVault przed przeprojektowaniem. Stan techniki (publikowany). Geofencing jako kontrola dostępu w aplikacjach; geo-szyfrowanie, czyli lokalizacja jako wejście do wyprowadzenia klucza (Scott i Denning, 2003). Kryterium (falsyfikowalne). Poza miejscem klucz nie istnieje, więc nie ma czego odmówić; plik nie zawiera niczego o miejscu — ani współrzędnych, ani promienia, ani nawet informacji, że wiązanie jest użyte; kod odzyskiwania zastępuje miejsce, nigdy pozostałe czynniki. Wynik. Potwierdzony w zakresie kryterium, dla sejfu i dla pojedynczego wpisu; na urządzeniu wpis związany z miejscem odmówił otwarcia w innym mieście. Konstrukcji wiązania tu nie opisujemy. Granice. Miejsce ma małą entropię: wiązanie chroni przed kimś, kto ma kopię zapasową i nie wie, gdzie stanąć, ale słabo przed kimś, kto ma telefon i zna miasto właściciela — to czynnik dodatkowy, nie zamiennik silnego hasła. Bez miejsca i bez kodu odzyskiwania treść jest zamknięta na stałe. Następny krok. Pomiar efektywnej przestrzeni przeszukiwania dla napastnika znającego miasto; dziś ta granica jest opisana jakościowo, nie zmierzona. Status: zaimplementowane + testy, w tym na urządzeniu.

3. Wyniki negatywne i przeprojektowania od lipca

Status: naprawione i pokryte testami.

Korekty wpisu z 2026-07-14

Status kierunku. Przeszłość poświadcza osobna, publicznie weryfikowalna usługa czasu; przyszłość wymusza dla pojedynczych wpisów kworum, które zaufanie rozkłada, a nie usuwa; wiązanie z miejscem jest częścią klucza. Żadna z opisanych konstrukcji nie przeszła zewnętrznego audytu.

Dowód czasu

Ten tekst został zahaszowany i ostemplowany przy publikacji. Do sprawdzenia potrzebne są oba pliki: stempel dowodzi, że w tamtej chwili istniał dokładnie jeden ciąg bajtów, a tym ciągiem jest wyłącznie źródło poniżej. Każda późniejsza zmiana przesuwa skrót i zrywa zgodność — i o to właśnie chodzi.

· @529.59 · 2026-W40

SHA-256 ostemplowanego tekstu: 0423ffe937b37667786bee63fc0abdd635e41e38bf3e3ef523c41e16a85cab7d

Sprawdzenie: ots verify <dowód> --file <źródło>