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

> **Forrás:** [lu.ke/self-custody-trilemma](https://lu.ke/self-custody-trilemma) (Luke Childs, 2590 szó)
> **Szerző:** Luke Childs (szoftverfejlesztő, Umbrel-munkatárs, [github.com/lukechilds](https://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:

1. **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.
2. **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.
3. **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:

1. A telefon elkészíti a vault következő évére szóló tervet (12 havi keret + 12 visszavonás + vészhelyzeti csomag)
2. 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)
3. 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:

1. **„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**.
2. **„Mindenki multivendor multisig-be kellene menjen”** — nem, mert az **nem használható** normál felhasználók számára.
3. **„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:

1. **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.

2. **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ű.

3. **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.

4. **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](https://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](https://github.com/lukechilds), a cikkhez kapcsolódó Anzen protokoll szerzője)
- **Anzen repo:** [github.com/lukechilds/anzen](https://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](../ungovernable_misfits/2026-08-07_ugmf_ftf51_coldcard_exploit_orange_surf.md)
  - TFTC 780 (2026-08-05): [dissecting-coldcard-hack-alex-thorn](../tftc/2026-08-05_tftc_780_dissecting_coldcard_hack_alex_thorn.md)
  - POD256 epi-122 (2026-08-04): [weak-entropy-coldcard-fallout](../pod256/2026-08-04_pod256_122_weak_entropy_coldcard_fallout.md)
- **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)