Solving Bitcoin's Self-Custody Trilemma — Luke Childs, lu.ke (2026-08-08)¶

Forrás: lu.ke/self-custody-trilemma (Luke Childs, 2590 szó) Szerző: Luke Childs (szoftverfejlesztő, Umbrel-munkatárs, github.com/lukechilds) Publikálás dátuma: 2026-08-08 (a Coldcard exploit hetében, péntek) Vendor: Lu.ke — saját blog Típus: Vélemény-cikk + technikai protokoll-bemutató

A cikk előzményei és a szerző személyes motivációja¶

A cikk a 2026 nyarának egyik legnagyobb Bitcoin-hardver-tárca incidense, a Coldcard Q1/Q2 firmware bug után született, amelyben a támadók seed phrase-öket szivárogtattak ki, és a veszteségek 130 millió dollár felett járnak. Luke Childs személyesen is érintett volt — a saját seed-jét 5 évvel ezelőtt egy Coldcardon generálta, és az egyetlen oka, hogy nem vesztette el a megtakarításait, az volt, hogy a Coldcard saját entrópia-generátorában nem bízott meg:

„My seed was originally generated on a vulnerable Coldcard. The only reason I didn't lose my life savings is that, years ago when I set it up, I refused to trust its random number generator. I generated 256 bits of entropy on my MacBook, flipped a coin 256 times, and mixed all of it into the Coldcard's own entropy on the device. Beforehand I did a test run, rewriting the Coldcard's seed-derivation logic from scratch to verify my additional entropy sources would be combined correctly.”

Ez a paranoiás, több-forrásból származó entrópia-keverés mentette meg a vagyonát. A cikk szerzője szerint ez nem a felhasználó felelőssége, hanem az iparág csődje:

„It is absolutely ridiculous that this is the level of paranoid schizophrenia required to not lose your life savings. Nobody should have to do this. The immediate cause was a bug. The real cause is that our industry's standard advice puts people's entire savings behind a single device, and just hopes that its hardware, firmware, supply chain, and random number generator are all flawless, forever.”

A Bitcoin self-custody trilemma¶

Luke a Bitcoin self-custody jelenlegi helyzetét egy háromszög-trilemmával írja le, amelynek három csúcsa:

SECURE — biztonságos, ne lehessen egyetlen pont támadásával feltörni
EASY TO USE — használható legyen normál, nem tech-hozzáértő felhasználók számára is
TRUSTLESS — ne kelljen harmadik félben megbízni (sem gyártó, sem szolgáltató, sem kormányzat)

A trilemma állítása szerint jelenleg csak kettőt választhatsz meg a háromból, és nincs egyetlen önkiszolgáló megoldás sem, amely mindhármat egyszerre nyújtaná.

1. Singlesig (hot wallet vagy single hardware wallet)¶

A singlesig megoldás trustless és easy to use: egyetlen eszköz, egy érintés a költéshez, nincs szükség külső szereplőre. De nem biztonságos: egyetlen bug, egyetlen lopás, vagy egyetlen rossz backup a teljes vagyon elvesztéséhez vezethet. A Coldcard-áldozatok túlnyomó többsége ezen a háromszög-élen volt, és elvesztette az életmegtakarításait.

2. Multivendor multisig¶

A multivendor multisig (különböző gyártók eszközeit kombináló többszörös aláírású tárcák) biztonságos és trustless: a támadónak több, egymástól független eszközt kell kompromittálnia. De nem easy to use: több eszköz, több seed-backup, több biztonságos tárolási hely, több PIN, éves zarándoklatok a tárolók ellenőrzésére. Normál felhasználóknak ajánlani több pénzt veszít user error és lockout miatt, mint amennyit a hackerek ellopnak. A legtöbb ember számára nem reális opció.

3. Collaborative custody (Casa, Bitkey)¶

A collaborative custody megoldások (a Casa és a Bitkey az úttörők) biztonságosak és easy to use:

Casa a multisig-et tette elérhetővé normál felhasználók számára.
Bitkey még tovább ment: nincs seed phrase, a telefon csak egy limitált összegig költhet, amit a hardver-tárca előre engedélyezett. Csak a nagyobb tranzakciókhoz kell a hardver-tárca. Olyan hideg tárolás, ami úgy viselkedik, mint egy hot wallet.

De nem trustless: a szolgáltató tartja az egyik cosigning key-t és ellenőrzi a telefon-alkalmazás update-channelét, ami a második kulcsot tartja. Egy rosszindulatú alkalmazás-frissítéssel a szolgáltató két kulcshoz jut a háromból. A szerző hangsúlyozza, hogy nem gondolja, hogy ez valószínű, de felvet egy 6102-style esemény (a 6102-es végzés a pénzügyi eszközök lefoglalásáról) forgatókönyvet:

„Imagine a 6102-style event where private custody becomes illegal and companies are legally compelled to assist with seizure. Their employees aren't going to prison to protect my stack, nor should I expect them to.”

A 6102-style event a szerző kontextusában egy amerikai kormányzati akciót jelent, amelyben a törvény lehetővé teszi a magánszemélyek Bitcoin-készletének lefoglalását, és a szolgáltatók jogilag kötelezhetők a segítségnyújtásra. Aki el akarja kerülni ezt a kockázatot, annak a Casa és Bitkey nem megfelelő — de ha ez a fenyegetés abszurdnak tűnik, akkor ezek a legjobb opciók a piacon.

Az Anzen megoldás¶

Luke a cikk második felében egy saját fejlesztésű protokollt mutat be, az Anzen-t (japán eredetű szó, jelentése: „biztonság, nyugalom”). Az Anzen a három csúcsot egyszerre teljesíti:

„Anzen is designed to be extremely easy to use and very difficult to mess up, it's genuinely almost impossible to lose your money. It achieves equivalent security to a 2-of-3 multivendor multisig, yet feels as simple as using a hot wallet, and does so while remaining entirely trustless. No third parties required.”

Az Anzen vault script¶

Az Anzen egy vault-szerű konstrukció, amely kizárólag a Bitcoin script-rendszerére épül (nincs soft fork, nincs új opcode, nincs third-party cosigner, nincs szerver). A script meglepően egyszerű:

Phone + Hardware wallet    immediately
OR
Phone alone                after 14 months
OR
Hardware wallet alone      after 15 months

Phone + Hardware wallet együtt: azonnali költés
Phone egyedül, 14 hónap után: a telefon elvesztése esetén a felhasználó visszakapja a hozzáférést
Hardware wallet egyedül, 15 hónap után: a hardver-tárca elvesztése esetén a felhasználó visszakapja a hozzáférést

A 2 kulcs és 3 útvonal kombinációja biztosítja, hogy egyetlen kulcs elvesztése vagy kompromittálása nem jár a vagyon elvesztésével. A két kulcs független eszközön van (telefon + hardver-tárca), és az időzítések (14 hónap vs. 15 hónap) biztosítják, hogy a telefonnak mindig 1 hónap előnye van — ez a „race condition” a támadó ellen dolgozik.

Az Anzen működése: checking + savings analógia¶

Az Anzen a checking account + savings account banki analógiát használja:

A telefon a checking account (mindennapi költés)
A vault a savings account (hosszú távú megtakarítás)
A havi keret (monthly allowance) egy automatikus átutalás a savings-ből a checking-ba, minden hónapban azonos összeg, a hónap 1-jén
A vészhelyzeti hozzáférés (emergency access) egy nagy összegű átutalás, amely 1 hét késleltetéssel lép életbe, és bármikor visszavonható

A konkrét képességek:

Havi keretek (monthly allowances): minden hónapban egy előre meghatározott összeg válik elérhetővé, amelyet a telefon önállóan át tud vinni a hideg tárolóból a beépített hot walletbe.
Vészhelyzeti hozzáférés (emergency access): egy nagyobb összegű tranzakció a telefonról azonnal indítható, de 1 hét késleltetés után válik véglegessé, és bármikor visszavonható. Egy tolvaj, aki ellopja a telefont és elindítja, csak egy 1 hetes „alarm clock”-ot indít el, amelyet a felhasználó le tud állítani.
Visszavonások (revocations): minden előre engedélyezett keret azonnal és véglegesen visszavonható a pénzeszközök hideg tárolóba való visszahelyezésével.

Az éves szertartás (annual signing ceremony)¶

Évente egyszer, ideális esetben ugyanazon a naptári napon, a felhasználó újra jóváhagyja a vault policy-t a hardver-tárcáján. Ez a folyamat:

A telefon elkészíti a vault következő évére szóló tervet (12 havi keret + 12 visszavonás + vészhelyzeti csomag)
A hardver-tárca kijelzőjén a felhasználó egyetlen gombnyomással jóváhagyja az egész éves tervet (lásd lent a policy-képernyő szimulációját)
A telefon eltárolja az előre aláírt tranzakciókat (encrypted), és a következő 364 napban a hardver-tárca a fiókban marad

A vault policy képernyő a hardver-tárcán így nézhet ki:

Anzen
Annual policy

Vault balance
2.1 BTC

Monthly allowance
0.1 BTC

Emergency access
0.5 BTC (1-week delay)

Approve?
[Reject] [Approve]

Ez egyetlen gombnyomás az egész évre vonatkozó összes előre aláírt tranzakcióhoz (12 havi keret végrehajtás + 12 visszavonás + vészhelyzeti csomag: emergency trigger + emergency withdrawal + emergency cancellation + change back to vault).

Miért tartják az állítások¶

A szerző három konkrét állítást tesz, és mindegyiket részletesen megindokolja:

1. „Ugyanolyan biztonságos, mint egy 2-of-3 multisig”¶

Egy 2-of-3 multisignél a támadónak két eszközt kell kompromittálnia a háromból; a biztonság a két leggyengébb eszköz biztonságával egyenlő. Az Anzennél két teljesen független kulcsot kell kompromittálni, két teljesen független eszközön. Ez ugyanaz a biztonsági szint, kevesebb kezelendő dologgal. A 2-of-3-hoz hasonlóan túlél egy kulcs elvesztését vagy kompromittálódását. Az Anzen opcionális social recovery útvonalat is kínál mindkét eszköz elvesztése esetére — ez még erősebb védelem, mint egy 2-of-3 multisig.

A konkrét forgatókönyvek és azok kezelése:

Mi történik	Mit teszel	Mit kap a támadó
Telefon elveszett/törött/lopott	Restore from encrypted cloud backup	Zárolt telefon. Semmit.
Hardver-tárca elveszett/lopott	Élj a havi keretekből; a teljes vault-ot a telefon timelock-jének lejárta után kapod vissza	Zárolt eszköz. Semmit.
Telefon kulcs kompromittálódott	Restore from backup, visszavonod a függőben lévő tranzakciókat, új vault-ba költözöl	Maximum a telefon hot balance-ában lévő összeg
Hardver-tárca kulcs kompromittálódott	A telefonod unlock dátuma 1 hónappal előbb van; mozgasd a pénzt, megnyered a versenyt	Semmit, ha 1 hónapon belül cselekszel
Mindkét eszköz elveszett	Opcionális social recovery útvonal	—
Mindkét kulcs kompromittálódott, ugyanaz a támadó, ugyanabban az ablakban	Teljes veszteség (ugyanaz a korlát, amelyet minden top-tier setup elbukik)	Mindent

„You really have to try hard to lose your money with Anzen. As long as you don't walk down the street blindfolded, arms outstretched, unlocked phone in one hand, unlocked hardware wallet in the other, you should be good.”

2. „Trustless”¶

Nincs harmadik kulcs, nincs cosigning szerver, nincs vállalati update-csatorna, amely hatalmat adna a pénzed felett. Még a recovery mechanizmusok sem adnak hozzá bizalmi elemeket:

A cloud backup a telefonod kulcsa, a hardver-tárcád titkosítja, így csak a hardver-tárca tudja visszafejteni.
A social recovery egy másolatot ad a cloud-ba, amelyet egy megbízható kontakt kulcsával titkosítanak: ők nem tartanak semmit, és nem is tudják, hogy ők a recovery kontaktod, hacsak nem mondod el nekik. Csak akkor segítenek visszafejteni a cloud backupot, ha mindkét eszközöd elveszett. Még ekkor is a vault timelockjait ki kell várni.

A pénz mozgásának minden útja olyan Bitcoin script, amelyet elolvashatsz, vagy olyan tranzakció, amelyet a saját hardver-tárcád írt alá. Senkit nem lehet beperelni a tárcádba, mert senki más nincs benne.

3. „Easy to use”¶

Egy jól konfigurált policy mellett a hardver-tárca évente egy jóváhagyást igényel. Minden más műveletet a telefonról vezérelhetsz. Ez kevesebb erőfeszítés, mint egy singlesig hardver-tárca, ahol minden egyes költéshez kézbe kell venni az eszközt. Nap mint nap az Anzen megközelíti a hot mobil wallet-ek használhatóságát.

„De a pre-signed tranzakciók bonyolultan hangzanak”¶

A szerző elismeri, hogy a motorháztető alatt az éves szertartás a vaultot chunkokra osztja és gondosan strukturált pre-signed tranzakció-láncot ír alá. De ez sosem jut el a felhasználóhoz. Ez tisztán mérnöki probléma, és nagyon megoldható. Ahogy senkinek nem kell értenie a Diffie-Hellman kulcscseréhez az HTTPS használatához, senkinek nem kell értenie a presigned tranzakció-lánc kezeléséhez az Anzen vault policy jóváhagyásához.

A valódi szűk keresztmetszet a hardver: a mai hardver-tárcák egyetlen primitív köré épülnek: „írd alá ezt a tranzakciót”. Az Anzen számára szükséges primitív: „hagyd jóvá ezt a policy-t”. A telefon elkészíti a tervet, a hardver-tárca kijelzője plain language-ben mutatja az egész tervet. A vault policy képernyő a hardver-tárcán az Anzen számára az, mint a zöld lakat a böngészőben az HTTPS számára.

Hogyan tovább?¶

A protokoll nem csak ötlet: Luke-nak van egy működő mainnet prototípusa, valódi pénzzel, minden vault funkcióval és recovery útvonallal teljesen implementálva. Nem production-ready, nagyon korai, de szinte használható, ha kis összegekkel akarod tesztelni.

A repo nyilvános: github.com/lukechilds/anzen. Van egy kiterjedt end-to-end teszt suite regtest-en, és egy interaktív CLI, amely teljesen emulálja a telefont, a hardver-tárcát, és minden köztük zajló műveletet.

A szerző meghívja az olvasókat, hogy próbálják meg rug-pull-olni a saját mainnet vaultját:

bc1pvaultn3953ns47dw6rpm6ahfpz449vcnns5rpnr5v2d0u55fekxq39v257

A jövőbeli tervek között szerepel egy teljes stack reference implementation az Anzenhez, amely demonstrálja, milyen sima lehet az UX. Ez valószínűleg egy iPhone alkalmazás és egy egyedi, sideloadolható Ledger companion alkalmazás lesz.

A szerző célja, hogy mind a reference implementation-t, mind a nyílt Anzen protokollt fejlessze. Az ötlet az, hogy bárki implementálhatja a protokollt. Ha a reference implementation validálja a felhasználási esetet, és az emberek értéket látnak benne, akkor potenciálisan a jövőben láthatunk olyat, hogy:

Anzen vault vanilla Ledger-en, Ledger Live-val
Trezor mint hardver-tárca aláíró oldal, BlueWallet mint hot wallet oldal
Bitkey támogat egy opcionális szuverén módot, amely a cosigner-jüket az Anzen consensus-alapú alternatívájával helyettesíti

Az Anzen személyes side project, Umbrel-től független, nyílt forráskódú, MIT licenc.

Végső gondolatok¶

A szerző összegzi a legfontosabb tanulságot:

„The Coldcard situation is extremely sad because the Coldcard users did everything right. As far as I'm concerned, the industry standard recommendation was a singlesig hardware wallet. While this issue manifested as a firmware bug in the Coldcard, this is ultimately a catastrophic failure of the Bitcoin technical community. We have done users a disservice and failed to provide good high quality self-custody tools.”

A Coldcard-áldozatok mindent jól csináltak (vagy legalábbis azt, amit az iparág tanácsolt). Ez az iparág katasztrofális kudarca, nem a felhasználók hibája.

A cikk végén Luke három gyakori reakciót cáfol:

„A self-custody nem megfelelő a legtöbb felhasználó számára” — nem, a self-custody a megfelelő, de rossz eszközöket adunk a felhasználóknak.
„Mindenki multivendor multisig-be kellene menjen” — nem, mert az nem használható normál felhasználók számára.
„A felhasználó személyes felelőssége, hogy tájékozódjon a biztonságos entrópia-generálásról” — nem, ez nem reális elvárás.

„Bitcoin's scripting capabilities are limited, but they are not that limited. Vault-like constructs are criminally underexplored.”

A Bitcoin scripting képességei korlátosak, de nem ennyire korlátosak. A vault-szerű konstrukciók kriminálisan alulhasznosítottak. A cikk üzenete: van jobb megoldás, csak el kell kezdenünk használni.

Összegzés¶

A cikk négy legfontosabb tudományos hozzájárulása:

A Bitcoin self-custody trilemma — egy 3-csúcsú háromszög (secure, easy to use, trustless), amelyből csak kettőt választhatsz meg. A három jelenlegi megoldás mindegyike egy csúcsot feláldoz: a singlesig a biztonságot, a multivendor multisig a használhatóságot, a collaborative custody (Casa, Bitkey) a trustless jelleget.
A 6102-style seizure event kockázata — a collaborative custody megoldásoknál egy jövőbeli kormányzati akció, amely a szolgáltatókat jogilag kényszerítheti a lefoglalásban való közreműködésre. Ez strukturális kockázat, amely nem technikai, hanem politikai/jogi természetű.
Az Anzen vault-szerű konstrukció — egy Bitcoin-script-alapú megoldás, amely a 2-of-3 multisig biztonsági szintjét nyújtja a hot wallet használhatóságával, miközben teljesen trustless marad. A kulcsgondolat: két független kulcs (telefon + hardver-tárca) három útvonallal (azonnali, 14 hónap, 15 hónap), ahol a telefonnak mindig 1 hónap előnye van — ez a „race condition” a támadó ellen dolgozik.
A Bitcoin scripting alulhasznosítottsága — Luke érvelése szerint a Bitcoin script képességei korlátosak, de nem ennyire korlátosak. A vault-szerű konstrukciók „kriminálisan alulhasznosítottak”, és az iparág azonnal elkezdhetné a jobb self-custody eszközök építését anélkül, hogy új opcode-okra vagy soft forkokra várna.

A cikk üzenete: a Coldcard-áldozatok mindent jól csináltak (vagy legalábbis azt, amit az iparág tanácsolt), és ez az iparág katasztrofális kudarca, nem a felhasználók hibája. Az Anzen egy konkrét példája annak, hogy a Bitcoin scriptinggel jobb megoldások építhetők, és a jövő a nyílt protokoll-alapú, auditható, trustless self-custody eszközöké — nem a felhasználó paranoiájától, hanem a rendszer biztonsági garanciáitól függő.

Forrás¶

Cikk forrása: Luke Childs, lu.ke/self-custody-trilemma (2590 szó, public, nincs paywall)
PubDate: 2026-08-08 (péntek, a Coldcard exploit hetében)
Szerző: Luke Childs (szoftverfejlesztő, Umbrel-munkatárs, github.com/lukechilds, a cikkhez kapcsolódó Anzen protokoll szerzője)
Anzen repo: github.com/lukechilds/anzen (MIT licenc, mainnet prototípus valódi pénzzel, end-to-end teszt suite regtest-en)
Anzen mainnet vault: bc1pvaultn3953ns47dw6rpm6ahfpz449vcnns5rpnr5v2d0u55fekxq39v257
Hivatkozott projektek: Coldcard (Coinkite), Bitkey (Block), Casa, Liana
Kapcsolódó epizód-összefoglalók a wikiben:
UGMF Freedom Tech Friday 51 (2026-08-07): tracking-the-coldcard-exploit-with-orange-surf
TFTC 780 (2026-08-05): dissecting-coldcard-hack-alex-thorn
POD256 epi-122 (2026-08-04): weak-entropy-coldcard-fallout
Topic-first mapping:
Primary: bitcoin-pleb-values.md (self-custody, szuverenitás, trustless, ideológiai sík)
Secondary: bitcoin-wallet-security.md (technikai vault, Anzen protokoll, 2-of-3 egyenértékűség)
Tertiary: bitcoin-lightning-and-tech.md (Bitcoin scripting, presigned tranzakciók, vault-szerű konstrukciók)
Feldolgozás: Fő agent (Henky-pipeline, < 5000 szó kategória, 2026-08-08)