# Open Bitcoin Metrics: Verifiable Full-Node-Derived Bitcoin Time Series for Economic Research **Szerző:** Diego R. Llanos (Department of Computer Science, University of Valladolid, Spain) **Dátum:** 2026-07-03 (arXiv submission) **arXiv ID:** 2607.03124v1 **URL:** https://arxiv.org/html/2607.03124v1 **GitHub:** https://github.com/diegorllanos/open-bitcoin-metrics **Keywords:** Bitcoin; on-chain data; time series; Bitcoin full node; reproducibility; econometrics; open data **DOI:** Zenodo (a paper végén) **Wiki raw:** raw/papers/2026-07-15_open_bitcoin_metrics_arxiv_2607_03124.md ## Epizód áttekintés A paper az **Open Bitcoin Metrics (OBM)** datasetet és reference guide-ot mutatja be, amely reproducibilis, full-node-derived Bitcoin on-chain time series-t biztosít gazdasági és ökonometriai kutatásokhoz. A 23 OBM metrika dokumentálva van, nyílt forráskódú Python kóddal, stabil azonosítókkal, explicit definíciókkal, validációs eljárásokkal és összehasonlításokkal a legközelebbi publikus metrikákkal. A 23 metrika négy fő kategóriába sorolható: (1) **blokk és tranzakció** (block_count, block_weight, tx_count, supply, issuance, fees, miner_revenue, difficulty, est7d_hashrate, fee_share_revenue_ratio), (2) **UTXO és supply** (utxo_eod_count, supply, spent_output_count, raw_output_value, spent_value_btc és korspecifikus változatai), (3) **monetáris** (issuance, fees, miner_revenue, supply), (4) **coin-age** (cdd, cdd_age_band, cdd_per_supply, dormancy, liveliness, spent_value_age_band). Az OBM dataset célja: a "don't trust, verify" Bitcoin ethosz kiterjesztése az empirikus metrikákra. A dataset teljes mértékben reprodukálható: bárki, aki futtat egy Bitcoin Core full node-ot és klónozza a GitHub repository-t, pontosan ugyanazt a datasetet állíthatja elő. --- ## 1. rész **Cikk:** *Open Bitcoin Metrics: Verifiable Full-Node-Derived Bitcoin Time Series for Economic Research* **Szerző:** Diego R. Llanos (University of Valladolid, Spanyolország) **Dátum:** 2026-07-03 **arXiv azonosító:** 2607.03124v1 **GitHub:** https://github.com/diegorllanos/open-bitcoin-metrics **Ez a rész:** Abstract + 1. Bevezetés + a 23 OBM-metrika felsorolása + 2. Related Work (kapcsolódó irodalom) + a 3. Methods (módszertan) nagy része --- ## 1. Absztrakt és a projekt célja A kutatási kérdés, amire a cikk választ ad, nagyon gyakorlatias: a Bitcoin gazdasági, monetáris és ökonometriai vizsgálatához egyre több kutató használ láncon belüli (on-chain) idősorokat — kibocsátás, tranzakciós díjak, bányász-bevételek, coin-age mutatók, UTXO-állapot, hosszú távú monetáris dinamika. Ezek az idősorok azonban jellemzően **szétszórva** érhetők el: fizetős adatszolgáltatóknál, blokkfelfedező (block explorer) oldalakon, illetve kereskedelmi platformokon. Még ha a kirajzolt grafikon vagy letölthető CSV ingyenes is, a definíció, az időbélyeg-konvenció, a szélsőséges esetek kezelése és az újraszámítás algoritmusa gyakran **nincs teljesen dokumentálva**. Erre a problémára kínál megoldást az **Open Bitcoin Metrics (OBM)** projekt: egy reprodukálható, teljes csomópontból (full node) származtatott Bitcoin on-chain idősor-adathalmaz és referencia-kézikönyv, amelyet kifejezetten közgazdasági és ökonometriai kutatásokhoz terveztek. A szerző a Bitcoin „don't trust, verify” (ne bízz, ellenőrizd) mottóját az empirikus mutatókra is kiterjeszti: a felhasználó ne fogadja el vakon egy zárt szolgáltató grafikonját, hanem legyen lehetősége maga is újrafuttatni a számítást. Az OBM három konkrét célt tűz ki: 1. **Ökonometriára kész idősorok** biztosítása stabil azonosítókkal, explicit mértékegységekkel, rendszeres gyakorisággal és dokumentált aggregációs szabályokkal. 2. Az egyes metrikák **rekonstrukciós algoritmusának** publikálása, hogy a számítás függetlenül megismételhető legyen elsődleges blokklánc-adatokból vagy más OBM-sorokból. 3. **Összehasonlíthatóság, bővíthetőség, auditálhatóság**: a forráskód, a kimeneti fájlok, a metaadatok, az ellenőrző eljárások és a metrika-szintű referencia mind nyilvánosak. Az öt legfontosabb tudományos hozzájárulás: - az OBM mint reprodukálható, teljes csomópontból származtatott adathalmaz, - egy részletes metrika-szintű referencia-kézikönyv (definíció, közgazdasági értelmezés, adatforrás-igény, algoritmus, validáció, formátum, korlátok, nyilvános összehasonlító források), - egy újrahasználható **spent-output indexelő** adatfeldolgozó folyamat, amely a korábbi tranzakció-kimeneteket (previous output) rekonstruálja a díjak, kibocsátás, bányászbevétel, elkölött érték, CDD, dormancy és UTXO-kor szerinti mutatók számításához, - egy átlátható **referencia-alap**, amellyel a szolgáltató-specifikus metrikák összevethetők, - a Bitcoin verifikációs ethoszának kiterjesztése az empirikus kutatásra. A tervezési elvek a cikk szerint: elsődleges forrásból származtatás, átlátható definíciók, ökonometriai használhatóság, verziózott reprodukálhatóság, validáció, és verifikáció-orientált nyitottság. Fontos hangsúly: az OBM **nem** akarja kiváltani a kereskedelmi adatszolgáltatókat (amelyek szélesebb lefedettséget, finomabb felületet, magasabb frekvenciát, entitás-korrigált mutatókat és piaci elemzéseket kínálnak), hanem **kiegészíti** azokat egy transzparens, auditálható alapsorral. ## 2. Bevezetés — miért van szükség ilyen adathalmazra? A Bitcoin-kutatás mára túlnőtt a tisztán informatikai megközelítésen: a közgazdaságtan, a pénzügytan, a monetáris elméletek és az informatika határterületén is intenzív empirikus irodalom épül. Ezek a tanulmányok speciális on-chain idősorokat igényelnek, amelyek a szokásos makro-pénzügyi adatbázisokból (FRED, Bloomberg stb.) nem érhetők el. A probléma: ha két, látszólag azonos nevű idősor (pl. „daily transaction fees”) eltérő értékeket mutat, annak oka lehet - eltérő időbélyeg-konvenció (medián idő vs. blokk-idő, UTC-határ kezelése), - a lánc-átszervezés (reorg) más-más kezelése, - entitás-klaszterezési heurisztikák (címkiosztás), - simítási ablakok, - az „elküldött érték” definíciója. Kis definíciós eltérések is **anyagilag érzékelhető** ökonometriai eltéréseket okozhatnak, különösen a Bitcoin korai időszakában, a napi határok közelében, illetve az UTXO-kor alapú metrikáknál (pl. Coin Days Destroyed). Az elsődleges, auditálható forrás maga a blokklánc, amit egy **teljesen szinkronizált Bitcoin Core csomóponton** keresztül lehet elérni. A teljes csomópont (full node) lehetővé teszi a főág ellenőrzését, a blokk- és tranzakció-adatok kiolvasását, valamint a korábbi kimenetek rekonstrukcióját. Ez maximalizálja az auditálhatóságot, de számítási költséggel és metrika-specifikus szoftver-fejlesztéssel jár. ## 3. Kapcsolódó munkák (Related Work) — 1. táblázat A cikk 1. táblázata 13 fő nyilvános Bitcoin-idősor forrást hasonlít össze, és mindegyikhez hozzárendeli az **auditálhatósági szintet** (magas / közepes / alacsony) és az **hozzáférési modellt** (ingyenes / freemium / előfizetéses): | Forrás | Tartalom | Hozzáférés | Auditálhatóság | |---|---|---|---| | **Bitcoin Core Project** | Elsődleges blokk- és tranzakció-adat, teljes csomópont, RPC. | Ingyenes, nyílt forráskód | **Magas** — a lánc-hatóság, de egyetlen OBM-metrikát sem ad közvetlenül | | **mempool.space** | Nyílt forráskódú explorer, REST/WebSocket API, mempool, fee, bányaadatok. | Ingyenes + enterprise | Közepes–magas (a kód nyílt, de a napi OBM-sorok nincsenek előre csomagolva) | | **Coin Metrics** | Hálózati metrikák: blokkszám, supply, díjak, bányászbevétel, coin-age mutatók. | Freemium | Közepes — azonosítók és definíciók dokumentáltak, a rekonstrukciós kód nem | | **Blockchair** | Explorer, SQL-szerű API, adatbázis-letöltések. | Freemium | Közepes — a nyers adat elérhető, de a chart-definíciók tömörek | | **Glassnode** | Széles on-chain, piaci, származékos, entitás-korrigált metrikák. | Freemium | Közepes–alacsony — a heurisztikák nem reprodukálhatók | | **CryptoQuant** | UTXO, bányász, tőzsde, hálózati, értékelési metrikák. | Freemium | Közepes–alacsony | | **Blockchain.com** | Publikus chartok, explorer, chart-endpointok. | Ingyenes (sok chart) | Közepes–alacsony — a módszertan rövid | | **Bitbo** | On-chain, piaci, makro indikátorok. | Freemium | Közepes–alacsony | | **Newhedge** | On-chain és értékelési metrikák, API. | Freemium–előfizetés | Közepes–alacsony | | **BitInfoCharts** | Hálózati statisztikák, több kriptovaluta. | Ingyenes | Alacsony | | **YCharts** | Pénzügyi chart-platform, gyakran a Blockchain.com-ból veszi át. | Előfizetéses | Alacsony | | **Bitcoin Magazine Pro** | Coin-age és értékelési indikátorok. | Freemium | Alacsony | | **Checkonchain** | Piaci ciklus, élettartam, supply, értékelés. | Ingyenes | Alacsony–közepes | | **Trading Digits** | Piaci ciklus és realized-price indikátorok. | Ingyenes | Alacsony | A szerző fontos distinkciót tesz: **hozzáférhetőség ≠ auditálhatóság**. Egy metrika lehet nyilvánosan látható, de nehezen auditálható, ha a szolgáltató nem teszi közzé a teljes rekonstrukciós eljárást. Fordítva: a nyers blokk- és tranzakció-adat teljesen auditálható, de közgazdászok számára kényelmetlen, amíg valaki nem alakítja át rendszeres, dokumentált, ökonometriára kész idősorokká. ## 4. Az OBM 23 metrikája (a cikk 4. fejezetének és A. függelékének felsorolása) Az adathalmaz 23, napi gyakoriságú idősort tartalmaz. Mindegyikhez tartozik stabil azonosító, explicit definíció, algoritmus, validáció és nyilvános összehasonlító forrás. A metrikák négy nagy csoportba sorolhatók: **Blokk- és tranzakció-szintű metrikák:** - `obm_block_count_daily` — napi blokkszám - `obm_block_weight_wu_daily` — napi blokksúly weight unitban (WU) - `obm_tx_count_daily` — napi tranzakció-szám - `obm_raw_output_value_btc_daily` — nyers kimeneti érték BTC-ben **UTXO-állapot és supply:** - `obm_utxo_eod_count_daily` — nap végi UTXO-szám - `obm_supply_btc_daily` — napi Bitcoin-kínálat (BTC) **Bányászat és monetáris dinamika:** - `obm_difficulty_eod_daily` — nap végi bányászati nehézség - `obm_est7d_hashrate_ehs_daily` — becsült 7 napos hálózati hashrate EH/s-ban - `obm_issuance_btc_daily` — napi kibocsátás BTC-ben - `obm_fees_btc_daily` — napi tranzakciós díjak BTC-ben - `obm_miner_revenue_btc_daily` — napi bányászbevétel BTC-ben - `obm_fee_share_revenue_ratio_daily` — díjak aránya a bányászbevételben **Coin-age / UTXO-kor mutatók (a cikk legérdekesebb része):** - `obm_spent_output_count_daily` — napi elkölött kimenetek száma - `obm_spent_value_btc_daily` — napi elkölött kimenetek értéke BTC-ben - `obm_spent_value_age_band_btc_daily` — elkölött érték kor-sávok szerint - `obm_spent_value_ge155d_btc_daily` — 155 napnál idősebb outputok elkölött értéke - `obm_spent_value_ge365d_btc_daily` — 365 napnál idősebb outputok elkölött értéke - `obm_spent_value_lt155d_btc_daily` — 155 napnál fiatalabb outputok elkölött értéke - `obm_cdd_btcxdays_daily` — Bitcoin Days Destroyed (BTC×nap) - `obm_cdd_age_band_btcxdays_daily` — CDD kor-sávok szerint - `obm_cdd_per_supply_days_daily` — CDD per unit of supply (nap) - `obm_dormancy_days_daily` — napi dormancy - `obm_liveliness_ratio_daily` — napi liveliness arány A „155 nap” és „365 nap” küszöbök a Bitcoin-ökoszisztémában elterjedt rövidtávú / hosszú távú tartó (STH/LTH) definíciókra utalnak, és a spent_value-metrikákban az adott korhatárnál idősebb vagy fiatalabb outputok aggregált viselkedését mérik. ## 5. Az adat-előállítási folyamat (Methods, 3. fejezet) ### 5.1 Kétféle idősor: elsődleges és származtatott Az OBM két típusú idősorból építkezik: - **Elsődleges (primary) sorok** — közvetlenül a Bitcoin blokkláncból származnak, egy lokálisan futtatott Bitcoin Core teljes csomópontról. Egyszerűbb metrikák (pl. napi blokkszám, tranzakció-szám) csak a blokk-metaadatokból számíthatók. Összetettebbek (CDD, spent value, díjak, kibocsátás, bányászbevétel) **korábbi tranzakció-kimenetek rekonstrukcióját** igénylik, ehhez szolgál a perzisztens spent-output indexelő. - **Származtatott (derived) sorok** — determinisztikus transzformációk már meglévő OBM-sorokon. Például a bányászbevételen belüli díj-rész a napi díjak és a napi realizált kibocsátás hányadosa, a supply pedig a napi kibocsátás kumulált összege. Ezek nem hívnak Bitcoin Core-t, csak OBM CSV-fájlokat olvasnak. ### 5.2 A teljes csomópont konfigurációja A cikk kiemeli, hogy a reprodukálhatósághoz a konfigurációt is dokumentálni kell: - **Bitcoin Core verzió:** 30.2 - **Hálózat:** mainnet - **Indexelés:** `txindex=1` - **Pruning:** kikapcsolva (a spent-output metrikákhoz a teljes lánc kell) - **Operációs rendszer:** Ubuntu 22.04.5 LTS - **Frissítési ütem:** napi A node-ot a Bitcoin Core saját **JSON-RPC interfészén** keresztül érik el, cookie-alapú vagy explicit RPC-hitelesítéssel. A scriptek kizárólag a lokálisan ellenőrzött főágat használják — nem támaszkodnak explorerre vagy fizetős API-ra. ### 5.3 Idő-konvenció és aggregáció Alapértelmezés szerint a napi sorok **UTC (Coordinated Universal Time)** szerinti naptári napra vannak aggregálva. Egy `b` blokk a `d(b) = UTCDate(t_b)` szabály alapján kap dátumot, ahol `t_b` a Bitcoin Core által visszaadott blokk-időbélyeg. A cikk jelzi, hogy a Bitcoin blokk-időbélyegek **nem szigorúan monotonok** a blokk-magasság szerint, ezért a scriptek egy biztonsági margóval kibővített magasság-intervallumot használnak, hogy ne maradjanak ki határ-blokkok. Az aggregáció fajtája a metrika közgazdasági jelentésétől függ: - **Flow-változók** (díjak, kibocsátás, bányászbevétel, spent value, CDD) → napi **összeg**, - **Stock-változók** (pl. supply) → időszak végi vagy kumulált érték, - **Arányváltozók** (pl. fee share) → a releváns napi számláló és nevező hányadosa, nem pedig alacsonyabb szintű arányok átlaga. Havi verzióknál a napi értékekből indulnak ki: havi flow-k a napi flow-k összege, havi arányok a havi összetevők hányadosaként (és nem a napi arányok számtani átlagaként) számítandók, hacsak a metrika másképp nem definiálja. ### 5.4 A spent-output indexelő (az architektúra kulcseleme) Több OBM-metrika (díjak, spent value, CDD, dormancy, long-term-holder spent value) olyan információt igényel, ami **egyetlen blokkból közvetlenül nem olvasható ki** — a tranzakció inputjai a Bitcoin **UTXO-modelljében** korábbi tranzakció-kimeneteket költenek el, és minden ilyen korábbi kimenet értékét és létrehozási idejét ismerni kell. Ezt a problémát oldja meg az `obm_spent_output_indexer.py` nevű script, amely a láncot magasság szerint pásztázza, és egy lokális **SQLite**-adatbázisban tartja fenn az aktuális outpoint-állapotot. Az adatbázis kulcsa a `(txid, vout)` pár, és minden élő (még el nem költött) outputhoz tárolja: - az értéket satoshiban, - a létrehozás időbélyegét, - a létrehozás magasságát. Amikor egy későbbi tranzakció inputja elkölt egy outpointot, az indexelő: 1. kiolvassa az értéket és a létrehozási időt, 2. frissíti a napi aggregátumokat, 3. törli az outpointot az élő táblából. A tábla tehát az aktuális UTXO-szerű állapotot tartja fenn (nem a teljes történeti naplót), ami a jövőbeli input-feloldáshoz kell. **Kor és CDD számítása.** Minden `i` elköltt inputra az indexelő kiszámolja a `V_i` (előző kimenet értéke), `t_i^create` (létrehozás ideje) és `t_i^spend` (elköltség ideje) értékeket, majd az életkort napokban: ``` A_i = max(0, (t_i^spend − t_i^create) / 86400) ``` A `max(0, ...)` azért kell, mert a Bitcoin blokk-időbélyegek nem szigorúan monotonok — néha egy input „későbbi” blokkban költ el egy „korábbi” blokkban létrehozott outputot, ami negatív nyers életkort adna. Az OBM ezeket nullára floor-olja, és a metaadatokban rögzíti az eseményszámot. A CDD (Coin Days Destroyed) járuléka input-szinten: ``` CDD_i = V_i × A_i ``` amit az indexelő belül **satoshi-day** egységben tárol, és az export scriptek váltják át **BTC × day** egységbe (10^8-cal osztva). **Díjak számítása.** Minden nem-coinbase `j` tranzakcióra: ``` F_j = V_j^in − V_j^out ``` A blokk teljes díja az `F_j` összege a blokk összes nem-coinbase tranzakciójára. A coinbase kimenet összértéke a blokk teljes BTC-bányászbevétele (új kibocsátás + díjak). Ebből a realizált kibocsátás: ``` Issuance_b = CoinbaseOutput_b − Fees_b ``` Ez a definíció szétválasztja az új BTC-t (issuance) és a felhasználóktól a bányászokhoz már létező BTC-ként átfolyó díjakat. **Napi aggregátum-tábla.** Az indexelő az alábbi napi összesítéseket tárolja minden UTC-napra (ahol volt blokk-tevékenység): - teljes elkölött kimeneti érték, - elköltt kimenetek száma, - Bitcoin Days Destroyed, - az életkorok összege, - 365+ napos outputok elköltt értéke és CDD-je, - 155+ napos outputok elköltt értéke és CDD-je, - 155 napnál fiatalabb outputok elköltt értéke és CDD-je, - teljes tranzakciós díjak, - teljes coinbase output érték, - realizált kibocsátás, - nullára floor-olt negatív-életkorú outpointok száma. **Kor-sávok.** A jelenlegi sávok: 0d–1d, 1d–1w, 1w–1m, 1m–3m, 3m–6m, 6m–1y, 1y–2y, 2y–3y, 3y–5y, 5y–7y, 7y–10y, 10y+. Minden dátum–sáv kombinációra az indexelő tárolja az elköltt értéket, a CDD-t és az elköltt kimenetek számát. Ezekből a táblákból később kor-disztribúciós metrikák exportálhatók anélkül, hogy másodszor is végig kellene pásztázni a teljes láncot. **Perzisztencia és újraindíthatóság.** Az indexelő **resumable**: egy meta-táblában tárolja az utoljára feldolgozott blokk magasságát, hash-ét, időbélyegét és dátumát. Újraindításkor az utolsó commitált magasság utáni blokktól folytatja, de előtte **ellenőrzi**, hogy a tárolt utolsó hash megegyezik-e a Bitcoin Core által ugyanott jelentett hash-sel. Ha nem egyezik, a script **nem próbál automatikus rollback-et**, hanem leáll — ezzel elkerüli, hogy inkoherens lánc-állapotokból származó adatok keveredjenek. A tranzakciók commitolása egy konfigurálható `--commit_every` paraméterrel szabályozható, ami hosszú történeti build-ek esetén lehetővé teszi a megszakítást és az onnan való folytatást. **Korai Bitcoin sajátosságok.** Az early Bitcoin tartalmaz kivételes duplikált `(txid, vout)` párokat. Amikor az indexelő ilyen duplikált élő outpointtal találkozik, a korábbi bejegyzést felülírja a későbbivel, és a metaadatokban rögzíti az eseményt. A felülírt output nem számít elköltöttnek, így nem generál spent value-ot vagy CDD-t. Ez a konvenció a ritka történeti szélsőséges esetek kezelését dokumentálja. ### 5.5 Metrika-export scriptek és a származtatott pipeline Az OBM szétválasztja a közös indexelést és a metrika-specifikus exportot. A spent-output indexelő belső SQLite-adatbázist állít elő, és **külön exporter scriptek** olvassák ki az aggregátum-táblákból a szabványos OBM CSV-fájlokat. Például: - `obm_cdd_btcxdays_daily` a napi CDD-aggregátumból exportálódik, - `obm_issuance_btc_daily` a napi kibocsátás-aggregátumból. Ennek az architektúrának három előnye van: 1. A drága spent-output rekonstrukciót csak **egyszer** kell elvégezni. 2. A metrika-specifikus scriptek egyszerűek és auditálhatók maradnak. 3. Ugyanaz az indexelő-adatbázis további jövőbeli metrikákat is támogathat (dormancy, bináris CDD, spent-output count, long-term-holder / short-term-holder spent value, age-band CDD). A cikk jelzi, hogy egyes dátumoknál — különösen a legkorábbi Bitcoin-periódusban — előfordulhat, hogy az indexelő nem hoz létre aggregátum-sort, mert az adott UTC-napra nem esik blokk a blokk-időbélyeg-konvenció szerint. Az export scriptek ezekre az esetekre metrika-specifikus „hiányzó dátum” szabályokat alkalmaznak. --- ## 6. Összegzés és a rész határai Ez a rész az OBM-projekt **bevezető és módszertani gerincét** tárgyalja: a problémafelvetést (a Bitcoin on-chain metrikák reprodukálhatatlansága), a 13 fő nyilvános forrás összehasonlítását, a 23 OBM-metrika felsorolását és az adat-előállítási architektúrát (Bitcoin Core teljes csomópont + perzisztens spent-output indexelő + metrika-specifikus export scriptek). A későbábbi részek a cikk valószínűleg a következőket részletezik: - a 23 metrika egyenkénti definícióját, képleteit, közgazdasági értelmezését, validációját és a nyilvános összehasonlító forrásait (4. fejezet és A. függelék), - a konkrét adatrekordokat, használati megjegyzéseket, kód- és adat-elérhetőséget (5–7. fejezet), - a korlátokat, a jövőbeli munkát és a teljes referencialistát (8–11. fejezet + irodalomjegyzék). A legfontosabb üzenet, amit a rész hordoz: az OBM nem egy újabb fizetős adatszolgáltató, hanem egy **auditálható, nyílt forráskódú referencia-alap**, amelyen a kereskedelmi szolgáltatók metrikái összevethetők, és amelyből a közgazdász-kutató maga is reprodukálhatja a számításait — a Bitcoin saját verifikációs ethoszát követve. --- ## 2. rész Ez a technikai összefoglaló Diego R. Llanos „Open Bitcoin Metrics” című arXiv-tanulmányának második részét dolgozza fel. Az első rész (1. rész) az absztraktot, a bevezetést, a 23 OBM-metrika listáját és a Related Work fejezet elejét tartalmazta. Ez a rész a Methods fejezet utolsó alfejezeteivel (3.5–3.6) folytatódik, majd a 4. fejezet (Description of OBM available metrics) első tizenöt metrikáját mutatja be részletesen. A szöveg leginkább referencia-kézikönyvként funkcionál: minden egyes metrikánál ismerteti a definíciót, a közgazdasági jelentést, a gyakori értelmezési csapdákat, valamint a legközelebbi publikus komparátorokat (Coin Metrics, Glassnode, CryptoQuant stb.). ## 1. A Methods fejezet lezárása (3.5–3.6) ### Hiányzó értékek és származtatott metrikák kezelése (3.5) A szerző kiemeli, hogy az OBM kétféle változót különböztet meg a hiányzó értékek (missing values) kezelésében: - **Flow változók** (pl. kibocsátás, díjak, bányászbevétel, CDD, elköltött érték): ha egy aggregált sor hiányzik, a rendszer **nullát** exportál. - **Arányszám-változók** (pl. dormancy, fee share): ha a nevező nulla, az érték **hiányzóként** (NaN) jelenik meg, nem nullaként. Ez azért fontos, mert így a rendszer nem rendel gazdasági jelentést egy értelmezhetetlen hányadoshoz. Más OBM-sorok már publikált CSV-fájlokból származnak, nem közvetlenül az indexer adatbázisából. Például a fee share of miner revenue a következőképpen számítódik: `FeeShare_d = FeesBTC_d / (Issuance_d + FeesBTC_d)` Ez a kialakítás biztosítja, hogy a származtatott metrikák kizárólag publikus CSV-fájlokból reprodukálhatók legyenek, az indexer pedig belső forrásként szolgáljon a primitív és fél-primitív aggregátumokhoz. ### Változó-elnevezési konvenció (3.6) Minden idősor stabil azonosítót kap a következő formában: `obm___` - Az **obm_** előtag azonosítja az Open Bitcoin Metrics adatbázist. - A kisbetűs, snake-case azonosítók kompatibilisek a Pythonnal, R-rel, Statával, SQL-lel és CSV-munkafolyamatokkal. - Példák: `obm_tx_count_daily`, `obm_cdd_btcxdays_daily`, `obm_fee_share_revenue_ratio_daily`. - Az egység explicit szerepel az azonosítóban: `btc` (BTC-ben denominált mennyiség), `btcxdays` (BTC-napok), `ratio` (dimenziómentes arány). - A záró komponens a megfigyelés gyakoriságát jelöli (pl. `daily`). Ez a konvenció egyszerre teszi az azonosítókat explicit módon értelmezhetővé és kompatibilissé a gyakori adatelemző környezetekkel. ## 2. A 4. fejezet szerkezete A 4. fejezet célja nem a teljes referencia-kézikönyv megismétlése, hanem az egyes OBM-sorok **tömör értelmezése**: mit mérnek, mit ne mérjenek velük, és hogyan használhatók empirikus Bitcoin-kutatásban. A metrikák a következő területeket fedik le: - blokktermelés és blokktér-használat, - coin-age viselkedés, - bányászati nehézség és becsült hashrate, - bányászbevétel és kompenzáció, - monetáris kibocsátás és kínálat, - tranzakció- és UTXO-aktivitás, - valamint életkor szerinti elköltési indikátorok. A teljes matematikai definíció, validáció és korlátok az A. függelékben találhatók. A 4.1–4.15 szakaszokból a következő metrikák kerülnek részletes bemutatásra. ## 3. A metrikák részletes ismertetése (4.1–4.15) ### 4.1 `obm_block_count_daily` — Napi blokkszám Az egyes UTC-naptári napokhoz rendelt Bitcoin-blokkok száma. Hosszú távon a benchmark ~144 blokk/nap (10 perces átlagos blokkintervallum), de a valós érték a valószínűségi blokkfelfedezés, a diszkrét nehézség-állítás és a naptári határokhoz nem illeszkedő időbélyegek miatt ingadozik. **Gazdasági jelentése:** a *megvalósult blokktermelés* mérőszáma, nem pedig a tranzakciós kereslet közvetlen indikátora. Fő értéke kontextuális: segít értelmezni más napi aggregátumok (pl. alacsony tranzakciószám, díjtotal) ingadozásait, és természetes normalizáló változó a blokkszintű sorokhoz. A legközelebbi publikus komparátor a Coin Metrics `BlkCnt` sorozata. ### 4.2 `obm_block_weight_wu_daily` — Napi blokksúly weight unitban Az egyes UTC-napokhoz rendelt blokkok teljes blokksúlya. A SegWit kapacitásszabálya weight unitban (WU) kifejezett, ezért ez a modern Bitcoin-elemzéshez illeszkedő blokktér-metrika. Napi összeg, nem átlag. A magas napi blokksúly jelezhet több blokkot, telítettebb blokkokat, vagy mindkettőt — ezért különösen informatikus a `obm_block_count_daily` sorral együtt használni. Származtatott mutatók alapja lehet (pl. átlagos blokksúly, díj per weight unit). Legközelebbi komparátor: Coin Metrics `BlkWghtTot`. ### 4.3 `obm_cdd_age_band_btcxdays_daily` — Napi CDD életkor-sávok szerint A napi Bitcoin Days Destroyed (CDD) széles táblázat formájában, ahol minden oszlop egy-egy output-életkor sávnak felel meg (pl. `0d_1d`, `1d_1w`, `1y_2y`, `10y+`). Minden bejegyzés az adott korosztályba tartozó outputok által megsemmisített BTC-napokat mutatja az adott UTC-dátumon. **Gazdasági jelentése:** az aggregált CDD elfedheti a viselkedésbeli különbségeket — egy nagy CDD-érték származhat közepesen idős coinok tömeges mozgásából vagy nagyon régi, évek óta inaktív coinok kisebb volumenű mozgásából. Az életkor-sávos bontás láthatóvá teszi ezt a különbséget. Különösen hasznos alvó kínálat aktivációjának, hosszú távú tulajdonosi viselkedésnek, disztribúciós epizódoknak és wallet-konszolidációnak a vizsgálatában. A legközelebbi nyilvános életkor-eloszlási komparátor a CryptoQuant Spent Output Age Bands, de ez BTC-értéket, nem BTC-napokat jelent. ### 4.4 `obm_cdd_btcxdays_daily` — Bitcoin Days Destroyed A klasszikus coin-age metrika: minden elköltött output BTC-értéke szorozva a keletkezése és elköltése között eltelt napok számával. Az egység BTC-nap. **Gazdasági intuíció:** 1 BTC 100 napos tétlenség utáni elköltése 100 BTC-napot semmisít meg; a frissen létrehozott outputok elköltése alig számít. A CDD tehát nagyobb súlyt ad a régebbi coinok mozgásának. **Fontos korlát:** nem fizetési volumen, nem tőzsdei volumen, nem felhasználószám, nem entitás-korrigált gazdasági settlement. Nyers spent-output metrika, amely tükrözhet self-transzfert, wallet-átszervezést, custodiális aktivitást is. A legközelebbi komparátor a Coin Metrics `TxTfrValDayDst` (Xfer'd Days Destroyed), de a teljes egyezés nem várható el: a Coin Metrics teljes napos számítást használ, míg az OBM tört napos számítást (86 400 másodperces osztással). ### 4.5 `obm_cdd_per_supply_days_daily` — CDD per kínálategység A napi CDD normalizálva az ugyanazon a napon fennálló Bitcoin-kínálattal. Két OBM forrássorból determinisztikusan származik: `obm_cdd_btcxdays_daily` és `obm_supply_btc_daily`. Az eredmény egysége **nap**. A 0,015 érték például azt jelenti, hogy az adott napon megsemmisített coin age a forgalomban lévő bitcoinonként 0,015 napnak felelt meg. **Gazdasági jelentés:** a nyers CDD az idő előrehaladtával egyre kevésbé összehasonlítható, mert a kínálat drámaian változik. A kínálatra normalizálás segít szétválasztani két hatást: a nagyobb monetáris bázis mechanikusan több BTC-nap megsemmisítését teszi lehetővé, míg a szokatlanul intenzív régi coin-mozgás viselkedésbeli változást jelez. A legközelebbi nyilvános megfelelők a Glassnode és a CryptoQuant Supply-Adjusted CDD. ### 4.6 `obm_difficulty_eod_daily` — Napi bányászati nehézség (nap végén) A bányászati nehézség az adott UTC-naphoz rendelt legmagasabb blokkmagasságú blokkhoz tartozó érték. Tehát **végállapot-megfigyelés**, nem napi átlag. A nehézség csak retarget-határoknál változik, közönséges nehézségi epochokon belül állandó. Ha egy naphoz nem tartozik blokk, az érték **hiányzóként** jelenik meg. **Gazdasági jelentés:** a protokoll-szintű bányászkörnyezetet írja le, nem a megfigyelt hashrate-et, a bányászprofítot, a tranzakciós keresletet vagy a felhasználói aktivitást. Hasznos a nehézség-állítási ciklusok, a bányászati szektor feltételei, a kibocsátás időzítése és a hálózati biztonság tanulmányozásában. A legközelebbi komparátor a Coin Metrics `DiffLast`. ### 4.7 `obm_dormancy_days_daily` — Napi dormancy Az adott napon elköltött coinok **életkorral súlyozott átlaga**, napokban. Számítása: napi BTC Days Destroyed osztva a napi spent output értékkel. Az eredmény egysége nap. Ha nincs spent value, a metrika nem definiált és **hiányzóként** jelenik meg (a nulla dormancy nem ugyanaz, mint a „nincs adat”). **Gazdasági jelentés:** a CDD-intuíció átlagos spent-age indikátorrá alakítása. Magas érték: az elköltött coinok jelentős kort halmoztak fel. Alacsony érték: a forgalom főként frissen létrehozott vagy aktív outputokból származik. Hasznos alvó kínálat aktivációjának, hosszú távú tulajdonosi viselkedésnek és UTXO-forgalomnak a vizsgálatában. A legközelebbi komparátor a Glassnode `indicators.AverageDormancy` és a CryptoQuant Average Dormancy. ### 4.8 `obm_est7d_hashrate_ehs_daily` — Becsült 7 napos hálózati hashrate EH/s-ban A Bitcoin-bányászatba fektetett aggregált számítási kapacitás becslése, exahash per szekundumban. A hashrate nem közvetlenül megfigyelhető on-chain; a proof-of-work nehézségből és a blokkok előállítási idejéből kell inferálni. Az OBM egy **7 napos, UTC-naptári ablakot** használ (ezért `est7d` az azonosítóban). A 7 napos ablak csökkenti a sztochasztikus blokkfelfedezés okozta zajt, miközben reagál a bányászati feltételek változásaira. **Gazdasági jelentés:** a bányászati aktivitás és hálózati biztonság proxyja. Különösen fontos az energiával kapcsolatos kutatásokban (pl. villamosenergia-fogyasztási modellek). **Fontos korlát:** nem közvetlen megfigyelése a gépeknek, bányászkészleteknek, földrajzi helyeknek, hardver-hatékonyságnak vagy villamosenergia-forrásoknak. A legközelebbi komparátorok a Glassnode `mining.HashRateMean` és a Blockchain.com Total Hash Rate. ### 4.9 `obm_fee_share_revenue_ratio_daily` — Díjak mint a bányászbevétel részaránya A bányászkompenzáció azon hányada, amely tranzakciós díjakból származik. Származtatott metrika, két OBM forrássorból: `obm_fees_btc_daily` és `obm_issuance_btc_daily`. Képlete: díjak / (kibocsátás + díjak). Az értéket **aránysként** (unit ratio) fejezi ki, nem százalékként — 0,025 tehát 2,5%-ot jelent. **Gazdasági jelentés:** a Bitcoin bányászbevétel-összetételének változását mutatja. A blokkjutalom a felezések során csökken, miközben a díjak hosszú távon várhatóan nagyobb szerepet kapnak a biztonsági költségvetésben. A metrika hasznos a szubvenció-korszakok, felezési epizódok és a fee-market érettségének vizsgálatában. A legközelebbi komparátorok: Coin Metrics `FeeRevPct`, Glassnode `mining.RevenueFromFees`. ### 4.10 `obm_fees_btc_daily` — Napi tranzakciós díjak Az egyes UTC-napokhoz rendelt blokkok nem-coinbase tranzakciói által fizetett díjak teljes BTC-összege. Minden nem-coinbase tranzakció esetén a díj a tranzakció inputjai által elköltött előző outputok értékösszege és a tranzakció outputjainak értékösszege közötti különbség. **Gazdasági jelentés:** a felhasználók által a blokktér-beillesztésért fizetett BTC-mennyiség. Központi változó a Bitcoin fee market kutatásában, a bányászösztönzők, a felezések hatásainak és a biztonsági költségvetés fenntarthatóságának vizsgálatában. **Fontos korlát:** nem teljes bányászbevétel, nem bányászprofít, nem fee-rate metrika — ez teljes díjösszeg BTC-ben. Legközelebbi komparátor: Coin Metrics `FeeTotNtv`. ### 4.11 `obm_issuance_btc_daily` — Napi Bitcoin-kibocsátás Az egyes UTC-napokhoz rendelt blokkokban ténylegesen létrehozott új BTC-mennyiség. Az OBM a kibocsátást **realizált flow-ként** definiálja, nem csupán a protokoll-ütemezés által implikált elméleti block subsidyként. Minden blokk esetén a coinbase tranzakció teljes outputértéke tartalmazza az újonnan kibocsátott BTC-t és a tranzakciós díjakat; mivel a díjak már létező BTC átutalásai, az OBM **levonja a díjakat** a coinbase output értékéből, hogy izolálja az újonnan létrehozott kínálatot. **Gazdasági jelentés:** monetáris flow-változó, amely a Bitcoin-kínálat napi növekedését méri. Központi a szűkösség, a kínálat növekedése, a felezési rezsim, a kibocsátási sokkok és a bányászbevétel monetáris oldalának vizsgálatában. **Három fontos megkülönböztetés:** nem az elméleti maximális szubvenció (a bányászok alul is igényelhetik), nem bányászbevétel (a díjak nélkül), nem forgó kínálat (a kínálat kumulatív stock, a kibocsátás napi flow). Legközelebbi komparátor: Coin Metrics `IssTotNtv`, Glassnode `supply.Issued`. ### 4.12 `obm_liveliness_ratio_daily` — Napi liveliness arány A coin-age megsemmisítés és coin-age létrehozás közötti **kumulatív egyenleget** összegzi. Két OBM forrássorból: `obm_cdd_btcxdays_daily` és `obm_supply_btc_daily`. A számláló a kumulatív Bitcoin Days Destroyed, a nevező a napi kínálat alapú közelítése a kumulatív coin-days created értéknek. Az eredmény dimenziómentes arány. **Gazdasági jelentés:** hosszú horizontú indikátora a tartás vs. költés viselkedésnek. Ha régi coinok mozognak és jelentős kumulatív coin age-et semmisítenek meg, a liveliness emelkedik. Ha a coinok inaktívak maradnak és a kínálat tovább halmoz coin days-t, a liveliness stabilizálódik vagy lassabban csökken. **Fontos korlát:** nem napi aktivitási mérőszám (kumulatív és lassan mozgó), nem entitás-korrigált (nem azonosít elveszett coinokat, custodiális mozgásokat, exchange-tevékenységet). A legközelebbi komparátor a Glassnode `indicators.Liveliness`. ### 4.13 `obm_miner_revenue_btc_daily` — Napi bányászbevétel BTC-ben A bányászoknak az egyes UTC-napokhoz rendelt blokkok coinbase tranzakcióin keresztül kifizetett teljes BTC-kompenzáció. Blokk szinten a coinbase tranzakció az újonnan kibocsátott BTC-t és a tranzakciós díjakat egyaránt kifizeti a bányásznak — így a napi bányászbevétel a coinbase outputok összege, vagy egyenértékűen a napi kibocsátás + napi díjak. **Gazdasági jelentés:** az egyik legfontosabb bányásszektor-változó az OBM-ben. A Bitcoin biztonsági költségvetésének, a bányászösztönzőknek, a felezési eseményeknek, a szubvenció-korszakoknak és a szubvenció-dominált kompenzációról a díj-támogatott kompenzációra való átmenetnek a vizsgálatára szolgál. **Fontos korlát:** nem bányászprofít (nem tartalmazza a villamosenergia-költséget, hardver-amortizációt, pool-díjakat, adókat, finanszírozási költségeket vagy egyéb működési költségeket), nem fiat-denominált jövedelem (BTC-ben van, nem USD-ben/EUR-ban). A legközelebbi komparátor a Glassnode `mining.RevenueSum`. ### 4.14 `obm_raw_output_value_btc_daily` — Napi nyers output-érték BTC-ben Az egyes UTC-napokhoz rendelt blokkok **nem-coinbase tranzakciói által létrehozott outputok** teljes BTC-értéke. A coinbase outputok kimaradnak, mert azok a bányászbevételt reprezentálják, és már az issuance/miner-revenue metrikák rögzítik. **Gazdasági jelentés:** átlátható kiindulópont az on-chain értékaktivitáshoz. A tranzakciószámot az érték dimenziójával, a spent value-t az output oldali nézőponttal egészíti ki. Előnye az egyszerűség: nem használ átlátszatlan entitás-korrigáló heurisztikákat, reprodukálható, alacsony szintű sor. **Fontos korlát:** nem fizetési volumen vagy gazdaságilag értelmezhető tranzakciós volumen, mert a Bitcoin-tranzakciók gyakran tartalmaznak change outputokat, és tükrözhetnek batchinget, self-transzfert, exchange-műveleteket, custodiális tárcakezelést és wallet-konszolidációt. A legközelebbi komparátor a Blockchain.com Output Value Per Day chart. ### 4.15 `obm_spent_output_count_daily` — Napi elköltött outputok száma Az egyes UTC-napokhoz rendelt blokkok **nem-coinbase tranzakcióinak inputjai által fogyasztott előző outputok** száma. Input-oldali UTXO-aktivitási metrika: elköltött outputokat számol, nem tranzakciókat, címeket, felhasználókat, entitásokat vagy fizetéseket. Egy Bitcoin-tranzakció egy vagy több inputot használhat, így ez a metrika a tranzakció-struktúra olyan aspektusát ragadja meg, amely a napi tranzakciószámban nem látható. **Gazdasági jelentés:** hasznos az UTXO-flow dinamikájának tanulmányozásában. Segít megkülönböztetni a szokásos tranzakciószám-ingadozást azoktól a napoktól, amikor a tranzakciók szokatlanul sok előző outputot fogyasztanak. ## 4. Összegzés és kitekintés Ez a rész alapvetően referencia-jellegű: minden metrikánál három dolgot tisztáz a szerző: 1. **Mit mér a sor** — a pontos matematikai definíciót és az adatforrást. 2. **Mit ne mérjen vele a kutató** — a gyakori értelmezési csapdákat (pl. CDD ≠ fizetési volumen, hashrate ≠ villamosenergia-fogyasztás, miner revenue ≠ miner profit). 3. **Melyik publikus komparátor áll a legközelebb** — Coin Metrics, Glassnode, CryptoQuant, Blockchain.com és más szolgáltatók konkrét soraira hivatkozva. Az OBM fő értéke itt is az átláthatóság: minden metrika vagy közvetlenül full-node-ból származik, vagy két dokumentált OBM-sorból determinisztikusan származik, explicit hiányzó-érték konvenciókkal, stabil azonosítókkal és világosan dokumentált korlátokkal. A fennmaradó metrikák (4.16–4.23) és a 3. Methods fejezet korábbi alfejezetei (3.1–3.4) valószínűleg a következő részekben kapnak helyet. --- ## 3. rész A paper harmadik része a 4. fejezet (Description of OBM available metrics) hátralévő metrikáit (4.15-4.23), valamint a 6-11. szekciókat (Usage notes, Code and data availability, Limitations, Acknowledgements, Author contributions, Declaration of Competing interests) és az Appendix A elejét (A.1 obm_block_count_daily) tartalmazza. ## 4.15 obm_spent_output_count_daily — naponta elköltött output-ok száma A metrika a naponta elköltött output-ok teljes darabszámát méri (coinbase nélkül). Gazdaságilag az input-oldali aktivitás volumetrikus proxy-ja, de NEM a felhasználók száma, NEM a tranzakciók száma, és NEM a gazdaságilag jelentős átutalásoké. A magas értékek tükrözhetnek "wallet consolidation"-t, exchange batching-et, custodial reorganizációt, vagy más input-heavy mintákat. A legközelebbi publikus komparátorok: Glassnode spent-output age-band count charts, CryptoQuant Spent Output Age Bands (value-based). "No reviewed provider appears to publish a simple named daily total exactly equivalent to obm_spent_output_count_daily" — ez az OBM egyik egyedi hozzájárulása. ## 4.16 obm_spent_value_age_band_btc_daily — daily spent output value by age band (wide table) A táblázat a napi spent output value-t az output-ok kora szerinti bontásban tartalmazza. Széles daily tábla (wide table): minden sor egy UTC dátum, minden oszlop egy kor-sáv (0d-1d, 1d-1w, 1w-1mo, ..., 10y+). A metrika a "spent volume age composition" térképét adja, megkülönböztetve a fiatal-output churn-t a hónapokig/évekig inaktív coinok mozgásától. Komparátorok: Glassnode Spent Volume by Age, SVAB, SOAB; CryptoQuant Spent Output Age Bands; Checkonchain Spent Volume Age Bands. Az OBM egyedi hozzájárulása a reproducibilis, BTC-denominált, full-node-derived wide table explicit age-band oszlopokkal. ## 4.17 obm_spent_value_btc_daily — daily spent output value BTC-ben A metrika a naponta blokkhoz rendelt nem-coinbase tranzakció input-ok által elköltött előző output-ok teljes BTC-értékét méri. Raw input-side value-flow metrika. Minden input hozzájárul a régi output értékével, függetlenül attól, hogy payment, self-transfer, wallet consolidation, batching, vagy custodial reorganization. A metrika a "gross UTXO turnover in BTC"-t méri, és a dormancy, age-band tables, threshold metrikák alap építőköve. Komparátorok: Glassnode Spent Volume, CryptoQuant Spent Output Value Bands, Coin Metrics TxTfrValNtv, Blockchain.com Output Value Per Day. Fontos: a Blockchain.com output value az újonnan létrehozott output-okat összegzi, nem az elköltötteket — ez koncepcionális különbség. ## 4.18 obm_spent_value_ge155d_btc_daily — 155 napnál idősebb spent output-ok értéke A metrika azokat a spent output-okat méri, amelyek **legalább 155 napig inaktívak** voltak, mielőtt elköltötték őket. A 155 nap a hagyományos long-term/short-term határ (Glassnode definíció). A mértékegység BTC, nem BTC-nap. A metrika a "raw long-term holder spent-value indicator" a 155-napos konvenció alatt, és kiemeli azokat a napokat, amikor hosszabb ideig tartott coinok mozognak. Fontos: ez thresholdelt spent value, NEM hagyományos CDD. A küszöb-alapú megközelítés előnye: egyszerűbb, könnyebb értelmezni, és a LTH/STH dichotómia alapja. ## 6. Usage notes A Usage notes szekció a felhasználási ajánlásokat tartalmazza. A OBM dataset-et három fő felhasználási módra tervezték: (1) empirikus kutatás (reprodukálható, peer-reviewed publikációk), (2) oktatás (Bitcoin Core, monetáris gazdaságtan, blockchain kurzusok), (3) iparági elemzés (compliance, market intelligence, risk assessment). A dataset használatához szükséges: Bitcoin Core full node, a OBM repository klónozása, Python 3.10+ függőségek, és a `--start_date` / `--end_date` paraméterek. A dataset frissítése havonta történik, a release version minden fájlban explicit jelölve van a reprodukálhatóság érdekében. ## 7. Code and data availability A teljes kód, a dokumentáció, a szkriptek és a generált dataset elérhető a **https://github.com/diegorllanos/open-bitcoin-metrics** repository-ban. A repository tartalmazza: (1) a Bitcoin Core konfigurációs fájlokat, (2) a spent-output indexer Python kódját, (3) a metric exporter szkripteket (minden metrikához egy), (4) a validációs teszteket, (5) a release_version.txt fájlt. A dataset maga a GitHub Releases oldalról tölthető le (CSV és Parquet formátumban). A DOI a Zenodo-n keresztül érhető el (lásd a paper végén). A licenc MIT — szabad felhasználás, kereskedelmi célra is, a forrás megjelölésével. ## 8. Limitations A Limitations szekció őszintén felsorolja a korlátokat: (1) Az OBM NEM entity-adjusted — a spent output-ok nem azonosíthatók konkrét szereplőkkel, exchange-ekkel vagy custodial szolgáltatókkal. (2) A NEM kínálati korrekció — ha egy coin elveszett (lost coins), az OBM supply metrika továbbra is tartalmazza. (3) A pre-2009 coinbase tranzakciók (genesis block) NEM részei a datasetnek. (4) A reorg-ok kezelése egyszerű: az exporter a chain tip-jét követi, és a Bitcoin Core finality konvenciót alkalmazza (6 blokk). (5) A konzervatív aggregáció néha ellentmondásos eredményeket adhat (pl. CDD éves aggregáció vs. napi összeg). (6) A indexer egyetlen Bitcoin Core instance-ot támogat — multi-node konszenzus nem implementált. ## 9. Acknowledgements A szerző köszönetet nyilvánít: (1) a University of Valladolid támogatásáért, (2) a Bitcoin Core fejlesztői közösségnek az indexelhető full node API-ért, (3) a nyílt forráskódú Bitcoin közösségnek a protokol-specifikációk részletes dokumentációjáért, (4) a peer-reviewereknek a paper konstruktív kritikájáért. A dataset elkészítése során felhasznált publikus források: Glassnode Studio dokumentáció, Coin Metrics dokumentáció, CryptoQuant API docs, valamint a Blockchair és YCharts publikus dashboardok. ## 10. Author contributions A szerző, **Diego R. Llanos**, egyedüli author. A koncepció, a módszertan, a szoftver implementáció, az adatgyűjtés, az elemzés és a manuscript elkészítése mind egy személy munkája. A University of Valladolid Department of Computer Science intézményi hátteret biztosított (számítási erőforrások, hozzáférés a publikációhoz). ## 11. Declaration of Competing interests A szerző kijelenti, hogy **nincsenek összeférhetetlenségi okok**. A dataset független, peer-review-vel ellátott tudományos munka, és nem áll kapcsolatban kereskedelmi Bitcoin analytics szolgáltatókkal (Glassnode, Coin Metrics, CryptoQuant, stb.). A szerző nem kapott pénzügyi támogatást egyetlen Bitcoin-hoz kapcsolódó kereskedelmi entitástól sem a dataset vagy a paper elkészítéséhez. ## Appendix A.1 obm_block_count_daily — kezdet Az Appendix A a 23 metrika részletes matematikai definícióját tartalmazza. Az A.1 (obm_block_count_daily) a "Definition" részt és a "Economic interpretation" részt mutatja be. A definíció formális: a metrika a naponta bányászott blokkok számát adja, magasság (height) alapján, a `--height_margin=288` paraméter alkalmazásával a no-block napokra. A "similar metrics publicly available" szekció a Glassnode, Blockchain.com, Coin Metrics, és BitInfoCharts hasonló metrikáit sorolja fel. Az A.1 teljes definíciója és algoritmusa a 4. részben folytatódik. --- ## 4. rész **Cikk:** *Open Bitcoin Metrics: Verifiable Full-Node-Derived Bitcoin Time Series for Economic Research* **Szerző:** Diego R. Llanos (University of Valladolid, Spanyolország) **Dátum:** 2026-07-03 **arXiv azonosító:** 2607.03124v1 **GitHub:** https://github.com/diegorllanos/open-bitcoin-metrics **Ez a rész:** A 4. fejezet (Results) két egyszerűbb metrikájának (4.1 `obm_block_count_daily` és 4.2 `obm_block_weight_wu_daily`) teljes referencia-leírása, valamint az Appendix A (Metric Reference Guide) első két teljes bejegyzése (A.2 és A.3) — utóbbi az életkor-sávos Bitcoin Days Destroyed táblát vezeti be. --- ## 1. Kontextus: hol tartunk a cikkben? A cikk első három része lefedte az absztraktot, a bevezetést, a 23 OBM-metrika felsorolását, a kapcsolódó irodalmat (Related Work) és a 3. Methods fejezetet (spent-output indexelő, reorg-kezelés, UTC-időbélyeg-konvenció, séma és release-mechanizmus). A 4. fejezet (Results) ezt követően tér rá az egyes metrikák konkrét bemutatására. Ez a rész (4. rész) a két „legegyszerűbb” OBM-sor, a napi blokkszám és a napi blokksúly teljes leírását adja, illetve megkezdi az életkor-sávos CDD-tábla referenciabejegyzését. Mindkét metrika közös jellemzője, hogy **kizárólag blokk-szintű metaadatokból** kiszámítható — nincs szükség UTXO-rekonstrukcióra, tranzakció-bemenetek feloldására, címkivonatra, fee-kalkulációra vagy külső árfolyamra. Emiatt ezek a projekt „legrobosztusabb” és legkönnyebben auditálható sorai. --- ## 2. A 4.1-es metrika: `obm_block_count_daily` — napi blokkszám ### 2.1 Definíció és aggregáció Ez a metrika adott UTC-naptári naphoz rendelt Bitcoin-blokkok számát méri. Ha a `d` naphoz tartozó blokkok halmaza `B_d`, és `t_b` a `b` blokk időbélyege, akkor a `d(b) = UTCDate(t_b)` hozzárendelés mellett: ``` BlockCount_d = Σ_{b : UTCDate(t_b) = d} 1 ``` vagyis a napi érték egyszerűen az adott napon kibányászott blokkok darabszáma. Havi változat esetén az aggregáció a napi értékek összegeként adódik: `BlockCount_m = Σ_{d ∈ m} BlockCount_d`. A blokk hozzárendelése kizárólag a Bitcoin Core által visszaadott blokk-időbélyegen alapul — nincs alternatív „medián idő” (median time past) korrekció. ### 2.2 Algoritmus és a `--height_margin` paraméter A `compute_obm_block_count_daily.py` szkript kilenc lépésben dolgozik: 1. A felhasználó által megadott `--start_date` és `--end_date` (formátum: `YYYY-MM-DD`) UTC-időpontként értelmeződik, és mindkét dátum benne marad a kimenetben. 2. A kezdődátum `00:00:00 UTC`, a záródátum `23:59:59 UTC` időbélyeggé konvertálódik. 3. A `getblockchaininfo` hívással lekérdezi a legfrissebb blokkmagasságot (`h_tip`). 4. Bináris kereséssel egy közelítő magasság-intervallumot (`[h_min^approx, h_max^approx]`) becsül a kért dátumtartományhoz. 5. Ezt az intervallumot a `--height_margin` biztonsági paraméterrel bővíti, így jön létre a ténylegesen szkennelt tartomány: `h_min^scan = max(0, h_min^approx − m)` és `h_max^scan = min(h_tip, h_max^approx + m)`. 6. A kibővített tartomány minden `h` magasságára: lekéri a blokk-hash-t (`getblockhash`), dekódolja a blokkot (`getblock`), kiolvassa `t_b`-t, hozzárendeli a `d(b) = UTCDate(t_b)` naphoz, és ha az a kért intervallumba esik, eggyel növeli a napi számlálót. 7. A kért intervallum minden dátumát előzetesen nullázza — így minden naptári naphoz garantáltan lesz sor a kimenetben, még ha nem is esett rá blokk. 8. A kimeneti CSV az egységes OBM-séma szerint íródik: `date, series_id, value, unit, frequency, release_version`. 9. Opcionálisan `plot` kapcsolóval grafikont is készít a sorozatról. A `--height_margin` alapértéke **288 blokk**, ami nagyjából **két napnyi** várható blokktermelés a ~144 blokk/nap ütem mellett. Ez a konzervatív margó azért kell, mert a Bitcoin blokkok időbélyege **nem szigorúan monoton** a magasság függvényében — a bányászok időbélyege néha kicsit előre vagy hátra csúszhat. A szkript a kibővített tartományban szkennel, de csak azokat a blokkokat számolja, amelyek UTC-dátuma a kért zárt intervallumba esik. A margó nem változtatja meg a kimenet dátumait, csak a belső keresést szélesíti. Nagyobb értéke robusztusabb, kisebb értéke gyorsabb, de határeseteknél kockázatosabb. ### 2.3 Kimeneti formátum és validáció Minden sor egy UTC-dátumhoz tartozik, ahol: - `date`: pl. `2024-01-01` - `series_id`: `obm_block_count_daily` (stabil azonosító) - `value`: pl. `147` (blokkok száma) - `unit`: `blocks` - `frequency`: `daily` - `release_version`: pl. `OBM v0.1.0` A technikai validáció a következőkből áll: a kért dátumtartomány érvényessége, a lánc túlnyúlásának ellenőrzése, az összes naptári nap nullázása a hiányzó megfigyelések észrevétele érdekében, a szkennelt blokkok és effektív magasság-intervallum naplózása, valamint egy külső összevethetőség (más szolgáltatókkal) — ez utóbbi csak diagnosztikai célú, mert a szolgáltatók timestamp-konvenciója, reorg-kezelése és nap-határ-szabálya eltérhet. ### 2.4 Ismert korlátok és közgazdasági értelmezés A szerző négy fontos korlátot jelöl meg: 1. A metrika blokkokat mér, nem tranzakciókat, felhasználókat, tranzakciós keresletet vagy gazdasági aktivitást. 2. Nem tartalmaz információt a blokkméret, blocksúly, díjak, tranzakciós volumen vagy bányászbevétel szempontjából. 3. A ~144 blokk/nap várható értéktől való rövid távú eltérések **normálisak** a Bitcoin valószínűségi blokk-felfedezési folyamata mellett — ezeket nem szabad mechanikusan a hálózat egészségének változásaként értelmezni. 4. A blokkok napokhoz rendelése a Bitcoin Core által visszaadott `time` mezőn alapul (alapértelmezés), de medián idő (MTP) konvenciót is lehetne használni — a kettő a napi határoknál kis eltérést produkálhat. A metrika közgazdasági szerepe, hogy **baseline-sorként** szolgál: átláthatóan méri a megvalósult blokktermelést, és természetes normalizáló változó a többi napi mutató (tranzakciószám, kibocsátás, díjak, bányászbevétel, blokktér-kihasználtság) értelmezéséhez. --- ## 3. A 4.2-es metrika: `obm_block_weight_wu_daily` — napi blokksúly weight unitban ### 3.1 Definíció és aggregáció Ez a metrika adott UTC-naphoz rendelt **összes blokk weight unit (WU) összegét** méri. Ha `B_d` a naphoz rendelt blokkok halmaza, és `W_b` a `b` blokk súlya, akkor: ``` BlockWeightWU_d = Σ_{b ∈ B_d} W_b ``` A mértékegység **WU** (weight unit), és az érték **napi összeg**, nem blokkonkénti átlag. A blokk-szintű weight mezőt a Bitcoin Core közvetlenül szolgáltatja, és a SegWit konszenzus-szabályok szerinti számítás tükröződik benne (`Weight = 3 × stripped_size + total_size`, 4 millió WU-s blokklimit). A metrika tehát a Bitcoin **blokktér-kihasználtságát** méri — a napi tranzakciószám és a kibocsátás mellett a harmadik, blokktér-oldali dimenziót testesíti meg. ### 3.2 Algoritmus és biztonsági paraméterek A `compute_obm_block_weight_wu_daily.py` ugyanazt a tíz lépéses struktúrát követi, mint a blokkszám-szkript, azzal a különbséggel, hogy: - a JSON-RPC-n keresztül lekéri a dekódolt blokkot a `getblock 1` hívással (verbosity = 1), - a blokk-szintű `weight` mezőt olvassa ki (nem a blokk `size` mezőjét), - a napi összegbe a blokk súlyát adja hozzá, nem pedig egy egységnyi számlálót. A `--height_margin` paraméter itt is 288 blokk alapértékkel működik, és ugyanazt a szerepet tölti be: a timestamp-alapú bináris keresésből származó közelítő magasság-intervallumot a konszenzus szerinti nem-monotonitás miatt kiterjeszti. A szkript szintén támogatja a szokásos RPC-, kimeneti, release-verzió és plot-paramétereket (`--rpc_url`, `--rpc_user`, `--rpc_password`, `--cookie_path`, `--use_default_cookie`, `--rpc_timeout`, `--output`, `--release_version`, `--plot`, `--plot_output`, `--quiet`). ### 3.3 Kimeneti formátum és származtatott diagnosztikák A CSV-séma megegyezik az OBM-szabvánnyal: - `date`: pl. `2024-01-01` - `series_id`: `obm_block_weight_wu_daily` - `value`: pl. `568923456` (egész WU, nincs lebegőpontos aritmetika) - `unit`: `WU` - `frequency`: `daily` - `release_version`: pl. `OBM v0.1.0` A szkript két fontos **származtatott diagnosztikát** javasol: - **Átlagos blokksúly**: `AvgBlockWeightWU_d = BlockWeightWU_d / BlockCount_d`, ha `BlockCount_d > 0`. Ez kiszűri a napi blokkszám-ingadozás hatását, és a konszenzus 4 millió WU-s limitjéhez viszonyítva a „blokktöltöttséget” jellemzi. - **Díj per weight unit**: `FeesPerWU_d = FeesBTC_d / BlockWeightWU_d`, ha `BlockWeightWU_d > 0`. Ez a fee-piac elemzésének természetes egysége, mert a blokktér-kapacitás a konszenzus szintjén weight unitban van megadva. ### 3.4 Hasonló nyilvános metrikák és összehasonlításuk A szerző részletesen végigmegy a főbb nyilvános blokksúly- és blokkméret-szolgáltatókon, és minden esetben megjelöli, hogy az OBM-sorhoz **milyen módon viszonyíthatók** (és hol nem): - **Coin Metrics `BlkWghtTot` (Sum Block Weight)**: a legközelebbi közvetlen megfelelő, mert szintén az intervallumban létrehozott blokkok súlyának összegét adja napi gyakorisággal. A `BlkWghtMean` (Mean Block Weight) átlagot ad, ami az OBM-ből a fenti hányadossal származtatható. - **Newhedge „Bitcoin Block Weight”**: napi átlagos blokksúlyt mutat, és hiányzik a teljes reprodukálható algoritmus (időbélyeg-konvenció, reorg-kezelés, aggregáció módja nincs dokumentálva). - **Bitcoin Visuals „Block Weight”**: napi medián blokksúlyt rajzol, és explicit megadja a weight-képletet (`3 × stripped size + total size`) és a 4 millió WU-s konszenzus-limitet. A koncepció validálására jó, de a teljes napi összeg nem egyenlő a mediánnal. - **Glassnode „Block Size (Mean)” és „Block Size (Total)”**: bájt-alapú, nem weight unit-alapú, így a SegWit tanú-adatkedvezményt nem tükrözik — a blokk-kapacitás elemzéséhez WU-s sor kell, de a tágabb blokktér-diskurzusban másodlagos összehasonlítóként használhatók. - **Blockchain.com „Average Block Size (MB)”**: 24 órás átlagot ad megabájtban — három ponton tér el az OBM-től (átlag vs. összeg, MB vs. WU, és a SegWit weight-képlet hiánya). - **Blockchair**: blokk-szintű explorer-adatokat és katalógust kínál, de nem publikál explicit „napi teljes blokksúly” metrikát dokumentált aggregációs szabállyal — inkább alacsonyabb szintű rekonstrukciós forrásként kezelendő. A szerző végső konklúziója, hogy a legerősebb közvetlen összehasonlító a Coin Metrics `BlkWghtTot`, a többi forrás (medián, átlag, bájt-alapú) csak kapcsolódó, de nem egyenértékű mutató. ### 3.5 Ismert korlátok és közgazdasági értelmezés A metrika hatszoros korlátlistát kap: 1. Napi összeget mér, nem átlagot — ezért részben a napi blokkszám-ingadozást is tükrözi. 2. Blokktér-használat, nem tranzakciós kereslet vagy gazdasági aktivitás. 3. Függ a blokk-időbélyeg-konvenciótól. 4. A weight formula már a witness kedvezményt tükrözi, de a metrika önmagában **nem bontja** szét witness és nem-witness adatokra. 5. Eltérhet a bájtos, átlagos vagy kapacitás-kihasználtsági százalékos publikus mutatóktól. 6. A szkript a dekódolt blokk-metaadatokból dolgozik, nincs szükség a spent-output indexerre — ennek előnye a sebesség és az egyszerűség. A közgazdasági értelmezés öt rétege: (1) a megvalósult blokktér-használat átlátható mérése, (2) a fee-piaci dinamika értelmezése (nagyobb blokktér-telítettség → erősebb verseny a blokkba kerülésért), (3) fee-per-WU indikátorok építése, (4) a blokkszámmal együtt használva szétválasztható a „sok blokk” és a „teli blokk” hatása, (5) normalizáló változó a tranzakciószám, raw output value, díjak és más aktivitási mutatók számára. ### 3.6 Technikai validáció Kilenc belső ellenőrzés: dátumtartomány érvényessége, `--height_margin` nem-negativitása, RPC autentikáció (cookie-fájl formátum és létezés), `getblockchaininfo` lánctippel való kapcsolat, kibővített magasság-intervallum helyessége, a szkennelt tartomány és a kért dátumtartomány konzisztenciája, minden szkennelt blokk tartalmazza a `weight` mezőt, a blokksúlyértékek nem negatívak, és minden kért dátumhoz tartozik sor (nullázással). Emellett a fenti származtatott hányadosok és a fees-per-WU kiszámítása is validációs eszköz. --- ## 4. Az Appendix A első két referenciabejegyzése A cikk Appendix A-ja (Metric Reference Guide) minden metrikát **nyolc szempont** szerint ír le: definíció, közgazdasági értelmezés, hasonló nyilvános metrikák, adatforrás és bemeneti igények, algoritmus, metrika-specifikus paraméterek, aggregációs szabály, kimeneti formátum, technikai validáció és ismert korlátok. A 4. rész az A.2 (`obm_block_weight_wu_daily`) és A.3 (`obm_cdd_age_band_btcxdays_daily`) bejegyzéseket tartalmazza — utóbbi csak az elejéig, a definícióig és az age-band-listáig. ### 4.1 A.2 — `obm_block_weight_wu_daily` (ismételt, referencia-formátumban) Az A.2 bejegyzés a fenti 4.2-es metrikát írja le újra, referencia-kézikönyv stílusban. Kiemeli, hogy a `Weight` mezőt a Bitcoin Core `getblock` hívásából nyeri, és hogy ehhez **nincs szükség `txindex=1`-re**, mert minden szükséges adat blokk-metaadatként elérhető. A feldolgozás a lokálisan verifikált fő láncot használja, és minden blokkot a Bitcoin Core által visszaadott timestamp UTC-dátumához rendel. Az A.2 lábjegyzetei sorra veszik a főbb publikus összehasonlítókat (Coin Metrics, Newhedge, Bitcoin Visuals, Glassnode, Blockchain.com, Blockchair), mindenhol jelölve, hogy az adott szolgáltató **melyik konvenciót használ** (összeg / átlag / medián / bájt), és hogy az OBM-hez képest ez **milyen eltérést jelent**. ### 4.2 A.3 — `obm_cdd_age_band_btcxdays_daily` (részleges, a 4. rész végén) Ez a metrika a **napi Bitcoin Days Destroyed-t (CDD) életkor-sávok szerint bontja**. A definíció: - `B_d` a `d` naphoz rendelt blokkok halmaza. - Minden nem-coinbase tranzakció-bemenet `i` esetén a változók: - `v_i` = az elkölttött előző kimenet (previous output) BTC-értéke, - `a_i = max(0, (t_i^spent − t_i^created) / 86400)` = a kimenet kora napokban, ahol `t_i^created` a kimenet létrehozásának blokk-időbélyege, `t_i^spent` pedig az elkölttésé. - A `k` életkor-sávhoz tartozó napi komponens: ``` CDDBand_{d,k} = Σ_{b ∈ B_d} Σ_{i ∈ I_b} v_i · a_i · 𝟙{a_i ∈ k} ``` ahol `𝟙{·}` az indikátorfüggvény (1 ha `a_i` a `k` sávba esik, 0 egyébként), és `I_b` a `b` blokk nem-coinbase tranzakció-bemeneteinek halmaza. A sávok a következők: **0d–1d, 1d–1w, 1w–1m, 1m–3m, 3m–6m, 6m–1y, 1y–2y, 2y–3y, 3y–5y, 5y–7y, 7y–10y, 10y+**. A sávok összege visszaadja a teljes napi CDD-t: `CDD_d = Σ_k CDDBand_{d,k}`. A kimenet tehát egy **széles, vektor-értékű napi tábla**: minden sor egy UTC-dátum, minden oszlop egy életkor-sáv. A közgazdasági értelmezés a 4. részben még csak elindul: a tábla azt mutatja meg, hogy a napi CDD-t **frissen létrehozott, középkorú vagy idős** kimenetek hajtják-e — ez a HODL-viselkedés, a long-term holder aktivitás és a hosszú távú készlet-dinamika egyik legfontosabb szeletelője. A teljes A.3 bejegyzés (a fennmaradó hét alpont) a következő részre marad. --- ## 5. Miért fontos ez a két metrika a teljes OBM-rendszerben? A blokkszám és a blokksúly a projekt „rétegzett komplexitású” felépítésének **alsó szintjét** képviselik. Mindkettő: - **kizárólag blokk-metaadatokból** számítható (nincs UTXO-rekonstrukció, nincs spent-output indexelés, nincs címkivonat, nincs fee-kalkuláció, nincs külső ár); - a legegyszerűbb belső konzisztencia-ellenőrzések egyike, mert a felsőbb szintű mutatók (tx_count, fees, miner revenue, supply, UTXO count) ezekből származtathatók, és így **visszafelé is ellenőrizhetők**; - a `--height_margin` (288 blokk) konzervatív margóval dolgozik, ami a Bitcoin timestampjeinek nem-monoton viselkedését kezeli — ez a projekt egyik legfontosabb és újra meg újra hivatkozott technikai mintája; - az egységes OBM-CSV-sémát használja (`date, series_id, value, unit, frequency, release_version`), ami az egész adathalmaz gépi feldolgozhatóságának alapja. A felsőbb szintű metrikák (CDD, dormancy, spent_value_age_band, supply, utxo_count stb.) **mind a blokk-szintű WU-ra és blokkszámra épülnek** normalizáló változóként, ezért e két sor helyessége kritikus az egész OBM-rendszer integritásához. A Appendix A-ban ezek a leírások a későbbi metrikák referenciamintái: a nyolc-pontos struktúra (definíció → közgazdasági értelmezés → hasonló nyilvános metrikák → adatforrás → algoritmus → metrika-specifikus paraméter → aggregáció → kimenet → validáció → korlátok) az A.3-as CDD-táblától kezdve minden további metrikára érvényes. --- ### 6. Összegzés A 4. rész az OBM két „belépő szintű” metrikáját (napi blokkszám és napi blokksúly weight unitban) teljes mélységben bemutatja, a 4. fejezet eredmény-blokkjában és az Appendix A referencia-kézikönyvében egyaránt. Mindkét metrika a `getblock` hívásból nyert blokk-metaadatokból dolgozik, a `--height_margin` 288 blokkos biztonsági margójával és az UTC-naptári naphoz rendelés szabályával. A blokksúly-metrika részletes összehasonlítást kap a főbb publikus forrásokkal (Coin Metrics, Newhedge, Bitcoin Visuals, Glassnode, Blockchain.com, Blockchair), mindenhol jelölve a konvencióbeli eltéréseket (összeg vs. átlag vs. medián; WU vs. bájt; átlag vs. teljes napi). A rész a CDD életkor-sávos tábla definícióját is elindítja az A.3 bejegyzésben — ez a tábla a HODL-viselkedés és a long-term holder aktivitás egyik legfontosabb szeletelője, és a teljes leírása a következő részben folytatódik. --- ## 5. rész Ez a technikai összefoglaló Diego R. Llanos „Open Bitcoin Metrics” című arXiv-tanulmányának ötödik részét dolgozza fel. Az előző részek (1. rész–4. rész) az absztraktot, a bevezetést, a Related Work fejezetet, a Methods fejezetet, a 4. fejezet metrikáinak első felét, valamint az Appendix A első metrikáit (A.1, A.2) fedték le. A jelenlegi darab (5. rész) az Appendix A függelék utolsó két, kifejezetten a **Coin Days Destroyed (CDD)**-re épülő metrikáját tárgyalja: az **A.3 obm_cdd_age_band_btcxdays_daily** széles (wide) táblát, amely a CDD-t output-kor szerinti sávokra bontja, valamint az **A.4 obm_cdd_btcxdays_daily** skalár sorozatot, amely a napi összesített CDD-t adja meg. Mindkét metrika a „spent-output” (elköltött output) nyers fogalmára épül, és ugyanazt a „BTC-nap” (BTC-days) mértékegységet használja. A CDD a Bitcoin-ökoszisztéma egyik klasszikus coin-age (érmekor) mutatója: azt méri, hogy egy adott napon mennyi „felhalmozott inaktivitás” semmisül meg azáltal, hogy a korábbi tranzakciókban létrehozott UTXO-kat elköltik. A metrika a **spent value × output age** szorzatot összegzi — vagyis egy 100 napja mozdulatlan 1 BTC elköltése 100 BTC-nap CDD-t generál, míg egy frissen kapott 1 BTC elköltése csupán néhány törtrésznyit. Ezzel a CDD kiszűri a „zajt” (friss pénz egyszerű ide-oda mozgatása, exchange batch-elés, change outputok) és a valódi long-term-holder aktivitást emeli ki. A tanulmány Appendix A.3 és A.4 szakasza ezt a két mutatót tisztán mechanikai, reprodukálható, nyers formában definiálja — entitás- vagy szubjektív korrekciók nélkül. ## 1. A.3 — `obm_cdd_age_band_btcxdays_daily`: napi CDD korosztály-sávok szerint ### Definíció és aggregációs szabály Az A.3 metrika egy **széles napi tábla** (wide daily table): minden sora egy UTC naptári nap, minden oszlopa pedig egy-egy rögzített output-kor sáv (age band). A sávok a teljes kor-tartományt diszkrét, rögzített határokkal rendelkező intervallumokra osztják. A definíció a következő: Legyen `S_d` azon előző outputok halmaza, amelyeket a `d` UTC naphoz rendelt blokkok nem coinbase tranzakció-inputjai elköltöttek. Legyen `v_i` az `i`-edik elköltött output értéke BTC-ben, és `a_i` a kora napokban (a keletkezés és az elköltés blokk-időbélyege közötti eltérés, napokra normalizálva). Minden `k = [ℓ_k, u_k)` kor-sávra a tábla a következő értéket jelenti: ``` CDDAgeBandBTCxDays_{d,k} = Σ_{i ∈ S_d} v_i · a_i · 𝟏{ℓ_k ≤ a_i < u_k} ``` Az utolsó sáv (a 10+ év) nyílt végű: `a_i ≥ 10 év`. Az indexer által használt sávok a következők (mindegyikhez saját oszlopnév tartozik a kimeneti CSV-ben): - `cdd_0d_1d_btcxdays` — 0–1 napos outputok - `cdd_1d_1w_btcxdays` — 1 nap – 1 hét - `cdd_1w_1m_btcxdays` — 1 hét – 1 hónap - `cdd_1m_3m_btcxdays` — 1–3 hónap - `cdd_3m_6m_btcxdays` — 3–6 hónap - `cdd_6m_1y_btcxdays` — 6 hónap – 1 év - `cdd_1y_2y_btcxdays` — 1–2 év - `cdd_2y_3y_btcxdays` — 2–3 év - `cdd_3y_5y_btcxdays` — 3–5 év - `cdd_5y_7y_btcxdays` — 5–7 év - `cdd_7y_10y_btcxdays` — 7–10 év - `cdd_10y_plus_btcxdays` — 10+ év A sorok összege visszaadja a teljes napi CDD-t: `CDD_d = Σ_k CDDAgeBandBTCxDays_{d,k}`. Havi aggregálás a sáv-oszlopok napi értékeinek egyszerű összegzésével történik: `CDDAgeBand_{m,k} = Σ_{d ∈ m} CDDAgeBand_{d,k}`. ### Gazdasági értelmezés A CDD age-band tábla azért értékes a közgazdasági kutatásban, mert **az aggregált CDD-nél finomabb, kor szerinti bontású információt** nyújt: 1. **Aggregált CDD dekompozíciója**: a teljes napi CDD-t output-kor szerinti sávokra bontja, így láthatóvá válik, hogy a CDD-spike-ok honnan származnak — nagy értékű közepesen idős outputokból, vagy kisebb értékű nagyon idős outputokból. 2. **Komplementer a spent-value age-band táblához**: míg a spent-value tábla azt mutatja, hogy mennyi BTC mozdult el korosztály szerint, a CDD age-band tábla azt mutatja, hogy mennyi „érmekor” semmisült meg korosztály szerint. A kettő együtt erőteljes diagnosztikai eszköz. 3. **Validációs alap**: a sor-összeg ellenőrzésével közvetlenül verifikálható az aggregált `obm_cdd_btcxdays_daily`. 4. **Részesedés-számítások alapja**: például meghatározható, hogy a napi CDD mekkora hányada származik 1 évnél idősebb outputokból. A szerző fontos figyelmeztetéseket is tesz: a metrika **nem** a tranzakciós volumen, a felhasználói aktivitás vagy az entitás-korrigált settlement érték mérőszáma. Mivel a CDD a spent value-t megszorozza az output korával, **egy kis értékű, de nagyon régi output több CDD-t generálhat, mint egy nagyobb értékű, frissen aktív output**. Továbbá a metrika nyers (raw), nem entitás-korrigált: nem azonosít felhasználókat, entitásokat, tőzsdéket, custodianokat, change outputokat vagy self-transzfereket. A wallet consolidation, a batching, a custodial átszervezés és a belső átutalások mind torzíthatják a megfigyelt CDD-koreloszlást. ### Hasonló nyilvános metrikák és összehasonlítás Az A.3 szakasz részletesen végigveszi a legfontosabb publikus komparátorokat, és hangsúlyozza, hogy **egyik szolgáltató sem publikál pontosan az OBM wide table-jének megfelelő CDD-by-age-band táblát**: - **Glassnode Bitcoin Coin Days Destroyed (CDD)**: skalár sorozat, amely a tranzakcióban lévő coinok számát szorozza az utolsó elköltés óta eltelt napok számával. Konceptuálisan közel áll az OBM aggregált verziójához, de **nem age-band wide table**, így a kor szerinti bontást nem lehet belőle validálni. A pontos összehasonlításhoz szükséges lenne az időbélyeg-konvenciók, az age-számítás, a törtrész-napok kezelése, az entitás-korrekció és a chain-reorg policy harmonizálása. - **CryptoQuant Coin Days Destroyed (CDD)**: szintén skalár, módszertani dokumentációja szerint „amikor egy UTXO megsemmisül, a CDD a keletkezés és az elköltés között eltelt napok számának és a UTXO összegének szorzata”. Aggregált benchmarknak kiváló, de nem age-band komparátor. - **CryptoQuant Spent Output Age Bands**: szerkezetileg közel áll, mert szintén kor-sávok szerint csoportosítja az elköltött outputokat — de **value-alapú, nem CDD-alapú**: a sávonkénti összesített BTC értéket adja meg, nem a BTC-napokat. A CDD-by-age-band táblát csak akkor lehetne belőle származtatni, ha a sávon belüli koreloszlás is ismert. - **Glassnode Spent Output Age Bands (SOAB)**: az elköltött outputok százalékos koreloszlását adja, de **nem BTC-napokat** — így a kor-összetételt igen, de az érték- és kor-súlyozott CDD-magnitúdót nem mutatja. - **Glassnode Spent Volume Age Bands (SVAB)**: az on-chain transfer volumen kor szerinti százalékos bontása. közelebb áll a spent-value age-band táblához, mint a CDD age-band táblához. - **Checkonchain Spent Volume Age Bands**: abszolút és relatív formában is elérhető; a spent-value age-band összehasonlítására és a régi coinok elköltési eseményeinek értelmezésére használható. - **Bitbo CDD Bitcoin Chart**: skalár, API/CSV/XLSX/JSON hozzáféréssel; aggregált komparátornak jó, de age-band felbontású verziót nem ad. - **Coin Metrics TxTfrValDayDst** (Xfer'd Days Destroyed): a tranzferált natív egységek és az utolsó elköltés óta eltelt napok szorzatának összege; jól dokumentált, metric ID-vel ellátott, de **nem wide age-band tábla**. - **Blockchair**: blokk-, tranzakció-, input- és output-szintű explorer adatokat ad, így a CDD-by-age-band tábla **rekonstruálható** belőle (minden elköltött inputot feloldva az előző outputra, kiszámítva a kort, megszorozva az értékkel, sávba sorolva, UTC dátumra aggregálva) — de Blockchair nem publikál ilyen nevű napi wide table-t. - **HODL Waves / UTXO Age Bands**: a jelenlegi **készlet** (stock) koreloszlását írja le, nem az elköltött (flow) koreloszlását. A stock metrikák hasznosak a kontextus megértéséhez, de nem mérik a naponta ténylegesen megsemmisített CDD-t. Az A.3 szakasz végkövetkeztetése: **egyetlen vizsgált publikus szolgáltató sem tesz közzé az OBM wide table-jével pontosan egyenértékű, elnevezett napi táblát**. Az OBM egyedülálló hozzájáradása, hogy reprodukálható, full-node-ból származtatott, BTC-napokban denominált, explicit age-band oszlopokkal rendelkező, nyers spent-output elszámolású, dokumentált UTC időbélyeg-konvenciójú, opcionális sor-összeg validációval és közvetlen összehasonlíthatósággal bíró wide daily table-t publikál. ### Adatforrás és bemeneti követelmények A metrika a perzisztens OBM spent-output indexer adatbázisból exportálódik, és **nem** futtat önálló blockchain-scan-t. Az indexer (leírva a 3.4 szakaszban) egy futó Bitcoin Core full node-ból épül, és a napi age-band aggregátumokat SQLite adatbázisban tárolja. Az A.3 metrika esetében a forrástábla a `daily_age_band_aggregates`, a releváns mezők a `date`, az `age_band` és a `cdd_sats_days`. Az indexer belső tárolási formulája: ``` cdd_sats_days_{d,k} = Σ_{b ∈ B_d} Σ_{i ∈ I_b} v^sats_i · a_i · 𝟏{a_i ∈ k} ``` Az exporter ezt a satoshi-nap értéket BTC-napokra konvertálja: `CDDBand_{d,k} = cdd_sats_days_{d,k} / 100 000 000`. Az exporter script **nem** csatlakozik közvetlenül a Bitcoin Core-hoz, csak a meglévő SQLite adatbázisból olvas. Ellenőrzi, hogy a kért záró dátum nem haladja meg az indexer `max_processed_date` értékét; ha egy kért date-band pár nem létezik a táblában, **nullát** ír (mivel a CDD flow változó: ha nincs hozzájárulás, az érték nulla, nem hiányzó). Az indexer a Bitcoin genesis block-jától kezdve fut, így feltételezi, hogy az adatbázis a teljes történeti feldolgozottságot lefedi. A metrika nem igényel address-extrakciót, user-clusteringet, entitás-azonosítást, külső árfolyamadatokat, harmadik féltől származó API-kat vagy közvetlen Bitcoin Core kapcsolatot az exportáláskor — viszont **függ** a spent-output indexer sikeres korábbi futásától, amely maga igényli a szinkronizált, nem-pruned Bitcoin Core full node-ot és a tranzakció-szintű adatokhoz való hozzáférést. ### Algoritmus (export_obm_cdd_age_band_btcxdays_daily.py) Az export script 14 lépésben dolgozik: 1. A felhasználó által megadott `--start_date` és `--end_date` (YYYY-MM-DD formátumú UTC dátumok, inkluzív) parse-olása. 2. A perzisztens SQLite adatbázis megnyitása a `--state_db` argumentumban megadott útvonalon. 3. Az adatbázis OBM spent-output indexerként való azonosítása: az `indexer_id` és a feldolgozási metaadatok (`last_processed_height`, `last_processed_date`, `max_processed_date`) ellenőrzése. 4. A `daily_age_band_aggregates` tábla és annak kötelező mezőinek (`date`, `age_band`, `cdd_sats_days`) meglétének vizsgálata. 5. A kért `--end_date` nem lehet későbbi, mint az indexer által feldolgozott maximális dátum — különben a script leáll. 6. A dataset release verziójának kikövetkeztetése az indexer metaadatokból; ha nincs release_version mező, a `--release_version` fallback értéket használja. 7. A kért intervallum minden egyes UTC dátumához egy teljes kimeneti sor inicializálása, minden CDD age-band oszlop értékével nullára állítva. 8. A `daily_age_band_aggregates` táblából az összes date-band megfigyelés lekérdezése a kért intervallumban. 9. Minden lekért sorban az `age_band` címke ellenőrzése: ha a várt címkék halmazán kívül esik, a script leáll. 10. A `cdd_sats_days` érték nem-negativitásának és a date-band párok egyediségének ellenőrzése. 11. Átváltás satoshi-napokról BTC-napokra (osztás 100 000 000-rel). 12. A wide table kiírása CSV fájlba: soronként egy UTC dátum, oszloponként egy age-band. 13. Opcionális sor-összeg validáció a `--validate_row_sums` flaggel: az age-band oszlopok összegét összehasonlítja a `daily_aggregates.cdd_sats_days` mezőből származtatott értékkel, a `--row_sum_tolerance` tolerancia mellett (alapértelmezetten 0,00000001 BTC-nap). 14. Opcionális halmozott területdiagram (stacked area plot) generálása a `--plot` flaggel, amely az egyes age-band-ek napi CDD-hez való hozzájárulását szemlélteti. Az exporter nem kérdez le Bitcoin Core-t, nem tart fenn outpoint state-et, és nem rekonstruálja a spent outputokat exportáláskor — minden számításigényes lépés (previous-output feloldás, age számítás, CDD akkumuláció, age-band hozzárendelés) már az indexerben megtörtént. Az export script ezért egy pehelysúlyú, determinisztikus transzformáció az indexed adatbázisból egy széles OBM CSV táblába. ### Metrika-specifikus bemeneti paraméterek - `--state_db`: a perzisztens SQLite adatbázis útvonala, amelyet az `obm_spent_output_indexer.py` generált. Tartalmaznia kell a `daily_age_band_aggregates` táblát és a szükséges metaadatokat. - `--start_date`, `--end_date`: az intervallum kezdő és záró dátuma (UTC, YYYY-MM-DD, inkluzív). - `--release_version`: fallback dataset release verzió, ha az adatbázis nem tartalmaz `release_version` metaadatot. - `--output`: a kimeneti CSV fájl útvonala. - `--validate_row_sums`: opcionális flag a sor-összeg validációhoz. - `--row_sum_tolerance`: tolerancia BTC-napokban, alapértelmezetten 0,00000001. - `--plot`: opcionális flag a halmozott területdiagram generálásához. - `--plot_output`: a plot opcionális kimeneti útvonala; ha nincs megadva, a CSV mellé `.png` kiterjesztéssel kerül. Az exporter **nem** fogadja a Bitcoin Core RPC paramétereket, a `--height_margin`, `--commit_every`, `--min_confirmations` vagy `--reset_state_db` kapcsolókat — ezek az indexerhez tartoznak, nem ehhez az exporterhez. ### Kimeneti formátum A kimeneti CSV egy megfigyelés/UTC dátum és egy oszlop/age-band elrendezésű. A szokásos OBM metaadat-mezők (`series_id`, `release_version`, `unit`, `frequency`) megmaradnak, de a séma kibővül a 12 age-band oszloppal. Minden CDD age-band oszlop 12 tizedesjeggyel van kiírva, ami a törtrész-napok használata miatt fontos. Az age-band oszlopok a `cdd___btcxdays` konvenciót követik (pl. `cdd_1y_2y_btcxdays` = 1–2 éves outputok CDD hozzájárulása BTC-napokban). ### Technikai validáció és ismert korlátok A belső validáció kilenc lépcsős: dátumtartomány-ellenőrzés; SQLite adatbázis megléte és query-only mód; OBM spent-output indexerként való azonosítás; feldolgozási metaadatok megléte; `daily_age_band_aggregates` tábla és mezők megléte; záró dátum nem haladja meg a max feldolgozott dátumot; age-band címkék és nem-negatív értékek ellenőrzése; date-band egyediség; valamint a sor-összeg validáció (amely a `Σ_k CDDAgeBand_{d,k} = CDD_d` azonosságot ellenőrzi a tolerancia mellett). A szerző kilenc explicit korlátot sorol fel: 1. A tábla nyers spent-output coin-age tábla, nem entitás-korrigált — nem azonosít felhasználókat, tőzsdéket, custodianokat, self-transzfereket vagy change outputokat. 2. A blokk időbélyeg-konvenciójától függ (mind az output-kor, mind a blokk-hozzárendelés szempontjából). 3. A rögzített age-band határok miatt kis különbségek egy határ közelében áthelyezhetnek egy outputot egyik oszlopból a másikba. 4. A tábla örökli a CDD-nél használt törtrész-nap konvenciót. 5. A tábla wide és vektor-értékű, nem skalár — a standard skalár OBM sémát váró szoftvereknek külön kell kezelniük. 6. A self-transzferek, wallet consolidation, batching, exchange műveletek és custodial tárcakezelés torzíthatják a megfigyelt CDD-koreloszlást. 7. A metrika BTC-napokat jelent, nem BTC értéket vagy fiat-értéket. 8. A perzisztens spent-output indexer adatbázisra épül, így függ az indexer futás helyességétől és teljességétől. 9. Az indexer egyszerű átszervezés-kezelési politikája inkonzisztencia esetén leáll, de **nem** automatikusan rollback-eli az állapot-adatbázist. A szerző ennek ellenére hasznosnak tartja a metrikát: a napi Bitcoin Days Destroyed átlátható, output-kor szerinti dekompozícióját adja, és jól kiegészíti a skalár CDD, a spent-value, a dormancy, a threshold-alapú CDD és a UTXO-flow metrikákat. ## 2. A.4 — `obm_cdd_btcxdays_daily`: napi összesített Bitcoin Days Destroyed ### Definíció és aggregációs szabály Az A.4 metrika a CDD age-band tábla **sor-összegeként** is felfogható: naponta egyetlen skalár értéket ad meg, amely az adott napon elköltött outputok által megsemmisített összesített coin-age. Formálisan: Legyen `S_d` azon tranzakció-outputok halmaza, amelyeket a `d` naphoz rendelt blokkokban költöttek el. Minden `i ∈ S_d` elköltött outputra legyen `v_i` az értéke BTC-ben, `t_i^created` a keletkezés blokk-időbélyege, és `t_i^spent` az elköltés blokk-időbélyege. Az output kora napokban: ``` a_i = max(0, (t_i^spent − t_i^created) / 86400) ``` Az `i` output hozzájárulása a Bitcoin Days Destroyed-hez: `CDD_i = v_i · a_i`. A napi Bitcoin Days Destroyed sorozat: ``` CDD_d = Σ_{i ∈ S_d} v_i · a_i ``` Egy `b` blokk a `d` UTC naptári naphoz van rendelve a blokk időbélyeg (`t_b`) UTC dátumaként: `d(b) = UTCDate(t_b)`. A mértékegység BTC-nap, mert a metrika egy BTC-ben denominált értéket szoroz a napok számával, ameddig az adott érték inaktív volt. A szerző kiemeli: a „destroyed” (megsemmisült) kifejezés **nem** jelenti azt, hogy a bitcoinok megsemmisültek — csupán azt, hogy az adott output felhalmozott inaktivitási kora nullázódik azáltal, hogy egy tranzakció-input elkölti. ### Gazdasági értelmezés A Bitcoin Days Destroyed egy coin-age metrika, amely **az idősebb coinok mozgását súlyozza jobban**, mint a frissen aktív coinokét. A klasszikus példa: 1 BTC elköltése, amely 1 napig volt inaktív, 1 BTC-nap CDD-t generál; míg 1 BTC elköltése, amely 100 napig volt inaktív, 100 BTC-napot. Hasonlóképpen 10 BTC × 100 nap = 1000 BTC-nap. A közgazdasági kutatásban a metrika azért hasznos, mert **megkülönbözteti a szokásos tranzakciós aktivitást az idős készlet mozgásától**: a magas tranzakció-szám lehet friss turnover, exchange művelet, batching vagy frissen elköltött coinok ismételt mozgatása. Ezzel szemben a CDD-spike azt jelzi, hogy vagy nagy mennyiségű BTC mozdult el, vagy régi coinok mozdultak el, vagy mindkettő egyszerre. A sorozat ezért releváns a long-term holder aktivitás, a dormant készlet mozgása, a coin-age dinamika, a disztribúciós epizódok, valamint az on-chain aktivitás és a piaci viszonyok közötti kapcsolat vizsgálatában. Fontos azonban hangsúlyozni: a metrika **nem** közvetlen mérőszáma a tranzakciós keresletnek, a felhasználószámnak vagy a fizetési volumennek — a CDD a megsemmisített coin-age mértéke. Egy nagy érték származhat néhány nagyon idős outputból, nagyszámú közepesen idős outputból, vagy hosszabb ideig inaktív nagyobb BTC összegekből. A legjobb értelmezés más OBM sorozatokkal (`obm_tx_count_daily`, `obm_block_count_daily`, `obm_spent_value_btc_daily`, jövőbeli dormancy indikátorok) együtt történik. ### Hasonló nyilvános metrikák Az OBM sorozat a „Bitcoin Coin Days Destroyed” vagy „Bitcoin Days Destroyed” metrikák családjával kompatibilis. A definíció szándékosan mechanikai: minden egyes, tranzakció-input által elköltött előző outputra az output BTC-értékét megszorozza a keletkezés és elköltés blokk-időbélyege között eltelt napok számával, majd a napi értéket az ugyanazon UTC naphoz rendelt blokkokban elköltött összes ilyen hozzájárulás összegzésével kapja. **Nem** kísérli meg az entitások, tőzsdék, self-transzferek, change outputok vagy gazdaságilag korrigált transzferek azonosítását — tehát reprodukálható, nyers spent-output Bitcoin Days Destroyed sorozatnak tekinthető. A legközelebbi elnevezett publikus komparátor a **Coin Metrics Xfer'd Days Destroyed (TxTfrValDayDst)**, amely a Coin Metrics dokumentációja szerint „az átutalt natív egységek számának és az utolsó elköltésük óta eltelt napok számának szorzatösszege”. A lekéréshez hitelesítő adatok szükségesek. Ez a metrika a legközelebbi aggregate benchmark, de nem széles age-band tábla — az OBM age-band wide table-jének (A.3) pontos egyenértékese továbbra sincs publikusan elérhető formában. ### Kitekintés Az Appendix A.3 és A.4 metrikák együttesen a CDD-re épülő OBM-skálát alkotják: az A.4 a napi aggregátum, az A.3 a kor-sávok szerinti dekompozíció. A kettő konzisztenciáját az opcionális sor-összeg validáció biztosítja (`Σ_k CDDAgeBand_{d,k} = CDD_d`), és mindkettő ugyanarra a `daily_age_band_aggregates` SQLite táblára épül, amelyet az indexer a teljes Bitcoin-történeten végigfuttat. A teljes OBM-rendszer ezzel a coin-age dimenziót teljes mértékben lefedi — a spent value age-band táblával (amelyet egy korábbi rész tárgyalt) együtt a kutatók számára egyaránt rendelkezésre áll a készlet (UTXO age bands, HODL waves) és a flow (spent value by age, CDD by age) oldali koreloszlás, mind reprodukálható, full-node alapú, dokumentált formában. ## Összefoglalás Ez a rész az Open Bitcoin Metrics tanulmány Appendix A.3 és A.4 szakaszait dolgozta fel. Az A.3 a `obm_cdd_age_band_btcxdays_daily` széles napi táblát definiálja, amely a napi Bitcoin Days Destroyed-t 12 fix output-kor sávra bontja (0d–1d, 1d–1w, 1w–1m, 1m–3m, 3m–6m, 6m–1y, 1y–2y, 2y–3y, 3y–5y, 5y–7y, 7y–10y, 10y+), BTC-nap mértékegységben, nyers spent-output elszámolással. Az A.4 a `obm_cdd_btcxdays_daily` skalár sorozat, amely a napi összesített CDD-t adja meg ugyanazzal a definícióval. Mindkét metrika a perzisztens OBM spent-output indexer adatbázisából exportálódik, és a tanulmány részletes útmutatást ad az adatforrásra, a bemeneti paraméterekre, a 14 lépéses export algoritmusra, a kimeneti formátumra, a belső validációra és az ismert korlátokra vonatkozóan. A szerző kiemeli, hogy **egyetlen publikus szolgáltató sem tesz közzé** az A.3 wide age-band táblával pontosan egyenértékű, elnevezett napi táblát — az OBM egyedülálló hozzájáradása a reprodukálható, teljes Bitcoin-történeten átívelő, age-band felbontású, dokumentált, validálható CDD dekompozíció. --- ## 6. rész ## Áttekintés Ez a rész az *Open Bitcoin Metrics* (arXiv:2607.03124) cikk Appendixének két, összetartozó metrikáját mutatja be részletesen: - **A.4 – obm_cdd_btcxdays_daily**: napi Bitcoin Days Destroyed (CDD) sorozat, amelyet kizárólag spent-output szinten, a Bitcoin Core teljes csomópontból rekonstruálnak. - **A.5 – obm_cdd_per_supply_days_daily**: az előző metrika kínálathoz viszonyított (supply-normalizált) változata, amelyet a CDD és a supply sorozat hányadosaként kapunk. Mindkét metrika a 3.4 alfejezetben leírt OBM spent-output indexer adatbázisára épül, és ugyanazt a szabványos CSV-sémát használja (`date, series_id, value, unit, frequency, release_version`). A fájl az A.5 „Data source and input requirements” alpontjánál félbeszakad — a metrika exportálási algoritmusa, validációja és korlátai egy következő részben kapnak helyet. --- ## A.4 – obm_cdd_btcxdays_daily: napi Coin Days Destroyed ### A metrika fogalma A Bitcoin Days Destroyed (más néven Coin Days Destroyed, CDD) a láncon mozgatott coinok „korát” méri: minden elköltött output esetén az output értékét (BTC-ben) megszorozzuk azzal az idővel, ameddig az adott output pihent (a legutóbbi felhasználás óta eltelt napok számával), majd a nap során elköltött outputokra összegzünk. Az OBM definíciója spent-output szintű, és a törtszámú napokat is megtartja: a kornak a `max(0, (t_spent − t_created) / 86400)` kifejezés adja meg, vagyis ha a chain-reorg miatt az elköltés időbélyege megelőzné a létrehozásét, azt nullaként kezeljük. Formálisan az indexer a `daily_aggregates` tábla `cdd_sats_days` mezőjében tárolja a napi összeget satoshi·nap egységben, majd az exporter ezt osztja `10^8`-nal, hogy BTC·napban kapjuk meg a végeredményt. A metrika kizárólag a nem-coinbase tranzakciók inputjait veszi figyelembe, és a blokkokat azok UTC szerinti naptári dátumához rendeli. ### Összehasonlítás kereskedelmi és nyilvános adatszolgáltatókkal A szerző részletesen, kritikusan hasonlítja össze az OBM-sorozatot a piacvezető CDD-mutatókkal: - **Coin Metrics – TxTfrValDayDst**: a legközelebbi referencia, a metrika azonosítóval és napi intervallum-konvencióval is dokumentált, de Coin Metrics transfer-szinten (nem spent-output szinten) számol, és *teljes napokra* kerekít (a 2,5 nap → 2 nap). Az OBM ezzel szemben törtszámú napokat használ. A kettő közti eltérés a Bitcoin hajnalán (amikor alig volt nem-coinbase tranzakció) a legnagyobb, és az idősor előrehaladtával egyre csökken. Az OBM ezért nem állítja, hogy a sorozat *megegyezik* a TxTfrValDayDst-vel — csak azt, hogy reprodukálható, és hogy az eltérések a konvenció-különbségekből fakadnak. A validációs gyakorlat: hasonlítsunk össze teljes mintát és a legelső 30/90 napot kizáró részmintát is. - **Glassnode – indicators.Cdd**: koncepcionálisan közel áll, de a nyilvános módszertan nem tárja fel a törtszámú napok kezelését, a tranzakció-szintű aggregáció részleteit, a change-outputok vagy a chain-reorgok kezelését. A CSV/JSON/API/Excel/MCP hozzáférés adott, de a teljes reprodukálhatóság nem. - **CryptoQuant – CDD**: a legpontosabb képlet-szintű leírást adja a kereskedelmi szolgáltatók közül (`CDD = Σ lifespan × UTXO value`), de a teljes, node-ból újraépíthető kódot nem teszi közzé. - **Bitbo, Newhedge, Blockchair, Bitcoin Magazine Pro, BitInfoCharts**: hasznos chartokat és vizuális összehasonlítási lehetőséget nyújtanak, de algoritmikus specifikációjuk hiányos. A Bitcoin Magazine Pro free tierje csak 90 napos mozgóátlagot mutat, a BitInfoCharts pedig a CDD-t a teljes kínálatra normalizálja, így inkább az A.5-tel vethető össze. Az OBM szerzőjének végső konklúziója: a legerősebb nyilvános összehasonlítási alap a Coin Metrics, a Glassnode és a CryptoQuant; ezekhez képest az OBM *teljes csomópontból rekonstruálható*, *stabil azonosítójú* és *minden konvencióját dokumentáló* sorozatot kínál. ### Adatforrás és bemeneti igények A metrika a `obm_spent_output_indexer.py` által épített, perzisztens SQLite adatbázisból származik. A releváns tábla a `daily_aggregates`, a releváns mező a `cdd_sats_days`. Az indexer a blokklánc szekvenciális végigpásztázásakor minden egyes nem-coinbase inputra: 1. feloldja az inputot a korábbi outputra (amit elkölt), 2. előhívja az előző output értékét és létrehozási időbélyegét az outpoint-állapotból, 3. kiszámolja az eltelt időt napokban, 4. hozzáadja az érték×kor szorzatot a napi CDD-aggregátumhoz. Az exporter nem kérdez le Bitcoin Core-t közvetlenül, csak a már megépített SQLite-ot olvassa. A CDD-t `satoshi·nap`-ról `BTC·nap`-ra konvertálja (8 tizedesjegyre), és a szabványos OBM CSV-sémát írja. Az exporter nem igényel address-extrakciót, user-klaszterezést, entitás-azonosítást, árfolyamadatokat vagy külső API-kat — viszont feltételezi, hogy a spent-output indexer sikeresen lefutott egy szinkronizált, nem-pruned teljes csomóponttal. ### Algoritmus (export_obm_cdd_btcxdays_daily.py) A kilenc lépéses eljárás lényege: 1. A felhasználó által megadott `--start_date` és `--end_date` UTC-dátumok értelmezése (`YYYY-MM-DD`). 2. A perzisztens SQLite adatbázis megnyitása a `--state_db` útvonalon. 3. Az adatbázis metaadatainak ellenőrzése (`indexer_id`, `last_processed_height`, `last_processed_date`, `max_processed_date`). 4. Annak vizsgálata, hogy a kért záró dátum nem nyúlik-e túl az indexer által feldolgozott tartományon; ha igen, a script leáll. 5. A release-verzió kiolvasása az indexer metaadatából (vagy a `--release_version` fallback alkalmazása). 6. Minden egyes UTC naphoz a `cdd_sats_days` mező kiolvasása; ha nincs sor, a script **nullát** ír. 7. Átszámítás BTC·napra: `CDD_d = cdd_sats_days_d / 100 000 000`. 8. CSV kiírás a szabványos OBM séma szerint. 9. Opcionális PNG-plot generálás (a `--plot_output` argumentummal vagy a CSV mellé). A script nem tart outpoint-állapotot, nem építi újra a spent outputokat, és nem hív Bitcoin Core RPC-t — ez egy „könnyűsúlyú”, determinisztikus transzformáció az indexer-adatbázis és az OBM CSV-formátum között. ### Metrika-specifikus paraméterek - `--state_db`: az indexer SQLite-adatbázisának útvonala. - `--start_date`, `--end_date`: UTC szerinti, befogadó intervallumhatárok. - `--release_version`: fallback release-címke, ha az indexer metaadatában nincs ilyen mező. - `--output`: a kimeneti CSV útvonala. - `--plot`, `--plot_output`: opcionális plot-készítés. A korábbi, önálló CDD-rekonstrukciós scripttel ellentétben ez az exporter **nem fogad** Bitcoin Core RPC paramétereket, `--height_margin`, `--min_confirmations`, `--commit_every` vagy `--reset_state_db` kapcsolókat — ezek mostantól kizárólag az indexerhez tartoznak. ### Aggregációs szabály A napi érték az adott UTC napon elköltött outputokra vett összeg: `CDD_d = Σ_{i ∈ S_d} v_i · max(0, (t_i^spent − t_i^created) / 86400)` ahol `S_d` a dátumhoz rendelt blokkokban elköltött outputok halmaza. A havi változat (ha elérhető) egyszerűen a napi értékek összege. ### Kimeneti formátum Minden sor egy UTC naptári naphoz tartozik, és a következő mezőket tartalmazza: | Mező | Példa | Jelentés | |------|-------|----------| | `date` | 2024-01-01 | UTC dátum | | `series_id` | obm_cdd_btcxdays_daily | stabil OBM azonosító | | `value` | 123456789.12345678 | napi CDD | | `unit` | BTC-days | mértékegység | | `frequency` | daily | gyakoriság | | `release_version` | OBM v0.1.0 | release-címke | ### Technikai validáció A script hat belső ellenőrzést végez: 1. A dátumintervallum érvényessége (`--start_date ≤ --end_date`). 2. SQLite adatbázis megléte, megnyitása query-only módban. 3. A `indexer_id` metaadat ellenőrzése. 4. A feldolgozottságot jelző mezők (`last_processed_height`, `last_processed_date`, `max_processed_date`) megléte. 5. A kért záró dátum nem lépheti túl az indexer által feldolgozott legnagyobb dátumot. 6. Minden napra kiolvassa a `cdd_sats_days` értéket; ha a sor hiányzik, **nullát** ír — ez azért helyes, mert a CDD flow változó: ha egy UTC naphoz nem tartozik CDD-járulék, az értéke definíció szerint nulla, nem pedig „hiányzó adat”. További konzisztencia-ellenőrzésként a szerző kiemeli: az `obm_dormancy_days_daily` sorozatnak minden olyan napra teljesülnie kell, ahol `SpentValueBTC_d > 0`, hogy `Dormancy_d = CDD_d / SpentValueBTC_d`; és az `obm_cdd_per_supply_days_daily` azonos a CDD/supply hányadossal. Külső sorozatokkal (Coin Metrics, Glassnode, CryptoQuant) való összehasonlításkor az eltérések a konvenciók miatt várhatók, és nem tekintendők hibának. ### Ismert korlátok 1. A metrika raw spent-output, **nem entitás- vagy transzfer-korrigált** — nem azonosít felhasználókat, tőzsdéket, self-transzfert vagy change-outputot. 2. A blokkok időbélyeg-konvenciója határozza meg mind az output korát, mind a napi besorolást. 3. A Bitcoin hajnalán a coinbase-outputok és az első nem-coinbase tranzakciók kezelése érzékenyen hat a CDD-re. 4. A reprodukálhatóság feltétele a perzisztens lokális állapotadatbázis megléte. 5. A egyszerű reorg-kezelés inkoherencia esetén leállítja a feldolgozást, de **nem rollbackeli automatikusan** az állapotot. 6. A két, BIP30 előtti ismert duplikált coinbase-tranzakciót a rendszer felismeri és a korábbi `txid:vout` bejegyzést felülírja, de az eseményt a metaadatokban rögzíti. A szerző hangsúlyozza: ez a metrika az OBM egyik központi coin-age indikátora, amely a dormáns kínálat, a hosszú távú tulajdonosok aktivitása, a dormancy, a supply-adjusted CDD és a lánc-magatartás piaci interakcióinak vizsgálatához is alapul szolgál. --- ## A.5 – obm_cdd_per_supply_days_daily: kínálatra normalizált CDD ### Definíció Ez egy származtatott metrika, amelyet két OBM-sorozat hányadosaként állítanak elő: `CDDPerSupply_d = CDD_d / SupplyBTC_d` A számláló (BTC·nap) és a nevező (BTC) hányadosaként az eredmény mértékegysége **nap**. A sorozat azt mutatja, hogy az adott napon megsemmisített coin-kor hány napnyi volt egységnyi bitcoinonként a forgalomban lévő kínálatból — például a 0,015-ös érték azt jelenti, hogy a megsemmisített kor 0,015 nap/bitcoin volt. Ha a nevező nulla (ami kizárólag a Bitcoin legeslegelején fordulhat elő, amikor a választott időbélyeg-konvenció szerint még nincs pozitív kínálat), az OBM **hiányzó értéket** rögzít, nem nullát. Ez a konvenció azért helyes, mert a nulla nevező melletti nulla hányados azt sugallná, hogy nincs coin-korrombolás egy pozitív monetáris bázis mellett — pedig a helyzet az, hogy egyáltalán nincs pozitív bázis, amelyből arányt lehetne számolni. ### Gazdasági értelmezés A CDD-per-supply az elpusztított coin-kort a Bitcoin monetáris bázisához viszonyítja. A szerző négy fő felhasználási területet emel ki: 1. **Összehasonlíthatóság**: a CDD értékei összehasonlíthatóvá válnak olyan időszakok között, amelyekben a forgalomban lévő kínálat merőben más. 2. **A nyers CDD növekedésének szétválasztása**: megkülönböztethető, hogy a CDD-emelkedés a nagyobb bázisnak vagy a szokatlanul intenzív régi-coin-mozgásnak köszönhető. 3. **Long-term holder aktivitás és dormáns kínálat mozgásának vizsgálata**: normalizált coin-age indikátort ad a hosszú távú tulajdonosok aktivitásához. 4. **Aktivitás intenzitás vs. korprofil szétválasztása**: a nyers CDD-vel, tranzakció-számmal, spent value-val és dormancy-indikátorokkal együtt lehetővé teszi, hogy az aktivitás intenzitását elválasszuk az elköltött coinok korprofiljától. Fontos korlát: ez a metrika **nem** közvetlen mérőszáma a tranzakciós keresletnek, a fizetési volumennek, a felhasználói aktivitásnak vagy a bányászbevételnek. Csak a kínálategységre jutó elpusztított coin-kort méri — a magas érték nem azonosítja az érintett entitásokat, a tranzakciók gazdasági célját, és nem mondja meg, hogy a mozgás fizetés, self-transzfer, tőzsdei művelet, letéti átrendezés vagy hosszú távú tulajdonosok elosztása volt-e. ### Hasonló nyilvános metrikák A sorozat a kereskedelmi forgalomban *Supply-Adjusted CDD* néven ismert mutatócsaládba tartozik: - **Glassnode – indicators.CddSupplyAdjusted** (Advanced Plan): a képlete „egyszerűen elosztja a CDD-t a keringő kínálattal”, ami nagyon közel áll az OBM definícióhoz. A Glassnode viszont nem dokumentálja teljes mértékben az alacsony szintű konvenciókat (törtszámú napok, időbélyeg, entitás-korrekció, reorg-kezelés). - **CryptoQuant – sa_cdd**: a kereskedelmi szolgáltatók közül a legpontosabb képlet-szintű leírás, az API-dokumentáció a `sa_cdd = CDD / supply_total` összefüggést adja meg, és a CDD-t is spent-output szinten definiálja. Ennek ellenére a teljes, node-ból rekonstruálható nyílt forráskódot nem teszi közzé. - **Bitcoin Magazine Pro – Supply Adjusted CDD**: a CDD fogalmát és a „coinok teljes számával való osztás” ötletét magyarázza el, de csak 90 napos medián mozgóátlagot tesz közzé, és a számítási konvenciókat nem részletezi. - **MacroMicro, TradingDigits, Checkonchain**: hasznos chartok, de a Checkonchain kifejezetten 7 napos EMA-s (simított) változatot mutat, így az OBM nyers (nem simított) napi sorozatával nem közvetlenül vethető össze. - **Coin Metrics**: nem publikál közvetlenül a CDD-per-supply-nak megfelelő metrikát, de a `TxTfrValDayDst` és a supply sorozat külső kombinációjával előállítható egy hasonló hányados — ez azonban örökli a Coin Metrics teljes-nap konvencióját, és csak másodlagos benchmarként szolgálhat. A szerző végkövetkeztetése: a legerősebb nyilvános megfelelők a Glassnode `indicators.CddSupplyAdjusted` és a CryptoQuant `sa_cdd`; az OBM-sorozat egyedisége, hogy a hányados két, kifejezetten dokumentált forrás-sorozatból (`obm_cdd_btcxdays_daily` és `obm_supply_btc_daily`) származik, stabil azonosítóval, explicit „nap” mértékegységgel, hiányzó-érték konvencióval és visszavezethető auditálhatósággal. ### Adatforrás és bemeneti igények (a rész itt félbeszakad) A metrika két korábban generált OBM CSV-ből indul ki: `obm_cdd_btcxdays_daily.csv` és `obm_supply_btc_daily.csv`. A feldolgozás **nem** kérdez le Bitcoin Core-t és **nem** rekonstruálja a spent outputokat — csupán determinisztikus aritmetikai transzformáció két meglévő idősoron. A bemeneti fájloknak meg kell felelniük a szabványos OBM-sémának (`date, series_id, value, unit, frequency, release_version`). A script ellenőrzi, hogy az első bemeneti sorozat `obm_cdd_btcxdays_daily`, a második pedig… — itt a rész véget ér, a leírás a folytatásban (algoritmus, validáció, korlátok) kapcsán folytatódik. --- ## Kapcsolódás a többi fejezethez Az A.4 és A.5 metrikák szervesen illeszkednek a cikk korábbi részeihez: - A **3.4 fejezetben** bemutatott spent-output indexer biztosítja azt a perzisztens SQLite-állapotot, amelyből az A.4 exporter dolgozik. Az indexer a `daily_aggregates.cdd_sats_days` mezőt a blokklánc szekvenciális feldolgozásakor tölti fel, így az exportálás valóban „könnyűsúlyú” transzformációvá válik. - A **4. fejezet metrikái** között az `obm_cdd_btcxdays_daily` és az `obm_cdd_per_supply_days_daily` a coin-age és dormant-supply indikátorok központi elemei; ezekből származik a dormancy és további normalizált mutatók. - Az **A.1–A.3 szakaszok** az alapvetőbb (tranzakció-, output- és supply-szintű) mutatókat definiálták, amelyekre a CDD-sorozatok mint magasabb rendű származtatottak épülnek. - A **külső benchmark-szolgáltatók** összehasonlítása (Coin Metrics, Glassnode, CryptoQuant, Bitbo, Newhedge, Blockchair, Bitcoin Magazine Pro, MacroMicro, TradingDigits, Checkonchain) egységes módszertani kritériumrendszert alkalmaz: képlet-szintű dokumentáció, nyílt forráskód, alacsony szintű konvenciók (törtszámú nap, időbélyeg, reorg), reprodukálhatóság teljes Bitcoin Core csomópontból. Az OBM ezek közül a nyílt, reprodukálható és auditálható spektrumot tölti be. --- ### Összegzés A 6. rész két, egymásra épülő, coin-age fókuszú OBM-metrikát dokumentál részletesen. Az **obm_cdd_btcxdays_daily** a Bitcoin Days Destroyed nyers, spent-output szintű, teljes Bitcoin Core csomópontból rekonstruálható változata, amelyet a spent-output indexer adatbázisából exportálunk az OBM szabványos CSV-sémájába. Az **obm_cdd_per_supply_days_daily** a CDD és a keringő kínálat hányadosaként előálló, kínálatra normalizált mutató, amely a coin-kor pusztulását a monetáris bázishoz viszonyítva méri „nap per bitcoin” mértékegységben. Mindkét metrika közös jellemzői: stabil azonosító, explicit mértékegység, teljes körű konvenció-dokumentáció (UTC időbélyeg, törtszámú nap, reorg-kezelés, BIP30 duplikátumok kezelése), és a kereskedelmi benchmark-szolgáltatókkal való kritikus, de korrekt összehasonlítás. Az A.4 teljes leírást kap (definíció, összehasonlítás, adatforrás, 9 lépéses algoritmus, paraméterek, aggregáció, output formátum, validáció, korlátok); az A.5 a definícióig, gazdasági értelmezésig, a hasonló nyilvános metrikák áttekintéséig és az adatforrás bemeneti igényeinek első mondatáig jut el, a teljes exportálási eljárás és a korlátok a következő részre maradnak. --- ## 7. rész **arXiv 2607.03124v1 — Diego R. Llanos — 7. rész** Ez a rész az Appendix három, egymáshoz szervesen kapcsolódó metrikadefinícióját tárgyalja. Az A.5-ös szakasz (az obm_cdd_per_supply_days_daily lezáró része) egy derivált, supply-normalizált CDD-metrikát ír le, amely kizárólag két korábbi OBM-sorozat hányadosaként áll elő. Az A.6 (obm_difficulty_eod_daily) a bányászati nehézség végén megfigyelt protokoll-állapotváltozót dokumentálja, és részletes összehasonlítást ad a Coin Metrics DiffLast, DiffMean, valamint a Glassnode, Blockchain.com, BitInfoCharts és CoinWarz nyilvános nehézség-sorozataival. Az A.7 (obm_dormancy_days_daily) definíciójának nyitánya a Bitcoin-hálózat egyik klasszikus on-chain mutatóját, a napi dormancy-t vezeti fel: az adott napon elköltött UTXO-k értékkel súlyozott átlagos életkorát napokban. Ez a metrika a 8. részben folytatódik. --- ## A.5 folytatása — `obm_cdd_per_supply_days_daily` (lezáró rész) ### Az algoritmus 13 lépése A `compute_obm_cdd_per_supply_days_daily.py` script a következő eljárást valósítja meg: 1. Beolvassa az `obm_cdd_btcxdays_daily` CSV-fájlt (első kötelező pozicionális argumentum). 2. Beolvassa az `obm_supply_btc_daily` CSV-fájlt (második kötelező pozicionális argumentum). 3. Mindkét fájlon sémavalidációt futtat: a kötelező mezők a `date`, `series_id`, `value`, `unit`, `frequency`, `release_version`. 4. Ellenőrzi, hogy a két sorozat azonosítója valóban `obm_cdd_btcxdays_daily` és `obm_supply_btc_daily`. 5. Ellenőrzi a mértékegységeket (a CDD-sorozat BTC-days, a supply-sorozat BTC) és a `daily` frekvenciát. 6. Meghatározza a feldolgozandó dátumintervallumot: ha a felhasználó megadja a `--start_date` és `--end_date` kapcsolókat, azokat használja, egyébként a két forrásfájl közös átfedésének határait. 7. Ellenőrzi, hogy minden dátumra pontosan egy megfigyelés essen mindkét fájlban — ha bármelyik dátum hiányzik, a script leáll. 8. Minden `d` dátumra beolvassa a `CDD_d` és `SupplyBTC_d` értékeket, és meggyőződik arról, hogy mindkettő nem-negatív. 9. Ha `SupplyBTC_d > 0`, kiszámolja a hányadost: `CDDPerSupply_d = CDD_d / SupplyBTC_d`. 10. Ha `SupplyBTC_d = 0`, az eredményt nem nullaként, hanem hiányzó értékként rögzíti. 11. A kiválasztott intervallumban inferálja a `release_version` értéket; ha több release-verzió keveredne, a script leáll, nehogy összemossa azokat. 12. A kész idősort a szabványos OBM-sémával írja ki. 13. Opcionálisan ábrát készít, amelyből a hiányzó értékeket reprezentáló sorok kimaradnak. ### Bemeneti paraméterek A metrika-specifikus kapcsolók a `cdd_csv` és a `supply_csv` (mindkettő kötelező pozicionális argumentum), valamint a `--start_date` és `--end_date` (opcionális; alapértelmezésben a két forrás közös határai). A szkript a többi OBM-szkripttel megegyező módon támogatja a `--output`, `--plot`, `--plot_output` kapcsolókat. Bitcoin Core RPC-paraméterekre nincs szükség, mert a metrika nem a blokkláncból, hanem determinisztikus transzformációval keletkezik. ### Aggregációs szabály A metrika nem blokk- vagy tranzakció-szintű aggregáció, hanem két napi OBM-sorozat pontonkénti hányadosa. Az egyenlet a korábbiakhoz hasonlóan: `CDDPerSupply_d = CDD_d / SupplyBTC_d`, ahol `SupplyBTC_d > 0`. A szerzők hangsúlyozzák, hogy **havi szinten az arányt nem szabad a napi hányadosok számtani átlagaként előállítani**. Értelmezhetőbb havi verzió a következő: a havi CDD-t összegezzük, és a nevezőbe a hónap végi (`end-of-month`) supply-állományt helyezzük, azaz: `CDDPerSupply_m = CDD_m / SupplyBTC_m^{EOM}`, ahol `CDD_m = Σ_{d∈m} CDD_d`. Ez azért fontos, mert így a havi érték konzervatív módon, a hónap végi kínálatra normalizáltan őrzi meg a "havi elpusztított coin-életkor" jelentést. Alternatív nevező (pl. havi átlagos supply) csak dokumentált formátumban használható. ### Kapcsolat a forrásmetrikákkal A sorozat közvetlenül az `obm_cdd_btcxdays_daily` (napi elpusztított coin-életkor, BTC-days) és az `obm_supply_btc_daily` (forgalomban lévő bitcoin-készlet, BTC) hányadosa. A dimenzióelemzés is világos: BTC-days / BTC = days, vagyis a kapott érték mértékegysége nap. A szerzők kiemelik, hogy ez az identitás egyben **validációs egyenlőség** is: ha a nyers CDD-sorozat és a `CDDPerSupply_d × SupplyBTC_d` szorzat eltérne, az vagy időbélyeg-eltérést, vagy forrásfájl-, implementációs-, kerekítési- vagy release-verzió inkonzisztenciát jelezne. ### Kimeneti formátum és technikai validáció Minden UTC-dátumhoz egy sor tartozik, az oszlopok: `date`, `series_id` (`obm_cdd_per_supply_days_daily`), `value` (12 tizedesjegy pontosságú, pl. 0.012345678901), `unit` (days), `frequency` (daily), `release_version` (a forrás-intervallumból örökölt, pl. OBM v0.1.0). Ha a supply nulla, a `value` mező üres marad — ez a hiányzó érték konvenciója, nem a nulla. A validációs lépések között szerepel: (1) a forrásfájlok OBM-sémának való megfelelése, (2) a sorozat-azonosítók egyezése, (3) a mértékegységek és a frekvencia ellenőrzése, (4) a kiválasztott intervallum minden dátumának pontosan egyszeri lefedése, (5) a forrásértékek nem-negativitása, (6) a hiányzó érték kizárólag `SupplyBTC_d = 0` esetén, valamint (7) a release-verziók keveredésének tilalma. Az elsődleges és másodlagos identitás a fenti két egyenlet. ### Ismert korlátok A metrika egyszerű és reprodukálható, de nem független teljes csomóponti rekonstrukció. Örökli a forrásmetrikák definíciós döntéseit, időbélyeg-konvencióit és esetleges revízióit. Akkor definiálatlan, amikor a supply nulla — ekkor a rendszer hiányzó értéket rögzít. A metrika nem entitás-korrigált és nem tranzfer-korrigált, mivel a forrás-CDD nyers spent-output mérőszám. Nem azonosít sem felhasználót, sem entitást, sem tőzsdét, sem custodian-t, sem self-transzfert, sem change outputot. Fontos hangsúlyozni, hogy **nem értelmezhető tranzakciós keresletként, fizetési volumenként vagy átvitt gazdasági értékként**. E korlátok ellenére a sorozat hasznos kutatási eszköz: a dormant-kínálat mozgását, a hosszú távú birtokosok aktivitását, a coin-age-dinamikát és a különböző kínálati szintek közötti on-chain viselkedés-összehasonlítást támogatja. --- ## A.6 — `obm_difficulty_eod_daily`: nap végi bányászati nehézség ### Definíció és közgazdasági értelmezés Az end-of-day bányászati nehézség-sorozat azt a nehézséget jelenti, amelyet az adott UTC-naptári naphoz rendelt **utolsó** (legmagasabb magasságú) blokk fejléce hordoz. A nehézség protokoll-állapotváltozó, nem napi flow, ezért end-of-day megfigyelésként rögzül, nem összegként vagy átlagként. A mértékegység a `difficulty` címke, és nem ismétlődik a sorozat azonosítójában. Formálisan: ha `B_d` a `d` naphoz rendelt blokkok halmaza, és `D_b` a Bitcoin Core által jelentett nehézség az adott blokkra, akkor: `DifficultyEOD_d = D_{b*}`, ahol `b* = arg max_{b∈B_d} h_b`. A blokk hozzárendelése a dátumhoz a `d(b) = UTCDate(t_b)` szabállyal történik, vagyis kizárólag a blokk timestampjének UTC szerinti naptári dátuma számít. Ha egy naphoz egyetlen blokk sem tartozik, a sorozat az adott dátumra definiálatlan, és a kimeneti érték `NaN` — így a protokoll-állapotváltozóhoz nem rendelődik megtévesztő nulla. ### Gazdasági értelmezés A Bitcoin bányászati nehézsége azt méri, hogy a referencia nehézséghez képest mennyire nehéz érvényes proof-of-work blokkot előállítani. A protokoll rendszeres újraszabályozással biztosítja a hozzávetőleges tízperces átlagos blokk-intervallumot. A metrika négyféle kutatási felhasználásra alkalmas: - a bányászok által a nap végén tapasztalt protokoll-szintű bányászati kondíciók megragadására, - a nehézség-újraszabályozási ciklusok és a bányászat-dinamika vizsgálatára, - a bányászbevételek és tranzakciós díjak elemzésével kombinálva a bányászati ösztönzések vizsgálatára, - valamint becsült hashrate-számítások inputjaként (a hashrate közvetlenül nem megfigyelhető on-chain, becslést igényel). Fontos, hogy a metrika **nem azonosítható megfigyelt hashrate-tel**, bányászati jövedelmezőséggel, tranzakciós kereslettel, felhasználói aktivitással vagy hálózathasználattal. A nehézség lépcsőzetes protokoll-állapotváltozó, amely csak a retarget-határokon változik — a tranzakciószámtól, a díjaktól és a block-weighttól eltérően lassan mozgó sorozat. ### Hasonló nyilvános metrikák — részletes összehasonlítás A szerzők öt fő külső forrást vetnek össze az OBM-mel: - **Coin Metrics `Difficulty` (`DiffLast`)** — a legerősebb közvetlen komparátor. Definíció szerint az utolsó blokk nehézsége a vizsgált időszakban, ami megegyezik az OBM end-of-day konvenciójával. A Coin Metrics `Mean Difficulty` (`DiffMean`) rokon, de kevésbé közvetlenül összehasonlítható, mert az OBM szándékosan nem átlagolja a lépcsős protokoll-állapotváltozót. A szerzők hangsúlyozzák, hogy a `DiffLast` és az OBM közötti pontos egyenlőség nem feltételezhető az intervallum-határ-konvenciók, az időbélyeg-hozzárendelés, a lánc-átszervezési (reorg) politika és a no-block dátumok kezelése nélküli ellenőrzés nélkül. - **Glassnode** — biztosít Bitcoin bányászati nehézség-chartokat és oktatási anyagot. Dokumentációja leírja, hogy a nehézség-újraszabályozás 2016 blokkonként történik, de kevésbé explicit a napi aggregáció módjában (utolsó, átlag, forward-fill), ezért a Glassnode sorozatait a külső összehasonlításnál a konvenciót érdemes külön ellenőrizni. - **Blockchain.com** — `Network Difficulty` chart. Fogalmilag közeli komparátor, de a nyilvános oldal nem specifikálja, hogy a napi megfigyelés end-of-day, átlag, forward-fill vagy más konvenció. A no-block dátumok, időbélyeg-határok és történeti revíziók kezelése sincsen teljesen dokumentálva, ezért inkább hasznos chart-referencia, mintsem teljesen auditálható módszertani benchmark. - **BitInfoCharts** — `Bitcoin Difficulty` chart, amely explicit módon `Average mining difficulty per day` címkével ellátott. Mivel a Bitcoin nehélység állandó egy nehézségi epochon belül, és csak a retarget-határokon változik, az átlag és az end-of-day értékek hagyományos napokon gyakran egybeesnek, de retarget-napokon vagy határ-konvenciók esetén eltérhetnek. - **CoinWarz** — `Bitcoin Difficulty Chart`; elsősorban bányászkalkulátor és chart-forrás. A nyilvános oldal nem ad elég módszertani részletet a historikus napi értékek aggregációjáról, ezért csak másodlagos komparátorként használható. A szerzők külön kiemelik, hogy a **hashrate-chartok nem közvetlen összehasonlítói** az OBM nehézség-sorozatnak. A Blockchain.com `total hash-rate` chartja például a nehézséget a blokktermelési feltételezésekkel kombinálja egy becsült értékké; az OBM nehézség ehelyett közvetlenül megfigyelt protokoll-állapotváltozó, amely a blokk-metaadatokból kinyerhető. A **legerősebb közvetlen komparátor tehát a Coin Metrics `DiffLast`**, mivel explicit módon az intervallum utolsó blokkjának nehézségét jelenti, és ez megegyezik az OBM end-of-day konvenciójával. A Coin Metrics `DiffMean`, a BitInfoCharts átlaga, a Blockchain.com, a Glassnode és a CoinWarz chartok hasznos referencia-sorozatok, de aggregációs konvencióik eltérhetnek vagy nem teljesen dokumentáltak. Az OBM egyedisége, hogy (1) a napi megfigyelést pontosan a legmagasabb magasságú blokk nehézségeként definiálja, (2) `NaN`-t ír, ha nincs blokk, (3) a Bitcoin Core blokk-szintű nehézség-mezejét használja, és (4) explicit módon dokumentálja a blokk időbélyeg-konvenciót és a magasság-margin pásztázást, amely a reprodukálhatósághoz szükséges. ### Adatforrás és bemeneti követelmények A metrikát futó Bitcoin Core teljes csomópontból nyerik a JSON-RPC interfészen keresztül. Minden blokkra a `getblock 1` hívás dekódolt blokk-objektumából olvassák ki a nehézséget. A metrika **nem igényli** a korábbi tranzakció-kimenetek rekonstrukcióját, a spent-output indexer adatbázist, a tranzakció-szintű input-feloldást, a cím-kivonatolást, a felhasználói klaszterezést, az entitás-azonosítást, külső árfolyam-adatokat vagy harmadik fél API-jait. A `txindex=1` sem szükséges, mert a szükséges információ a blokk metaadatokból elérhető. A script a lokálisan verifikált fő láncot használja, és a Bitcoin Core által visszaadott blokk időbélyeget alkalmazza a UTC-dátum hozzárendeléshez. ### Algoritmus A `compute_obm_difficulty_eod_daily.py` 11 lépésben dolgozik: 1. A felhasználó által megadott dátumintervallumot parse-olja `YYYY-MM-DD` formátumban, UTC-s dátumként értelmezve, mindkét határ inklúzív. 2. A kezdő dátumot a nap `00:00:00 UTC` timestampjévé, a záró dátumot `23:59:59 UTC` timestampjévé alakítja. 3. Kapcsolódik a helyi Bitcoin Core csomóponthoz (explicit RPC, környezeti változók vagy cookie-auth). 4. A `getblockchaininfo` hívással lekéri az aktuális fő lánc magasságot. 5. Becsült magasság-intervallumot keres a kért dátumtartományhoz, blokk időbélyegek és bináris keresés segítségével. 6. A becsült intervallumot a `--height_margin` biztonsági paraméterrel kibővíti (ennek oka, hogy a Bitcoin blokk-időbélyegek nem szigorúan monotonok a magasság függvényében). 7. A kért intervallum minden dátumát inicializálja hiányzó értékkel — így a kimenet minden UTC-dátumra tartalmaz sort, a no-block dátumokra is. 8. Minden magasságra a kibővített intervallumban: `getblockhash` → `getblock` (verbosity=1) → timestamp → UTC-dátum-hozzárendelés → kiszűrés, ha dátum kívül esik → difficulty mező kiolvasása → összehasonlítás az adott dátumhoz tárolt utolsó blokk magasságával → tárolás, ha ez a blokk a legmagasabb. 9. Minden kiválasztott UTC-dátumra a tárolt nehélységet írja ki, ha van blokk; egyébként `NaN`-t. 10. A kész idősort a szabványos OBM-sémával írja ki. 11. Opcionálisan ábrát készít, ha a `--plot` flag aktív. A script tehát közvetlenül a dekódolt blokk metaadatokból dolgozik, nem kérdezi le a spent-output indexert, nem old fel tranzakció inputokat, és nem rekonstruál korábbi kimeneteket. ### Metrika-specifikus paraméterek Az egyetlen metrika-specifikus kapcsoló a `--height_margin`, amely a kért dátumtartományhoz tartozó becsült magasság-intervallum két oldalán pásztázandó extra blokkok számát adja meg. A script a becsült intervallumot így terjeszti ki: `h_min^{scan} = max(0, h_min^{approx} - m)`, `h_max^{scan} = min(h_tip, h_max^{approx} + m)`. Az alapértelmezett érték **288 blokk, vagyis hozzávetőlegesen két napnyi várható blokktermelés** — ez tudatosan konzervatív. A margin csak a belső blokk-pásztázást szélesíti; a script továbbra is csak azokat a blokkokat veszi figyelembe, amelyek UTC-s dátuma a kért intervallumba esik. Ezen felül a szkript támogatja a szokásos RPC, output, release-verzió és plot kapcsolókat: `--rpc_url`, `--rpc_user`, `--rpc_password`, `--cookie_path`, `--use_default_cookie`, `--rpc_timeout`, `--output`, `--release_version`, `--plot`, `--plot_output`, `--quiet`. ### Aggregációs szabály A nehézség nem aggregálódik flow-ként. A napi érték: `DifficultyEOD_d = D_{b*}`, ahol `b* = arg max_{b∈B_d} h_b`. Ha nincs blokk, `B_d = ∅`, és a metrika definiálatlan — a kimenetben `NaN`. Havi szinten **a napi értékek összege vagy számtani átlaga nem megengedett**. Mivel a nehézség protokoll-állapotváltozó, a havi verziót end-of-month megfigyelésként kell előállítani: `DifficultyEOM_m = DifficultyEOD_{d*}`, ahol `d*` a hónap utolsó olyan dátuma, amelyre van difficulty-megfigyelés. Alternatívaként havi átlag is konstruálható specifikus empirikus célokra, de azt külön konvencióként kell dokumentálni. ### Kimeneti formátum és technikai validáció A kimenet minden UTC-dátumra egy sort tartalmaz, 12 tizedesjegy pontossággal (pl. `73197634206448.906250000000`). Az oszlopok: `date`, `series_id` (`obm_difficulty_eod_daily`), `value`, `unit` (`difficulty`), `frequency` (`daily`), `release_version` (pl. OBM v0.1.0). A no-block dátumok `NaN` értéket kapnak. A `unit` mező a `difficulty` címkét viseli — bár a nehézség dimenziómentes, ez a label informatívabb, mint egy általános "dimenziómentes" megjelölés. A belső validáció tíz lépést ölel fel: a dátumtartomány érvényessége, a `--height_margin` nem-negativitása, az RPC-auth (cookie-formátum-ellenőrzéssel), a `getblockchaininfo` lánctippel való kapcsolat, a magasság-intervallum megkeresése és kibővítése, a kért intervallumba eső blokkok kiszűrése, a difficulty mező jelenléte minden figyelembe vett blokkban, a negatív nehézség-értékek elutasítása, a legmagasabb magasságú blokk kiválasztása és a `NaN` kiírása a no-block dátumokra. További konzisztencia-ellenőrzések: ha `obm_block_count_daily` pozitív egy adott dátumra, akkor `obm_difficulty_eod_daily` általában definiált; ha a blokkszám nulla, a difficulty `NaN`. A nehézség a retarget-periódusokon belül állandó, és csak a nehézség-újraszabályozási határokon változik — a nagy ugrásoknak tehát a retarget-magasságokkal, nem tetszőleges dátumokkal kell egybeesniük. Külső validációhoz a nyilvános nehézség-sorozatokkal való összevetés megengedett, de körültekintéssel: a külső források aggregációs konvenciói eltérhetnek. ### Ismert korlátok A sorozat átlátható és reprodukálható, de fontos korlátokkal bír: - End-of-day értéket jelent, nem napi átlagot. - A definíció a legmagasabb magasságú blokkra épül, ezért függ a blokk időbélyeg-konvenciótól. - A no-block dátumok `NaN`-ként szerepelnek, nincs forward-fill. Aki teljesen kitöltött állapotsorozatot szeretne, downstream transzformációként forward-fillelheti az OBM kimenetet, de ez nem része az elsődleges definíciónak. - A nehézség nem megfigyelt hashrate; a hashrate a nehézségből és a megvalósult blokktermelésből becsülhető egy választott ablakon. - A metrika nem méri közvetlenül a bányászat jövedelmezőségét, a tranzakciós keresletet, a hálózathasználatot vagy a gazdasági aktivitást. - A számítás közvetlenül a dekódolt blokk metaadatokból történik, a spent-output indexer nem szükséges. Mindezek ellenére az `obm_difficulty_eod_daily` hasznos OBM protokoll-állapotsorozat: egyszerű, teljes csomópontból származtatott, és kiegészíti a blokkszám, block-weight, díjak, bányászbevétel, kibocsátás és a jövőben becsült hashrate metrikákat. --- ## A.7 — `obm_dormancy_days_daily`: napi dormancy (definíció nyitánya) A hetedik appendix-szakasz a napi dormancy-sorozat definícióját vezeti be. A metrika az adott UTC-naptári naphoz rendelt blokkokban elkölött outputok **értékkel súlyozott átlagos életkorát** méri napokban. A blokkok halmazát itt is `B_d` jelöli, és a definíció a coinbase-kimenetek kizárásával dolgozik — ezt a részletes képletet és a kapcsolódó metrikát (várhatóan az `obm_dormancy_days_daily` teljes algoritmusa, a forrásmetrikák, az aggregációs szabály és a kimeneti formátum) a 8. rész tárgyalja. A dormancy a Bitcoin-hálózat egyik klasszikus, hosszú távú birtokosok aktivitását jellemző on-chain mérőszáma. A Bitcoin "coin age" koncepciójára épül: minden UTXO életkora az utolsó mozgása óta eltelt napok száma, és az adott napon elköltött outputok életkorainak értékkel súlyozott átlaga megadja, hogy a nap során "alacsony alvó" vagy "régóta tartott" coinok mozdultak-e meg. Ez a metrika később a 8. részben a CDD-vel is összekapcsolódik majd, hiszen a CDD (az előző fejezetekben tárgyalt `obm_cdd_btcxdays_daily`) és a dormancy közötti kapcsolat: `CDD_d = Dormancy_d × DestroyedValue_d`. A konkrét formula, az input-követelmények, a validációs lépések és a kimeneti séma a következő részben folytatódnak. --- ## Összefoglalás a 7. rész tartalmáról Ez a rész az OBM-Appendix három, egymásra épülő metrikáját dokumentálja: 1. **A.5 lezárása** — az `obm_cdd_per_supply_days_daily` mint derivált, két forrás-sorozat hányadosaként előálló metrika: algoritmus, paraméterek, aggregációs szabály, kimeneti formátum, validációs identitások és ismert korlátok. 2. **A.6 teljes definíció** — az `obm_difficulty_eod_daily`, a nap végi bányászati nehézség protokoll-állapotváltozóként; részletes összehasonlítás a Coin Metrics, Glassnode, Blockchain.com, BitInfoCharts és CoinWarz megfelelőivel; magasság-margin-alapú biztonságos blokk-pásztázás; end-of-day aggregációs konvenció. 3. **A.7 bevezető** — az `obm_dormancy_days_daily` definíciójának nyitánya, amely a 8. részben folytatódik a teljes algoritmussal, a forrásmetrikákkal és a kimeneti formával együtt. A három metrika együttesen a Bitcoin-hálózat három nagyon különböző aspektusát ragadja meg: a kínálat-normalizált coin-életkor-pusztulást, a bányászati protokoll-állapotot, és az elköltött outputok életkor-súlyozott dinamikáját. Mindhárom esetben az OBM alapelve érvényesül: a mérőszámok vagy közvetlenül a Bitcoin Core teljes csomópontból származnak, vagy determinisztikus, auditálható transzformációként keletkeznek, és minden esetben a teljes reprodukálhatóságot szolgáló, explicit módszertani leírás és validációs egyenlőség áll rendelkezésre. --- ## 8. rész Ez a részlet az arXiv 2607.03124 számú, Diego R. Llanos „Open Bitcoin Metrics” című cikkének nyolcadik feldolgozott darabja. A korábbi hét rész a Methods fejezetet, valamint az Appendix A.1–A.6 metrikáit (block_count, block_weight, cdd_age_band, cdd, cdd_per_supply, difficulty) járta körül. A nyolcadik rész az Appendix A.7 (dormancy) metrika leírásának második felét, valamint az Appendix A.8 (estimated 7-day network hashrate) metrika definícióját, gazdasági értelmezését és a publikus komparátorokkal való összevetését tartalmazza. A dokumentum itt véget ér, így az A.8-hoz tartozó algoritmus, output formátum és limitációk a következő részben folytatódnak. ## A.7 obm_dormancy_days_daily – A napi dormancy ### Definíció A napi dormancy az adott napon elkölött coinok értékkel súlyozott átlagos életkorát méri. A mértékegysége nap, és a Bitcoin Days Destroyed (CDD) és a napi spent output value hányadosaként adódik: $$\mathrm{Dormancy}_d = \frac{\mathrm{CDD}_d}{\mathrm{SpentValueBTC}_d}, \quad \mathrm{SpentValueBTC}_d > 0.$$ A CDD definíciója megegyezik a korábbi A.4 metrikánál ismertetettel: minden egyes nem-coinbase tranzakciós inputra a költött output BTC-értéke szorozva az adott output korával (napokban, a két blokk timestampje közti különbség 86 400-zal osztva, a negatív korokat nullára vágva). A SpentValueBTC pedig a költött outputok teljes BTC-értéke, coinbase-ek nélkül. Ha a nevező nulla, a dormancy nem értelmezhető, és az OBM hiányzó értéket (NaN) ír, nem nullát – ez fontos konvenció, mert a nulla dormancy azt jelentené, hogy pozitív értéknek nulla az átlagos kora, ami értelmetlen. A blokkok UTC naptári naphoz rendelése a blokk timestampjéből történik: $d(b) = \mathrm{UTCDate}(t_b)$. ### Gazdasági értelmezés A dormancy szétválasztja a költött érték mennyiségét és a költött érték korprofilját. Egy magas spent value jelezheti, hogy sok BTC mozog, míg egy magas dormancy érték arra utal, hogy a mozgatott coinok átlagosan hosszú ideig inaktívak voltak. A cikk egy egyszerű számpéldát is ad: ha egy napon 1 BTC 10 napos kort és 3 BTC 20 napos kort költenek el, akkor CDD = 1×10 + 3×20 = 70 BTC-day, a spent value 4 BTC, így a dormancy 17,5 nap. A metrika közgazdasági szempontból hasznos alvó készlet aktivációjának, hosszú távú birtokosok viselkedésének, disztribúciós epizódoknak, UTXO-forgalomnak, valamint a coin-életkor dinamikája és a piaci feltételek kapcsolatának vizsgálatához. Ugyanakkor a cikk hangsúlyozza, hogy a dormancy **nem** azonos a tranzakciószámmal, a fizetési volumennel, a felhasználói aktivitással vagy az entitás-korrigált gazdasági settlement értékkel. Nyers, spent output alapú, entitás-korrekció nélküli mérőszám, amely nem azonosít felhasználókat, entitásokat, tőzsdéket, vagyonkezelőket, change outputokat vagy self-transzferket. ### Hasonló publikus metrikák A legerősebb publikus komparátorok: - **Glassnode AverageDormancy** (`indicators.AverageDormancy`): definíciója a coin days destroyed és a transfer volume hányadosa, ami koncepcionálisan nagyon közel áll az OBM definícióhoz. A fő különbség, hogy a Glassnode a saját transfer volume konvencióját használja, míg az OBM a nyers spent output value-t. - **CryptoQuant average_dormancy** (és `sa_average_dormancy`): szintén CDD / mozgatott coin volumen. A `sa_average_dormancy` supply-adjusted, így az OBM-mel nem közvetlenül összehasonlítható. - **Coin Metrics**: nincs közvetlenül elnevezett dormancy metrika, de a `TxTfrValDayDst / TxTfrValNtv` hányadosból származtatható egy proxy. Ez a Coin Metrics saját transfer value és days-destroyed konvencióit örökli, ezért csak component-based komparátorként kezelendő. - **Bitbo dormant coins chart** és **Checkonchain coin-age chartok**: dormant-supply stock mutatók, nem napi átlagos spent age flow-k. - **Dormancy Flow** (Glassnode): holdings és a coin-day destruction rolling annual USD értékének aránya, inkább értékelési/ciklus indikátor, nem közvetlen egyenértékese a napi dormancy-nek. Az OBM sajátossága, hogy két ellenőrizhető forrás-sorozatból (`obm_cdd_btcxdays_daily` és `obm_spent_value_btc_daily`) építkezik, dokumentált hiányzó-érték konvenciót használ, és kerüli a szabadalmaztatott entitás-korrekciós heurisztikákat. ### Adatforrás és bemeneti követelmények A metrika az OBM spent-output indexer adatbázisából exportálódik, nem önálló blokklánc-szkenneléssel. Az indexer a Bitcoin Core full node futásából épül, és a `daily_aggregates` SQLite táblában tárolja a `cdd_sats_days` és `spent_value_sats` mezőket. Mindkettőt az indexer a lánc szekvenciális végigpásztázásakor számítja ki. Mivel a számítás satoshis egységben történik, a BTC-re váltás a hányados előtt kiesik, így a kapott érték egysége automatikusan nap. Az exportáló script (`export_obm_dormancy_days_daily.py`) a Bitcoin Core-t nem kérdezi le, csak a meglévő SQLite adatbázisból olvas. Bemeneti paraméterei: `--state_db` (az indexer adatbázis elérési útja), `--start_date` és `--end_date` (UTC dátumok YYYY-MM-DD formátumban), `--release_version` (fallback, ha az adatbázis metaadatokból nem nyerhető ki), `--output` (CSV kimenet), valamint opcionálisan `--plot` és `--plot_output` (ábra generáláshoz, ahol a NaN értékek kimaradnak). ### Algoritmus 1. A megadott dátumintervallum értelmezése UTC-ben, inkluzív határokkal. 2. A perzisztens SQLite adatbázis megnyitása read-only módban. 3. Az indexer metaadatok validálása (`indexer_id`, `last_processed_height`, `last_processed_date`, `max_processed_date`). 4. Annak ellenőrzése, hogy a kért `--end_date` nem haladja meg az indexer által feldolgozott maximális dátumot. 5. A release version kiolvasása az adatbázisból, fallback a `--release_version` paraméterre. 6. Minden UTC dátumra a `cdd_sats_days` és `spent_value_sats` kiolvasása a `daily_aggregates` táblából. 7. Ha `spent_value_sats > 0`, a dormancy kiszámítása a két érték hányadosaként. 8. Ha a sor hiányzik vagy a nevező nulla, a cella értéke NaN. 9. Az eredmény kiírása az OBM standard CSV sémába: `date`, `series_id`, `value`, `unit`, `frequency`, `release_version`. 10. Opcionálisan ábra generálása a definiált értékekből. ### Aggregációs szabály A dormancy nem egyszerű összegzéssel aggregálható. A napi érték a két napi aggregátum hányadosa. Havi dormancy-t nem szabad a napi dormancy-értékek számtani átlagaként számolni. Az interpretálható havi verzió: előbb összegezzük a havi CDD-t és a havi spent value-t, majd ezek hányadosát vesszük. Ez megőrzi azt az értelmezést, hogy a dormancy az adott időszakban költött coinok értékkel súlyozott átlagos életkora. ### Kimeneti formátum A CSV minden UTC dátumra egy sort tartalmaz: `date` (pl. 2024-01-01), `series_id` (`obm_dormancy_days_daily`), `value` (szám vagy NaN), `unit` (days), `frequency` (daily), `release_version` (pl. OBM v0.1.0). A NaN értékek a definíció szerint hiányzó arányt jelentenek, nem nullát. ### Technikai validáció Az exportáló script a következő ellenőrzéseket végzi: érvényes dátumintervallum, az adatbázis létezik és megnyitható read-only módban, a metaadatok OBM spent-output indexerként azonosítják, a `daily_aggregates` tábla jelen van, a kért záró dátum nem haladja meg az indexer által feldolgozott maximális dátumot. További konzisztencia-ellenőrzés, hogy a kiírt sorok száma megegyezik a naptári napok számával az intervallumban, és minden definiált érték nem-negatív. Az elsődleges validációs azonosság: $\mathrm{CDD}_d = \mathrm{Dormancy}_d \times \mathrm{SpentValueBTC}_d$ minden olyan dátumra, ahol a dormancy értelmezhető. Ez az azonosság csak akkor áll fenn, ha mindhárom sorozat ugyanabból az indexer release-ből származik. ### Ismert limitációk A szerző hangsúlyozza, hogy a napi dormancy hasznos, de definíció-érzékeny metrika. Először is, nyers spent-output metrika, nem entitás- vagy transfer-korrigált; örökli a CDD és a spent value korlátozásait. Másodszor, függ a blokk timestamp konvenciótól mind az output korának számításában, mind a blokkok naptári naphoz rendelésében. Harmadszor, a nulla spent value-jú napokon a metrika nem értelmezhető, és az OBM ezeket NaN-ként rögzíti. Negyedszer, self-transzferek, change outputok, batching, konszolidációs tranzakciók, tőzsdei műveletek és vagyonkezelői tevékenység torzíthatják. Ötödször, a sorozat a perzisztens spent-output indexer adatbázistól függ, így örökli annak helyességét és teljességét. Hatodszor, az indexer egyszerű reorg-kezelése inkonzisztenciát észlel és leáll, de nem rollbackeli automatikusan az állapotot. A cikk mindezek ellenére hasznos OBM coin-age sorozatnak tartja, amely átlátható, értékkel súlyozott mértéket ad a költött coinok átlagos életkoráról. ## A.8 obm_est7d_hashrate_ehs_daily – Becsült 7-napos hálózati hashrate EH/s-ban ### Definíció Ez a metrika a Bitcoin bányászatba fektetett aggregált számítási kapacitás becslését adja exahashes per second egységben. A hashrate – a difficulty-val ellentétben – nem olvasható le közvetlenül a láncból; a proof-of-work nehézségből és a blokkok termeléséhez szükséges eltelt időből kell inferálni. Az OBM kanonikus definíciója egy 7 napos trailing (gördülő) blokk-timestamp ablakot használ. Minden $d$ UTC dátumra az ablak az előző 6 nap 00:00:00 UTC-jétől $d$ 23:59:59 UTC-jéig terjed. Az ablakba eső blokkok halmaza $W_d$. Minden $b \in W_d$ blokkra $D_b$ a Bitcoin Core által jelentett difficulty és $t_b$ a blokk timestampje. A becsült hashrate hash/másodpercben: $$\widehat{H}^{\mathrm{H/s}}_d = \frac{\sum_{b \in W_d} D_b \cdot 2^{32}}{\max_{b \in W_d}(t_b) - \min_{b \in W_d}(t_b)}.$$ Ez exahash/másodpercre átszámítva: $$\widehat{H}^{\mathrm{EH/s}}_d = \frac{\widehat{H}^{\mathrm{H/s}}_d}{10^{18}}.$$ Az OBM metrika azonosítója: `obm_est7d_hashrate_ehs_daily`. Az `est7d` komponens azért része az azonosítónak, mert az ablak hossza a metrika definíciójának része; egy 14 napos becslés (`obm_est14d_hashrate_ehs_daily`) más metrika, más simasággal és reakciókészséggel. Ha az ablakban a blokkok száma kisebb, mint a minimálisan megkövetelt (alapértelmezetten 2), vagy az első és utolsó blokk timestampje közti eltelt idő nem pozitív, a becslés nem értelmezhető, és az érték NaN. ### Gazdasági értelmezés A becsült 7-napos hálózati hashrate bányászati aktivitási indikátorként szolgál. Közelíti a trailing 7 napos ablakban a proof-of-work számítások aggregált sebességét, így proxy a bányászszektor aktivitására és – közvetettebb módon – a Bitcoin hálózat számítási biztonságára. A cikk öt felhasználási területet emel ki. Először, kiegészíti a mining difficulty-t azáltal, hogy a protokoll-célértéket a tényleges blokktermeléssel ötvözi. Másodszor, simább bányászati aktivitási mértéket ad, mint egy egynapos becslés, mivel a blokk-felfedezés sztochasztikus, és a napi blokkszám ingadozik akkor is, ha a hashrate stabil. Harmadszor, a miner bevétellel, fee-kkel, issuance-szel és a BTC árfolyammal együtt a bányász-ösztönzők tanulmányozására alkalmas. Negyedszer, energia-kutatási szempontból releváns, mert a becsült hashrate gyakran közbülső változó a bányászat villamosenergia-fogyasztását becslő modellekben. Ötödször, kontrollváltozóként szolgálhat ökonometriai elemzésekben, ahol a bányászati feltételek vagy a hálózati biztonság változásai számítanak. A metrikát nem szabad közvetlenül megfigyelt hashrate-ként értelmezni. Csak becslés, amely a blokk nehézségen és a realizált blokk timestamp-eken alapul. Nem azonosít egyéni bányászokat, bányászközösségeket, földrajzi helyszíneket, energiaforrásokat, bányászhardvert vagy villamosenergia-fogyasztást, és nem méri közvetlenül a bányászat jövedelmezőségét. Értelmezése függ az ablak-konvenciótól, a timestamp-konvenciótól és a minimum-blokk szabálytól. ### Hasonló publikus metrikák Az OBM sorozat a következő publikus metrikákkal komparálható: estimated hashrate, mean hash rate, total hash rate, network hashrate, Bitcoin hashrate. A legközelebbi komparátor a Glassnode Bitcoin Hash Rate (`mining.HashRateMean`), amelyet a Glassnode „az átlagos becsült hashes per second szám” definícióval ír le. A fájl itt véget ér, így a többi publikus szolgáltató (CryptoQuant, Coin Metrics, Bitbo) részletes összevetése és a további belső szakaszok (algoritmus, kimeneti formátum, technikai validáció, ismert limitációk) a következő részben folytatódnak. ### Összegzés A nyolcadik rész két fontos metrikát mutat be. Az `obm_dormancy_days_daily` a CDD és a napi spent output value hányadosaként definiálja a napi dormancy-t, amelyet az OBM spent-output indexer adatbázisából exportál, és konkrét, reprodukálható módon kezeli a nulla nevező esetét (NaN, nem nulla). A metrika nyers, entitás-korrigálatlan, és a CDD-től, valamint a spent value-tól örökölt korlátokkal rendelkezik, de átlátható, ellenőrizhető alternatívát kínál a Glassnode AverageDormancy és a CryptoQuant average_dormancy sorozatok mellett. Az `obm_est7d_hashrate_ehs_daily` egy 7 napos trailing blokk-timestamp ablakból becsli a hálózati hashrate-et, ahol a nevező az ablak első és utolsó blokkjának timestamp-különbsége, a számláló pedig a blokkok nehézségének és a $2^{32}$ faktornak a szorzata. A metrika kiegészíti a difficulty-t a realizált blokktermeléssel, simább bányászati aktivitási indikátort ad, és alapvető közbülső változó az energiafogyasztás-modellekben. A cikk mindkét metrika esetében hangsúlyozza az explicit, reprodukálható definíció és a dokumentált konvenciók fontosságát, valamint a publikus komparátorokkal való összevethetőség korlátait. --- ## 9. rész > **Megjegyzés a rész-határokról.** Az „Open Bitcoin Metrics” (arXiv 2607.03124v1, szerző: Diego R. Llanos) cikk 9. chunkja a várt A.13–A.17 metrikák (miner_revenue, raw_output_value, spent_output_count, spent_value_age_band, spent_value_btc) helyett az **A.8 `obm_est7d_hashrate_ehs_daily`** metrika public-comparator és algorithm szakaszait, valamint az **A.9 `obm_fee_share_revenue_ratio_daily`** metrika teljes definícióját, gazdasági értelmezését, public-comparator áttekintését és az algoritmus első lépéseit tartalmazza. Az alábbi összefoglaló ennek megfelelően ezt a két metrikát dolgozza fel, a fájlban ténylegesen megjelenő tartalommal. --- ## 1. A.8 `obm_est7d_hashrate_ehs_daily` – a 7 napos hálózati hashrate-becslés közérthetően ### 1.1 Mit mér ez a metrika? Ez az OBM-metrika a Bitcoin-hálózat teljes számítási kapacitását becsli, **exahashes per secundumban (EH/s)** kifejezve. A becslés nem on-chain közvetlen megfigyelésen alapul (a protokusszintű hashrate nem olvasható ki a láncból), hanem a blokkok `difficulty` mezőjéből és a valós blokk-időbélyegekből származik. A kanonikus OBM-sorozat egy 7 napos, UTC-naptári napokra épülő, gördülő ablakot használ; a 7 napos ablak a sorozat-azonosítóban is kódolva van (`obm_est7d_hashrate_ehs_daily`), és az `--window_days` kapcsolóval más hosszúságú ablakok is kérhetők (pl. 14 nap → `obm_est14d_hashrate_ehs_daily`). A becslés képlete a következő: $$\widehat{H}^{\mathrm{EH/s}}_{d} = \frac{\sum_{b \in W_{d}} D_{b} \cdot 2^{32}}{\bigl(\max_{b \in W_{d}}(t_{b}) - \min_{b \in W_{d}}(t_{b})\bigr) \cdot 10^{18}}$$ ahol: - $W_{d}$ a $d$ UTC-dátumra 23:59:59-kor végződő 7 napos gördülő ablak, - $D_{b}$ a $b$ blokk `difficulty` értéke, - $t_{b}$ a blokk timestampje (UTC, másodperc), - a számláló tehát az ablak blokkjaira összegzett várható próbálkozások száma, - a nevező az első és utolsó blokk timestampje közti eltelt idő másodpercben, - az eredményt $10^{18}$-nal osztva kapjuk meg EH/s-ban. Ha az ablakban kevés blokk van (alapértelmezés: `--min_blocks 2`), vagy az eltelt idő nem pozitív, a sorozat értéke `NaN` (hiányzó). Ez a konvenció teszi a metrikát konzervatívvá: a bizonytalan, alulmintás ablakok nem torzítják a görbét. ### 1.2 Adatforrás és futtatási környezet A metrika kizárólag a helyi Bitcoin Core full node JSON-RPC interfészéről olvassa a blokk-metaadatokat (`getblock 1`), és csak a `time`, `difficulty`, `height` mezőkre van szüksége. Nem kell hozzá a spent-output indexelő adatbázis, a tranzakció-szintű input feloldás, címklaszterezés, entitás-azonosítás, külső árfolyamadat vagy third-party API, és a node-nak nem is kell `txindex=1`-gyel futnia. A lánc-hegyet (`getblockchaininfo`) a szkript a magasságintervallum meghatározásához használja, és a saját node által validált főláncra támaszkodik. A szkript neve: `compute_obm_est7d_hashrate_ehs_daily.py`. Fő lépései: 1. A felhasználó által megadott `--start_date` / `--end_date` UTC dátumintervallum beolvasása. 2. Az ablakméret betöltése (`--window_days`, alapértelmezés 7) – ez határozza meg a `series_id`-t. 3. A vizsgálandó dátumtartomány visszafelé kiterjesztése `window_days − 1` nappal, hogy az első output-dátumhoz is legyen elég blokk-előzmény. 4. RPC-kapcsolat (explicit user/pass, környezeti változók vagy cookie-alapú auth). 5. A jelenlegi lánctipp magasságának lekérése. 6. A kibővített dátumtartományhoz tartozó hozzávetőleges magasságintervallum megkeresése bináris kereséssel a blokk-időbélyegek alapján. 7. A magasságintervallum biztonsági kiterjesztése `--height_margin` (alapértelmezés: 2016) blokkal mindkét oldalon, mivel a blokkok timestampje nem szigorúan monoton a magasság szerint. 8. A kibővített tartomány minden blokkjának beolvasása, a timestamp alapján történő UTC-dátum-hozzárendelés, a `difficulty` rögzítése. 9. A blokkok rendezése timestamp szerint (magasság szerinti tie-breaker). 10. Minden output-dátumra a 7 napos ablak kijelölése, az ablakba eső blokkok kiválogatása, és a fenti képlet alkalmazása. 11. Az eredmény kiírása a standard OBM CSV-sémába: `date, series_id, value, unit, frequency, release_version` – értékek 12 tizedesjegyre, hiányzó értékek `NaN`. 12. Opcionális plotkimenet. ### 1.3 Metrika-specifikus paraméterek - `--window_days`: a gördülő ablak hossza naptári napokban (alapértelmezés 7, része a metrika definíciójának, és a `series_id`-be beépül). - `--min_blocks`: az ablakban minimálisan szükséges blokkok száma, hogy a becslés definiált legyen (alapértelmezés 2; ez alatt `NaN`). - `--height_margin`: a magasságkeresés biztonsági margója blokkokban (alapértelmezés 2016, azaz egy teljes difficulty-epoch). Ezeken felül a szkript a szokásos OBM-paramétereket is fogadja: `--rpc_url`, `--rpc_user`, `--rpc_password`, `--cookie_path`, `--use_default_cookie`, `--rpc_timeout`, `--output`, `--release_version`, `--plot`, `--plot_output`, `--quiet`. ### 1.4 Technikai validáció és belső konzisztencia-ellenőrzések A szkript futás közben több belső ellenőrzést végez: - érvényes dátumintervallum, és a `--start_date` nem későbbi, mint `--end_date`; - `--window_days ≥ 1`; - `--min_blocks ≥ 2`; - `--height_margin ≥ 0`; - érvényes RPC-hitelesítés, cookie-fájl megléte és formátuma; - a lánctipp sikeres lekérdezése; - a kibővített dátumtartomány visszafelé kiterjesztése `window_days − 1` nappal; - a magasságintervallum meghatározása és kiterjesztése; - minden megtartott blokkhoz van `difficulty` mező, és az nem negatív; - a blokkok rendezése timestamp + magasság szerint; - minden gördülő ablakban megszámlálásra kerülnek a blokkok, és `NaN` íródik, ha kevés a blokk vagy nem pozitív az eltelt idő. További belső konzisztencia-ellenőrzések más OBM-metrikákkal: - A 7 napos blokkszámoknak összhangban kell lenniük az `obm_block_count_daily` sorral. - A hashrate nagy ugrásait blokkszám- és/vagy difficulty-változásokkal kell tudni magyarázni. - A hashrate-sorozatot érdemes összevetni az `obm_difficulty_eod_daily` értékekkel: a difficulty a protokoll-célt adja meg, a becsült hashrate pedig ezt a célt kombinálja a valós blokkidőzítéssel. ### 1.5 Ismert korlátok A metrika hasznos, de definíció-érzékeny. A cikk nyolc pontban foglalja össze a korlátokat: 1. A hashrate nem on-chain megfigyelés, hanem a difficulty és a blokkidőzítés alapján becsült érték. 2. Az eredmény függ a választott gördülőablak-hossztól; a 7 nap a kanonikus OBM-választás, más hossz más görbét ad. 3. A becslést a blokk-felfedezés sztochasztikus varianciája befolyásolja, különösen rövid ablakok esetén. 4. A metrika a blokk-timestamp konvenciójától függ (itt: UTC). 5. Az eltelt időt az első és utolsó blokk timestampje közti különbség adja, ezért korai vagy blokk-szegény ablakok zajosak, illetve definiálatlanok lehetnek. 6. A metrika nem azonosít bányászokat, pool-okat, hardvert, áramfogyasztást, földrajzi eloszlást vagy profittabilitást. 7. Csak blokk-metaadatokból dolgozik, nem igényli a spent-output indexelőt. 8. Eltérhet a különböző szolgáltatók simítási ablakait és formuláit használó soroktól. ### 1.6 Összehasonlítás a publikus hashrate-sorozatokkal A cikk részletesen végigmegy a fő publikus komparátorokon. Mindenütt hangsúlyozza, hogy a hashrate-becslés erősen konvenciófüggő: a szolgáltatók ablakméretben, simításban, időbélyeg-konvencióban, blokk-beválogatási szabályban, egységrendszerben és a ritka korai időszakok kezelésében is eltérhetnek. - **Glassnode `mining.HashRateMean`**: a legerősebb nyilvános komparátor, mert explicit módon becsült hálózati hashrate-et publikál, de a pontos formulát és ablakot a nyilvános dokumentáció nem adja visszafordíthatóan. - **Blockchain.com Total Hash Rate (TH/s)**: szintén becsült hálózati hashrate, de 24 órás ablakkal és TH/s egységben – az OBM 7 napos EH/s ablakától eltérő, így az egység- és ablak-konverzió nélkül nem összehasonlítható közvetlenül. - **Coin Metrics**: mining-metrikái között a difficulty- és hashrate-típusúakat különböző „last-” és „mean-” difficulty-konvenciókkal teszi közzé; a hashrate-sor csak akkor tekinthető szigorú benchmarknak, ha a pontos formula és ablak megegyezik az OBM-ével. - **BitInfoCharts**: „average hashrate per day” címkével publikál, de a teljes reprodukálható algoritmust nem adja meg; másodlagos diagnosztikai komparátor. - **CoinWarz, Newhedge, MacroMicro, Bitbo**: hasznos chartolási referenciák, de a nyilvános oldalak nem dokumentálják az ablakot, a simítást, az időbélyeg-konvenciót és a korai időszakok kezelését – így legfeljebb vizuális összevetésre alkalmasak. - **mempool.space**: API-szinten pool-szintű és alacsonyabb szintű bányászati végpontokat kínál, és a block API-kból az OBM-mel azonos 7 napos formula alkalmazásával újraépíthető a hálózati hashrate, de publikus, előre konfigurált 7 napos sorozatot nem ad. A lényegi megkülönböztetés a cikk szerint: a hashrate-szolgáltatók a hashrate-et a difficulty és a blokktermelés alapján *becsülik*, míg a difficulty on-chain protokoll-állapot, és közvetlenül olvasható. Az OBM egyedisége, hogy a becslési szabály explicit: 7 napos UTC-ablak, a blokkok `difficulty * 2^32` összege osztva az első/utolsó blokk timestampje közti eltelt idővel, EH/s-ban kiírva, `NaN` ahol az ablak elégtelen, és az ablakhossz a sorozat-azonosítóban is kódolva van. --- ## 2. A.9 `obm_fee_share_revenue_ratio_daily` – a díjak aránya a bányász-bevételben ### 2.1 Definíció Ez a metrika azt méri, hogy a BTC-ben denominált bányász-kompenzáció mekkora részét adják a tranzakciós díjak. Két OBM-sorozatból származtatjuk: a napi tranzakciós díjakból (`obm_fees_btc_daily`) és a napi realizált kibocsátásból (`obm_issuance_btc_daily`). A képlet: $$\mathrm{FeeShare}_{d} = \frac{\mathrm{FeesBTC}_{d}}{\mathrm{Issuance}_{d} + \mathrm{FeesBTC}_{d}}$$ Az eredmény **dimenziómentes**; OBM arányként (és nem százalékként) jelenti. Például a `0.025` azt jelenti, hogy az adott napon a bányász-bevétel 2,5 %-a származott díjakból. Ha a nevező nulla (a legkorábbi bitcoin-időszakban, amikor egy adott UTC-naphoz nincs blokk, kibocsátás vagy díj), az érték nem `0`, hanem **hiányzó** – ezzel a konvencióval a metrika nem sugallja azt, hogy a díjak a pozitív bevétel 0 %-át tették volna ki. ### 2.2 Gazdasági értelmezés A fee-share arány közvetlen indikátora annak, hogy a Bitcoin biztonsági költségvetése mennyire támaszkodik a szubvencióra (a kibocsátásra) a díjakhoz képest. A metrika a következő kutatási célokra használható: - a bányász-kompenzáció összetételének alakulása a különböző szubvenció-érákban; - a hosszú távú biztonsági költségvetésben a díjak szerepének mérése; - a blokktér-kereslet gazdasági jelentőségének azonosítása a kibocsátáshoz képest; - a felezési események körüli elemzés (a kibocsátás mechanikusan csökken, így a díjak relatív súlya nőhet); - normalizált, időszakok között összehasonlítható mérőszám a nyers díjak helyett. Fontos, hogy a metrika **nem** a teljes bányász-bevétel, profit, vagy fiat-bevétel; nem veszi figyelembe az árat, az áramköltséget, a hardver amortizációját, a pool-díjakat, a finanszírozási költségeket vagy az üzemi marzsokat. Kizárólag a BTC-oldali kompozíciót méri. ### 2.3 Publikus analógok A cikk a következő publikus metrikákat azonosítja, mint közeli komparátorokat (címkék: „revenue from fees”, „fee-to-reward ratio”, „fee percentage of total block reward”, „percent miner revenue from fees”): - **Coin Metrics `FeeRevPct`**: a „Revenue from Fees (%)” metrika – a díjak és a bevétel hányadosa, dimenziómentes, napi gyakoriságú, és a definíció gyakorlatilag megegyezik az OBM-ével, feltéve hogy a bevétel = díjak + újonnan kibocsátott coinok. A pontos egyezőség nem feltételezhető a timestamp-konvenció, a reorg-kezelés, az aluligényelt kibocsátás kezelése és a százalék/arány skálázása nélkül. A lekéréshez hitelesítő szükséges. - **Glassnode `mining.RevenueFromFees`**: a bányász-bevétel díjakból származó százaléka = díjak / (díjak + vert coinok). Gazdaságilag azonos az OBM-definícióval. Advanced Plan szükséges, és a nyilvános dokumentáció nem ad teljesen reprodukálható algoritmust a két komponens nyers Bitcoin Core adatokból való visszaépítéséhez. - **CryptoQuant „Fees to Reward Ratio”**: regisztrációhoz kötött, a chart leírása szerint a díjak aránya a teljes block reward-ban, 0 és 1 közé eső érték; közeli megfelelő, de a pontos alacsony szintű konvenciók nem ismertek. - **BitInfoCharts „Fee in Reward”**: „average fee percentage in total block reward” – koncepcionálisan közeli, de a publikus dokumentáció nem adja meg az aggregációs szabályt, a timestamp-konvenciót, a díjmentes blokkok kezelését, és hogy napi szinten a napi összegek hányadosa vagy a blokk-szintű százalékok átlaga-e. - **Bitbo „Fees as Percent of Total Block Reward”**: erős koncepcionális egyezés, de a publikus oldal elsősorban magyarázó, és a kapcsolódó Bitbo-chartok néha mozgóátlagolt verziót jelenítenek meg alapértelmezetten. - **Newhedge „Percent Miner Revenue from Bitcoin Fees”**: közvetlenül illeszkedik az OBM-értelmezéshez, de a teljes adathozzáférés regisztrációhoz/ fizetős csomaghoz kötött. - **Bitcoin Magazine Pro „Miner Revenue (Fees vs Rewards)”**: a bányász-bevétel díj/reward komponenseinek százalékos bontása, értelmezési célokra kiváló, reprodukálhatóságra nem. - **Blockchain.com**: kapcsolódó díj- és bevételsorokat közöl (Total Transaction Fees BTC/USD, Miners Revenue USD, Cost % of Transaction Volume), de a Cost % of Transaction Volume nem egyezik a fee-share of miner revenue-val, mert az a bányász-bevételt a tranzakciós forgalommal hasonlítja össze, nem a díjakkal. A komponenssorokból fee-share-szerű mérőszám visszaépíthető, de közvetlenül elnevezett BTC-denominált fee-share of miner revenue-sor nem érhető el. A cikk hangsúlyozza: a legerősebb publikus komparátor a Coin Metrics `FeeRevPct` és a Glassnode `mining.RevenueFromFees`, mert mindkettő definíció szerint díjak / teljes bányász-bevétel. Az OBM-megkülönböztető jegyei: a fee-share arány transzparensen származik az `obm_fees_btc_daily` és az `obm_issuance_btc_daily` sorokból, arányként (nem százalékként) van jelentve, explicit a hiányzó értékek konvenciója, és az auditálhatóságot a forrás-sorokkal való validációs azonosságok biztosítják. ### 2.4 Adatforrás és algoritmus (a részben elérhető rész) A metrika két meglévő OBM CSV-fájlból származik: `obm_issuance_btc_daily.csv` és `obm_fees_btc_daily.csv`. Nem kérdez le Bitcoin Core-t és nem épít újjá blokk- vagy tranzakció-információt – determinisztikus transzformáció két korábban generált OBM-idősorból. A bemeneti fájloknak az OBM standard sémáját kell követniük (`date, series_id, value, unit, frequency, release_version`), és a szkript ellenőrzi: - az első input-sorozat azonosítója `obm_issuance_btc_daily`, a másodiké `obm_fees_btc_daily`; - mindkettő egysége `BTC`, gyakorisága `daily`; - mindkét fájl a kiválasztott intervallum minden dátumára pontosan egy megfigyelést tartalmaz (ha bármelyik dátum hiányzik, a szkript leáll). A szkript neve: `compute_obm_fee_share_revenue_ratio_daily.py`. A rész az algoritmus első nyolc lépéséig jut el: 1. Beolvassa az `obm_issuance_btc_daily` CSV-fájlt (első kötelező pozicionális argumentum). 2. Beolvassa az `obm_fees_btc_daily` CSV-fájlt (második kötelező pozicionális argumentum). 3. Ellenőrzi mindkét fájl OBM-sémáját. 4. Ellenőrzi, hogy a sorozat-azonosítók a vártak (`obm_issuance_btc_daily` és `obm_fees_btc_daily`). 5. Ellenőrzi, hogy mindkét sorozat `BTC` egységű és `daily` gyakoriságú. 6. Meghatározza a dátumintervallumot: ha `--start_date` / `--end_date` meg van adva, azt használja, egyébként a két fájl közös átfedésének határait. 7. Ellenőrzi, hogy mindkét forrásfájl pontosan egy megfigyelést tartalmaz minden kiválasztott dátumra. 8. A rész itt félbeszakad; a hátralévő lépések (minden dátumra a fenti hányados kiszámítása, `NaN` írása ahol a nevező nulla vagy a bemenet hiányzik, és a standard OBM CSV-kimenet kiírása) a következő részben várhatók. ### 2.5 Metrikaközi konzisztencia Mivel ez a metrika két másik OBM-sor transzformációja, értelemszerűen a belső konzisztencia-azonosság erős: a fee-share, a kibocsátás és a díjak bármelyik napi értékére igaz, hogy `FeeShare * (Issuance + Fees) = Fees`, és így a fee-share közvetlenül visszavezethető a komponens-sorokra. Ez az auditálhatóság a fő OBM-megkülönböztető jegye a külső szolgáltatókkal szemben, ahol az aggregáció gyakran nem rekonstruálható. --- ## 3. Összefoglalás és kapcsolat a többi részhez A 9. rész két, egymástól tartalmilag független, de a bányászati gazdaságtanhoz kapcsolódó OBM-metrikát dolgoz fel. Az **A.8 `obm_est7d_hashrate_ehs_daily`** egy hálózati szintű, teljes Bitcoin Core node-ból származtatott hashrate-becslés, amely a blokkok `difficulty` mezőjét és a valós blokkidőzítést kombinálja egy explicit, 7 napos UTC-ablakos, gördülő becsléssé. A metrika a kanonikus OBM-formulát használja, a sorozat-azonosítóban kódolja az ablakméretet, és a definíció-érzékenységet több ismert korlátlistával is dokumentálja. Az **A.9 `obm_fee_share_revenue_ratio_daily`** egy sokkal egyszerűbb, determinisztikusan származtatott aránymetrika: a napi díjak és a napi realizált kibocsátás hányadosa, dimenziómentes arányként jelentve, hiányzó értékkel ott, ahol a bányász-bevétel nulla. A két metrika együtt a Bitcoin biztonsági költségvetésének két oldalát világítja meg: a hashrate a védelmi kapacitás oldalát, a fee-share a kompenzáció összetételének oldalát. A korábbi részek (A.1–A.7, valamint a difficulty, block_count, fees, issuance, dormancy, liveliness, CDD-metrikák) lefedték a nyers blokk- és tranzakció-oldali inputokat; a 9. rész ezekre épít: a hashrate a blokk-metaadatokból (`difficulty` + `time`) építkezik, míg a fee-share a korábban definiált `obm_fees_btc_daily` és `obm_issuance_btc_daily` sorokból. A várttal ellentétben (A.13–A.17) a 9. rész valójában az A.8–A.9 metrikákat tartalmazza, és ezek feldolgozását követően a későbbi részek térnek majd át a spent-output indexelőre épülő metrikákra (raw_output_value, spent_output_count, spent_value_age_band, spent_value_btc, miner_revenue). --- ## 10. rész Az „Open Bitcoin Metrics” (OBM) című arXiv-tanulmány (2607.03124v1) tizedik részletében a szerző három, egymással szorosan összefüggő napi idősor-metrikát mutat be részletesen: a `obm_fee_share_revenue_ratio_daily` (a bányászok díjbevételének aránya a teljes bevételhez képest), a `obm_fees_btc_daily` (napi tranzakciós díjak BTC-ben) és a `obm_issuance_btc_daily` (napi BTC-kibocsátás) metrikákat. Ezek a származtatott és elsődleges sorok alkotják a Bitcoin bányászbevétel-elemzésének gerincét, és együttesen szolgálnak a hálózat hosszú távú biztonsági költségvetésének vizsgálatához. Az alábbi összefoglaló a függelék ezen szakaszait ismerteti közérthető, ugyanakkor technikailag pontos stílusban. ## 1. A fee-share revenue ratio (díjbevétel-arány) ### 1.1 Definíció és számítási logika Az `obm_fee_share_revenue_ratio_daily` egy származtatott OBM-metrika, amely azt mutatja meg, hogy a bányászok teljes napi bevételén belül milyen arányt képviselnek a tranzakciós díjak az újonnan kibocsátott BTC-vel (az úgynevezett blokkjutalommal vagy szubvencióval) szemben. A napi arány a következő képlettel számítható: ``` FeeShare_d = FeesBTC_d / (Issuance_d + FeesBTC_d), ha Issuance_d + FeesBTC_d > 0 ``` Ha a nevező nulla (azaz egy adott UTC-napon sem kibocsátás, sem díj nem volt), akkor a megfigyelés nem nulla, hanem hiányzó értékként (`missing`) kerül rögzítésre — ez a konvenció fontos, mert a nulla nevező miatti osztás értelmetlen lenne. A metrika tehát tisztán determinisztikus transzformációja két meglévő OBM napi sornak (`obm_fees_btc_daily` és `obm_issuance_btc_daily`), és nem igényel közvetlen Bitcoin Core RPC-hozzáférést a futtatáskor, hiszen nem a blokkláncról, hanem a már előállított CSV-fájlokból dolgozik. ### 1.2 Algoritmus (lépésről lépésre) A szkript a következő lépéseket hajtja végre: 1. Két kötelező CSV-bemenetet olvas be: az egyik a napi kibocsátást, a másik a napi díjakat tartalmazza (`obm_issuance_btc_daily` és `obm_fees_btc_daily`). 2. A megadott dátumintervallum alapján kiválogatja a közös dátumokat — a `--start_date` és `--end_date` zárt intervallumot jelöl. 3. Ellenőrzi, hogy a forrásértékek nem negatívak. 4. Kiszámítja a `MinerRevenueBTC_d = Issuance_d + FeesBTC_d` nevezőt. 5. Ha a nevező pozitív, kiszámítja a hányadost; ha nulla, a megfigyelést „missing”-ként jelöli. 6. Ellenőrzi a `release_version` konzisztenciáját — ha a kiválasztott időszakban több release-verzió keveredne, a szkript leáll, hogy ne keveredjenek a definíciók. 7. Az eredményt a szabványos OBM CSV-sémával írja ki: `date, series_id, value, unit, frequency, release_version`. 8. Opcionálisan diagramot is készít, kihagyva a hiányzó értékeket. ### 1.3 Paraméterek és aggregáció A metrika-specifikus bemeneti paraméterek a következők: - `issuance_csv` (kötelező pozicionális): a kibocsátási CSV elérési útja. - `fees_csv` (kötelező pozicionális): a díjak CSV elérési útja. - `--start_date`, `--end_date` (opcionális): a szűkített intervallum; ha nincs megadva, a két forrásfájlban elérhető legkorábbi, illetve legkésőbbi közös dátumot használja. - További opciók: `--output`, `--plot`, `--plot_output` — ezek a többi OBM-szkriptnél megszokott kimeneti és ábrázolási konvenciókat követik. A metrika nem aggregálódik közvetlenül blokkokból vagy tranzakciókból; napi szinten, pontról pontra számítódik a két forrássorból. Havi szinten a szerző kifejezetten óva int a napi arányok egyszerű számtani átlagolásától — ehelyett a helyes havi verzió a havi díjak és a havi kibocsátás összegzéséből indul ki, és csak ezután számol hányadost. Ez a konvenció a napokat BTC-ben denominált bányászbevételükkel súlyozza, és megőrzi a metrika értelmezését: a díjak havi részesedését a teljes havi bányászbevételből. ### 1.4 Kapcsolat más OBM-metrikákkal A `obm_fee_share_revenue_ratio_daily` szoros kapcsolatban áll más OBM-sorokkal. Mivel `MinerRevenueBTC_d = Issuance_d + FeesBTC_d`, a díjhányados egyenértékű formában `FeesBTC_d / MinerRevenueBTC_d` is felírható. Ez a másodlagos átalakítás egy hasznos validációs azonosságot ad: ha a bányászbevétel-sor is elérhető, akkor a kétféle nevezőnek (Issuance + Fees, illetve MinerRevenue) meg kell egyeznie. Az eltérés időbélyeg-eltérést, forrásfájl-inkonzisztenciát, implementációs hibát vagy release-verzió-keveredést jelezhet. ### 1.5 Kimeneti formátum és validáció A kimeneti CSV minden UTC-napra egy sort tartalmaz. A `value` mezőben a díjak és a (díjak + kibocsátás) hányadosa szerepel (például `0.007216384512`), az `unit` mező értéke `ratio` (dimenziómentes arány), a `frequency` pedig `daily`. Ha a nevező nulla, a `value` mező üresen marad — ez nem nulla arányt jelent, hanem hiányzó értéket. A technikai validáció nyolc belső ellenőrzést foglal magában: a forrásfájlok OBM-sémának való megfelelése, a sorazonosítók helyessége, a mértékegységek és gyakoriságok egyezése, a dátumok egyértelműsége, a nemnegativitás, a [0, 1] intervallumba esés biztosítása, a hiányzó értékek konzekvens kezelése, valamint a release-verziók keveredésének tilalma. A két fő validációs azonosság: - Elsődleges: `FeeShare_d = FeesBTC_d / (Issuance_d + FeesBTC_d)`, ha a nevező pozitív. - Másodlagos: `FeeShare_d = FeesBTC_d / MinerRevenueBTC_d`, amennyiben a bányászbevétel-sor is elérhető. ### 1.6 Ismert korlátok A metrika egyszerű és reprodukálható, de több korláttal rendelkezik. Egyrészt származtatott sor, nem önálló teljes csomópontos (full-node) rekonstrukció. Másrészt örökli az `obm_issuance_btc_daily` és `obm_fees_btc_daily` minden definíciós döntését, időbélyeg-konvencióját és esetleges revízióit. Harmadrészt a nulla nevezőjű esetekben értelmezhetetlen, ezért ezek a megfigyelések hiányoznak. Negyedrészt arányt jelent, nem százalékot. Ötödrészt BTC-ben denominált bevétel-összetételt mér, nem fiat-alapú bányászbevételt. Végül nem méri a bányászprofilt, az energiaköltségeket, a hardver- és üzemeltetési költségeket, sem az árrést. Mindezek ellenére a metrika transzparens képet ad a díjak relatív súlyáról a bányászbevételben, és támogatja a Bitcoin biztonsági költségvetésével, a fee-piac fejlődésével, a felezési ciklusokkal és a szubvenció-alapúról a díj-alapú bányászbevételre való hosszú távú átmenettel kapcsolatos kutatásokat. ## 2. A napi tranzakciós díjak (obm_fees_btc_daily) ### 2.1 Definíció és gazdasági értelmezés A `obm_fees_btc_daily` metrika az adott UTC-naphoz rendelt blokkokban található összes nem coinbase tranzakció által fizetett teljes díjösszeget méri, BTC-ben kifejezve. Formálisan: ``` FeesBTC_d = Σ (b ∈ B_d) Σ (j ∈ T_b) F_j, ahol F_j = V_in_j - V_out_j ``` ahol `B_d` a d naphoz rendelt blokkok halmaza, `T_b` a b blokk nem coinbase tranzakcióinak halmaza, és `F_j` a j-edik tranzakció díja (az inputok által hivatkozott előző kimenetek összértéke minus a tranzakció kimeneteinek összértéke). A blokk hozzárendelése az UTC-naphoz a Bitcoin Core által visszaadott blokk időbélyegből (`t_b`) származtatott `d(b) = UTCDate(t_b)` függvénnyel történik. A napi tranzakciós díjak egy BTC-denominált folyamatváltozó (flow variable), amely közvetlenül jelzi a felhasználók által a blokktér-beépítésért fizetett összeget. A metrika több szempontból is hasznos: segíti a Bitcoin fee-piac fejlődésének vizsgálatát, méri a torlódást és a blokktér-keresletet (különösen a tranzakciószám, blokkszám, blocksúly vagy fee-rate metrikákkal együtt), a bányászbevétel kulcsfontosságú komponense, és elengedhetetlen a bányászbevétel díjhányadának kiszámításához — amely a hosszú távú biztonsági költségvetés egyik központi mutatója. Fontos hangsúlyozni, hogy a metrika nem azonos a teljes bányászbevétellel (amely `MinerRevenueBTC_d = IssuanceBTC_d + FeesBTC_d`), és nem méri a bányászprofilt (mivel nem veszi figyelembe az energiaköltségeket, hardver-amortizációt, pool-díjakat, finanszírozási költségeket vagy egyéb működési kiadásokat). Fee-rate metrika sem, hiszen a teljes napi díjat méri BTC-ben, nem pedig a virtuális bájtonkénti vagy tranzakciónkénti díjat. ### 2.2 Hasonló, nyilvánosan elérhető metrikák Az OBM-sor számos kereskedelmi és nyilvános forrással vethető össze, de a pontos egyezés nem feltételezhető az időbélyeg-konvenciók különbsége miatt: - **Coin Metrics — `FeeTotNtv`**: a legerősebb benchmark, mert van metrikaazonosítója, natív egységben jelent, napi és órás gyakorisággal elérhető, és API-n keresztül lekérdezhető. Fontos különbség, hogy a Coin Metrics a Bitcoin esetében a medián blokkidőt használja, míg más szolgáltatók gyakran a bányász (miner) időbélyegét. - **Glassnode — `fees.VolumeSum`**: koncepcionálisan nagyon közeli, de a nyilvános dokumentáció nem teljesen specifikálja a rekonstrukciós algoritmust. - **Blockchain.com — Total Transaction Fees (BTC)**: koncepcionálisan közel álló, de a reprodukálható algoritmust nem teszi közzé. - **Blockchair, Newhedge, Bitbo, BitInfoCharts, YCharts**: hasznos másodlagos keresztellenőrzési források, de vagy hiányos az algoritmikus specifikációjuk, vagy a mögöttes adatsor nem független. Az OBM megkülönböztető hozzájárulása, hogy teljes csomópontos (full-node) adatokból rekonstruálja a napi BTC-díjakat, kizárja a coinbase tranzakciókat a tranzakció-szintű díjszámításból, explicit időbélyeg-konvencióval rendeli a blokkokat az UTC-napokhoz, és dokumentálja az aggregációs és validációs szabályokat az auditálhatóság érdekében. ### 2.3 Adatforrás és bemeneti követelmények A metrika nem egyedi blokklánc-lehívásból származik, hanem az OBM „spent-output indexer” (elköltött kimeneteket nyilvántartó indexelő) adatbázisából exportálódik. Az indexelő a 3.4-es szekcióban leírt módon egy futó Bitcoin Core teljes csomópontból épül, és SQLite-adatbázisban tárolja az újrafelhasználható napi aggregátumokat. A `daily_aggregates` tábla `fees_sats` mezője szolgáltatja a forrást. Az indexelő minden nem coinbase tranzakció esetén feloldja az inputokat a korábbi kimenetekre, lekéri azok értékét az élő outpoint-állapotból, kiszámolja a tranzakció díját (`F_j = V_in_j - V_out_j`), majd UTC blokkdátum szerint halmoz. A tárolás satoshiban történik: `fees_sats_d = Σ Σ (V_in,sats_j - V_out,sats_j)`. Az exportáló szkript ezt a satoshi-értéket osztja `100 000 000`-rel, így kapjuk meg a BTC-ben kifejezett napi díjat. Az exportáló szkript nem hív Bitcoin Core-t közvetlenül. Szükséges hozzá az OBM spent-output indexer által generált SQLite-adatbázis, benne a feldolgozottságot jelző metaadatokkal (`last_processed_height`, `last_processed_date`, `max_processed_date`). Ha egy dátumhoz nem tartozik sor a `daily_aggregates` táblában, az exportáló nullát ír — ez a konvenció helyes, mert a díjak folyamatváltozók, és egy adott UTC-napra vonatkozó „nincs hozzájárulás” jelentése a nulla díj, nem a hiányzó érték. ### 2.4 Algoritmus (lépésről lépésre) A `export_obm_fees_btc_daily.py` szkript a következőképpen működik: 1. A felhasználó által megadott dátumintervallumot (`--start_date`, `--end_date`) UTC-dátumként értelmezi és beolvassa (`YYYY-MM-DD` formátumban). 2. Megnyitja a megadott `--state_db` SQLite-adatbázist. 3. Ellenőrzi, hogy az adatbázis metaadatai valóban OBM spent-output indexerhez tartoznak-e (`indexer_id` ellenőrzés). 4. Megvizsgálja, hogy a kért `--end_date` nem haladja-e meg az indexer által feldolgozott legkésőbbi dátumot — ha igen, a szkript leáll, és az indexert tovább kell futtatni. 5. A release-verziót az indexer metaadatából veszi, vagy a `--release_version` fallback értéket használja, ha a metaadat hiányzik. 6. Minden egyes UTC-dátumra lekérdezi a `fees_sats` mezőt a `daily_aggregates` táblából. Ha nincs sor, nullát ír. 7. Átváltja az értéket satoshiból BTC-be (osztás `100 000 000`-rel). 8. A szabványos OBM-sémával (`date, series_id, value, unit, frequency, release_version`) kiírja a CSV-t. 9. Opcionálisan diagramot készít, amelynek címében szerepel a sor leírása és a kiválasztott dátumintervallum. ### 2.5 Paraméterek és aggregáció A metrika-specifikus paraméterek a következők: - `--state_db`: az OBM spent-output indexer által generált SQLite-adatbázis elérési útja. - `--start_date`, `--end_date`: a kért intervallum határai UTC-ben. - `--release_version`: fallback érték, ha az adatbázis metaadatai nem tartalmaznak release-verziót. - `--output`: a kimeneti CSV elérési útja. - `--plot`, `--plot_output`: opcionális ábrázolás. A szkript nem fogad Bitcoin Core RPC-paramétereket, `--height_margin`, `--min_confirmations`, `--commit_every` vagy `--reset_state_db` kapcsolókat — ezek az indexerhez tartoznak, nem az exportőrhöz. Az aggregációs szabály napi szinten: `FeesBTC_d = Σ Σ (V_in_j - V_out_j)` a d naphoz rendelt blokkok és azok nem coinbase tranzakciói felett. Havi szinten a helyes konvenció a napi értékek összegzése, nem az átlagolás, hogy megmaradjon a metrika „teljes kifizetett díj” jelentése. ### 2.6 Validáció és korlátok Az exportáló szkript hat belső ellenőrzést végez: a dátumintervallum érvényessége, az adatbázis megléte és csak olvasható módban való megnyitása, az OBM-indexer-azonosító megléte, a feldolgozottsági metaadatok megléte, a `daily_aggregates` tábla megléte, valamint a kért záró dátum és a feldolgozott tartomány felső határának összevetése. A CSV-ben a sorok számának meg kell egyeznie az intervallumba eső naptári napok számával. Az értékek nemnegatívak kell legyenek. Fontos konzisztencia-ellenőrzés, hogy a bányászbevétel, a kibocsátás és a díjak sorai között fennálljon az `MinerRevenueBTC_d = IssuanceBTC_d + FeesBTC_d` azonosság. Külső forrásokkal való összevetés csak diagnosztikai céllal történjen, nem szigorú egyezés-vizsgálatként, mert a szolgáltatók időbélyeg-konvenciói, megerősítési politikái, átszervezés-kezelése és történeti élkezelése eltérő lehet. A metrika korlátai: függ az OBM spent-output indexer helyességétől és teljességétől; a blokk időbélyeg-konvenciójától; BTC-ben jelent, nem fiat-ban; nem fee-rate metrika; nem entitás-korrigált (nem azonosít tőzsdéket, őreket, self-transzfer stb.); valamint az indexer egyszerű átszervezés-kezelése inkonzisztenciát észlel és leáll, de nem görgeti vissza automatikusan az állapot-adatbázist. Mindezek ellenére a `obm_fees_btc_daily` az OBM egyik alapvető sora: átlátható, BTC-denominált mértéke a napi díjkomponensnek, és alapja a fee-piac, a blokktér-kereslet, a bányászösztönzők, a díjhányad és a hosszú távú biztonsági költségvetés vizsgálatának. ## 3. A napi BTC-kibocsátás (obm_issuance_btc_daily) ### 3.1 Definíció A `obm_issuance_btc_daily` az adott UTC-naphoz rendelt blokkokban ténylegesen létrehozott új BTC-k mennyiségét méri. Formálisan: ``` I_b = C_b - F_b, Issuance_d = Σ (b ∈ B_d) I_b ``` ahol `C_b` a b blokk coinbase tranzakciójának teljes kimeneti értéke, `F_b` pedig a b blokk nem coinbase tranzakciói által fizetett díjak összege. A blokk hozzárendelése a naphoz a `d(b) = UTCDate(t_b)` függvénnyel történik. A realizált kibocsátás tehát a coinbase outputok és a tranzakciós díjak különbsége. Ez egy fontos részlet: a coinbase tranzakció ugyanis a blokkjutalom és a díjak összegét is tartalmazza, így a coinbase outputok teljes értékéből levonva a díjakat kapjuk meg a ténylegesen újonnan vert BTC mennyiségét. A 10. részlet a definíció és az aggregációs szabály lefektetésével zárul, a metrika teljes algoritmusa, forrásigénye, validációja és ismert korlátai a következő részletekben kerülnek részletes kifejtésre. ## 4. A három metrika együttes jelentősége A három sor — `obm_fee_share_revenue_ratio_daily`, `obm_fees_btc_daily` és `obm_issuance_btc_daily` — egységes keretet ad a Bitcoin bányászbevételének komponens-szintű elemzéséhez. A napi kibocsátás a monetáris politikát testesíti meg (a felezési ciklusokkal együtt), a napi díjak a keresleti oldalt (a fee-piac fejlettségét, a blokktér-sűrűséget), a díjhányados pedig e kettő arányát fejezi ki — azt a kulcsmutatót, amely megmutatja, hogy a hálózat biztonsága mennyire támaszkodik a díjakból származó bevételre a szubvencióval szemben. Az OBM-módszertan egységes elvei — a teljes csomópontos rekonstrukció, az explicit időbélyeg-konvenció (Bitcoin Core blokkidőből származtatott UTC-nap), a coinbase tranzakciók kizárása a díjszámításból, a determinisztikus és auditálható aggregációs szabályok, a release-verzió-követés és a validációs azonosságok — biztosítják, hogy e három metrika reprodukálható, egymással konzisztens és más szolgáltatók adataival összevethető, de azokkal nem szükségszerűen szigorúan egyenlő módon kezelhető. A függelék ezen szakasza a sorok formális leírásán túl a gyakorlati implementáció minden fontos aspektusát megadja: a bementi paramétereket, a szkriptlépéseket, a kimeneti formátumot, a validációs szabályokat és az ismert korlátokat, előkészítve a terepet a későbbi, ezekre épülő származtatott metrikák és alkalmazási példák számára. --- ## 11. rész Ez a tizenegyedik részlet az „Open Bitcoin Metrics” című tanulmány Appendix A szekciójából két, egymáshoz tematikusan kapcsolódó napi on-chain metrikát mutat be részletesen. A korábbi részek a Methods szakaszt, a 4. fejezetet és a függelék korábbi (A.1–A.10) metrikáit dolgozták fel; itt az A.11 és A.12 alpontok következnek: az `obm_issuance_btc_daily` (a napi realizált bitcoin-kibocsátás) és az `obm_liveliness_ratio_daily` (a napi „liveliness”, vagyis az életrevalósági arány). Mindkét mérőszám ugyanabból a korábban bemutatott spent-output indexerből építkezik, és a szokásos OBM-sémát követi: definíció → gazdasági értelmezés → nyilvános komparátorok → adatforrás → algoritmus → metrika-specifikus paraméter → aggregációs szabály → kimeneti formátum → technikai validáció → ismert korlátok. ## A.11 – `obm_issuance_btc_daily`: napi realizált BTC-kibocsátás ### Definíció és pénzügyi értelmezés A napi bitcoin-kibocsátás (daily Bitcoin issuance) egy monetáris áramlási változó: azt méri, hogy egy adott UTC-napon hány új bitcoin jött ténylegesen létre a blokkokban. A szerző fontos distinkciót tesz a realizált és az elméleti kibocsátás között. A Bitcoin protokoll ugyan előír egy elméleti blokkjutalom-ütemezést (a 2009-es 50 BTC-től a felezési ciklusokon át a mai 3,125 BTC-ig), de a bányászok a coinbase tranzakcióban általában kevesebbet is igényelhetnek a maximumnál, a coinbase output ugyanakkor a tranzakciós díjakat is tartalmazza. Mivel a díjak már létező coinok újraelosztásai, nem pedig új pénzteremtés, a mérőszám kiszámításához a coinbase teljes outputértékéből le kell vonni a blokk díjait: `I_b = C_b − F_b` (blokk szinten), majd ezt kell naponta összegezni. Az eredmény a coin Metrics „Total Issuance (IssTotNtv)” sorával analóg, de OBM kontextusban realizált, teljes csomópontból származtatott áramlás. A definíció három fontos dolgot különböztet meg: 1. Nem azonos az elméleti blokkjutalommal, hiszen a bányászok néha aluligénylik a coinbase-t. 2. Nem azonos a bányászbevétellel (miner revenue), mert az a kibocsátás és a díjak összege. 3. Nem azonos a forgalomban lévő készlettel (circulating supply), ami egy kumulatív állomány, nem pedig napi áramlás. A mérőszám önmagában a `obm_block_count_daily` sorral együtt a leginformatívabb, mert a napi kibocsátás mechanikusan függ a napra jutó blokkok számától. A felezési események körül a sor segítségével a protokoll-ütemezés helyett valódi blokkszintű adatokból azonosítható a váltás az egyik szubvenzió-korszakból a másikba, nem csupán naptári közelítéssel. ### Hasonló nyilvános metrikák A szerző több szolgáltatót is megvizsgál, és egyértelmű erősorrendet állít fel. A legközelebbi komparátor a Coin Metrics `IssTotNtv` (Total Issuance, natív egységek) sor, amelyet a Bitcoin esetében a legrelevánsabb benchmarknak tekint, de jelzi, hogy az egyezés nem feltételezhető a dátum-hozzárendelés, a chain-reorganizációk, az aluligényelt coinbase és a történeti él esetek kezelésében mutatkozó eltérések miatt. A második fő komparátor a Glassnode `supply.Issued` diagramja, amely fogalmilag nagyon közel áll, ám a nyilvános dokumentáció nem ad teljesen reprodukálható algoritmust (nem derül ki, hogy coinbase outputból, a szubvenzió-ütemezésből, vagy aluligényelt jutalom-korrekcióval számolnak-e). A Newhedge, MacroMicro és Bitbo diagramjai hasznos vizuális keresztellenőrzésre, de kevésbé részletes a módszertanuk. A Blockchain.com, YCharts és Blockchair készletszint-sorai (kumulatív stock, nem napi áramlás) csak a kibocsátás hozzávetőleges deriválására alkalmasak az első differenciával, és a mögöttes számítás az elméleti jutalomra épül – tehát ezek közvetlen összehasonlításra nem alkalmasak. Az OBM fő hozzáadott értéke, hogy a kibocsátást realizált, teljes csomópontból származtatott áramlásként definiálja, szétválasztja az új BTC-t a díjaktól, a blokkokat explicit UTC-dátum-konvenció szerint rendezi, és reprodukálható algoritmust ad. ### Adatforrás és algoritmus Az exportáló script (`export_obm_issuance_btc_daily.py`) nem a Bitcoin Core-t kérdezi le közvetlenül, hanem a spent-output indexer által létrehozott perzisztens SQLite adatbázisból dolgozik. A forrástábla a `daily_aggregates`, a forrásmező az `issuance_sats`; a satoshit BTC-re való átváltás egyszerű osztás `100 000 000`-rel. Az indexer a kibocsátást blokkszinten a coinbase output és a nem-coinbase tranzakciók díjainak különbségeként számítja ki, így az exportált napi sor örökli az indexer UTC-időbélyeg-konvencióját, a previous-output rekonstrukció kezelését és a történeti éles esetekre vonatkozó szabályait. Az algoritmus kilenc lépésből áll: dátumintervallum értelmezése (YYYY-MM-DD, UTC, inkluzív), adatbázis-megnyitás query-only módban, indexer-azonosító és feldolgozási metaadatok ellenőrzése, az indexelt tartomány fedése, a release-verzió kiolvasása (vagy fallback), naponkénti `issuance_sats` kiolvasás (hiányzó sor esetén zéró), satoshi→BTC átváltás, a standard OBM CSV séma kiírása (`date, series_id, value, unit, frequency, release_version`), valamint opcionális ábrarajzolás. A metrika-specifikus paraméter a `--height_margin`, amelynek alapértéke 288 blokk (kb. két nap termelése). Ez azért kell, mert a Bitcoin blokkok timestampjei nem szigorúan monotonok a magasság függvényében: a bányászok időnként kissé vissza- vagy előreállítják az időt, így a kizárólag timestampre épülő bináris keresés túl szűk magasság-intervallumot jelölhetne ki, és kihagyhatna határblokkokat. A margin csak a belső blokk-szkennelést tágítja, a kiírt dátumokat nem. Az aggregáció napi összegzés: minden blokk realizált kibocsátása (`I_b = C_b − F_b`) hozzáadódik ahhoz az UTC-naphoz, amelyre a blokk timestampje esik. A havi változat a napi értékek egyszerű összege. ### Technikai validáció és ismert korlátok A script többszintű belső ellenőrzést végez: érvényes dátumtartomány, adatbázis-azonosító (`indexer_id`), feldolgozási metaadatok (`last_processed_height`, `last_processed_date`, `max_processed_date`), a `daily_aggregates` tábla megléte, valamint a kért záró dátum nem lépheti túl az indexelt maximumot. További külső konziszciavizsgálat: `MinerRevenueBTC_d = IssuanceBTC_d + FeesBTC_d` – ennek az identitásnak a három kapcsolódó sorból (azonos indexer adatbázisból, azonos timestamp-konvencióval) tizedesjegyre egyeznie kell. Az ismert korlátok között szerepel, hogy a mérőszám realizált, nem elméleti kibocsátást mér; függ a díjak pontos rekonstrukciójától; a történeti díj-rekonstrukció nem-pruned node-ot igényel undo-adatokkal; a napi értékek a blokkszámmal együtt ingadoznak (ami nem protokollváltozás, hanem a bányászat természetes varianciája); valamint a határnapokon a választott timestamp-konvenció (alapértelmezetten a Bitcoin Core által visszaadott UTC timestamp) apró eltéréseket okozhat más konvenciókhoz (pl. median time past) képest. E korlátok ellenére a szerző az `obm_issuance_btc_daily`-t az OBM-adathalmaz egyik központi soraként jelöli meg, amely a kumulatív készlet, a bányászbevétel, a szubvenzió-korszak-elemzés és a Bitcoin monetáris ütemezésének empirikus vizsgálatához egyaránt alapvető építőkocka. ## A.12 – `obm_liveliness_ratio_daily`: napi liveliness-arány ### Definíció és gazdasági értelmezés A napi liveliness egy kumulatív „coin-age utilization” (coin-életkor-hasznosítási) mérőszám. Azt hasonlítja össze, hogy a kollektív költés mennyi coin-életkort (coin days destroyed) semmisített meg, szemben azzal, amennyi coin-életkor az idők során keletkezett. Az OBM implementáció két már létező napi sorból építkezik: az `obm_cdd_btcxdays_daily`-ból (napi BTC-days destroyed) és az `obm_supply_btc_daily`-ból (napi BTC-készlet). A kumulatív számlálók: - `CumCDD_d = Σ_{τ ≤ d} CDD_τ` - `CumCoinDaysCreated_d = Σ_{τ ≤ d} SupplyBTC_τ` Ezekből az arány: `Liveliness_d = CumCDD_d / CumCoinDaysCreated_d`, feltéve, hogy a nevező nem nulla (ellenkező esetben az érték NaN). Az eredmény dimenziómentes, mert mindkét oldal BTC-days-ben mért; a kimeneti egység ezért `ratio`. A szerző jelzi, hogy ez napi közelítés: egy „igazí” folytonos verzió UTXO- vagy blokkszintű nyomonkövetést igényelne, ám a napi közelítés auditálható, reprodukálható, és közvetlenül számítható a meglévő OBM sorokból. Gazdaságilag a liveliness a hosszú távú tartás és költés viselkedésének kumulatív indikátora. Amikor a coin-életkor gyorsan megsemmisül (régi coinok mozognak), az arány emelkedik; amikor a coinok inaktívak maradnak és a készlet tovább halmozza a coin-dayset, az arány stabilizálódik vagy lassabban csökken. A mérőszám tehát alacsony frekvenciájú, kumulatív ellenpárja a napi CDD-nek és a dormancy-nek, és segít megkülönböztetni a felhalmozási és a régi coinok intenzív mozgásával jellemzett időszakokat. Fontos, hogy nem napi aktivitási mérőszám, hanem kumulatív arány – csak a szokatlanul nagy napi CDD esetén reagál gyorsan. A szerző óva int az értelmezéstől: a liveliness nem korrigál elveszett coinokra, inaktív de hozzáférhetetlen coinokra, self-transzferre, tőzsdei aktivitásra, custody wallet-menedzsmentre vagy entitás-szintű viselkedésre – nyers, protokollból származtatott kumulatív coin-age arány. ### Hasonló nyilvános metrikák Az `obm_liveliness_ratio_daily` a nyilvánosan Liveliness néven futó metrikákkal összehasonlítható. A legközelebbi komparátor a Glassnode `indicators.Liveliness` sora, amelyet a szerző a metódustani definíció alapján (cumulative CDD / cumulative coin-days ever created) koncepcionálisan azonosnak tart. Ugyanakkor a számszerű egyezés nem feltételezhető: az OBM a napi készlet kumulatív összegét használja a coin-days-created napi közelítésére, míg egyes szolgáltatók blokk- vagy UTXO-szintű felbontásban dolgozhatnak; emellett a CDD-konvenciók, a tört napok kezelése, a timestamp-hozzárendelés, az entitás-korrekció, az elveszett coinok kezelése és a chain-reorg politika is eltérhet. További komparátorok: a ChainExposed Liveliness diagramja (értelmezésében nagyon közeli, de algoritmust nem közlő forrás), a Newhedge Liveliness oldala (magyarázó jellegű, vizuális összehasonlításra alkalmas), a CoinGlass Bitcoin Liveliness indikátora (szintén koncepcionálisan közeli, de nem teljesen reprodukálható), valamint a BGeometrics Liveliness diagramja (másodlagos vizuális hivatkozás). A Coin Metrics és a CryptoQuant nem tesz közzé közvetlenül Liveliness-sorokat, de a `TxTfrValDayDst` (CM) és a Coin Days Destroyed (CQ) komponens-sorokból külső proxy építhető – ám az ilyen konstrukció a szolgáltató saját átviteli, készlet- és timestamp-konvencióit örökli, ezért komponens-alapú közelítésként, nem közvetlen publikus megfelelőként kell rá hivatkozni. A szerző kiemeli, hogy a liveliness nem azonosítható össze az azonos coin-age információt használó, de más szerkezetű metrikákkal: az aggregált CDD, a Dormancy, a Binary CDD, a Reserve Risk, a CVDD, a HODL Waves és a supply-age eloszlások mind coin-age alapúak, de más-más mutatószámot állítanak elő. ### Adatforrás és algoritmus (összefoglalva) A liveliness származtatott (derived) metrika, ezért saját indexer-független implementációja van: a két komponenst (CDD és Supply) tartalmazó OBM sorokból építkezik. A kumulatív összegzést naponta kell elvégezni, és a hányados kiszámítása után az eredményt a szokásos OBM-sémával kell kiírni. A függelék e metrikánál a rész határánál a „Similar metrics publicly available” alpontig jut el, a további alpontok (adatforrás, algoritmus, paraméterek, aggregáció, output, validáció, korlátok) várhatóan a következő részekben folytatódnak. ## A két metrika együttese – miért fontosak együtt? A két szakasz jól mutatja az OBM egyik fő erényét: a mérőszámok közötti belső konzisztenciát. A kibocsátás-sor a realizált bányászbevétel és a díjak azonos kódból származó három komponense, amelyekre a `MinerRevenue = Issuance + Fees` identitásnak pontosan teljesülnie kell. A liveliness-sor pedig a CDD- és Supply-sorokra épül, így a coin-age komponensek és a készlet-sorok szintén egymásból következnek. Ez a fajta belső származtatás és a közös indexer-adatbázisra támaszkodó architektúra teszi lehetővé, hogy a kutató az OBM-ből ne csupán egy-egy izolált idősorhoz, hanem egymással összekapcsolt, reprodukálható metrikák koherens rendszeréhez férjen hozzá. ### Összegzés A 11. részlet az OBM Appendixének két olyan metrikáját tárgyalja, amelyek egyrészt a Bitcoin monetáris ütemezését (napi realizált kibocsátás), másrészt a hosszú távú tulajdonosi viselkedést (liveliness arány) mérik. Mindkettő a spent-output indexer által előállított perzisztens SQLite adatbázisból dolgozik, azonos UTC-dátum-konvenciót és release-verziót alkalmaz, és a standard OBM CSV-sémát követi. Az A.11 teljes, kilenc lépéses algoritmust, explicit aggregációs szabályt, output-formátumot, technikai validációt és öt ismert korlátot ad; az A.12 a definíció és a gazdasági értelmezés után a nyilvános komparátorok (különösen a Glassnode Liveliness) részletes összevetéséig jut el. A rész a függelékben e két mérőszámot lefedte; a sorozat további részei várhatóan a liveliness-sor adatforrását, algoritmusát és korlátait, valamint a hátralévő appendix-metrikákat (bányászbevétel, supply, tx_count, utxo_count, spent_value_age_band stb.) dolgozzák fel. --- ## 12. rész Ez a tizenkettedik rész az "Open Bitcoin Metrics" (arXiv 2607.03124v1, szerző: Diego R. Llanos) című tanulmány Appendix A függelékének két hátralévő metrikáját tárgyalja: az **A.12 obm_liveliness_ratio_daily** (napi liveliness arány) és az **A.13 obm_miner_revenue_btc_daily** (napi bányász bevétel BTC-ben) metrikákat. Mindkét leírás a szerző által alkalmazott egységes struktúrát követi: definíció, gazdasági értelmezés, hasonló publikus metrikák, adatforrás és bemeneti követelmények, algoritmus, metrika-specifikus paraméterek, aggregációs szabály, kimeneti formátum, technikai validáció és ismert korlátok. --- ## A.12 obm_liveliness_ratio_daily – Napi liveliness arány ### Definíció és gazdasági jelentés A liveliness arány az egyik legismertebb on-chain aktivitási indikátor, amelyet a Bitcoin-ökoszisztémában a "mozgásban lévő coin-életkor" mérésére használnak. A mérőszám két kumulatív mennyiség hányadosa: a számláló az adott napig bezárólag felhalmozott Bitcoin Days Destroyed (CDD, BTC-days), a nevező pedig az adott napig felhalmozott, naponta létrehozott coin-days mennyiség, amelyet a szerző a napi teljes BTC-kínálat (supply) összegzésével közelít. Formálisan: Liveliness_d = Σ_{τ≤d} CDD_τ / Σ_{τ≤d} SupplyBTC_τ A hányados értéke elvileg 0 és 1 közé esik, és a Bitcoin gazdaság "ébrenléti állapotát" jellemzi: magasabb érték azt jelenti, hogy a korábban hosszabb ideig pihent coinokat nagyobb arányban költik el, míg alacsonyabb érték hosszabb távú hodlást jelez. A szerző hangsúlyozza, hogy a definíció szenzitív: a nevezőben használt napi kínálat csak közelítése a coin-day creation valódi értékének, hiszen utóbbit UTXO-szinten vagy blokk-intervallum szinten lehetne pontosan számolni. ### Publikus komparátorok és az OBM eltérő jellemzői A szerző több kereskedelmi és ingyenes szolgáltatóval veti össze az OBM-megközelítést. A **ChainExposed** és a **CoinGlass** lényegében azonos konceptuális formulát használnak, míg a **Newhedge** és a **BGeometrics** vizuálisan hasznos, de metodikailag kevésbé dokumentált. A **Coin Metrics** és a **CryptoQuant** CDD- vagy kínálati komponenseket szolgáltatnak, de nem neveznek meg konkrét liveliness arányt. Az OBM egyedisége abban áll, hogy a metrikát két, OBM-formátumú CSV-fájlból (CDD és supply) számítja, dokumentálja a coin-day creation közelítését, a hiányzó CDD megfigyeléseket nullaként kezeli (a CDD flow-jellegéből fakadóan), a supply-sorozattól örökölt UTC dátum-konvenciót használja, és reprodukálható CSV-to-CSV transzformációt nyújt. ### Adatforrás és bemenet A metrika két meglévő OBM CSV-fájlból építkezik: - `obm_cdd_btcxdays_daily`: napi Bitcoin Days Destroyed BTC-days egységben. - `obm_supply_btc_daily`: napi Bitcoin-kínálat BTC egységben. Mindkét fájl a szabványos OBM skalár sémát követi: `date, series_id, value, unit, frequency, release_version`. A script ellenőrzi a `series_id`, az `unit` és a `frequency` mezők helyességét, megköveteli, hogy az értékek numerikusak, nem-NaN és nem-negatívak legyenek, valamint hogy ne legyenek ismétlődő dátumok. A kiválasztott dátumintervallum explicit módon megadható a `--start_date` és `--end_date` kapcsolókkal; ezek hiányában a script a supply-fájl első, illetve utolsó dátumát használja (ezt a konvenciót a supply denomiátor-szerepe indokolja). A supply-fájlnak minden kiválasztott dátumra tartalmaznia kell megfigyelést, a CDD-fájl lehet ritkás: a hiányzó dátumokat a script nulla napi CDD-ként értelmezi. A metrika kiszámítása nem igényel futó Bitcoin Core node-ot, JSON-RPC hozzáférést, cím-kivonatolást, felhasználói klaszterezést, entitás-azonosítást, külső árfolyamadatokat, harmadik fél API-jait vagy közvetlen SQLite-indexer hozzáférést számítási időben – örökli viszont a CDD és supply forrássorozatok definícióját, időbélyeg-konvencióját és release-metaadatát. ### Algoritmus A `compute_obm_liveliness_ratio_daily.py` script az alábbi determinisztikus transzformációt hajtja végre: 1. Beolvassa a két CSV bemenetet, ellenőrzi a séma érvényességét. 2. A dátumokat `YYYY-MM-DD` formátumban, UTC-ként értelmezi. 3. Ellenőrzi, hogy a CDD-fájl `obm_cdd_btcxdays_daily` sorozata `BTC-days` egységben, napi gyakorisággal áll rendelkezésre; hasonlóan a supply-fájlra. 4. A kiválasztott dátumintervallumban megköveteli a teljes supply-sort, a CDD-rést nullaként kezeli. 5. A kiválasztott időszakra vonatkozóan egy közös `release_version` meglétét ellenőrzi. 6. Minden dátumra kumulatív CDD-t (`CumCDD_d = CumCDD_{d-1} + CDD_d`) és kumulatív coin-days created értéket (`CumCoinDaysCreated_d = CumCoinDaysCreated_{d-1} + SupplyBTC_d`) számol. 7. A liveliness értéket a `Liveliness_d = CumCDD_d / CumCoinDaysCreated_d` hányadosként írja ki, tizenkét tizedesjegy pontossággal. Ha a nevező nulla, a cella `NaN` értéket kap. 8. A kimeneti CSV az OBM szabványos sémát követi, és a `--plot` kapcsolóval PNG-ábra generálható. ### Aggregációs szabály és kimeneti formátum Mivel a metrika kumulatív, fontos szabály, hogy havi vagy éves változatait **nem szabad** a napi értékek összegzésével előállítani – ehelyett a kumulatív számlálót és nevezőt kell újraszámolni a kívánt periódus végpontjára, vagy a napi sorozatot kell mintavételezni a periódus végén. A kimeneti CSV minden UTC dátumra egy sort tartalmaz: `date`, `series_id=obm_liveliness_ratio_daily`, `value` (12 tizedesjegy), `unit=ratio` (dimenziótlan), `frequency=daily`, `release_version` (a forrásfájlokból örökölt). ### Technikai validáció és ismert korlátok A script kilenc belső ellenőrzést futtat: a séma helyessége, az értékek parseolhatósága, a dátum-egyediség, a `series_id/unit/frequency` invariánsok, az intervallum érvényessége, a supply-sor teljessége, a CDD-rezsérték nullás kezelése, valamint a közös `release_version` megléte. A kiadás előtt további külső ellenőrzés javasolt: az értékek nem-negatívak, és konzisztens CDD/supply konvenciók mellett 0 és 1 közé esnek. Az 1 fölé menő érték definíciós inkonzisztenciát jelez a számláló és a nevező között. A kumulatív CDD és a kumulatív coin-days created sorok nem csökkenhetnek; a liveliness nagy ugrásait az `obm_cdd_btcxdays_daily` kiugró értékeivel együtt kell interpretálni a CDD age-band és spent-value age-band táblákkal. A szerző nyolc korlátot sorol fel: (1) a metrika származtatott jellege, (2) a hiányzó CDD-dátumok nullás kezelése csak akkor helyes, ha a hiány valóban nulla flow-t jelent, (3) a teljes napi supply-sor követelménye, (4) a napi supply közelítés a coin-day creationre, (5) az elveszett coinokra való korrekció hiánya, (6) a nyers CDD-ből örökölt entitás-korrekció hiánya, (7) a kumulatív, lassan mozgó jelleg, ami nem alkalmas magas frekvenciájú aktivitásmérésre, és (8) a forrássor definíciójának vagy release verziójának változása esetén a teljes újraszámolás szükségessége. --- ## A.13 obm_miner_revenue_btc_daily – Napi bányász bevétel BTC-ben ### Definíció és gazdasági értelmezés A napi bányász bevétel a Bitcoin protokollon keresztül a bányászoknak kifizetett teljes BTC-mennyiséget méri, adott UTC naptári naphoz rendelt blokkok coinbase tranzakcióinak összesített kimeneti értékeként. Formálisan: MinerRevenueBTC_d = Σ_{b ∈ B_d} C_b ahol B_d a d UTC naphoz rendelt blokkok halmaza, és C_b a b blokk coinbase tranzakciójának teljes kimeneti értéke. A blokk-hozzárendelés a blokk timestamp UTC dátumából származik. Mivel a coinbase tranzakció az újonnan kibocsátott BTC-t (subsidy, issuance) és a trakciós díjakat egyaránt a bányásznak fizeti, a metrika felírható mint: MinerRevenueBTC_d = IssuanceBTC_d + FeesBTC_d A mérőszám tehát közvetlenül méri a Bitcoin BTC-denominált biztonsági költségvetését: a protokollon keresztül a bányászoknak fizetett kompenzációt. A szerző négy konkrét felhasználási területet emel ki: (1) a biztonsági költségvetés közvetlen mérése, (2) a bányász ösztönzők vizsgálata a subsidy-korszakokon átívelve, (3) a felezési események (halving) elemzése, ahol a subsidy csökkenését a díjaknak kell kompenzálniuk, és (4) a fee-share-of-miner-revenue metrika nevezőjeként való szolgálat. Fontos negatív megállapítás: a metrika **nem** méri a bányász profitot (nem veszi figyelembe az áramköltséget, hardver-amortizációt, pool-díjakat, finanszírozási költségeket, adókat), nem fiat-denominált jövedelem, és nem azonosítja az egyes bányászokat vagy poolokat. ### Publikus komparátorok A legerősebb publikus benchmark a **Glassnode mining.RevenueSum** (BTC-ben, halmozott kibocsátás + díjak). A **Coin Metrics** az `IssTotNtv` (teljes kibocsátás natív egységben) és a `FeeTotNtv` (teljes díjak natív egységben) komponensek összegeként állítható elő – ez konceptuálisan összhangban van az OBM-mel, de származtatott komparátor, nem közvetlen replika. A **Blockchain.com** és az **YCharts** USD-denominált sorozatot szolgáltatnak, így közvetlen benchmarknak nem alkalmasak. A **Newhedge**, **BitInfoCharts**, **Bitcoin Magazine Pro**, **MacroMicro** és **Bitbo** hasznos másodlagos források, de vagy USD-ben vannak, vagy hiányzik a teljes reprodukálható algoritmus. A **Blockchair** blokkszintű adataiból rekonstruálható a metrika, ha a csoportosítási és összegzési konvenciók expliciten dokumentálva vannak. Az OBM egyedisége, hogy a BTC-bevételt közvetlenül a coinbase tranzakció kimeneti értékeiből számítja, a blokkokat explicit UTC timestamp-konvenció szerint rendeli naphoz, és a metrikát a napi issuance és fee sorozatokon keresztül validálja. ### Adatforrás és bemenet Az `obm_miner_revenue_btc_daily` metrika a perzisztens OBM spent-output indexer SQLite adatbázisából exportálódik, nem önálló blokklánc-szkennelésből. A releváns forrástábla a `daily_aggregates`, a releváns mező a `coinbase_output_sats` (satoshi-ban tárolva). A konverzió: MinerRevenueBTC_d = coinbase_output_sats_d / 100 000 000 A script nem hív Bitcoin Core-t közvetlenül – a szükséges adatokat az `obm_spent_output_indexer.py` már kiszámította a blokklánc szekvenciális szkennelése során. Az exportáláshoz szükséges, hogy a kért záró dátum ne lépje túl az indexer által feldolgozott maximális dátumot (`max_processed_date`); ellenkező esetben a script leáll és az indexer továbbfuttatását kéri. Ha egy adott naphoz nem tartozik sor a `daily_aggregates` táblában, a script nulla értéket ír ki – ez a konvenció a flow-jellegből fakad: hiányzó sor azt jelenti, hogy nem volt a naphoz rendelt blokk-hozzájárulás. ### Algoritmus A `export_obm_miner_revenue_btc_daily.py` script kilenc lépésben dolgozik: 1. A felhasználó által megadott `--start_date` és `--end_date` UTC dátumokat parseolja `YYYY-MM-DD` formátumban. 2. Megnyitja az indexer által generált SQLite adatbázist a `--state_db` útvonalon. 3. Validálja, hogy az adatbázis valóban OBM spent-output indexer: ellenőrzi az `indexer_id`, `last_processed_height`, `last_processed_date`, `max_processed_date` metaadatokat. 4. Ellenőrzi, hogy a kért `--end_date` nem későbbi, mint az indexer által feldolgozott maximális dátum. 5. A `release_version`-t az indexer metaadatából veszi, vagy a `--release_version` fallback értéket használja. 6. Minden dátumra lekéri a `coinbase_output_sats` értéket a `daily_aggregates` táblából; hiányzó sor esetén nullát ír. 7. Satiról BTC-re konvertál (osztás 100 000 000-zal). 8. Az eredményt az OBM szabványos CSV sémába írja. 9. A `--plot` kapcsolóval PNG-ábra generálható (a cím tartalmazza a sorozat leírását és az intervallumot). ### Paraméterek és aggregációs szabály A metrika-specifikus kapcsolók a következők: `--state_db`, `--start_date`, `--end_date`, `--release_version`, `--output` (alapértelmezetten `obm_miner_revenue_btc_daily.csv`), `--plot` és `--plot_output`. A script explicit módon elutasítja a Bitcoin Core RPC paramétereket, a `--height_margin`, `--commit_every`, `--min_confirmations` és `--reset_state_db` kapcsolókat – ezek az indexerhez tartoznak, nem az exportőrhöz. Az aggregációs szabály: a napi érték a coinbase kimenetek összege az adott UTC naphoz rendelt blokkokra. Havi változat esetén a napi értékeket összegezni kell (szemben a liveliness-szel, ahol ez tilos lenne), mivel a metrika flow-jellegű. ### Kimeneti formátum és validáció A kimeneti CSV minden UTC dátumra egy sort tartalmaz: `date`, `series_id=obm_miner_revenue_btc_daily`, `value` (BTC-ben, pl. 931.13492017), `unit=BTC`, `frequency=daily`, `release_version`. A validáció során a script ellenőrzi az intervallum érvényességét, az adatbázis megnyithatóságát, a query-only mód beállítását, valamint a release-verzió konzisztenciáját. A kiadás előtt ajánlott külső ellenőrzés: a `MinerRevenueBTC_d = IssuanceBTC_d + FeesBTC_d` identitás teljesülése, az értékek nem-negativitása, a subsidy- és fee-komponensekkel való összhang, valamint a lánc-újrarendeződések (reorg) kezelésének konzisztenciája. ### Ismert korlátok A szerző a következő korlátokat sorolja fel: a metrika a flow-változó jelleg miatt érzékeny a reorgokra és az aluligényelt coinbase rewardokra; a konvenciók (időbélyeg, reorg-kezelés, aluligénylés, fee-rekonstrukció) szolgáltatónként eltérhetnek; a historikus él-esetek (pl. genesis blokk, ismert anomáliák) kezelése eltérő lehet; a sorozat nem azonosít entitásokat, és nem szolgáltat USD-bevételt – a piaci árfolyam-változások elemzéséhez külső árfolyamsor szükséges. Ugyanakkor az OBM-megközelítés előnye, hogy minden lépése (blokk-coinbase kiolvasás, UTC dátum-hozzárendelés, satoshi-BTC konverzió, release-metaadat) reprodukálható és auditálható. --- ## Összegzés és kontextus A tizenkettedik rész két, konceptuálisan nagyon eltérő, de egyaránt fontos OBM-metrikát mutat be. Az **A.12 liveliness arány** a Bitcoin "ébrenléti állapotának" kumulatív, lassan mozgó indikátora, amelyet két OBM CSV-ből (CDD és supply) számol a script – ez a megközelítés teljesen CSV-to-CSV, nincs szükség Bitcoin Core-ra vagy indexerre a futtatáshoz. Az **A.13 napi bányász bevétel** ezzel szemben a spent-output indexer által a blokklánc szkennelése során már kiszámított `coinbase_output_sats` napi összesítésből exportálódik – ez az indexer-alapú megközelítés az Appendix A második felének domináns mintája. A két metrika együttesen jól példázza az OBM architektúra kettősségét: a derivált, tisztán CSV-alapú számítások (mint a liveliness) és az indexer által aggregált nyers lánc-adatokból származó exportok (mint a miner revenue) ugyanazon szabványos OBM CSV sémába (`date, series_id, value, unit, frequency, release_version`) torkollanak, biztosítva a sorozatok közötti kompatibilitást és a reprodukálható, auditálható számítást. A következő rész várhatóan az Appendix A maradék metrikáit (vagy az esetleges Appendix B-t) és a References szekciót fogja tartalmazni. --- ## 13. rész ## Bevezető: a tizenharmadik rész helye a dokumentumban A „Diego R. Llanos: Open Bitcoin Metrics” című arXiv-tanulmány (2607.03124v1) tizenharmadik feldolgozási egysége, a `13. rész szövege` körülbelül 4500 szót tartalmaz. Ez a rész az Appendix két, egymáshoz szorosan kapcsolódó metrikáját dolgozza fel: - az **A.13** szakasz (obm_miner_revenue_btc_daily) leírásának végét, valamint a teljes belső konzisztenciaellenőrző blokkot, illetve a „Known limitations” alfejezetet; - az **A.14** szakaszt (obm_raw_output_value_btc_daily) teljes terjedelmében – definíció, gazdasági értelmezés, hasonló publikus metrikák, adatforrás, algoritmus, input-paraméterek, aggregációs szabály, kimeneti formátum, technikai validáció. Az alábbiakban először a Miner-revenue metrika lezárását foglalom össze, majd részletesen bemutatom az A.14 nyers output-érték metrikát, amely a teljesítmény-szempontból kritikus OBM spent-output indexer adatbázis egyik legfontosabb származtatott sora. --- ## 1. Az A.13 (miner-revenue) lezáró része: konzisztencia-ellenőrzések és ismert korlátok ### 1.1 A belső konzisztenciaazonosság A bányászok napi bevételét leíró metrika egy fontos könyvelési azonosság köré épül, amelyet minden OBM-exportőr ugyanabból az indexer-adatbázisból kiindulva köteles reprodukálni: - MinerRevenueBTC(d) = IssuanceBTC(d) + FeesBTC(d) – vagy ezzel egyenértékűen FeesBTC(d) = MinerRevenueBTC(d) − IssuanceBTC(d). Ez az azonoság akkor áll fenn, ha az obm_miner_revenue_btc_daily, az obm_issuance_btc_daily és az obm_fees_btc_daily ugyanabból az indexer-adatbázisból, azonos időbélyeg-konvencióval és azonos release-verzióval lett exportálva. A szerző hangsúlyozza, hogy külső miner-revenue vagy block-reward szolgáltatókkal való összevetés kizárólag diagnosztikai célokat szolgálhat, és soha nem tekinthető szigorú egyenlőségi tesztnek, mivel a különböző szolgáltatók eltérhetnek: - az időbélyeg-konvencióban (melyik blokk melyik naptári naphoz rendelődik); - a megerősítési politikában (hány confirmation után tekintik a blokkot véglegesnek); - a reorg-kezelésben (mit csinálnak, ha egy hosszabb lánc érvényteleníti a korábbi blokkokat); - az aluligényelt kibocsátás (underclaimed issuance) kezelésében; - a történeti él-esetek (pl. Coinbase 2010-es „value overflow incident” vagy a korai genesis előtti duplikált coinbase-ek) kezelésében; - abban, hogy az értékeket BTC-ben vagy fiat pénznemben jelentik-e. ### 1.2 A metrika ismert korlátai A szerző hat, explicit korlátot sorol fel, amelyek egyben az OBM teljes filozófiáját is jellemzik – az indexer-alapú rekonstrukció inherens sajátosságai: 1. **Indexer-függőség.** A sor teljes mértékben az OBM spent-output indexer adatbázis helyességén és teljességén múlik; ha az indexer futása megszakadt, vagy egy blokk kimaradt, az itt is megjelenik. 2. **Időbélyeg-konvenció.** A metrika a blokk timestamp UTC-származtatásán alapul; a Bitcoin-protokoll lehetővé teszi, hogy a bányász a valós időnél ±2 órával eltérő timestampet írjon, ami a napi határok mentén mérési bizonytalanságot okozhat. 3. **Csak BTC-ben van denominálva.** A sor nem tartalmazza a fiat-árfolyam-ingadozások hatását, így közvetlenül nem alkalmas USD-bevétel-vizsgálatokra. 4. **Nem profit.** A miner-revenue bruttó, top-line bevétel; nem veszi figyelembe az áramköltséget, a hardver-amortizációt, a pool-díjakat, a finanszírozási költségeket és az adókat. 5. **Nem azonosít entitást.** A sor nem mondja meg, hogy melyik bányász, pool vagy szervezet termelte az adott blokkot – ez az OBM szándékos döntése a személyes adatok védelme és a reprodukálhatóság érdekében. 6. **A reorg-politika korlátja.** Az indexer egyszerűsített reorg-kezelése inkonzisztencia esetén leáll, de nem görgeti vissza automatikusan az állapot-adatbázist. A szerző ugyanakkor kiemeli, hogy ezen korlátok ellenére az obm_miner_revenue_btc_daily „core OBM series”: átlátszó, BTC-denominált, naponta frissíthető, és alapul szolgál a miner-incentive-ek, a felezési (halving) dinamika, a fee-piac fejlődése, a fee-share of revenue és a Bitcoin hosszú távú biztonsági költségvetésének vizsgálatához. --- ## 2. Az A.14 metrika: obm_raw_output_value_btc_daily ### 2.1 Definíció és formális specifikáció Az obm_raw_output_value_btc_daily a nem-currency-alapú, azaz a hétköznapi (nem coinbase) tranzakciók által az adott UTC-naptári naphoz rendelt blokkokban létrehozott outputok teljes BTC-értékét méri. Formálisan: - Legyen B(d) azon blokkok halmaza, amelyeket a d UTC-naphoz rendelünk. - Minden b ∈ B(d) blokkban minden j tranzakcióra, amely nem coinbase (azaz j ∈ T_b^noncb), legyen O(j) a j tranzakció által létrehozott outputok halmaza, és v(o) az o output BTC-értéke. - A nyers output-érték definíciója: RawOutputValueBTC(d) = Σ_{b ∈ B(d)} Σ_{j ∈ T_b^noncb} Σ_{o ∈ O(j)} v(o). A blokk hozzárendelése a naphoz: d(b) = UTCDate(t_b), ahol t_b a blokk fejléce által hordozott timestamp. A coinbase-outputok szándékosan kimaradnak, mert azok a bányászbevételt reprezentálják (újonnan kibocsátott BTC + díjak), és ezt az obm_miner_revenue_btc_daily és az obm_issuance_btc_daily már lefedi. ### 2.2 Gazdasági értelmezés: miért „nyers”, és miért nem „fizetési volumen”? A metrika neve nem véletlenül tartalmazza a „raw” előtagot. A szerző hangsúlyozza, hogy ez a sor egy transzparens, alacsony szintű blokklánc-könyvelési alapvonal, és NEM tekinthető a gazdaságilag értelmezhető fizetési volumen becslésének. A nyers output-érték ugyanis tartalmazza: - a **change outputokat** (visszajáró coinok, amelyeket a küldő saját címére utal vissza a tranzakció); - az **öntranszfereket** (saját magamnak küldök, például wallet-konszolidáció); - a **batchinget** (egy fizetés valójában több kimenetet fizet egyszerre, pl. exchange kifizetési kör); - az **exchange- és custodial-tevékenységet** (belső átvezetések, meleg-meleg tárcák közötti mozgások); - a **wallet-reorganizációt** (címstruktúra-váltás, UTXO-set takarítás). A metrika kiegészíti a tranzakciószámlálót (mert értéket, nem gyakoriságot mér), és kiegészíti a spent output value metrikát is (mert a kimeneti, nem a bemeneti oldalt nézi). Olyan empirikus kutatásokhoz ideális, ahol a kutatók szándékosan kerülik az átlátszatlan entitás-klaszterezési heurisztikákat, és egy reprodukálható baseline-sort keresnek. ### 2.3 Hasonló publikus metrikák A szerző részletesen végigmegy a nyilvános összehasonlító szolgáltatókon, és mindenhol jelzi, hogy a metrika koncepcionálisan rokon, de nem feltétlenül ekvivalens: - **Blockchain.com Output Value Per Day** – a legközelebbi nyilvános megfelelő. Ez is a teljes tranzakciós output-értéket méri, és a definíció szintén tartalmazza a change outputokat. A szerző azonban felhívja a figyelmet arra, hogy a Blockchain.com oldala nem egyértelműsíti, hogy a coinbase-outputok benne vannak-e vagy sem, míg az OBM ezeket kizárja. A Blockchain.com „Estimated Transaction Value (BTC)” egy másik rokon, de change-korrigált metrika – ez a change-eltávolított gazdasági transzfer-becslés, nem a raw output value. - **YCharts Bitcoin Total Output Value Per Day** – a Blockchain.com adat másodközlése; nem független rekonstrukció. - **Blockchair On-chain volume (BTC / USD)** – Block total − Blocks (BTC) konstrukcióval, output-oldali blokk-aggregáció, de a pontos algoritmus (coinbase-kezelés, időbélyeg, reorg, change) nem teljesen dokumentált. - **Glassnode transactions.TransfersVolumeSum** – transfer volume, tehát a „küldött érték” keretrendszerben gondolkodik, és entitás-korrigált variánsokat is kínál. A raw output value-val való egyezés csak akkor lenne szigorú, ha a Glassnode konvenciói pontosan megegyeznének az OBM-ével. - **Coin Metrics TxTfrValNtv (Xfer'd Val)** – natív egységben mért átutalási érték, ahol a „adjusted” változatok self-churn és cold-wallet shuffle szűrőket alkalmaznak. Az OBM szándékosan nem alkalmaz ilyen korrekciókat. - **Newhedge output volume / transaction volume indikátorok** – a konkrét definíciók (change, coinbase, szűrés) nem dokumentáltak, és a teljes adathoz regisztráció kell. - **BitInfoCharts „Bitcoins sent last 24h”** – a módszertan nem kellően specifikált ahhoz, hogy közvetlen összehasonlításra alkalmas legyen. - **Blockchain.com Confirmed Payments Per Day** – output-alapú, de a fizetések számát becsli (change-heurisztikával), nem pedig BTC-értéket összegzi. Az OBM egyedülálló hozzájárulása ezen a téren az, hogy a raw output-érték objektumot formálisan definiálja, a coinbase-outputokat konstrukció szintjén kizárja, megőrzi a nyers output-oldali könyvelést (beleértve a change-et és az öntranszfereket), a blokkokat az indexer dokumentált UTC timestamp-konvenciójával rendeli naphoz, és mindezt reprodukálható módon, dekódolt Bitcoin Core blokkokból számítja. ### 2.4 Adatforrás és input-követelmények A metrika nem saját blokklánc-szkennelést végez; az OBM spent-output indexer adatbázisából dolgozik. A forrástábla a `daily_aggregates`, a releváns mezők a `spent_value_sats` és a `fees_sats` (vagy ezek satoshi-denominált megfelelői). A számítás a tranzakció-szintű könyvelési azonosságot használja: nem-currency tranzakcióknál a fee = bemenet − kimenet, azaz a nem-currency output-érték = spent value − fee. A számítás lépései: - RawOutputValueSats(d) = SpentValueSats(d) − FeesSats(d) - RawOutputValueBTC(d) = RawOutputValueSats(d) / 100 000 000 Az exportőr script (`export_obm_raw_output_value_btc_daily.py`) nem kérdez le Bitcoin Core-t exportáláskor, és nem hív dekódolt blokkokat. A számításigényes blokklánc-feldolgozás, a previous-output rekonstrukció, a spent value és a fee kiszámítása mind előzetesen, az obm_spent_output_indexer.py futásakor történik. Az exportálás tehát egy determinisztikus transzformáció: indexer-adatbázis → standard OBM CSV. A metrika nem igényel cím-extrakciót, user-klaszterezést, entitás-azonosítást, külső árfolyamadatot, harmadik féltől származó API-t vagy közvetlen Bitcoin Core kapcsolatot. Viszont örökli az indexer összes tulajdonságát: az UTC timestamp-konvenciót, a previous-output rekonstrukciós eljárást, a lánc-konzisztencia-ellenőrzéseket, a release-metaadatokat és a történeti duplikált-outpoint él-esetek kezelését. ### 2.5 Algoritmus – 17 lépésben A metrikát exportáló script pontos, determinisztikus eljárást követ: 1. A felhasználó által megadott dátumintervallum (`--start_date`, `--end_date`) értelmezése YYYY-MM-DD formátumban, UTC-ben. 2. Annak ellenőrzése, hogy a kezdő dátum nem későbbi a végdátumnál. 3. Az OBM spent-output indexer SQLite adatbázis megnyitása a `--state_db` útvonalon; ha nem létezik, a script leáll hibával. 4. A `daily_aggregates` (vagy `--table` argumentumban megadott) tábla azonosítása – automatikus detektálással vagy explicit megadással. 5. A dátumoszlop azonosítása (`date`, `day`, `utc_date` – vagy `--date_column`). 6. A spent-value és fee oszlopok azonosítása; a `--value_mode auto` módban az exporter először satoshi-oszlopokat (`spent_value_sats`, `fees_sats`) keres, és csak azok hiányában tér át BTC-oszlopokra. 7. A kért kimeneti intervallum inicializálása – minden dátum „undefined” állapotban, amíg az adatbázis-lekérdezés nem szolgáltat aggregált sort. 8. Az adatbázis-lekérdezés: minden sor, amelynek dátuma a kért intervallumba esik. 9. Duplikált dátumok ellenőrzése – hiba, ha egy naptári nap kétszer szerepel. 10. Szatomi-oszlopoknál integer-ellenőrzés; BTC-oszlopoknál decimal-aritmetika. 11. A nyers output-érték kiszámítása: RawOutputValue(d) = SpentValue(d) − Fees(d). 12. Negatív eredmény elutasítása (ez adatbázis-inkonzisztenciát jelezne). 13. Átváltás BTC-be: osztás 100 000 000-zal. 14. Hiányzó dátumok kezelése: a `--missing_dates_as_zero` flag nélkül a script leáll hibával, mert ez potenciális indexer-lefedettségi problémát jelez; a flag megadásával a hiányzó napok 0 értékkel kerülnek kiírásra (ez a konvenció csak akkor helyes, ha az indexer adatbázisáról tudjuk, hogy teljesen lefedi a kért intervallumot). 15. Az eredmény kiírása a standard OBM CSV-sémával: `date, series_id, value, unit, frequency, release_version`, 8 tizedesjegy pontossággal. 16. Opcionális ábragenerálás a `--plot` kapcsolóval (alapértelmezetten a CSV neve mellé, .png kiterjesztéssel). 17. Diagnosztikai információk kiírása (kimeneti útvonal, dátumintervallum, adatbázis-útvonal, tábla, oszlopok, value-mode, olvasott sorok száma, hiányzó dátumok száma) – kivéve, ha `--quiet` van megadva. ### 2.6 Metrika-specifikus paraméterek Az A.14 exporter a következő egyedi argumentumokat fogadja: - `--state_db`: az indexer SQLite adatbázis útvonala (alapértelmezetten `cache/obm_spent_output_indexer.sqlite`). - `--table`: opcionális aggregált tábla neve (alapértelmezetten `daily_aggregates`). - `--date_column`: opcionális dátumoszlop-név. - `--spent_value_column`: opcionális spent-value oszlop; a satoshi-változat előnyben részesített a pontos integer-könyvelés megőrzése miatt. - `--fees_column`: opcionális fee oszlop; szintén satoshi-verzió az előnyös. - `--value_mode`: `auto`, `sats` vagy `btc` – az auto mód először satoshit próbál, és csak visszaesésként használ BTC-t. - `--missing_dates_as_zero`: opcionális flag, amely csak teljes indexer-lefedettség esetén használható. A standard közös paraméterek (`--start_date`, `--end_date`, `--output`, `--release_version`, `--plot`, `--plot_output`, `--quiet`) természetesen itt is elérhetők. A script NEM fogad Bitcoin Core RPC paramétereket vagy `--height_margin`-t, mivel ez a metrika nem blokk-szkenneléssel, hanem az előre elkészített indexer-adatbázisból dolgozik. ### 2.7 Aggregációs szabály A napi érték az adott UTC naphoz rendelt összes nem-currency tranzakciós output-érték összege: RawOutputValueBTC(d) = Σ_{b: UTCDate(t_b)=d} Σ_{j ∈ T_b^noncb} Σ_{o ∈ O_j} v_o Az aggregációs szabály tehát „napi összeg”. A havi változat, ha az OBM terjesztené, szintén a napi értékek összegeként áll elő: RawOutputValueBTC(m) = Σ_{d ∈ m} RawOutputValueBTC(d) Ez megőrzi a metrika értelmezését, miszerint az adott időszakban létrehozott teljes nyers nem-currency output-értéket tükrözi. ### 2.8 Kimeneti formátum A kimeneti CSV minden UTC naphoz egy megfigyelést tartalmaz, a következő oszlopokkal: - `date`: UTC naptári dátum (pl. 2024-01-01); - `series_id`: stabil OBM sorazonosító (`obm_raw_output_value_btc_daily`); - `value`: a nyers nem-currency output-érték BTC-ben (8 tizedesjegy pontossággal, pl. 587321.12345678); - `unit`: BTC; - `frequency`: daily; - `release_version`: az adatrelease verziója (pl. OBM v0.1.0). ### 2.9 Technikai validáció A script tíz belső konzisztenciaellenőrzést futtat: 1. A dátumintervallum érvényessége (`--start_date` ≤ `--end_date`). 2. A megadott SQLite állapotadatbázis létezése. 3. A választott aggregált tábla létezése (explicit megadás vagy auto-detect). 4. A választott dátum, spent-value és fee oszlopok létezése. 5. Satomi-oszlopok esetén az értékek integer volta. 6. Minden numerikus érték decimal-aritmetikával való parse-olása (a bináris lebegőpontos artefaktumok elkerülése végett). 7. Az adatbázis-lekérdezés által visszaadott dátumok egyediségi ellenőrzése. 8. A raw output value kiszámítása a könyvelési azonossággal, és a negatív eredmény elutasítása. 9. Hiányzó dátumok kezelése: `--missing_dates_as_zero` nélkül a script leáll; a flag használatával 0 érték kerül kiírásra. 10. A kimeneti CSV kiírása a standard OBM sémával és a diagnosztikai információk megjelenítése. Ezen felül a tranzakció-szintű könyvelési azonosság a rokon OBM-metrikákkal (spent_value, fees) együttesen is ellenőrizhető: nem-currency tranzakcióknál InputValue(j) = OutputValue(j) + Fee(j), és ebből output-érték = input − fee. Az A.14 metrika a spent value és fees mezők indexerbeli kombinációjából származik, így a konzisztenciavizsgálat automatikusan elérhető. --- ## 3. Összegzés és a rész jelentősége A tizenharmadik feldolgozási egység két fontos üzenetet hordoz: - **A.13 (miner-revenue) lezárása** megerősíti, hogy az OBM metrikus identitások (MinerRevenue = Issuance + Fees) belső konzisztenciája az indexerből származtatott minden sor esetén szigorúan fenntartandó, míg a külső szolgáltatókkal való összevetés csak diagnosztikai lehet. A „Known limitations” lista tudatosan szűk: a sor bruttó BTC-bevétel, nem profit, nem entitás-szintű, és érzékeny a timestamp-konvencióra. - **A.14 (raw output value)** az output-oldali blokklánc-aktivitás egyetlen, reprodukálható, szolgáltató-semleges definícióját adja. A szerző a metrika „nyers” jellegét hangsúlyozza: bár ez a sor az on-chain output-érték egyik legátfogóbb és leginkább dekódolható mérőszáma, nem fizetési volumen, és a change outputok, az öntranszferek, a batching és a custody-aktivitás miatt a kutatónak tudatosan kell kezelnie. A kivitelezés a spent-output indexer adatbázisra épül, és a nyers output-érték = spent value − fees tranzakció-szintű azonosságból indul ki – így a metrika egy tiszta, determinisztikus transzformáció eredménye, és az OBM export-formátumba (date, series_id, value, unit, frequency, release_version) konvertálódik 8 tizedesjegy pontossággal. A teljesítmény-szempontból kulcsfontosságú részlet, hogy az A.14 exportőr nem végzi el újra a blokklánc-szkennelést: az obm_spent_output_indexer.py előre kiszámítja a `daily_aggregates` táblát, és az exportőr csupán erre a már meglévő SQLite adatbázisra alkalmazza a `RawOutputValue = SpentValue − Fees` képletet. Ez a „számítsd egyszer, exportálj sokszor” filozófia teszi az OBM-et hatékonnyá és skálázhatóvá nagy historikus idősorok (akár a 2009-es genesis blokktól napjainkig) előállításához. A következő rész (14. rész) várhatóan az A.15 (obm_spent_output_count_daily) és az A.16 (obm_spent_value_btc_daily) metrikákkal folytatja a spent-output családot. --- ## 14. rész ## Bevezető: hol tartunk a függelékben? Ez a részlet a „Open Bitcoin Metrics” (arXiv: 2607.03124v1, szerző: Diego R. Llanos) című tanulmány A függelékének (Appendix A) középső szakaszát tárgyalja. A korábbi részek a 4. fejezet módszertanát és az A.1–A.13 metrikákat (block_count, block_weight, nehézség, CDD, dormancy, kibocsátás, díjak, hashrate, élénkség, bányászbevétel stb.) fedték le. A mostani darab három, egymáshoz szorosan kapcsolódó metrikát mutat be részletesen: a `obm_raw_output_value_btc_daily` (A.14), a `obm_spent_output_count_daily` (A.15) és a `obm_spent_value_age_band_btc_daily` (A.16) nevű napi sorokat. Mindhárom metrika a Bitcoin lánc UTXO-szemléletű aktivitását írja le, és ugyanabból a kitartó (perzisztens) spent-output indexelő adatbázisból származik, amelyet a tanulmány 3.4-es szakasza ismertet. ## A.14 – `obm_raw_output_value_btc_daily`: napi nyers kimeneti érték BTC-ben ### Definíció és számítási azonosság A metrika célja, hogy a Bitcoin-tranzakciók outputjainak teljes, nyers BTC-értékét napi szinten megadja, **coinbase (bányász) tranzakciók nélkül**. A számítás a jól ismert könyvelési azonosságra épül: - Tranzakció szinten: `InputValue_j = OutputValue_j + Fee_j` - Napi szinten: `SpentValueBTC_d = RawOutputValueBTC_d + FeesBTC_d` Ebből következik, hogy a nyers kimeneti érték a napi elköltött érték és a napi díjak különbségeként áll elő: `RawOutputValueBTC_d = SpentValueBTC_d − FeesBTC_d` Ez az átalakítás azért hasznos, mert a spent-output indexelő a tranzakció input oldaláról dolgozik: minden elköltött kimenethez ismert az értéke és az eredeti blokk, így a díjak levonásával a tranzakció kimeneti oldalának teljes, nyers BTC-értéke rekonstruálható. Az exportőr tehát a számítást az indexelő adatbázisából végzi, nem a Bitcoin Core-ból közvetlenül. ### Azonosító, konvenciók és értelmezés - **Sorozatazonosító:** `obm_raw_output_value_btc_daily` - **Értelmezés:** az adott UTC naptári naphoz rendelt blokkokban lévő, nem coinbase tranzakciók kimeneteinek teljes BTC-értéke. - **Blokk–dátum hozzárendelés:** `d(b) = UTCDate(t_b)`, azaz a blokk időbélyege alapján UTC naptári napra képezzük le. - **Ablakkezelés:** ha a `--missing_dates_as_zero` kapcsolóval futtatjuk, a hiányzó aggregált sorok nullaként íródnak ki – ez csak akkor helyes, ha az indexelő adatbázis valóban lefedi a kért időszakot. ### Gazdasági jelentés A nyers kimeneti érték egy **output-oldali, nyers aktivitási mutató**. Nem entitás-korrigált, nem azonosít címeket, felhasználókat vagy entitásokat, így a következő elemek mind bekerülnek: change outputok, saját maguknak küldött tranzakciók, batchelt kifizetések, tőzsdei műveletek, letétkezelői átszervezések, tárcakonszolidációk. Ugyanakkor a coinbase tranzakciók (bányászjavadalmazás) kimaradnak, ezért a metrika nem a teljes, láncon keletkezett értéket méri. Hasznossága inkább abban rejlik, hogy **átlátható, reprodukálható alapot** ad, amelyhez képest a bonyolultabb, heurisztikákkal korrigált forgalmi mutatók összehasonlíthatók. ### Ismert korlátok Kilenc explicit korlátot sorol fel a szöveg: (1) az indexelő futás helyességétől és release-verziójától függ; (2) az értéket az indexelő komponenseiből származtatjuk, így örökli azok esetleges hibáit; (3) a `--missing_dates_as_zero` csak teljes lefedettségnél biztonságos; (4) nem gazdaságilag korrigált fizetési volumen; (5) a coinbase-szel együtt nem értelmezhető; (6) nem azonosít szereplőket; (7) az UTC időbélyeg-konvencióhoz kötött; (8) BTC-ben mér, nem fiatban; (9) a kereskedelmi forgalmi mérőszámoktól (change-szűrés, entitás-klaszterezés, alternatív időbélyeg, „adjusted transfer volume”) eltérhet. ## A.15 – `obm_spent_output_count_daily`: napi elköltött kimenetek száma ### Definíció Ez a metrika a napi szinten elfogyasztott korábbi UTXO-k darabszámát adja meg. Formálisan: `SpentOutputCount_d = Σ_{b ∈ B_d} |I_b|` ahol `B_d` a naphoz rendelt blokkok halmaza, `I_b` pedig a `b` blokkban lévő nem coinbase tranzakció-inputok halmaza. Minden input pontosan egy korábbi kimenetet költ el, ezért a napi érték a nap során elfogyasztott outputok száma. A blokk–dátum hozzárendelés itt is `d(b) = UTCDate(t_b)`. ### Gazdasági értelmezés A metrika kiegészíti a tranzakciószámot: egyetlen Bitcoin-tranzakció akár sok inputot is fogyaszthat, és ez a szám az ilyen eseteket érzékenyen méri. A kutatási felhasználás négy tipikus esete: 1. Értelmezi a `spent_value`, CDD, dormancy és age-threshold metrikák változásait. 2. Segít azonosítani a tárcakonszolidációs epizódokat, amelyek jellemzően sok inputot költenek el egyszerre. 3. Nevezőül szolgálhat származtatott mutatókhoz, például az „átlagos elköltött érték outputonként” mérőszámhoz. 4. Lehetővé teszi az UTXO-áramlás és az input-oldali aktivitás szerkezetének vizsgálatát. Fontos, hogy a metrika **nem** jelent felhasználószámot, entitásszámot, fizetésszámot vagy gazdaságilag korrigált tranzakciószámot – kizárólag nyers UTXO-szintű input-számláló. ### Hasonló nyilvános metrikák A szöveg részletesen végigmegy a konkurens adatszolgáltatókon: - **Glassnode** – a `Spent Outputs 1d-1w`, illetve más kor-sávos (`1h-24h`, `3y-5y` stb.) diagramok közel állnak, de sáv-specifikusak, nem összesített nyers darabszám. Teljes rekonstrukció csak akkor lehetséges, ha minden nem-átfedő sáv elérhető és abszolút darabszámot ad. - **CryptoQuant** – a `Spent Output Age Bands` jellemzően érték-súlyozott, nem egyszerű darabszám; a SOPR-család arányszám, nem számosság. - **Coin Metrics** – nincs pontosan egyenértékű, nyilvános, nevükön nevezett metrika; a tranzakció- és transzferérték-sorozatok heurisztikákkal korrigált változatok. - **Blockchair** – kiválóan alkalmas független rekonstrukcióra (bemenet, kimenet, előző output feloldása), de nincs előre csomagolt, egyenértékű napi sor. - **Blockchain.com** – az `Output Value Per Day` diagram az újonnan létrehozott outputok értéke, nem az elköltöttek száma; a tranzakciószám-diagramok szintén nem egyenértékűek. Összességében **egyetlen áttekintett szolgáltató sem publikál egyszerű, nevükön nevezett, napi szintű, az OBM-metrikával közvetlenül egyenértékű sorozatot**. Az OBM egyedisége, hogy a nyers napi számot közvetlenül, entitás-korrekció nélkül, UTC-alapon, coinbase nélkül publikálja, és a számítás teljes csomóponti (full-node) adatból auditálható. ### Algoritmus és implementáció Az exportőr script (`export_obm_spent_output_count_daily.py`) lépései: 1. A felhasználó által megadott `--start_date` és `--end_date` (YYYY-MM-DD, UTC) értelmezése. 2. Az `obm_spent_output_indexer.py` által generált SQLite-adatbázis megnyitása a `--state_db` argumentumon keresztül. 3. Az adatbázis metaadatainak (pl. `indexer_id`, `last_processed_height`, `last_processed_date`, `max_processed_date`) ellenőrzése. 4. Annak verifikálása, hogy a kért záró dátum nem későbbi, mint az indexelő által feldolgozott maximális dátum. 5. A release-verzió kiolvasása az adatbázisból, vagy a `--release_version` fallback használata. 6. Minden egyes UTC naphoz a `daily_aggregates` tábla `spent_output_count` mezőjének kiolvasása; ha nincs sor, a script nullát ír. 7. A sor kiírása a szabványos OBM CSV-sémába: `date, series_id, value, unit, frequency, release_version`. 8. Opcionális PNG-plot készítése a `--plot`/`--plot_output` kapcsolókkal. Az exportőr **nem** kérdezi le a Bitcoin Core-t, nem tart fenn outpoint-állapotot, és nem rekonstruálja az elköltött kimeneteket – ezeket a számításigényes lépéseket az indexelő már elvégezte. A script így csupán egy könnyű, determinisztikus transzformáció az adatbázis → CSV irányba. ### Paraméterek és kimeneti séma A specifikus paraméterek: `--state_db`, `--start_date`, `--end_date`, `--release_version` (fallback), `--output` (CSV útvonal), `--plot`, `--plot_output`. A script **nem fogad** Bitcoin Core RPC paramétereket, `--height_margin`, `--commit_every`, `--min_confirmations` vagy `--reset_state_db` kapcsolókat – ezek az indexelőhöz tartoznak. A kimeneti CSV egy megfigyelés / sor, és a sorok száma megegyezik a kért intervallum naptári napjainak számával. ### Technikai validáció és konzisztencia-ellenőrzések A hét belső ellenőrzés lefedi: a dátumintervallum érvényességét, az SQLite meglétét és csak olvasható módban való megnyitását, az `indexer_id` egyezését, a feldolgozási metaadatok meglétét, a `daily_aggregates` tábla jelenlétét, valamint azt, hogy a záró dátum nem nyúl túl az indexelt tartományon. További keresztellenőrzésként: ha a `SpentValueBTC_d = 0`, akkor `SpentOutputCount_d = 0` is kell, hogy legyen (ugyanabból az adatbázisból, azonos release-verzióval); a tranzakciószámmal összevetve pedig a nem coinbase tranzakciók száma nem haladhatja meg az elköltött kimenetek számát. ### Ismert korlátok A metrika nyers input-oldali számláló, nem entitás-korrigált; tranzakciókat nem tranzakciószinten számol; UTC időbélyeg-konvencióhoz kötött; a tárcakonszolidáció, a batching és a tőzsdei műveletek torzíthatják; nem mér BTC- vagy fiatértéket, díjat vagy coin-kort; függ az indexelő futás helyességétől; az indexelő egyszerű lánc-átszervezési (reorg) politikája anomália esetén leáll, de nem vonja vissza automatikusan az adatbázis-állapotot. ## A.16 – `obm_spent_value_age_band_btc_daily`: napi elköltött érték kor szerinti sávokban ### Definíció és az adatstruktúra jellege Ez a metrika egy **széles, vektor-értékű napi tábla**: minden sor egy UTC naptári nap, és minden kor-sáv oszlop az adott napon elköltött, a sávba eső korú outputok BTC-értékét tartalmazza. Formálisan minden nem coinbase inputra `i`: - `v_i` az elköltött output BTC-értéke - `a_i = max(0, (t_i^spent − t_i^created) / 86400)` az elköltött output kora napokban - `SpentValueBand_{d,k} = Σ_{b ∈ B_d} Σ_{i ∈ I_b} v_i · 𝟙{a_i ∈ k}` Az alkalmazott kor-sávok: `0d–1d, 1d–1w, 1w–1m, 1m–3m, 3m–6m, 6m–1y, 1y–2y, 2y–3y, 3y–5y, 5y–7y, 7y–10y, 10y+`. A sávok egymás után következnek, az utolsó nyílt végű. A sávok összege visszaadja a teljes elköltött értéket: `SpentValueBTC_d = Σ_k SpentValueBand_{d,k}` ### Gazdasági értelmezés A tábla azt írja le, hogyan oszlik meg a napi elköltött érték a frissen keletkezett, közepes és hosszabb ideig inaktív outputok között. Öt tipikus felhasználás: 1. A teljes elköltött érték kor szerinti dekompozíciója – részletesebb, mint egy skalár sorozat. 2. A fiatal-output forgalom és az alvó készlet aktiválódásának szétválasztása. 3. Annak vizsgálata, hogy a forgalmi kiugrásokat rövid UTXO-churn, tárcakonszolidáció vagy idősebb coinok mozgása okozza-e. 4. A küszöbérték-metrikák validációja (`obm_cdd_155d_btc_daily`, `obm_cdd_365d_btc_daily`). 5. Kor-sáv-arányok számítása, például az egy évnél idősebb outputok részesedése a napi elköltött értékből. A metrika itt sem jelent entitás-korrigált fizetési volument, felhasználói aktivitást vagy gazdaságilag korrigált elszámolási értéket – kizárólag nyers, kor-dekomponált elköltött outputok BTC-értéke. ### Hasonló nyilvános metrikák A tábla a `Spent Volume by Age`, `Spent Volume Age Bands`, `Spent Output Age Bands` vagy röviden `SVAB` nevű nyilvános sorozatokkal rokon. A legfontosabb egyenlet a szolgáltatók konvencióinak összehasonlításához: `SpentValueAgeBandBTC_{d,k} = Σ_{i ∈ S_d} v_i · 𝟙{ℓ_k ≤ a_i < u_k}` ahol `k = [ℓ_k, u_k)`. A legtöbb publikus szolgáltató érték-súlyozott sávokat közöl, és csak kevesen adnak teljes, minden sávra kiterjedő, abszolút számszerű táblát. A nyílt rekonstrukció nehézsége, hogy a különböző szolgáltatók eltérő időbélyeg-konvenciót, kor-határt, reorg-kezelést és esetleges entitás-szűrést alkalmaznak – az OBM ezzel szemben a saját, teljes csomóponti feldolgozásából származtatja az értékeket. ## A három metrika közös vonásai A három mutató egyetlen, egységes elven nyugszik: az OBM spent-output indexelő a Bitcoin Core teljes csomópontjából, szekvenciális feldolgozással, SQLite-adatbázisba gyűjti a napi aggregátumokat, és az exportőrök csupán ebből az adatbázisból dolgoznak. Mindhárom metrika: - **UTC blokk-időbélyeget** használ a blokk → naptári nap leképezéshez. - **Coinbase tranzakciókat kizárja** (az A.14-nél a definíció, A.15-nél az inputok halmaza, A.16-nál az input-halmaz értelemszerűen). - **Nyers, entitás-korrigálatlan**, vagyis a change output, az ön-átutalás, a batching és a tárcakonszolidáció mind megjelennek benne. - **Reprodukálható és auditálható** teljes csomóponti adatból, és a számítás determinisztikus. Ezek a tulajdonságok együttesen teszik az OBM-et a kereskedelmi forgalmi mérőszámoktól eltérő, de azokkal összevethető, átlátható alternatívává a Bitcoin lánc UTXO-szintű aktivitásának kutatásához. --- ## 15. rész ## Bevezetés: miről szól ez a rész? Ez a fejezet az *Open Bitcoin Metrics* (Diego R. Llanos, arXiv:2607.03124v1) című tanulmány Appendix A függelékének két, egymáshoz szervesen kapcsolódó metrikáját mutatja be. Az A.16-os és A.17-es számmal jelölt metrikák a bitcoin láncon történt **költségeket (spent output-okat)** mérik: az egyik (A.16) azt részletezi, hogy a költött coin-ok milyen korúak voltak, a másik (A.17) pedig ezek összesített BTC-értékét adja meg napi bontásban. Mindkét metrika ugyanarra a belső, perzisztens indexelő adatbázisra épül, és a szerző hangsúlyozza, hogy a köztük lévő összefüggések belső konzisztencia-ellenőrzésre is használhatók. A szöveg a korábbi függelékbeli metrikákhoz hasonlóan részletes definíciót, gazdasági értelmezést, nyilvános összehasonlítókat, adatforrásokat, algoritmust, paramétereket, kimeneti formátumot, validációt és ismert korlátokat sorol fel. ## A.16 – `obm_spent_value_age_band_btc_daily`: napi költött output érték korosztályok szerint ### Definíció és a mögötte álló gondolat Ez a metrika egy **széles (wide) formátumú napi tábla**, amelyben minden sor egy UTC-naptári naphoz tartozik, és minden oszlop egy-egy rögzített életkori sávnak (age band) felel meg. A tábla nem egyetlen skalár értéket tartalmaz dátumonként, hanem vektort – ez az OBM-séma fontos, tudatos kiterjesztése. Az életkori sávok a következők: `0d–1d`, `1d–1w`, `1w–1m`, `1m–3m`, `3m–6m`, `6m–1y`, `1y–2y`, `2y–3y`, `3y–5y`, `5y–7y`, `7y–10y`, valamint `10y+` – vagyis a szerző nagyon finom felbontást alkalmaz a frissen mozgatott coin-okra, és egyre ritkább, hosszabb távú sávokkal dolgozik a régebbi UTXO-k esetében. A mérőszám nyers (raw) és kifejezetten a költött output-okra épül: nem azonosít entitásokat, tőzsdéket, letétkezelőket, saját átutalásokat, váltó (change) output-okat vagy fizetési célokat. Mértékegysége BTC, nem BTC-days. A legközelebbi nyilvános megfelelője a Glassnode "Spent Volume by Age" diagramja, de a szerző külön kiemeli, hogy a pontos egyenértékűséget nem szabad feltételezni, mert a korlátok, az időbélyeg-konvenciók, az entitás-korrekció, a simítás, a tranzakciószegély-kezelés és a chain-reorg-szabályok providerenként eltérhetnek. ### Gazdasági értelmezés és belső összefüggések A tábla gazdaságilag azt mutatja meg, hogy a napi szinten láncon elköltött BTC mekkora hányada származott frissen mozgatott, illetve hosszabb ideig pihent coinokból. Ez a fajta kor szerinti dekompozíció az on-chain elemzés egyik legelterjedtebb eszköze: segíti a hosszú távú birtokosok (LTH-k) és rövid távú birtokosok (STH-k) aktivitásának szétválasztását, a piaci stresszhelyzetek felismerését, valamint a dormancy és a spent-output-érték együttes vizsgálatát. A szerző kiemeli, hogy a sorok összege visszaadja a napi teljes költött output-értéket: $$\sum_{k} \mathrm{SpentValueBand}_{d,k} = \mathrm{SpentValueBTC}_{d}$$ Ez az azonosság belső konzisztencia-ellenőrzésként is használható, amennyiben mindkét aggregátum ugyanabból az indexelő futtatásból származik. Hasonlóképp, a küszöböket alkalmazó OBM-sorozatok (pl. `obm_spent_value_lt155d_btc_daily`, `obm_spent_value_ge155d_btc_daily`, `obm_spent_value_ge365d_btc_daily`) konzisztensnek kell lenniük a megfelelő korosztályok összegével – feltéve, hogy a küszöb és a sávok határai pontosan fedik egymást. ### Hasonló nyilvános metrikák A szerző több szolgáltató hasonló megoldásait is megvizsgálja. A Glassnode `Spent Volume by Age` (breakdowns.SpentVolumeSumByAge) a teljes költött volument kor szerint bontja – fogalmilag nagyon közel áll, de a pontos egyezés nem garantált. A Glassnode SVAB (Spent Volume Age Bands) és SOAB (Spent Output Age Bands) családja százalékos eloszlásként jelenik meg, nem abszolút BTC-értékként, ezért inkább kiegészítő, mint helyettesítő mutató. Az entity-adjusted SVAB-változat továbbá entitás-szintű szűrést alkalmaz, amivel OBM szándékosan nem él. A CryptoQuant "Spent Output Age Bands" metrikája az egyik legközelebbi formula-szintű analóg, de a pontos sáv-határok, értéke-gységek és reorganizáció-kezelés publikus dokumentációjából nem rekonstruálható. A Checkonchain "Spent Volume Age Bands" eszköze abszolút és relatív formában is elérhető, de szintén nem teljesen reprodukálható. A Glassnode "Spent Volume by Date Bands" metrikája a dátum szerinti (abszolút létrehozási idő) csoportosítást alkalmazza, ami más kérdésre válaszol, mint az életkor szerinti. A Coin Metrics nem publikál ezzel közvetlenül egyenértékű széles táblát, bár TxTfrValNtv és TxTfrValDayDst kapcsolódó, de nem azonos fogalmak. A Blockchair alacsonyabb szintű (block-, tranzakció-, input-, output-szintű) nyers adatként kiválóan alkalmas reprodukcióra, de nem szolgáltat előre elkészített, napi wide táblát. Fontos, hogy a HODL Waves és a UTXO Age Bands **stock**-mutatók (a még el nem költött készlet koreloszlását írják le), nem pedig a költött érték koreloszlását – tehát ezek nem közvetlen helyettesítői az OBM táblának. ### Adatforrás és belső számítás Az exportőr nem futtat önálló láncolvasást: a `obm_spent_output_indexer.py` által épített perzisztens SQLite adatbázis `daily_age_band_aggregates` táblájából dolgozik. A tábla mezői: `date`, `age_band`, `spent_value_sats`. Az indexelő minden nem-coinbase tranzakció inputra feloldja az előző outputot, lekéri annak értékét és létrehozási időbélyegét, kiszámolja az eltelt napok számát, hozzárendeli a coin-t a megfelelő sávhoz, és a napi korosztály-aggregátumhoz adja az értékét. A belső képlet: $$\mathrm{spent\_value\_sats}_{d,k} = \sum_{b \in B_d} \sum_{i \in I_b} v_i^{\mathrm{sats}} \cdot \mathbf{1}\{a_i \in k\}$$ Az exportőr ezt a satoshi-aggregátumot váltja át BTC-re a `100 000 000` való osztással. Ha egy adott dátum–sáv párhoz nem tartozik rekord, a cella értéke nulla, ami helyes flow-változó esetén: nincs költés, nincs érték. ### Az exportőr algoritmusa lépésről lépésre A `export_obm_spent_value_age_band_btc_daily.py` script egy determinisztikus, könnyűsúlyú transzformáció: 1. A felhasználó által megadott dátumintervallumot (`--start_date`, `--end_date`) `YYYY-MM-DD` formátumban értelmezi, UTC-s naptári dátumként, mindkét végpontot beleértve. 2. Megnyitja a `--state_db` útvonalon megadott SQLite adatbázist. 3. Ellenőrzi, hogy az adatbázis valóban az OBM spent-output indexeré: az `indexer_id`, valamint a feldolgozási metaadatok (`last_processed_height`, `last_processed_date`, `max_processed_date`) megléte alapján. 4. Ellenőrzi, hogy a `daily_age_band_aggregates` tábla létezik és tartalmazza a kötelező mezőket (`date`, `age_band`, `spent_value_sats`). 5. Ellenőrzi, hogy a kért záró dátum nem nyúlik túl az indexer által feldolgozott maximális dátumon – egyébként megszakítja a futást. 6. A release-verziót az adatbázis metaadatából veszi, vagy a `--release_version` fallback értéket használja. 7. Minden kért dátumra létrehoz egy teljes sort, ahol minden korosztály oszlop értéke kezdetben nulla. 8. Lekéri a `daily_age_band_aggregates` táblából az összes dátum–sáv rekordot az intervallumban. 9. Minden lekért sornál ellenőrzi, hogy az `age_band` a várt címkék halmazába tartozik – ellenkező esetben leáll. 10. Ellenőrzi, hogy az érték nem negatív, és nincs duplikátum ugyanarra a dátum–sáv párra. 11. Átváltja az értéket satoshiból BTC-re. 12. Az eredményt CSV-fájlba írja; minden sor egy UTC-dátum, minden oszlop egy korosztály. 13. Opcionálisan ellenőrzi a sorok összegét a `--validate_row_sums` kapcsolóval, összevetve a sávok összegét a `daily_aggregates.spent_value_sats` BTC-re váltott értékével a `--row_sum_tolerance` (alapértelmezetten 0,00000001 BTC) tűrésen belül. 14. Opcionálisan halmozott területdiagramot készít a `--plot` kapcsolóval (a kimeneti útvonalat a `--plot_output` adja meg, vagy a CSV-vel azonos néven `.png` kiterjesztéssel). Az exportőr nem kérdez le Bitcoin Core-t, nem tart fenn outpoint-állapotot, nem rekonstruálja a költéseket – ezeket a számításigényes lépéseket az indexelő már elvégezte. ### Specifikus paraméterek és kimeneti séma Az exportőr paraméterei a következők: `--state_db` (kötelező), `--start_date`, `--end_date`, `--release_version` (fallback), `--output` (CSV útvonal), `--validate_row_sums`, `--row_sum_tolerance`, `--plot`, `--plot_output`. A szerző kiemeli, hogy az exportőr **nem fogad** Bitcoin Core RPC paramétereket, `--height_margin`, `--min_confirmations`, `--commit_every` vagy `--reset_state_db` kapcsolókat – ezek az indexelőhöz tartoznak. A kimeneti séma eltér a szokásos skalár OBM-sémától, mert több numerikus oszlopot tartalmaz dátumonként. A fix oszlopok: `date`, `series_id` (`obm_spent_value_age_band_btc_daily`), `unit` (`BTC`), `frequency` (`daily`), `release_version` (pl. `OBM v0.1.0`), valamint a 12 korosztály-oszlop: `spent_value_0d_1d_btc`, `spent_value_1d_1w_btc`, `spent_value_1w_1m_btc`, `spent_value_1m_3m_btc`, `spent_value_3m_6m_btc`, `spent_value_6m_1y_btc`, `spent_value_1y_2y_btc`, `spent_value_2y_3y_btc`, `spent_value_3y_5y_btc`, `spent_value_5y_7y_btc`, `spent_value_7y_10y_btc`, `spent_value_10y_plus_btc`. Minden numerikus érték 8 tizedesjegy pontossággal, BTC-ben. ### Aggregációs szabály és technikai validáció Az aggregáció definíciója: $$\mathrm{SpentValueBand}_{d,k} = \sum_{b \in B_d} \sum_{i \in I_b} v_i \cdot \mathbf{1}\{a_i \in k\}$$ A sorok összege visszaadja a napi teljes költött output-értéket. Havi aggregáció esetén az életkori sávok napról napra összegezhetők: $$\mathrm{SpentValueBand}_{m,k} = \sum_{d \in m} \mathrm{SpentValueBand}_{d,k}$$ A technikai validáció kilenc lépésből áll: dátumintervallum érvényessége, SQLite megléte és csak olvasható módban való megnyitása, az `indexer_id` ellenőrzése, a feldolgozási metaadatok megléte, a tábla és mezői megléte, a záró dátum nem haladja meg az indexer által feldolgozott maximumot, minden dátumra inicializált nulla sorok, az `age_band` címkék halmazának ellenőrzése, a nem-negatív értékek és a duplikátum-mentesség, valamint a satoshi-BTC konverzió. ### Ismert korlátok A szerző nyolc fontos korlátot sorol fel: (1) a tábla nyers, entitás-korrigálatlan, (2) a blokk-időbélyeg konvenciójától függ, (3) a sávok határai fixek, ezért kicsi határ-esetekben egy-egy output átkerülhet egy másik oszlopba, (4) a tábla vektor-értékű, nem skalár, ezért a szokásos OBM szoftverek külön kezelést igényelnek, (5) a self-transzfer, konszolidáció, batching, tőzsdei műveletek és letétkezelői átrendezések torzíthatnak, (6) BTC-ben van, nem fiat-ban, (7) az indexelő adatbázisának helyességére és teljességére épül, (8) az indexer egyszerű reorganizációs szabálya inkonzisztencia esetén leáll, de nem rollback-eli automatikusan az állapot-adatbázist. ## A.17 – `obm_spent_value_btc_daily`: napi költött output érték BTC-ben ### Definíció és a két metrika viszonya Ez a metrika az A.16-os tábla sorösszegének megfelelő, egyszerű skalár sorozat. Definíciója: $$\mathrm{SpentValueBTC}_d = \sum_{b \in B_d} \sum_{i \in I_b} v_i$$ ahol $B_d$ a napra jutó blokkok halmaza, $I_b$ a $b$ blokk nem-coinbase tranzakció inputjainak halmaza, és $v_i$ a költött előző output értéke BTC-ben. A blokk $b$ a $t_b$ időbélyeg UTC-naptári dátumához van rendelve: $d(b) = \mathrm{UTCDate}(t_b)$. A coinbase inputok kimaradnak, mert a coinbase tranzakciók nem költenek előző outputot. A metrika tehát nyers, UTXO-alapú, gépiesen számított: nem azonosít entitásokat, nem szűri a self-transzfereket, change output-okat vagy gazdaságilag értelmezhető fizetési volument. ### Gazdasági értelmezés A napi költött output érték egy BTC-ben denominált flow-változó, amely megmutatja, hogy a láncon egy adott napon mennyi korábban el nem költött BTC-érték „fordult meg” a tranzakció inputokon. A szerző öt fontos felhasználási módot emel ki: (1) nyers, BTC-denominált aktivitási mérőszám, (2) a dormancy számlálója (Bitcoin Days Destroyed osztva a költött értékkel megadja a költött coin-ok átlagos érték-súlyozott korát), (3) segít megkülönböztetni a tranzakció-számláláson alapuló aktivitást az érték-súlyozott költési aktivitástól, (4) alkalmas az UTXO turnover, konszolidációs epizódok és a hideg tárcák mozgásának vizsgálatára, (5) alapja a korosztályos költési és LTH-mutatóknak. A metrika viszont **nem** tekinthető entitás-korrigált fizetési volumennek, gazdaságilag értelmezhető settlement értéknek vagy tőzsde-korrigált transzfer-volumennek, mert a self-transzfer, batching, tőzsdei és letétkezelői műveletek miatt a nyers érték általában jóval nagyobb, mint a tisztított gazdasági volumen. ### Hasonló nyilvános metrikák A legközelebbi fogalmi analóg ismét a Glassnode "Spent Volume by Age" családja, de ott a fókusz az életkor szerinti bontás, nem az egyszerű napi összesítés; a publikus dokumentáció nem ad UTXO-szintű reprodukciós algoritmust. A Glassnode `transactions.TransfersVolumeSum` a sikeres on-chain transzfereket méri, nem a nyersen fogyasztott UTXO-értéket, ezért fogalmilag rokon, de nem azonos. A CryptoQuant "Spent Output Value Bands" a költött output-ok érték szerinti eloszlása (formula-szerű leírása: $\sum_{o \in \mathrm{spent\ outputs}} \mathrm{value}_o \cdot \mathbf{1}\{a_i \le \mathrm{value}_o < b_i\}$) – ha minden értéksávot összeadnánk, megközelítené az OBM nyers értéket, de a publikus doksi nem tartalmaz teljes rekonstrukciós scriptet. A Coin Metrics `TxTfrValNtv` (Xfer'd Val, natív egység) a natív transzferek összege, míg az `TxTfrValAdjNtv` heurisztikákkal (korai költések kizárása, self-churn csökkentése, cold-wallet shuffle szűrés) szűri a zajt – ezek a transzfer-konstrukciók nem ugyanazok, mint az OBM költött output definíció. A Blockchain.com "Output Value Per Day" diagramja az újonnan létrehozott output-okat összegzi (és a change-et is beleértve), ami nem azonos az OBM költött input értékkel – a kettő mechanikusan összefügg, de a díj, coinbase és határ-időzítési különbségek miatt naponta nem egyenlő. A Blockchain.com "Estimated Transaction Value" change-szűrt, gazdasági transzfer-becslés, tehát szintén nem nyers spent-output. A YCharts a Blockchain.com sorát veszi át, így ugyanaz a korlát érvényes rá. A Newhedge "Bitcoin Transaction Volume" diagramja a napi tranzakciós volument mutatja, de a cikk ezen a ponton megszakad (a 15. rész fájl vége). ### Belső konzisztencia és a két metrika kapcsolata A két metrika szervesen összetartozik: az A.16 sorösszegeinek mindig meg kell egyezniük az A.17 értékével, ha mindkettő ugyanabból az indexer-adatbázisból és release-verzióból készült. Ez az identitás a gyakorlatban a legerősebb belső önellenőrzés. További konzisztenciapont, hogy a küszöböket alkalmazó OBM-sorozatok (pl. `obm_cdd_365d_btc_daily`) értelmezhetők a megfelelő korosztályok összegeként – feltéve, hogy a küszöb és a sávok határai pontosan illeszkednek. ## Miért fontos ez a két metrika együtt? Az A.16 és A.17 együtt egy nagyon hasznos, két-szintű képet ad a lánc napi aktivitásáról. Az A.17 megmutatja, **mennyi** BTC fordult meg naponta, míg az A.16 szétbontja ugyanezt az értéket aszerint, hogy a coin-ok **milyen régóta** pihentek. Ez a kettős nézet a befektetési, makro- és piaci elemzés egyik legértékesebb on-chain eszköze. A szerző hangsúlyozza, hogy OBM megkülönböztető értéke a reprodukálhatóság: full node-ból, nyílt algoritmussal, dokumentált UTC-konvencióval, opcionális sorösszeg-validációval és a többi OBM-sorozattal való natív kompatibilitással. Ezzel szemben a vezető fizetős szolgáltatók (Glassnode, CryptoQuant, Coin Metrics) vagy elzárják a pontos algoritmust, vagy másképp definiálják a fogalmakat (entitás-korrigált, change-szűrt, transzfer-alapú), így közvetlen numerikus összehasonlításra csak gondos konvenció-ellenőrzés után alkalmasak. ### Összegzés Ez a rész két, technikailag igényes, de gazdaságilag jól értelmezhető metrikát mutat be. Az A.16-os `obm_spent_value_age_band_btc_daily` egy széles, 12 korosztályra bontott napi tábla, amelyhez a szerző részletes indexelő és exportáló leírást, paraméterlistát, kimeneti sémát, validációs lépéseket és nyolc ismert korlátot ad. Az A.17-es `obm_spent_value_btc_daily` ennek a vektornak a skalár sorösszege, amely önmagában is hasznos nyers aktivitási mutató, és egyben a korosztályos bontás belső konzisztenciájának ellenőrző pontja. A két metrika együtt a teljes költött BTC-érték és annak kor szerinti dekompozícióját adja, és az OBM-rendszer többi metrikájával (CDD, dormancy, küszöb-alapú költési mutatók, UTXO-flow) natívan kompatibilis. --- ## 16. rész Ez a rész az arXiv 2607.03124v1 számú, „Open Bitcoin Metrics” című tanulmány tizenhatodik feldolgozott szegmense. A szegmens a függelék (Appendix A) három, egymással szorosan összefüggő metrikáját tárgyalja: az **A.17** `obm_spent_value_btc_daily`, az **A.18** `obm_spent_value_ge155d_btc_daily` és az **A.19** `obm_spent_value_ge365d_btc_daily` mutatókat. Mindhárom napi bontású, BTC-ben denominált, spent-output szintű flow-mutató, amelyek az OBM spent-output indexer adatbázisából (`daily_aggregates` tábla) származnak. A szegmens teljes terjedelmében a szerző (Diego R. Llanos) azonos, korábban már megismert séma szerint jár el: definíció, közgazdasági értelmezés, kapcsolódó nyilvános metrikák, adatforrás és input-követelmények, algoritmus, metrika-specifikus paraméterek, aggregációs szabály, kimeneti formátum, technikai validáció, valamint ismert korlátok. ## 1. Közös kiindulópont: a spent-output indexer Mielőtt a három metrika részleteit tárgyaljuk, érdemes rögzíteni a közös technikai alapot. Az OBM rendszer a Bitcoin Core full node-ból egy külön indexert (`obm_spent_output_indexer.py`) futtat, amely szekvenciálisan végigmegy a blokkláncon, és minden egyes nem coinbase tranzakció-bemenethez (`input`) feloldja, hogy az melyik korábbi outputot költi el, onnan kiolvassa a korábbi output értékét (satoshi-ban és/vagy BTC-ben), valamint a létrehozás időbélyegét, és ezeket az értékeket napi bontású aggregátumokká alakítva eltárolja egy SQLite adatbázisban. Az indexer a tranzakció-szintű rekonstrukciót egyszer végzi el; az exportáló szkriptek csupán a már kész, perzisztens aggregátumokat olvassák ki és konvertálják át a szabványos OBM CSV-formátumba. Ez a szétválasztás azért fontos, mert a nehéz, számításigényes lépések (előző outputok feloldása, életkor-számítás) az indexerben zajlanak, az exportálás pedig determinisztikus és könnyűsúlyú transzformáció. A blokkokat az indexer a blokk-időbélyeg (`block.timestamp`) UTC naptári napjához rendeli, és ezt a konvenciót öröklik az exportált sorok is. A metrikák tehát „flow” jellegűek: ha egy adott UTC napra nincs aggregátum-rekord, a rendszer nullát ír ki — ez a konvenció helyes, hiszen a hiányzó rekord azt jelenti, hogy az adott napon nem történt a kritériumoknak megfelelő költés. ## 2. A.17 — `obm_spent_value_btc_daily`: a teljes elköltött output-érték napi szinten, BTC-ben ### 2.1 Definíció és képlet Az A.17 metrika a legegyszerűbb a három közül: az adott UTC napon a blokkokban talált minden nem coinbase tranzakció-bemenethez tartozó, elfogyasztott korábbi output BTC-értékének az összege. Formálisan: `SpentValueBTC_d = Σ_{b ∈ B_d} Σ_{i ∈ I_b} v_i` ahol `B_d` a `d` UTC naphoz rendelt blokkok halmaza, `I_b` a `b` blokk nem coinbase tranzakció-bemeneteinek halmaza, és `v_i` az `i` bemenet által hivatkozott korábbi output BTC-értéke. Belső tárolásban az érték satoshiban van (`spent_value_sats` mező a `daily_aggregates` táblában), és a metrika BTC-vé konvertálása az exportáláskor történik, 100 000 000-rel való osztással. ### 2.2 Közgazdasági értelmezés és korlátok A metrika az on-chain értékmozgás nyers, entitás-igazítás nélküli mérőszáma. Nem azonosít felhasználókat, entitásokat, tőzsdéket, sem önátutalásokat, és nem szűri ki a change outputokat sem. Következésképpen a napi értékeket felfújhatják a tárcakonszolidációk, a batch-tranzakciók, a tőzsdei belső mozgások és a self-transzferek. A metrika nem USD- vagy fiat-denominált, tehát az áringadozás nem befolyásolja. A sorozat egyik legfontosabb felhasználása, hogy fundamentuma más OBM metrikáknak: a dormancy, a CDD és a korcsoportos spent-value mutatók mind erre a bázisra épülnek. ### 2.3 Hasonló nyilvános metrikák A szerző szisztematikusan végigmegy a főbb on-chain adatszolgáltatókon: - **Glassnode**: a `Spent Volume` család a legközelebbi analóg, de a Glassnode dokumentációja nem teljesen nyilvános, és a metrika alapja lehet input-, output- vagy transfer-érték is. - **CryptoQuant**: a `Spent Output Value Bands` hasonló koncepciójú, de sávokban (age band), nem pedig egyetlen küszöbértékkel dolgozik. - **Coin Metrics**: a `TxTfrValNtv` és `TxTfrValAdjNtv` transfer-értékek, amelyek konvencióikban eltérnek a nyers spent-output összegtől. - **Blockchain.com**, **YCharts**, **Newhedge**, **BitInfoCharts**: output-volume és „sent coins” típusú indikátorokat kínálnak, de reprodukálható algoritmust nem közölnek, és általában regisztrációhoz kötik a teljes adathozzáférést. - **Blockchair**: output-szintű explorer-adatokat ad, amelyekből elvileg rekonstruálható lenne a metrika, de nem publikál az OBM definíciójának pontosan megfelelő napi sorozatot. Az OBM egyedisége, hogy a definíciót a spent-output szintjén rögzíti, nyersen (entitás-korrekció nélkül) tartja, BTC-ben jelenti, a blokkokat UTC naptári napokhoz rendeli, és a teljes rekonstrukció visszavezethető full-node adatokra. ### 2.4 Algoritmus és kimeneti séma Az `export_obm_spent_value_btc_daily.py` kilenc lépésben dolgozik: (1) a felhasználó által megadott `--start_date` és `--end_date` UTC dátumokat értelmezi (inkluzív); (2) megnyitja a `--state_db` útvonalon megadott SQLite adatbázist; (3) ellenőrzi, hogy az adatbázis metaadatai (`indexer_id`, `last_processed_height`, `last_processed_date`, `max_processed_date`) valóban az OBM spent-output indexerhez tartoznak; (4) megvizsgálja, hogy a kért záró dátum nem későbbi-e az indexer által feldolgozott utolsó dátumnál, és ha igen, megszakítja a futást; (5) a release verziót az indexer metaadatából olvassa, vagy a `--release_version` fallback értéket használja; (6) minden dátumra lekéri a `spent_value_sats` mezőt, vagy nullát ír, ha nincs rekord; (7) a satoshit BTC-vé konvertálja; (8) kiírja a szabványos OBM CSV-sémát; (9) opcionálisan PNG-plotot generál. A szkript explicit nem fogad Bitcoin Core RPC paramétereket, `--height_margin`, `--commit_every`, `--min_confirmations` vagy `--reset_state_db` kapcsolókat — ezek az indexerhez tartoznak. ### 2.5 Technikai validáció és konzisztencia-ellenőrzések Az exportáló szkript többrétegű belső ellenőrzést végez: a dátumintervallum érvényessége, az adatbázis megléte és read-only módban való megnyitása, az `indexer_id` egyezése, a feldolgozási metaadatok megléte, a `daily_aggregates` tábla jelenléte, valamint a kért záró dátum és az indexer által feldolgozott maximum dátum közötti inkonzisztencia-kezelés. A kiírt sorok számának meg kell egyeznie a naptári napok számával, és minden érték nem-negatív kell legyen. Fontos belső konzisztencia-azonosság: ha ugyanabból az indexer-kiadásból származik a `obm_dormancy_days_daily`, a `obm_cdd_btcxdays_daily` és a `obm_spent_value_btc_daily`, akkor teljesülnie kell a `Dormancy_d = CDD_d / SpentValueBTC_d` összefüggésnek minden pozitív spent-value-val rendelkező napra. Külső sorozatokkal való összevetés csak diagnosztikai célú, nem szigorú egyenlőségi teszt, mert a szolgáltatók timestamp-konvencióban, change-kezelésben, entitás-korrekcióban és él-edge-esetek kezelésében eltérhetnek. ## 3. A.18 — `obm_spent_value_ge155d_btc_daily`: 155 napnál idősebb outputok elköltött értéke ### 3.1 Definíció és a 155 napos küszöb jelentősége Az A.18 metrika az A.17-re épül, de kiegészíti azt egy életkor-küszöb feltétellel. Minden egyes elfogyasztott outputra kiszámítja az életkort napokban: `a_i = max(0, (t_i^spent − t_i^created) / 86400)` ahol `t_i^created` a korábbi outputot létrehozó blokk időbélyege, `t_i^spent` pedig az azt elköltő blokk időbélyege. A napi aggregátum ezután: `CDD155BTC_d = Σ_{b ∈ B_d} Σ_{i ∈ I_b} v_i · 1{a_i ≥ 155}` vagyis csak azok a költések számítanak bele, ahol az output legalább 155 napig inaktív volt. A belső tárolás a `spent_value_155d_sats` mezőben satoshiban történik; az exportálás 100 000 000-rel való osztással állítja elő a BTC-s értéket. Bár az azonosító a „CDD” (Coin Days Destroyed) családra utal, fontos hangsúlyozni, hogy **az egység BTC, nem BTC-nap**: a metrika nem szorozza az értéket az életkorral, csupán egy bináris küszöböt alkalmaz, és utána egyszerűen összegzi a BTC-értékeket. ### 3.2 A 155 napos küszöb eredete és közgazdasági értelmezése A 155 nap az iparági standard long-term holder (LTH) küszöbértéke. Az OBM ezt a küszöböt „kemény” formában, a spent-output szintjén alkalmazza: a 155 napnál fiatalabb coinok nulla járulékot adnak, az annál idősebbek teljes BTC-értékükkel számítanak. A metrika a nyers, entitás-korrekció nélküli long-term holder aktivitás proxyja. Önmagában és más sorozatokkal egyaránt használható: - azonosítja azokat a napokat, amikor viszonylag idős coinok mozognak; - szétválasztja a hosszabb ideig tartott kínálat mozgását a frissen forgó coinokétól; - kiegészíti a nyers CDD-t, mert míg a CDD súlyozza a coinok életkorát, addig ez a met rögzített életkor-küszöböt alkalmaz, és csak összegzi a BTC-értéket; - hányadosok alapja lehet (pl. 155+ napos költés aránya a teljes költéshez). A 155 napos küszöb nem véletlen: a Coin Days Destroyed koncepció és a HODL-wave elemzések egyaránt ezt a választóvonalat használják. A Glassnode LTH/STH definíciója ezt a határt egy logisztikus függvénnyel, 10 napos átmeneti sávval lágyítja — ez fontos eltérés, amelyet a szerző kiemel. ### 3.3 Kapcsolat a 365 napos küszöbbel Mivel minden 365 napos vagy annál idősebb output egyben 155 napos vagy annál idősebb is, fennáll az alábbi halmaz-reláció: `0 ≤ CDD365BTC_d ≤ CDD155BTC_d ≤ SpentValueBTC_d` A két küszöb-sorozat különbsége (`CDD155BTC_d − CDD365BTC_d`) izolálja a közepesen öreg (≥ 155 nap, de < 365 nap) coinok elköltött értékét — ez egyfajta „medium-old” komponens az OBM küszöb-konvenciók mellett. ### 3.4 Hasonló nyilvános metrikák - **Glassnode Spent Volume by LTH/STH**: a legközelebbi koncepcionális analóg, de entity-alapú és logisztikus átmenetet alkalmaz 155 nap körül, nem pedig kemény UTXO-szintű küszöböt. Tehát „useful public comparator”, de nem közvetlen replikáció. - **Glassnode Spent Volume by Age**: életkor-sávokra bontott spent volume; a 155 nap feletti sávok összegzésével közelíthető, de a sáv-határok, simítás, reorg-konvenciók és entitás-korrekció eltérhetnek. - **CryptoQuant Spent Output Age Bands**: tartalmilag nagyon hasonló, de sávokban prezentálja az adatot; a 155 nap feletti sávok összege közelítésként szolgálhat. - **CryptoQuant Long Term Holder SOPR** és a Glassnode long-term holder profit/sorozatok: a 155 napos küszöböt használják, de nyereségességi arányt (SOPR) vagy készlet-állományt (LTH Supply) mérnek, nem napi spent-value flow-t, ezért közvetlen összehasonlításra nem alkalmasak. - **Bitcoin Magazine Pro Long-Term Holder Supply**: 155 napos küszöböt alkalmaz, de készlet-metrika, nem flow. - **Blockchair**: rekonstrukciós forrásként használható, de nem publikál az OBM-mel azonos napi nevesített sorozatot. - **Coin Metrics**: `TxTfrValDayDst` és `TxTfrValNtv` transfer-értékek, amelyek nem izolálják a 155 napos küszöböt. Az OBM egyedisége itt is: a 155 napos küszöböt a spent-output szintjén, kemény vágással alkalmazza, nyersen és entitás-korrekció nélkül jelenti BTC-ben, és teljes mértékben visszavezethető full-node adatokra. ### 3.5 Algoritmus, paraméterek és kimenet Az exportáló szkript az A.17-nél látott séma analógiájára működik: a `daily_aggregates` tábla `spent_value_155d_sats` mezőjét olvassa, vagy nullát ír hiányzó rekord esetén (ami flow-változónál helyes konvenció), a satoshit BTC-vé konvertálja, és a szabványos OBM CSV-sémát írja ki (`date`, `series_id`, `value`, `unit`, `frequency`, `release_version`). Az input paraméterek megegyeznek az A.17-nél megismertekkel (`--state_db`, `--start_date`, `--end_date`, `--release_version`, `--output`, `--plot`, `--plot_output`), és ugyanazok a technikai validációs lépések futnak le (adatbázis metaadatainak ellenőrzése, feldolgozási határok vizsgálata, sorméret-konzisztencia, nem-negativitás). ## 4. A.19 — `obm_spent_value_ge365d_btc_daily`: 365 napnál idősebb outputok elköltött értéke ### 4.1 Definíció és a 365 napos küszöb sajátosságai Az A.19 metrika szerkezete az A.18-cal azonos, csupán a küszöbérték 365 nap: `CDD365BTC_d = Σ_{b ∈ B_d} Σ_{i ∈ I_b} v_i · 1{a_i ≥ 365}` A belső tárolás itt a `spent_value_365d_sats` mező, az export BTC-ben szolgáltatja a végeredményt. A 365 napos küszöb az „éves” vagy annál idősebb coinok aktivitását izolálja — ez a legerősebb dormancy-szűrő a három metrika közül, és a hosszú távú, valóban inaktív kínálat mozgásának legjobb nyers proxyja. ### 4.2 A 365 napos küszöb kiegészítő szerepe A 365 napos küszöb a long-term holder definíció „konzervatív” változatának tekinthető: míg a 155 nap a Glassnode-iparági standard LTH-határ, addig a 365 nap a coinok „évesnél idősebb” kategóriáját jelöli, és a Bitcoin-pénzügyi elemzésben gyakran használják a valóban inaktív készlet azonosítására. A két küszöb együttes alkalmazása — ahogy azt az OBM sorozat megteszi — lehetővé teszi a dormancy-gradiens részletes feltérképezését: a teljes spent value-ből (A.17) kivonva a 155+ napos komponenst (A.18) a rövid távú költést kapjuk; a 155+ és a 365+ különbsége a közepesen öreg, míg maga a 365+ a nagyon öreg coinok aktivitását méri. ### 4.3 Nyilvános megfelelők és az OBM egyedisége A 365 napos küszöbnek is vannak nyilványos analógjai: - a **Glassnode Spent Volume by Age** sávjainak 365 nap feletti összege közelítésként szolgálhat; - a **CryptoQuant Spent Output Age Bands** sávokra bontott prezentációja itt is alkalmazható közelítésre; - a **Blockchair** output-szintű adataiból elvileg rekonstruálható; - különböző „dormant supply” indikátorok (pl. Glassnode `supply.LthSum`) a készletet, nem a flow-t mérik, így közvetlen összehasonlításra nem alkalmasak. Az OBM ismét azzal járul hozzá a közös elemzési keretrendszerhez, hogy a 365 napos küszöböt nevesített, reprodukálható sorozatként publikálja, nyersen, entitás-korrekció nélkül, BTC-ben, UTC naptári napokra bontva, és a rekonstrukció visszavezethető a Bitcoin Core full-node adatokig. ### 4.4 Algoritmus és kimenet Az A.19 exportáló szkriptje (`export_obm_spent_value_ge365d_btc_daily.py`) ugyanazt a kilenc lépéses eljárást követi, mint az A.17 és A.18: dátumintervallum értelmezése, adatbázis-megnyitás read-only módban, `indexer_id` és feldolgozási metaadatok ellenőrzése, a kért záró dátum és a max_processed_date összevetése, release-verzió olvasása vagy fallback alkalmazása, a `spent_value_365d_sats` mező olvasása naponta (nulla helyettesítéssel, ha nincs rekord), satoshi → BTC konverzió, a szabványos OBM CSV-séma kiírása, opcionális plot. Az input paraméterek és a technikai validációs lépések azonosak a korábbi két metrikánál leírtakkal. ## 5. Közös ismert korlátok A szerző mindhárom metrika esetén ugyanazokat a definíció-érzékenységi korlátokat hangsúlyozza: 1. **Entitás-korrekció hiánya**: a sorozatok nyers spent-output aggregátumok, nem azonosítanak felhasználókat, tőzsdéket, őrzőket, önátutalásokat vagy change outputokat. 2. **Időbélyeg-konvenció**: a blokkok UTC naptári naphoz rendelése a block.timestamp alapján történik, ami eltérhet más szolgáltatók konvencióitól. 3. **BTC-denomináció**: a metrikák nem USD- vagy fiat-értéken vannak, így az árszint változása nem befolyásolja őket. 4. **Inflációs hatások**: a wallet-konszolidáció, a batching, a tőzsdei belső mozgások és a self-transzferek felfújhatják a napi értékeket. 5. **Indexer-függőség**: a sorozatok csak akkor exportálhatók, ha a spent-output indexer már lefutott a kért dátumig; az indexer helyes és teljes futása előfeltétel. 6. **Reorg-kezelés**: az indexer egyszerű reorg-politikája detektálja az inkonzisztenciákat és leáll, de nem görgeti vissza automatikusan az állapot-adatbázist. E korlátok ellenére a három metrika a CDD-család és a long-term holder spent-value elemzés magját képezi az OBM-ben: együttesen lehetővé teszik a dormancy, az életkor-sávok és a hosszú távú inaktivitás konzisztens, reprodukálható vizsgálatát. ## 6. Miért fontos ez a három metrika együtt? A 16. rész voltaképpen a CDD-család és a long-term holder spent-value blokkját zárja le az Appendix A-n belül. Az A.17 adja a teljes elköltött érték alapsorát, amelyből az A.18 (155+ nap) és az A.19 (365+ nap) származtatott küszöb-sorozatok kiindulnak. A három együtt koherens hierarchiát alkot: - **A.17**: minden elköltött output értéke, korra való tekintet nélkül. - **A.18**: ebből csak a ≥ 155 napig inaktív coinok értéke. - **A.19**: ebből csak a ≥ 365 napig inaktív coinok értéke. A különbségek (A.17 − A.18, A.18 − A.19) automatikusan megadják a rövid távú és a közepesen öreg aktivitás komponenseit, így a teljes dormancy-gradiens egyetlen, konzisztens forrásból elemezhető. Az OBM ezzel a három nevesített, nyers, BTC-ben denominált, spent-output szintű sorozattal hidat épít a klasszikus CDD-indikátorok (amelyek BTC-napban mérnek és életkor-súlyoznak) és a modern long-term holder flow-metrikák (amelyek jellemzően entity-alapon, lágy küszöbbel dolgoznak) között. Az eredmény egy átlátható, reprodukálható, full-node-ból rekonstruálható, UTC-napra standardizált adatsor-család, amelyet bármely kutató vagy gyakorlati elemző saját maga is előállíthat a közzétett OBM szkriptek és a Bitcoin Core full node segítségével. --- ## 17. rész **Szerző:** Diego R. Llanos **Rész:** 17/20 **Lefedett függelékek:** A.18 (`obm_spent_value_ge155d_btc_daily`), A.19 (`obm_spent_value_ge365d_btc_daily`) --- ## Bevezető: miről szól ez a rész A tizenhetedik rész az OBM (Open Bitcoin Metrics) függelékének két, egymással szoros rokonságban álló, korlátos coin-age (érmekor) küszöbmetrikáját mutatja be: - **A.18** — `obm_spent_value_ge155d_btc_daily`: az adott UTC napon elkölött, legalább **155 napja** inaktív UTXO-k (felhasználatlan tranzakció-kimenetek) teljes BTC-értéke. - **A.19** — `obm_spent_value_ge365d_btc_daily`: ugyanez, de **365 napos** (egyéves) inaktivitási küszöbbal. Mindkét metrika a CDD (Coin Days Destroyed, megsemmisített érmenapok) családba tartozik, de **nem BTC-days mértékegységben** mér, hanem **BTC-ben** — az érmekort csupán bináris küszöbként (≥ 155, illetve ≥ 365 nap) alkalmazza, és a BTC értéket súlyozatlanul összegzi. A két metrika felépítése, export-folyamata, technikai validációja és korlátai szinte szó szerint azonosak — ezért az alábbiakban a közös szerkezetet egyetlen egységként tárgyalom, majd ahol a 155 és 365 napos változat lényegesen eltér (gazdasági interpretáció, korlátok, konzisztenciaellenőrzések), ott külön kiemelem. --- ## Fogalmi háttér és definíció ### Érmekor és korlátos költési érték A Bitcoin blokkláncán minden egyes UTXO életciklusa nyomon követhető: a `t^created` létrehozási időbélyeg és a `t^spent` elköltési időbélyeg között eltelt napok száma az output "kora": ``` a_i = max(0, (t^spent_i − t^created_i) / 86400) ``` Ha az érmét egy láncszerveződés (reorg) miatti technikai anomália következtében a számítás negatív kort adna, a függvény 0-ra vágja le az eredményt. A korlátos költési érték metrikák ezt a kort bináris szűrőként alkalmazzák: ``` CDD155BTC_d = ∑_{b∈B_d} ∑_{i∈I_b} v_i · 𝟏{a_i ≥ 155} CDD365BTC_d = ∑_{b∈B_d} ∑_{i∈I_b} v_i · 𝟏{a_i ≥ 365} ``` Itt `B_d` a `d` UTC naptári naphoz rendelt blokkok halmaza, `I_b` a `b` blokk nemcoinbase tranzakció-inputjainak halmaza, `v_i` az input által elkölött előző output BTC-értéke, az `𝟏{·}` indikátorfüggvény pedig 1, ha a feltétel teljesül, egyébként 0. A blokk hozzárendelése a naptári naphoz kizárólag a blokk `t_b` időbélyegéből képzett UTC dátum alapján történik. A havi változat — amennyiben terjesztik — a napi értékek egyszerű összege: ``` CDD155BTC_m = ∑_{d∈m} CDD155BTC_d CDD365BTC_m = ∑_{d∈m} CDD365BTC_d ``` Ez a konvenció megőrzi a metrika jelentését: a teljes, küszöb fölötti inaktivitás után elköltött BTC-mennyiség az adott időszakban. ### Gazdasági interpretáció A **155 napos** változat a közepesen hosszú inaktivitású érmék mozgását méri — kb. 5 hónapos küszöb. A **365 napos** változat a legalább egy éve mozdulatlan, "régi" érmék áramlását ragadja meg, és a "long-dormant spent value" nyers indikátoraként szolgál. A szerző öt konkrét felhasználási módot emel ki: 1. **Azon napok azonosítása**, amikor hosszabb ideig inaktív coinok mozognak. 2. **Szétválasztás** a régebbi és a frissen forgó coinok aktivitása között. 3. **Kiegészítés** a nyers Bitcoin Days Destroyed metrikához — utóbbi az értéket a korral súlyozza (BTC-days), míg ez a metrika csak egy bináris küszöböt alkalmaz. 4. **Hányadosok** építése: a 155/365 napos küszöb alatti elköltött érték és a teljes elköltött érték hányadosa. 5. **Long-term holder aktivitás**, dormant supply aktiválódás és UTXO-forgalom életkori küszöb alapú vizsgálata. A szerző fontosnak tartja hangsúlyozni, hogy a metrika **nem** jelent klasszikus Bitcoin Days Destroyed értéket (mert az BTC-days lenne), és **nem** azonosítható entitás-korrigált long-term holder eladással, mert nincs benne felhasználó-, entitás-, tőzsde-, custodian-, change-output vagy self-transfer azonosítás. A két metrika kizárólag nyers, output-alapú, korlátos aggregátum. --- ## Hasonló publikus metrikák A 365 napos változathoz a szerző részletes irodalmi áttekintést nyújt: - **Glassnode — Spent Volume by Age**: korszerinti sávokra bontott elköltési volumen, ahol a "1y-2y", "2y-3y" stb. sávok összege közelítené a 365 napos küszöböt. A teljes rekonstrukciós algoritmus nem publikus. - **Glassnode — Spent Output Age Bands (SOAB)**: korsávok százalékos eloszlása, nem abszolút BTC-érték — koncepcionálisan rokon, de nem helyettesíti közvetlenül. - **CryptoQuant — Spent Output Age Bands**: nagyon közeli formula (∑ value_o · 𝟏{a_i ≤ lifespan_o < b_i}), de sávos megjelenítésű, és nincs teljes rekonstrukciós szkript. - **CryptoQuant — Exchange Inflow SOAB**: csak a tőzsdékbe áramló régi coinok — szűkebb, mint az OBM metrika. - **Coin Metrics** — `TxTfrValDayDst` (transferred days destroyed) és `TxTfrValNtv`: nem izolálják a 365 napnál idősebb spent value-t. - **Blockchair**: blokk-, tranzakció- és output-szintű nyers adat; kutató maga rekonstruálhatja, de nincs nevesített napi metrika. - **HODL Waves / UTXO Age Bands** (Glassnode, CryptoQuant): ezek **stock** metrikák (még nem költött supply kor szerinti eloszlása), nem **flow** metrikák — az OBM sorozat ezzel szemben napi flow-t mér. A szerző végkövetkeztetése: egyetlen vizsgált publikus szolgáltató sem tesz közzé pontosan egyenértékű, elnevezett napi 365 napos küszöbmetrikát. Az OBM egyedisége, hogy: - a küszöbértéket explicit módon definiálja (`a_i ≥ 365`), - BTC-ben jelenti, - nyers, entitás-korrigálatlan számítást végez, - UTC naptári napokhoz rendel, - teljes csomóponti (full-node) adatból auditálható. A 155 napos változathoz a szerző nem ad ilyen részletes összehasonlító elemzést — feltételezhetően a Glassnode és CryptoQuant 3m-6m, illetve 6m-12m sávjainak összegzésével közelíthető. --- ## Adatforrás és bemeneti követelmények Mindkét metrika a **perzisztens OBM spent-output indexer** SQLite adatbázisából származik — ez az indexer a 3.4. szakaszban leírt `obm_spent_output_indexer.py` szkript, amely futó Bitcoin Core teljes csomópontra épít és a `daily_aggregates` táblában tárolja az újrafelhasználható napi aggregátumokat. A 155 napos metrika forrásmezője: `spent_value_155d_sats`. A 365 napos metrika forrásmezője: `spent_value_365d_sats`. Az indexer minden egyes nem-coinbase tranzakció-inputra: 1. feloldja az inputot az általa elkölött előző outputra, 2. lekéri az előző output értékét és létrehozási időbélyegét az élő outpoint-állapotból, 3. kiszámítja az életkort napokban, 4. ha a kor ≥ küszöb, hozzáadja az output értékét a megfelelő küszöb-aggregátumhoz. Az export szkript **nem** hív Bitcoin Core-t, **nem** tart fenn outpoint-állapotot, és **nem** rekonstruálja a spent outputokat exportáláskor — a számításigényes feladatokat az indexer már elvégezte. Az exportáló tehát egy könnyű, determinisztikus transzformáció: kiolvassa a satoshi-értékeket a `daily_aggregates` táblából, és a `÷ 100 000 000` osztással BTC-vé alakítja: ``` CDD155BTC_d = spent_value_155d_sats_d / 100 000 000 CDD365BTC_d = spent_value_365d_sats_d / 100 000 000 ``` Az export szkript nem igényel address-extrakciót, user-klaszterezést, entitás-azonosítást, külső árfolyamadatokat, harmadik fél API-ját, és nincs közvetlen Bitcoin Core kapcsolat az export idején. Azonban **függ** az indexer korábbi sikeres futásától, amely viszont szinkronizált, nem-prunált Bitcoin Core teljes csomópontot igényel. A kimeneti sorozat örökli az indexer összes konvencióját: UTC blokk-időbélyeg konvenció, előző-output rekonstrukciós eljárás, törtnapi életkor-konvenció, negatív látszólagos korok kezelése, lánckonzisztencia-ellenőrzések, release metadata, és a történeti duplikált outpoint edge case-ek kezelése. --- ## Algoritmus A két metrika export-szkriptje (`export_obm_spent_value_ge155d_btc_daily.py`, illetve `export_obm_spent_value_ge365d_btc_daily.py`) kilenc lépésben dolgozik: 1. **Dátumintervallum értelmezése** — `--start_date` és `--end_date` paraméterek `YYYY-MM-DD` formátumban, UTC dátumként, mindkét végpont inclusive. 2. **SQLite adatbázis megnyitása** — az indexer által generált perzisztens adatbázis, amelyet a `--state_db` argumentummal ad meg a felhasználó. 3. **Indexer-azonosítás validálása** — a szkript ellenőrzi az `indexer_id`-t, valamint a `last_processed_height`, `last_processed_date`, `max_processed_date` metaadatok meglétét. 4. **Dátumtartomány-ellenőrzés** — a kért `--end_date` nem lehet későbbi, mint az indexer által feldolgozott legutolsó UTC dátum; ellenkező esetben a szkript leáll és az indexer továbbfuttatását kéri. 5. **Release-verzió kikövetkeztetése** — az indexer metaadatából; ha nincs release_version mező, a `--release_version` fallback értéket használja. 6. **Napi értékek kiolvasása** — minden `d` UTC napra a `daily_aggregates` tábla `spent_value_155d_sats` (vagy `spent_value_365d_sats`) mezőjét olvassa; ha nincs sor, 0 értéket ír. 7. **Sat → BTC konverzió** — osztás `100 000 000`-rel. 8. **CSV kiírás** — az egységes OBM séma szerint: `date`, `series_id`, `value`, `unit`, `frequency`, `release_version`. 9. **Opcionális plot** — ha a `--plot` flag aktív, PNG ábra készül a sorozatról; ha `--plot_output` nincs megadva, a CSV mellé kerül ugyanazon alaptővel és `.png` kiterjesztéssel. ### Metrika-specifikus paraméterek - `--state_db`: az OBM spent-output indexer adatbázis elérési útja. - `--start_date`, `--end_date`: az intervallum kezdete és vége UTC dátum. - `--release_version`: fallback release verzió. - `--output`: a kimeneti CSV fájl útvonala. - `--plot`, `--plot_output`: opcionális ábra-generálás. A szkript **nem** fogad el Bitcoin Core RPC paramétereket, `--height_margin`, `--commit_every`, `--min_confirmations` vagy `--reset_state_db` kapcsolókat — ezek az indexerhez tartoznak, nem az exportőrhöz. --- ## Kimeneti formátum A CSV egy megfigyelés sor / UTC dátum struktúrájú. Az oszlopok a 365 napos változatra: | Oszlop | Példa | Leírás | | --------------- | ---------------------------------- | --------------------------------------------------------------- | | `date` | `2024-01-01` | UTC naptári dátum | | `series_id` | `obm_spent_value_ge365d_btc_daily` | Stabil OBM sorozatazonosító | | `value` | `34182.49281735` | A ≥ 365 napos kort elérő költési output-ok BTC-értéke | | `unit` | `BTC` | Mértékegység | | `frequency` | `daily` | Megfigyelés gyakorisága | | `release_version` | `OBM v0.1.0` | Adatkészlet release verzió | A 155 napos változat `series_id`-je `obm_spent_value_ge155d_btc_daily`, az example value `58291.49281735`. --- ## Technikai validáció Hat belső konzisztencia-ellenőrzést alkalmaz a szkript: 1. **Dátumtartomány érvényessége** — `start_date ≤ end_date`. 2. **SQLite adatbázis létezik** — read-only módban nyitja. 3. **Indexer-azonosító egyezés** — az `indexer_id` metaadat megfelelősége. 4. **Field-ek megléte** — `last_processed_height`, `last_processed_date`, `max_processed_date`. 5. **`daily_aggregates` tábla jelenléte**. 6. **`--end_date` ≤ `max_processed_date`**. A hiányzó dátumokra a szkript 0-t ír, nem `NaN`-t vagy üres cellát. Ez azért helyes, mert a metrika **flow** változó: ha egy adott UTC naphoz nem tartozik küszöb-kielégítő költés, a napi érték valóban nulla, nem hiányzó adat. A kiírt sorok számának meg kell egyeznie az intervallumban lévő naptári napok számával, mert a szkript kifejezetten iterál a teljes dátumtartományon. Az exportált értékek nem-negatívak. ### Belső konzisztencia-ellenőrzések A két metrika között, valamint a teljes költési értékkel szemben fontos relációk: - **0 ≤ CDD155BTC_d ≤ SpentValueBTC_d** — a 155 napos küszöbszett részhalmaza a teljes költési értéknek. - **0 ≤ CDD365BTC_d ≤ CDD155BTC_d** — a 365 napos küszöbszett részhalmaza a 155 naposnak, hiszen minden ≥ 365 napos output egyben ≥ 155 napos is. A fenti egyenlőtlenségek csak azonos indexer-adatbázis, időbélyeg-konvenció és release verzió mellett érvényesek. További, fogalmi (nem szigorú egyenlőség) összehasonlítások végezhetők a nyers CDD-vel és a dormancy-vel, de ezek a mértékegység-különbség (BTC-days vs. BTC) miatt nem szigorú azonosságok. Külső benchmarkokkal (long-term holder spent value, old-coin movement, age-threshold metrikák) végzett összehasonlítás hasznos diagnosztikai eszköz, de nem szigorú egyenlőségi teszt — a szolgáltatók eltérhetnek időbélyeg-konvencióban, output-kor küszöbölésben, entitás-korrekcióban, change-output kezelésben, transfer-value definícióban, LTH-küszöb definícióban és történeti edge case-ek kezelésében. --- ## Ismert korlátok A szerző hét explicit korlátot sorol fel: 1. **Nem entitás-korrigált LTH metrika** — nem azonosít felhasználókat, entitásokat, custodianokat, tőzsdéket, self-transzfereket vagy change outputokat. 2. **Időbélyeg-konvenció függőség** — a blokk-időbélyeg konvenció határozza meg az output korát és a költési blokk naptári naphoz rendelését. 3. **Éles (sharp) küszöb** — a 155 vagy 365 napnál éppen kicsit fiatalabb output nem számít, a küszöböt elérő igen. A küszöb tehát nem "smooth" — ez szándékos, de értelmezéskor figyelembe kell venni. 4. **Mértékegység** — BTC, nem BTC-days, noha a CDD-családba tartozik. 5. **Self-transzferek, konszolidáció, batching, tőzsdei műveletek, custodian wallet menedzsment** — mind torzíthatják a metrikát. 6. **Indexer-függőség** — az eredmény csak olyan pontos, mint az indexer futása; a spent-output indexer perzisztens adatbázisának helyessége és teljessége kritikus. 7. **Reorg-kezelés** — az indexer egyszerű reorg-politikája inkonzisztenciát észlel és leáll, de **nem** rollbackeli automatikusan az állapotadatbázist. A szerző e korlátok ellenére a két metrikát hasznosnak tartja a dormant supply, a long-term holder viselkedés, az UTXO turnover és az on-chain aktivitás kutatásában — különösen a nyers CDD, a dormancy, a teljes spent value és a kor-sáv metrikák kiegészítőjeként. --- ## A rész tartalmi ellenőrzése és kitekintés A várakozás szerint a 17. rész az A.20–A.22 metrikákat (`spent_value_lt155d`, `supply`, `tx_count`) fedte volna le. A fájl vizsgálata azt mutatja, hogy **a teljes rész valójában csak az A.18 és A.19 metrikákat tartalmazza** — a `spent_value_ge155d_btc_daily` és a `spent_value_ge365d_btc_daily` definícióját, gazdasági interpretációját, hasonló publikus metrikáit, adatforrását, algoritmusát, kimeneti formátumát, technikai validációját és korlátait. A rész teljesen elhasználja a 4500 szavas terjedelmet erre a két, egymáshoz nagyon hasonló szerkezetű metrikára. A jelenlegi OBM appendices-sorozat (15. részig A.1-A.17, 16. rész: A.17 kibővítése/lezárása, 17. rész: A.18-A.19) és a maradék 3 rész (18. rész, 19. rész, 20. rész) a metrikák teljes listáját figyelembe véve (A.1-A.22, ahol A.22 = `tx_count`) — az A.20 (`spent_value_lt155d`), A.21 (`supply`) és A.22 (`tx_count`) metrikák a hátralévő részekben kaphatnak helyet. --- ### Összegzés A 17. rész két, szinte iker-metrikát mutat be: a Bitcoin blokkláncán legalább 155, illetve 365 napig inaktív UTXO-k napi elköltési értékét BTC-ben. Mindkettő: - nyers, output-alapú, entitás-korrigálatlan flow metrika, - a CDD-családba tartozik, de BTC-ben mér (nem BTC-days), - éles korlátot alkalmaz bináris szűrőként, - az OBM spent-output indexer `daily_aggregates` SQLite táblájából származik, - könnyű, determinisztikus export-szkripttel dolgozik, - az egységes OBM CSV sémát követi, - konzisztencia-ellenőrzések sorával validálható (0 ≤ CDD365 ≤ CDD155 ≤ total spent value). A két metrika a Bitcoin lánc hosszú távú inaktív kínálatának (dormant supply) mozgását méri — a 155 napos közepes, az egyéves hosszú távú inaktivitást reprezentálja — és a nyers CDD-vel, a dormancy-vel, valamint a kor-sáv metrikákkal együtt alkalmas a long-term holder aktivitás, a régi coinok áramlása és az UTXO turnover kutatására. A tranzakciós inputok korának és értékének rekonstrukcióját az indexer végzi, az exportáló pedig csupán a `÷ 100 000 000` BTC-konverziót és a CSV-formázást végzi. --- ## 18. rész ## Bevezetés: miről szól ez a rész? Ez a fejezet az *Open Bitcoin Metrics* (Diego R. Llanos, arXiv:2607.03124v1) című tanulmány Appendix A függelékének két, egymástól módszertanilag eltérő, de az on-chain kínálati oldal szempontjából kulcsfontosságú metrikáját mutatja be. Az A.20-as (`obm_spent_value_lt155d_btc_daily`) és az A.21-es (`obm_supply_btc_daily`) sorszámú metrikák a fiatalság-küszöbös költött értéket, valamint a teljes felhalmozott bitcoin-kínálatot mérik. Az A.20-as metrika **származtatott**: két másik OBM CSV-fájlból, kivonással áll elő. Az A.21-es metrika ezzel szemben **elszámolási (flow) → készlet (stock) átalakítás**: a napi realizált kibocsátás kumulatív összege a 2009-01-01-es kezdőponttól. Mindkét metrika a szerző eddig is alkalmazott, szigorú OBM-sémát követi (`date`, `series_id`, `value`, `unit`, `frequency`, `release_version`), és belső konzisztencia-azonosságokkal is ellenőrizhető. ## A.20 – `obm_spent_value_lt155d_btc_daily`: 155 napnál fiatalabb költött output-ok értéke BTC-ben ### Definíció és az alapgondolat Ez a metrika egy adott UTC-naptári napon a láncon elköltött azon output-ok teljes BTC-értékét méri, amelyek a költés pillanatában **szigorúan kevesebb, mint 155 naposak** voltak. A definíció kiegészíti (pontosabban a komplementere) az A.19-ben tárgyalt ≥ 155 napos küszöbmetrikának. A szerző hangsúlyozza, hogy a korlát éles: egy 154,99 napos output még nem, míg egy 155,00 napos output már beleszámít. Ez a 155 napos határ az iparági konvenció: a Glassnode és a CryptoQuant is ezt alkalmazza a rövid távú birtokos (STH) fogalom definiálásához. A mérőszámot formálisan a következőképp definiálja a szerző. Ha `SpentValueBTC_d` az adott napi teljes költött output-érték, és `SpentValueGE155BTC_d` a ≥ 155 napos költött output-ok értéke, akkor: ``` SpentValueLT155BTC_d = SpentValueBTC_d − SpentValueGE155BTC_d ``` A részteles képlet a blokk- és input-szintű összegzéssel: $$\mathrm{SpentValueLT155BTC}_{d}=\sum_{b\in B_{d}}\sum_{i\in I_{b}}v_{i}\mathbf{1}\{a_{i}<155\}$$ ahol `B_d` a `d` naptári naphoz rendelt blokkok halmaza (a blokk `t_b` időbélyege alapján, UTC-s naptári napra vetítve), `I_b` a `b` blokk nem-coinbase tranzakció-inputjainak halmaza, `v_i` az `i` input által korábban birtokolt output BTC-értéke, és `a_i` annak életkora napokban. Az indikátor dimenziója BTC, nem BTC-days. ### Gazdasági értelmezés A metrika a **fiatal coin-ok** forgalmát méri. Négy fontos felhasználási területet emel ki a szerző: 1. **Dekompozíció**: a teljes költött értéket fiatal és idős komponensre bontja, ami megmutatja, hogy az adott napon a forgalmat a rövid távú kereskedők vagy a hosszú távú birtokosok mozgása dominálja-e. 2. **Fiatal/régi arányok**: a `SpentValueLT155BTC_d` és a `SpentValueGE155BTC_d` hányadosa, illetve hányadosa az összforgalomhoz képest jól használható piaci stressz-indikátorként. 3. **Rövid távú birtokos aktivitás**: bár a metrika nem entitás-korrigált, a 155 napos küszöb a gyakorlatban közel áll az STH-forgalomhoz. 4. **CDD-vel és dormancy-vel való együttes vizsgálat**: segít szétválasztani, hogy a coin-életkor-pusztulás (BTC-days destroyed) mögött fiatal vagy idős coin-ok állnak-e. A szerző ismét hangsúlyozza, hogy a metrika **nem entitás-korrigált**: nem azonosít felhasználókat, tőzsdéket, letétkezelőket, change output-okat, batch-tranzakciókat vagy saját átutalásokat. Ezek a hatások torzíthatják a mérőszámot – egy nagy tőzsdei cold wallet-átrendezés például hirtelen nagy fiatal-költést generálhat anélkül, hogy valódi eladási nyomás lenne. ### Hasonló nyilvános metrikák A szerző ismét nagyon részletesen végigmegy a lehetséges összehasonlítókon: - **Glassnode `Spent Volume by LTH/STH`** (breakdowns.SpentVolumeSumByLthSth): a legközelebbi fogalmi analóg. A Glassnode maga is dokumentálja a 155 napos konvenciót, de a módszertan entitás-orientált, és a küszöb körül valószínűségi vagy simított átmenetet alkalmaz. Az OBM ezzel szemben éles, output-szintű, nem-entity-adjusted küszöböt alkalmaz. - **Glassnode `Spent Volume by Age`** (breakdowns.SpentVolumeSumByAge): korcsoportos lebontás, a 155 nap alatti sávok összege közelítheti az OBM-metrikát, de a pontos egyenértékűség a sávhatárok és az egységek eltérései miatt nem garantált. - **Glassnode SVAB (Spent Volume Age Bands)**: százalékos formátumban van megadva, nem abszolút BTC-értékben, ezért kevésbé alkalmas közvetlen összehasonlításra. Az entity-adjusted változat kiszűri az azonos entitáshoz tartozó tranzakciókat, míg az OBM szándékosan megtartja azokat. - **CryptoQuant `Spent Output Age Bands`**: az OBM-hez legközelebbi formula-szintű megfelelő, de a sávok publikusak, a pontos 155 napos határ szerinti aggregátum nem, és a teljes rekonstrukciós script sem érhető el. - **CryptoQuant `STH-SOPR`**: a 155 napos küszöböt használja, de nyereségességi arány (USD-value-at-spend / USD-value-at-create), nem költött érték – így csak kapcsolódó, nem közvetlen összehasonlító. - **Coin Metrics**: nem publikál ezzel egyenértékű nevű napi sorozatot. A `TxTfrValNtv` és a `TxTfrValDayDst` rokon, de nem küszöbölt metrikák. - **Blockchair**: kiváló alacsony szintű forrás (block-, tranzakció-, input-, output-szintű adatok), de nem publikál előre elkészített 155 napos küszöbmetrikát. A szerző konklúziója: egyetlen áttekintett provider sem szolgáltat pontosan egyenértékű, elnevezett napi sorozatot. Az OBM egyedi értéke, hogy a 155 napos küszöböt **explicit, output-szintű, BTC-denominált, auditálható, teljes-csomópontból rekonstruálható** módon teszi elérhetővé. ### Adatforrás és bemeneti követelmények Az A.20-as metrika **származtatott**: két már elkészült OBM CSV-ből indul ki: 1. `obm_spent_value_btc_daily` – teljes napi költött output-érték BTC-ben. 2. `obm_spent_value_ge155d_btc_daily` – ≥ 155 napos költött output-ok értéke BTC-ben. Mindkét fájlnak tartalmaznia kell a kötelező OBM-séma mezőit, a `series_id`, a `unit` és a `frequency` értékeinek pedig konzisztensnek kell lenniük. A kiválasztott dátumintervallumban mindkét forrásnak teljesnek kell lennie (nincs hiányzó dátum), és a `release_version` mezőben is egyezniük kell. A metrika nem igényel Bitcoin Core RPC-t, SQLite-hozzáférést, vagy outpoint-nyilvántartást – a számítás tiszta CSV-szintű transzformáció. ### Algoritmus A `compute_obm_spent_value_lt155d_btc_daily.py` script a következő determinisztikus lépéseket hajtja végre: 1. Beolvassa a teljes költött érték CSV-fájlt (1. pozicionális argumentum). 2. Beolvassa a ≥ 155 napos költött érték CSV-fájlt (2. pozicionális argumentum). 3. Ellenőrzi, hogy mindkét fájl létezik, nem üres, és tartalmazza a kötelező oszlopokat. 4. A dátumokat `YYYY-MM-DD` formátumban, UTC-ként értelmezi. 5. Az értékeket decimális számokként parse-olja; a hiányzó, érvénytelen vagy negatív értékek leállítják a scriptet. 6. Ellenőrzi, hogy egyik fájlban sincs duplikált dátum. 7. Ellenőrzi, hogy az 1. fájl `series_id` értéke `obm_spent_value_btc_daily`, `unit` = BTC, `frequency` = daily. 8. Ellenőrzi, hogy a 2. fájl `series_id` értéke `obm_spent_value_ge155d_btc_daily`, `unit` = BTC, `frequency` = daily. 9. A dátumintervallumot vagy a felhasználó adja meg (`--start_date`, `--end_date`), vagy a két fájl közös dátumtartományából inferálja. 10. Ellenőrzi, hogy mindkét forrás teljes a kiválasztott intervallumban. 11. Ellenőrzi, hogy a két fájl közös `release_version`-t használ az intervallumban. 12. Minden `d` dátumra kiszámítja a különbséget: `SpentValueLT155BTC_d = SpentValueBTC_d − SpentValueGE155BTC_d`. 13. Ha az eredmény kis negatív (abszolút érték ≤ `--negative_tolerance`, alapértelmezetten 1e-8 BTC), nullára kerekíti – ez a lebegőpontos kerekítés kezelésére szolgál. 14. Ha az eredmény ennél nagyobb negatív, a script leáll, mert ez inkonzisztens forrásfájlokra utal. 15. Az eredményt a standard OBM-sémával írja ki (CSV). 16. Opcionálisan `--plot` flaggel ábrát is készít. ### Paraméterek és aggregáció A script specifikus paraméterei: - `spent_value_csv` – az 1. forrásfájl útvonala. - `spent_value_ge155d_csv` – a 2. forrásfájl útvonala. - `--start_date`, `--end_date` – az intervallum opcionális határai. - `--output` – a kimeneti CSV útvonala (alapértelmezetten `obm_spent_value_lt155d_btc_daily.csv`). - `--plot`, `--plot_output` – opcionális ábra-generálás. - `--negative_tolerance` – alapértelmezetten `0.00000001` BTC. A script **nem fogadja** a Bitcoin Core RPC paramétereket, a `--state_db`, `--height_margin`, `--min_confirmations`, `--commit_every` vagy `--reset_state_db` kapcsolókat – ezek csak az indexer-alapú exportőrökre jellemzők. A havi aggregáció szabálya: a havi érték a napi értékek összege, vagy egyenértékűen a havi ≥ 155 napos és a havi teljes költött érték különbsége. Ez megőrzi a metrika flow-jellegét. ### Kimeneti formátum, validáció és korlátok A kimeneti CSV oszlopai: `date` (UTC), `series_id = obm_spent_value_lt155d_btc_daily`, `value` (BTC, max. 8 tizedesjegy), `unit = BTC`, `frequency = daily`, `release_version` (a forrásfájlokból örökölt). A belső validáció kilenc lépésből áll: (1) a forrásfájlok megléte és nem-üressége, (2) a kötelező oszlopok megléte, (3) minden érték numerikus és nem-negatív, (4) nincs duplikált dátum, (5) a `series_id`, `unit`, `frequency` mezők konzisztensek, (6) van átfedés a két forrás dátumtartományai között, (7) a `--start_date` ≤ `--end_date`, (8) mindkét forrás teljes a kiválasztott intervallumban, (9) közös `release_version`. Az elsődleges konzisztencia-azonosság: `SpentValueBTC_d = SpentValueLT155BTC_d + SpentValueGE155BTC_d` – ennek minden dátumra teljesülnie kell, ha a források konzisztensek. A hét fő ismert korlát: (1) a metrika származtatott, tehát mindkét forrás helyességétől függ; (2) örökli a források UTC-blokkidő-konvencióját; (3) örökli a 155 napos küszöb definícióját; (4) nyers, nem entitás-korrigált; (5) érzékeny a batch-tranzakciókra, tőzsdei műveletekre, saját átutalásokra; (6) BTC-értékben van, nem fiat-értékben; (7) ha bármelyik forrás definíciója vagy release_version-je megváltozik, a származtatott sorozatot újra kell generálni. ## A.21 – `obm_supply_btc_daily`: Bitcoin-kínálat (kumulatív realizált kibocsátás) ### Definíció és alapgondolat Ez a metrika a bitcoin teljes, halmozottan kibocsátott kínálatát méri egy adott UTC-naptári nap végén, a 2009-01-01-es kezdőponttól a kiválasztott záró dátumig. Formálisan, ha `Issuance_d` a `d` napi realizált kibocsátás BTC-ben (amelyet az A.11-es `obm_issuance_btc_daily` metrika már definiált): $$\mathrm{Supply}_{d;s}=\sum_{k=s}^{d}\mathrm{Issuance}_{k},\qquad s=2009\text{-}01\text{-}01,\ s\leq d\leq e$$ A szerző hangsúlyozza, hogy a `s` kezdőpont az OBM naptár kezdete, így `Supply_{s;s} = Issuance_s`, és minden dátumra `Supply_{d;s} − Supply_{d-1;s} = Issuance_d` (a `d > s` esetben). Ezzel a teljes bitcoin-kínálat **stock-változóvá** alakul a napi realizált kibocsátás flow-változójából. A mértékegység BTC. A definíció kulcsa, hogy az OBM **realizált** kibocsátást használ (a coinbase-tranzakciókban ténylegesen létrehozott BTC), nem elméleti protokoll-szerinti reward-ot. Ez azért fontos, mert egyes blokkokban a miner nem kapja meg a teljes block reward-ot (pl. NULL adatokkal kitöltött extranonce, korai szoftverbug-ok), és az OBM ezt a valóságos, láncon ténylegesen megjelenő kibocsátást méri. ### Gazdasági értelmezés A metrika elsősorban a Bitcoin **monetáris alapját** írja le – az "összes valaha kibányászott BTC" mennyiségét. Négy konkrét felhasználási területet emel ki a szerző: 1. **Monetáris rezsimek összehasonlítása**: pre-halving vs. post-halving időszakok kumulatív kibocsátásának mérése, a 21 milliós felső határhoz való közelítés ütemének vizsgálata. 2. **Részperiódus-elemzés**: tetszőleges részintervallum kumulatív kibocsátása (pl. egy adott év kibocsátása, egy ciklus kibocsátása), ami flow-változóként viselkedik, de a napi készletszinten alapul. 3. **Stock-flow és hasonló makro-mutatók építése**: az SF ratio, a készlet-pótlási arány, a készlet/idő típusú leíró statisztikák mind az `obm_supply_btc_daily` sorozatból indulnak ki. 4. **Híd a napi flow és a stock-szerű monetáris változók között**: a sorozat ugyanazt az információt hordozza, mint az `obm_issuance_btc_daily`, de az alkalmazott kutatásokban gyakran készlet-formában van rá szükség. A szerző explicit kiemeli, hogy a metrika **nem vezet be új információt** az issuance-sorozathoz képest – ez egy transzformáció, nem új mérés. Hasznossága abban áll, hogy a kutatók gyakran készlet-formátumban gondolkodnak, és a transzformáció explicit, dokumentált, reprodukálható. ### Hasonló nyilvános metrikák A sorozat a "current supply", "circulating supply", "total bitcoins" vagy "total issued supply" címkéken futó nyilvános metrikákkal összevethető. A szerző három konkrét összehasonlítást végez: - **Coin Metrics `Current Supply` (SplyCur)**: a legközelebbi megfelelő. A Coin Metrics az UTXO-kláncokon az összes el nem költött output értékének összegeként definiálja, de megjegyzi, hogy "total issued supply"-ként is értelmezhető, mert a főkönyvben megjelenő összes natív egységet összegzi. Mivel az OBM 2009-01-01-től kumulálja a realizált napi kibocsátást, a két sorozat közelítenie kell egymáshoz. Eltérések az időbélyeg-konvenciókban, a reorg-kezelésben, a nem-igényelt coinbase-reward-okban, a nem-költehető (unspendable) output-okban és abban a módszertani döntésben lehetnek, hogy a kínálatot a realizált kibocsátás összegéből vagy a jelenlegi UTXO-k összegéből számítják-e. - **Glassnode `Circulating Supply` (`supply.Current`)**: közvetlenül rokon. A Glassnode a "valaha létrehozott vagy kibocsátott összes coin" mennyiségként definiálja. A módszertan viszont nem teljesen transzparens: nem egyértelmű, hogy coinbase output-okból rekonstruálják-e, a protokoll ütemezéséből számítják-e, vagy korrigálják-e a nem-igényelt reward-okra. Benchmarknak használható, de nem tekinthető pontosan egyenértékűnek. - **Blockchain.com `Total Circulating Bitcoin`**: a módszertan dokumentációja szerint **a protokoll által meghatározott elméleti reward-ból** számít, nem a tényleges coinbase-tranzakciókból. Ez fontos különbség: a Bitcoin korai időszakában (amikor a blokk reward 50 BTC volt, és néhány miner a teljes coinbase-t nem igényelte) a két megközelítés eltérő eredményt ad. Az OBM a realizált kibocsátást preferálja. ### Kitekintés és a rész sorozat lezárása A 18. rész ezen a ponton zárul. A kínálati oldal utolsó két metrikája (az A.20 és A.21) jól mutatja, hogyan épül az OBM-rendszer modulárisan: az A.20 kivonással áll elő két másik OBM-sorozatból, az A.21 pedig egyszerű kumulatív összegzéssel az issuance-sorozatból. Mindkét esetben a belső konzisztencia-azonosság (`SpentValueBTC = SpentValueLT155 + SpentValueGE155`; `ΔSupply = Issuance`) a release-version és az időbélyeg-konvenció egyeztetése mellett tesztelhető. A szerző az A.20 és A.21 metrikáknál is alkalmazza az egész Appendix A-t átható strukturális mintát: definíció → gazdasági értelmezés → hasonló nyilvános metrikák (ütköztetés a Glassnode, Coin Metrics, CryptoQuant, Blockchain.com, Blockchair szolgáltatókkal) → adatforrás és bemeneti követelmények → algoritmus (lépésről lépésre) → paraméterek → aggregáció → kimeneti formátum → technikai validáció → ismert korlátok. Ez a struktúra biztosítja, hogy minden OBM-metrika önállóan, más OBM-sorozatoktól függetlenül is tesztelhető, auditálható és reprodukálható legyen. Az A.22-es (várhatóan `utxo_count` vagy a kiadvány utolsó metrikája) és az esetleges B függelék a 19. rész és 20. részben kap helyet, de a 18. rész a Bitcoin kínálati és fiatal-költési oldal két fontos, jól definiált, belső konzisztencia-ellenőrzéssel is megerősített metrikáját már teljes egészében bemutatta. --- ## 19. rész Ez a rész az Appendix három utolsó, illetve utolsó előtti metrikáját tárgyalja. Az A.21 (`obm_supply_btc_daily`) leírása a 18. részről átnyúlva itt fejeződik be: a külső komparátorok, a konkrét implementációs algoritmus, a kimeneti séma és a validációs szabályok. Az A.22 (`obm_tx_count_daily`) és az A.23 (`obm_utxo_eod_count_daily`) a legfontosabb on-chain aktivitási és állapotváltozók közé tartoznak: előbbi a napi tranzakciószámot, utóbbi a nap végi UTXO-készlet méretét méri. ## A.21 obm_supply_btc_daily – a külső komparátorok és az implementáció A metrika a realizált napi kibocsátás kumulatív összegeként definiálja a `supply` értéket 2009-01-01-től. A definíció tisztán formális, de a gyakorlati használhatóság szempontjából kulcskérdés, hogy milyen nyilvános adatsorokkal vethető össze. ### Hasonló publikus metrikák A szerző hét fő komparátort azonosít, és explicit módon rangsorolja azokat: - **Coin Metrics `SplyCur`** és **Glassnode `supply.Current`**: a két legközelebbi megfelelő. Mindkettő olyan „stock” (készlet-) sor, amely koncepcionálisan a teljes történeti kibocsátásnak felel meg, így közvetlen összevetésre alkalmas. - **Blockchain.com** „Total Bitcoins in Circulation” sora: a cikk hangsúlyozza, hogy ez az elméleti jutalomütemezésen (`subsidy`) alapul, nem a realizált Coinbase-kibocsátáson, ezért „hasznos széles validációhoz, de nem szigorú benchmarknak”. - **YCharts** (a Blockchain.com sor újraközlése): másodlagos komparátor, de örökli a módszertani korlátokat. - **Newhedge** „Bitcoin Circulating Supply” oldala: hasznos diagnosztikai referencia, de a teljes újraépítési algoritmust nem teszi közzé, és egyes API-funkciók fizetősnek tűnnek. - **Blockchair** „circulation” chartja: készletsor, nem kumulatív flow. Blockchair blokk- és tranzakciószintű adataiból elvileg újraépíthető, de maga a chart nem tekinthető az `obm_supply_btc_daily` implementációjának. - **MacroMicro** napi kibocsátási chart: chart-orientált, bejelentkezéshez kötött, és a dokumentáció nem tér ki egyértelműen arra, hogy realizált coinbase outputokra, blokkszám × szubvencióra, vagy saját konvencióra épül-e. Az OBM-módszertan legfontosabb megkülönböztető jegye e téren: a sor kumulatív összegként transzparens, örökli a `release_version` címkét, és a fő belső validációs azonosság az első differenciákra épül (`Δ Supply = Issuance`). ### Adatforrás és bemeneti követelmények A metrika nem igényel közvetlen hozzáférést Bitcoin Core-hoz, blokk-metaadatokhoz, Coinbase-tranzakciókhoz vagy fee-rekonstrukcióhoz. A bemenet mindössze az OBM szabványos napi realizált kibocsátási fájl (`obm_issuance_btc_daily.csv`), amely a szokásos OBM-sémát követi: `date`, `series_id`, `value`, `unit`, `frequency`, `release_version`. A szkript ellenőrzi, hogy a `series_id` értéke `obm_issuance_btc_daily`, az `unit` mező `BTC`, a `frequency` mező `daily`, és minden kért dátumhoz pontosan egy megfigyelés tartozik. ### Algoritmus (compute_obm_supply_btc_daily.py) A számítás 11 lépésben van leírva: 1. A bemeneti CSV beolvasása (kötelező pozicionális argumentum). 2. A `--end_date` argumentum `YYYY-MM-DD` formátumban, UTC-ben értelmezve. 3–4. A séma és a `series_id`, `unit`, `frequency` mezők validálása. 5. A 2009-01-01 és `--end_date` közötti megfigyelések kiválasztása. 6. Annak ellenőrzése, hogy minden dátumhoz pontosan egy kibocsátási érték tartozik – ha bármelyik hiányzik, a szkript leáll. 7. A kumulatív számláló nulláról indul. 8. Kronologikus iteráció: `Supply_{d;s} = Supply_{d-1;s} + Issuance_d`, ahol a `Supply_{s-1;s} = 0` konvenció érvényesül. 9. A `release_version` inferálása a kiválasztott intervallumból. Ha több release-verzió keveredik, a szkript leáll – ez a kiadás-verziók közötti keveredés elleni védelem. 10. Az eredmény kiírása a szabványos OBM-sémával. 11. Opcionális ábra készítése a `release_version` és az intervallum címkézésével. ### Aggregációs szabály és reláció a kibocsátással Az aggregáció zárt alakban: `Supply_{d;s} = Σ_{k=s}^{d} Issuance_k`, rekurzív formában pedig `Supply_{d;s} = Supply_{d-1;s} + Issuance_d` minden `d > s` esetén. A havi változatoknál a szerző két lehetőséget vázol fel: (i) a napi kumulált sor végén vett hónapvégi érték, vagy (ii) a havi kibocsátási folyamok kumulálása. A választott konvenciót dokumentálni kell. Az `obm_issuance_btc_daily` és az `obm_supply_btc_daily` kapcsolatát a legegyszerűbb belső validációs azonosság, `Supply_{d;s} - Supply_{d-1;s} = Issuance_d` fogalmazza meg: az első differenciáknak vissza kell adniuk a napi kibocsátási forrást. ### Kimenet és technikai validáció A kimeneti CSV minden UTC naphoz egy sort tartalmaz, ahol a `value` mező a 2009-01-01 óta akkumulált realizált kibocsátás. A `release_version` öröklődik a forrás-intervallumból. A technikai validáció négy szinten működik: (i) dátumtartomány-ellenőrzés, (ii) sémaellenőrzés, (iii) a `series_id`, `unit`, `frequency` mezők konzisztenciája, (iv) a teljesség ellenőrzése (minden dátum pontosan egyszer szerepel), (v) egyetlen `release_version` a kiválasztott intervallumban, (vi) a napi kibocsátás nem-negativitása (ami garantálja, hogy a kumulált sor monoton növekvő). A legfőbb validációs azonosság az első differenciák egyezése a forrás napi kibocsátással. ### Ismert korlátok A szerző öt korlátot sorol fel. (1) Származtatott sor, nem önálló full-node rekonstrukció. (2) Örökli az `obm_issuance_btc_daily` összes definíciós döntését és esetleges revízióit. (3) Rögzített 2009-01-01 kezdőpontot használ. (4) Nem értelmezhető teljes forgalomban lévő kínálatként, hacsak a forrássor nem fedi le a teljes kibocsátási történetet. (5) Ha a kibocsátási forrást egy későbbi OBM-kiadás revideálja, a kumulált sort is újra kell generálni. ## A.22 obm_tx_count_daily – napi tranzakciószám ### Definíció A metrika azon Bitcoin-tranzakciók számát méri, amelyeket a `d` UTC-naptári naphoz rendelt blokkok erősítenek meg. Formálisan: `TxCount_d = Σ_{b ∈ B_d} N_b`, ahol `B_d` a `d` naphoz rendelt blokkok halmaza, és `N_b` a `b` blokkban lévő tranzakciók száma. A blokk hozzárendelése a Bitcoin Core által visszaadott blokk-időbélyeg UTC-s dátumán alapul. A Coinbase-tranzakciók **beleszámítanak** a metrikába, mivel ezek a Bitcoin Core által jelentett blokk-szintű tranzakciószám részét képezik – ez a konvenció teszi a mutatót közvetlenül reprodukálhatóvá a blokk-metaadatokból. ### Gazdasági értelmezés A napi tranzakciószám a Bitcoin-hálózati aktivitás alapvető proxyja: a láncra kerülő elszámolások számát méri, függetlenül a tranzakció méretétől, díjától vagy a bemenetek/kimenetek számától. Különösen jól használható kombinációkban (fee-szorzatok, blokksúly, elköltött output-érték, BDD), mert az aktivitás más-más dimenzióit ragadják meg. A szerző három figyelmeztetést emel ki. Először, egyetlen tranzakció több bemenetet összesíthet, több kimenetet hozhat létre, vagy self-transfer, illetve tőzsdei/custodial belső művelet lehet. Másodszor, sok gazdasági fizetés off-chain zajlik (pl. Lightning), így nem jelenik meg önálló Bitcoin-tranzakcióként. Harmadszor, a metrika nem egyenlő a felhasználók vagy a fizetési események számával – csak a megerősített on-chain tranzakciókéval. ### Hasonló publikus metrikák Kilenc komparátort azonosít a cikk, és hármat emel ki legerősebb benchmarkként: - **Coin Metrics `TxCnt`**: a legerősebb benchmark. A definíció („sum count of transactions during the interval”) explicit, és natív tranzakciószám-sorként érhető el. Fontos, hogy az egyenlőség nem feltételezhető automatikusan – a coinbase-kezelés, az időbélyeg-hozzárendelés, a reorg-kézelés és a revíziós politika eltérhet. - **Glassnode**: biztosít nyers tranzakciószámlálót (minden típust beleértve: fizetések, exchange deposit/withdrawal, custodial műveletek, Lightning channel nyitás/zárás) és entity-adjusted változatot (`transactions.EntityAdjustedCount`). Az utóbbi tulajdonosi klaszterezésen alapul, professzionális előfizetéshez kötött, és nem közvetlen összevethető az OBM nyers számmal. - **Blockchain.com „Confirmed Transactions Per Day”**: a „number of daily confirmed transactions” definíciót adja, és `Charts and Statistics API`-n programozottan is elérhető. UTC-alapú, de a coinbase-kezelést, a reorg-policy-t és a revíziós logikát nem dokumentálja teljesen. - **Blockchair**: van napi és kumulatív tranzakciószám-chart. A napi a koncepcionálisan közeli, a kumulatív rokon, de nem ekvivalens. A blokk- és tranzakciószintű explorer-adatokból elvileg újraépíthető. - **Bitbo**: 30 napos mozgóátlagot alapértelmezetten mutat, de a nyers napi adat is megjeleníthető – az OBM-mel csak a nyers nézet vethető össze. - **Newhedge, BitInfoCharts, YCharts**: másodlagos források, jellemzően deskriptív, nem algoritmikus specifikációval. - **Token Terminal**: a „unique transactions” kifejezés és a cross-chain keretezés miatt kevésbé közvetlenül összevethető, amíg a Bitcoin-specifikus módszertant nem vizsgáljuk meg. Az OBM-módszertan legfontosabb megkülönböztető jegye, hogy explicit, full-node reprodukálható implementációt ad: blokk-metaadatokból (`nTx` mező vagy a dekódolt blokk `tx` tömbjének hossza) származtat, a coinbase-tranzakciókat definíció szerint tartalmazza, a blokkokat a Bitcoin Core időbélyegéből képzett UTC dátumhoz rendeli, és dokumentálja a `height_margin` eljárást, amely kompenzálja a nem monoton blokk-időbélyegek miatti határblokk-kimaradást. ### Adatforrás és bemeneti követelmények A metrika futó Bitcoin Core full node-ból, a JSON-RPC interfészen keresztül származik. Minden blokkhoz lekéri a blokk-hash-t és a dekódolt blokk-objektumot; a tranzakciók számát a `nTx` mezőből olvassa (ha elérhető), egyébként a `tx` tömb hosszából. Nem igényel UTXO-rekonstrukciót, címkivonatolást, tranzakciós értékeket vagy árfolyamadatokat – kizárólag blokk-szintű információból dolgozik, ezért a legegyszerűbb és legrobosztusabb OBM-metrikák egyike. ### Algoritmus (compute_obm_tx_count_daily.py) Kilenc lépésben: 1. A `--start_date` és `--end_date` argumentumok értelmezése UTC-ben. 2. A kezdő és záró dátum átalakítása a nap 00:00:00, illetve 23:59:59 UTC timestampjeivé. 3. `getblockchaininfo` hívás a jelenlegi láncmagasság meghatározásához. 4. `getblockhash` + `getblock` hívásokkal bináris keresés a kért dátumtartományt lefedő hozzávetőleges magasságtartományra. 5. A tartomány kibővítése a `--height_margin` biztonsági paraméterrel. 6. A kibővített tartományban minden blokkra: hash lekérése, dekódolt blokk lekérése, `t_b` időbélyeg kiolvasása, hozzárendelés `d(b) = UTCDate(t_b)`-hez, `N_b` kiolvasása (lehetőleg `nTx` mezőből), összeadás a napi számlálóhoz, ha a dátum az intervallumba esik. 7. A kért intervallum összes dátumát 0-val inicializálja, így a kimenetben minden naptári naphoz lesz sor (akkor is, ha egy naphoz nem tartozik blokk a határblokkok szűrése után). 8. A szabványos OBM-séma szerinti CSV kiírása. 9. Opcionális ábra készítése. ### A `--height_margin` paraméter Ez a metrika-specifikus paraméter a blokk-időbélyegek nem-monoton viselkedését kezeli. A magasság szigorúan rendezett a láncpozíció szerint, de a bányászok időbélyegei időnként kissé visszacsúszhatnak vagy előreugrálhatnak a szomszédos blokkokéhoz képest. Egy kizárólag időbélyeg-alapú bináris keresés ezért túl szűk tartományt jelölhet ki, és kihagyhat olyan blokkokat, amelyek időbélyege a kért UTC-napra esik. Ezért a szkript a közelítő magasság-tartományt kibővíti: `h_min^scan = max(0, h_min^approx − m)`, `h_max^scan = min(h_tip, h_max^approx + m)`, ahol `m` a `--height_margin` értéke. Az alapértelmezés **288 blokk, ami kb. két nap** termelésnek felel meg a várt 144 blokk/nap ütemben. A kibővítés nem változtatja meg a kimeneti dátumokat, csak a belső szkennelést szélesíti; a számlálás továbbra is csak a `--start_date`–`--end_date` intervallumba eső UTC dátumú blokkok tranzakcióit adja hozzá. Nagyobb `m` érték növeli a robusztusságot több blokk szkennelése árán, kisebb érték gyorsabb, de határeseteken kimaradást okozhat. Napi frissítésekhez az alapértelmezés elegendő; teljes történeti rekonstrukcióhoz vagy formális archív kiadáshoz érdemes nagyobbat választani. ### Aggregáció, kimenet, validáció, korlátok Az aggregáció `TxCount_d = Σ_{b: UTCDate(t_b) = d} N_b`; havi változatnál `TxCount_m = Σ_{d ∈ m} TxCount_d`. A kimenet naponta egy sort tartalmaz `transactions` egységben, a `series_id` `obm_tx_count_daily`. A validáció hatszintű: dátumtartomány-ellenőrzés, lánctúllépés-vizsgálat, a kimenet teljes naptári napokkal való inicializálása, blokk-szintű újraszámolhatóság, valamint a szkennelt blokkok számának és effektív magasságtartománynak a futásidejű kiírása. A korlátok között a szerző ismét hangsúlyozza, hogy a metrika tranzakciókat mér, nem felhasználókat vagy gazdaságilag distinct fizetéseket; nem tesz különbséget kis és nagy tranzakciók között; nem veszi figyelembe a batchinget, a change outputokat, a self-transzfert, a tőzsdei műveleteket vagy az off-chain elszámolást; és a határnapi hozzárendelés függ az időbélyeg-konvenciótól – az OBM az UTC dátumot használja a Bitcoin Core által visszaadott időbélyegből, míg alternatíva (pl. MTP / median time past) a határokon kicsit más eredményt adna. ## A.23 obm_utxo_eod_count_daily – a nap végi UTXO-készlet mérete ### Definíció A metrika a `d` UTC-naptári naphoz rendelt legmagasabb magasságú blokk feldolgozása után a rendelkezésre álló, elköltethető UTXO-k számát jelenti. A sor nem napi flow, hanem protokoll-állapotváltozó. Formálisan: `UTXOCountEOD_d = UTXOCountAfter_{b*}`, ahol `b* = arg max_{b ∈ B_d} h_b` – vagyis a `d` naphoz rendelt blokkok közül a legnagyobb magasságú. A blokk hozzárendelése `d(b) = UTCDate(t_b)` alapján történik. Ha egy naphoz nem tartozik blokk, a sor undefined; a kimenetben `NaN` érték szerepel. Ez a konvenció tudatosan elkerüli, hogy egy olyan naphoz, amely az adott időbélyeg-konvenció mellett nem kapott végblokkot, hamis állapotértéket rendeljünk. A mértékegység `outputs`; a `series_id` `obm_utxo_eod_count_daily`, ahol a `count` az `eod` (end-of-day) után áll, jelezve, hogy a számlálás a nap végi megfigyelési konvencióhoz kötődik. ### Gazdasági értelmezés Az UTXO-készlet a Bitcoin-főkönyv elköltött, de elköltésre váró outputjainak halmaza – ez a Bitcoin ledger „spendable” állapota. A készlet mérete közvetlen hatással van a skálázhatóságra, a full node-ok erőforrásigényére és a Bitcoin hosszú távú „state burden” alakulására. Ha a készlet nő, a node-oknak több elköltethető outputot kell karbantartaniuk; ha csökken, a költési aktivitás több outputot konszolidál, mint amennyit létrehoz. A metrika kutatási szempontból hálózati állapotváltozóként hasznos. Kiegészíti a tranzakciószámot, az elköltött outputok számát, a blokksúlyt és a raw output value-t azáltal, hogy az output-létrehozás és -megsemmisítés kumulatív egyenlegének időbeli alakulását ragadja meg. A leírás a fájl ezen részénél a „capturing the” szónál megszakad; a teljes A.23 algoritmus, kimeneti séma, validáció és korlátok a következő (20.) részben folytatódnak. ## Összegzés A 19. rész gyakorlatilag lezárja az OBM metrikakészletének formális leírását. Az A.21 esetén a hangsúly a komparátorok gondos osztályozásán (legközelebbi / másodlagos / kevésbé összevethető) és a `Δ Supply = Issuance` validációs azonosság központi szerepén van. Az A.22 a legegyszerűbb, mégis legrobosztusabb OBM-metrikák egyike: csak blokk-metaadatokból dolgozik, a `height_margin` paraméterrel kezeli a nem-monoton blokk-időbélyegek határproblémáját, és a coinbase-tranzakciók konvencióját explicit módon dokumentálja. Az A.23 a teljes on-chain állapot legfontosabb indikátora: a nap végi UTXO-szám a protokoll állapotváltozójaként, nem pedig flow-metrikaként viselkedik, és a NaN-konvenció tudatosan jelzi, hogy egyes napokhoz a választott időbélyeg-szabály mellett nem tartozik értelmezhető végblokk. --- ## 20. rész **Forrás:** Diego R. Llanos: *Open Bitcoin Metrics* (arXiv: 2607.03124v1), 20. (utolsó) chunk. **Rész mérete:** 3335 szó, egyetlen hosszú sor. **Lefedett tartalom:** az Appendix A.23 metrikájának (`obm_utxo_eod_count_daily`) teljes definíciója, valamint a teljes References (irodalomjegyzék) szakasz. --- ## 1. Bevezetés — mit tartalmaz ez a rész? A huszadik, egyben utolsó rész a cikk függelékének (Appendix) utolsó, A.23 jelű metrika-leírását, majd a cikk irodalomjegyzékét (References) tartalmazza. Nincs benne Appendix B, külön Limitations, Code and Data Availability, Acknowledgements vagy Author Contributions szakasz — ezek vagy a korábbi chunkokba kerültek, vagy a paperben nem is jelennek meg önállóan. A szöveg egybefüggő, de tematikusan két jól elkülöníthető részre bontható: - **A.23 metrika:** `obm_utxo_eod_count_daily` — a Bitcoin UTXO-készletének napi, végállapot szerinti elemszáma. - **References:** 15 forrásmunka kizárólag szoftver-dokumentáció, weboldal és on-chain adatszolgáltató kategóriában. --- ## 2. Az A.23 metrika: `obm_utxo_eod_count_daily` — napi UTXO darabszám ### 2.1 A metrika célja és értelmezése Az OBM (Open Bitcoin Metrics) projekt ezen utolsó függeléke a Bitcoin-hálózat egyik legalapvetőbb állapotváltozóját definiálja: a nap végén fennálló, el nem költött tranzakció-kimenetek (Unspent Transaction Outputs, UTXO-k) darabszámát. A szerző külön kiemeli, hogy a metrika kizárólag a darabszámot méri — **a BTC-értéket nem** —, és nem szabad összekeverni sem a felhasználók, sem a címek, sem a tárcák, sem a gazdasági szereplők számával. Egyetlen felhasználó sok UTXO-t birtokolhat, és egyetlen entitás is létrehozhat vagy költhet el nagyon sok kimenetet. A növekedési szakaszok output-szétaprózódásra, cím- és tárca-töredezettségre, sok kis outputra vagy a státusz-terhet növelő aktivitási mintákra utalhatnak; a csökkenő UTXO-szám konszolidációs epizódokat jelezhet. ### 2.2 Formális definíció Jelölje `B_d` a `d` UTC naptári naphoz rendelt blokkok halmazát, és `UTXOCountAfter_b` a `b` blokk feldolgozása után fennálló UTXO-számot. Ekkor a definíció: - `b* = arg max_{b ∈ B_d} h_b` (a naphoz tartozó legmagasabb magasságú blokk), - `UTXOCountEOD_d = UTXOCountAfter_{b*}`. Ha egy naphoz egyetlen blokk sem tartozik, az érték **NaN** (nem forward-fill-elt, nem nullázott). A metrika tehát **end-of-day protokoll-állapotváltozó**, nem napi flow. A szkript a következőképpen frissíti a számlálót blokkról blokkra: a frissen létrehozott, nem bizonyíthatóan elköltött outputok hozzáadódnak, minden nem coinbase tranzakció inputja eggyel csökkenti a számlálót. A coinbase outputok akkor is beleszámítanak, ha még nem érettek (immature-ok), hiszen ők is a UTXO-készlet részei. A provably unspendable outputok — a `scriptPubKey.type == nulldata` (OP_RETURN) és a `0x6a` prefixű scriptek — viszont kimaradnak. ### 2.3 Publikus komparátorok A szerző részletesen összeveti a saját definícióját a piacon elérhető hasonló metrikákkal, és világossá teszi, hogy az OBM-sorozat miben tér el (vagy miben egyezik) az egyes szolgáltatókétól: - **Blockchain.com — Unspent Transaction Outputs:** a legerősebb komparátor. Mindkettő érvényes, el nem költött outputokat számol, és kizárja a provably unspendable OP_RETURN-öket. A pontos egyenértékűség azonban nem garantált, mert a publikus oldal nem dokumentálja teljesen a timestamp-konvenciót, a reorg-kezelést és a no-block dátumok kezelését. - **Glassnode — UTXO Set Growth:** koncepcionálisan szintén nagyon közeli; a stock-számot közvetlenül össze lehet hasonlítani, a 7 napos EMA-t viszont nem szabad összekeverni az end-of-day stock-számmal. A pontos sznapshot-időpont és a kezelési konvenciók itt sincsenek teljesen dokumentálva. - **CryptoQuant — UTXO Count:** a leírás szerint egy adott pillanatban fennálló UTXO-k száma. Snapshot-konvenció, OP_RETURN-kezelés, immature coinbase-ok, reorg-policy nem dokumentált. - **Newhedge — Bitcoin UTXO Count:** a definíció koncepcionálisan egyezik, de sem az end-of-day megfigyelés, sem a no-block dátumok, sem a reorg-kezelés nem tisztázott. - **Bitbo — Unspent Outputs By Year:** csak éves aggregátum, nem összehasonlítható közvetlenül a napi sorozattal. - **ChainMetrics:** UTXO stock, created/spent flow és koreloszlás szerinti bontás; a dokumentáció itt is hiányos. - **Coin Metrics:** nincs egyértelműen publikus, az OBM-mel közvetlenül komparálható UTXO-számláló a standard publikus oldalakon. A szerző ezen kívül megemlíti, hogy **blokk-explorer és Bitcoin Core node-szintű lekérdezések** (`gettxoutsetinfo`) is használhatók független rekonstrukcióhoz vagy validációhoz, de ezek nem dokumentált napi idősorok. Fontos elkülöníteni az `obm_utxo_eod_count_daily` metrikát a rokon, de mást mérő sorozatoktól: UTXO value bands, age bands, HODL waves, profit/loss metrikák, created/spent countok — mind használják a UTXO-modellt, de mást mérnek. Az OBM ezen sora kifejezetten az **end-of-day stock-szám** egy explicit számolási konvenció mellett. Az OBM-hozzájárulás egyedisége öt pontban foglalható össze: 1. A napi megfigyelés pontosan definiált: az adott UTC-naphoz rendelt legmagasabb blokk feldolgozása UTÁNI érték. 2. Az immature coinbase outputok **beleszámítanak**, ha nem provably unspendable-ek. 3. A standard OP_RETURN / nulldata outputok kimaradnak. 4. A no-block dátumok NaN-ként íródnak ki, nem forward-fill-elve. 5. A genesis-scan és a checkpoint-alapú számítási mód egyaránt dokumentált a reprodukálhatóság kedvéért. ### 2.4 Adatforrás és bemeneti követelmények A metrikát egy futó Bitcoin Core full node-ból nyerik a JSON-RPC interfészen keresztül. Minden blokkhoz a dekódolt blokk-objektumot a `getblock 2` hívással kérik le — ez tartalmazza a tranzakciókat, az inputokat, az outputokat és a dekódolt `scriptPubKey` metaadatokat, amelyek a provably unspendable outputok azonosításához kellenek. A metrika **nem igényli** a korábbi tranzakció-kimenetek rekonstrukcióját, a spent-output indexer adatbázist, cím-kivonatolást, felhasználó-klaszterezést, entitás-azonosítást, külső ár-adatokat, third-party API-kat, valamint a `txindex=1` opciót. (Az utóbbi azért nem kell, mert minden nem coinbase input pontosan egy UTXO-t költ el, így a számláló frissíthető az input előző tranzakció-kimenetének feloldása nélkül is.) A futtatáshoz szinkronizált Bitcoin Core full node és JSON-RPC hitelesítés (credentials vagy cookie) szükséges. A szkript a node által lokálisan ellenőrzött main chain-t használja, és — a többi közvetlenül szkennelt OBM-metrikához hasonlóan — a Bitcoin Core által visszaadott blokk-timestampet rendeli hozzá az egyes blokkokhoz, hogy UTC naptári napokba sorolja őket. ### 2.5 Az algoritmus lépései A `compute_obm_utxo_eod_count_daily_v2.py` szkript a következő 20 lépésben dolgozik: 1. A felhasználó által megadott `--start_date` és `--end_date` dátum-intervallum parse-olása `YYYY-MM-DD` formátumban; mindkét dátum UTC-ben értendő és a kimenetben is benne van. 2. A futási mód meghatározása: **genesis mód**, ha a `--start_date` értéke `2009-01-03` és nincs megadva checkpoint; **checkpoint mód** egyébként. 3. Ha a `--start_date` nem `2009-01-03`, a `--start_date_eod_utxo_count` paraméter megadása kötelező — ez a megbízható UTXO-szám a start nap végén, ugyanabban a konvencióban. 4. Csatlakozás a helyi Bitcoin Core node-hoz JSON-RPC-n keresztül (credentials, környezeti változók vagy cookie-auth). 5. A lánc aktuális csúcs-magasságának lekérdezése `getblockchaininfo`-val. 6. Az `--end_date`-et lefedő közelítő végmagasság meghatározása bináris kereséssel a blokk-timestamp-ek alapján. 7. A közelítő végmagasság kiterjesztése a `--height_margin` biztonsági paraméterrel, hogy a határon lévő blokkok ne maradjanak ki (mivel a Bitcoin blokk-timestamp-ek nem szigorúan monotonok a magasság függvényében). 8. Genesis módban: `utxo_count = 0` inicializálás, szkennelés a 0. blokktól. 9. Checkpoint módban: `utxo_count = --start_date_eod_utxo_count` inicializálás, majd a `--start_date`-hez vagy korábban rendelt legmagasabb blokk megkeresése, a checkpoint érték kiírása a start dátumra, és a szkennelés a következő láncpozíciótól indul. 10. Blokkok szkennelése lánc-magasság szerinti sorrendben; minden blokkhoz a `getblock` verbosity 2-vel lekérve. 11. Minden outputnál a provably unspendable státusz meghatározása: `scriptPubKey.type == nulldata` esetén kizárás, valamint a `0x6a` prefixű scriptek defenzív kizárása (OP_RETURN). 12. Minden nem provably unspendable output újonnan létrehozott spendable outputnak számít — beleértve a nem provably unspendable coinbase outputokat is. A coinbase-maturitás nem kizárási ok, mert az immature coinbase outputok is a UTXO-készlet részei. 13. Minden nem coinbase tranzakció minden inputja eggyel csökkenti a számlálót. A coinbase inputok nem költenek el korábbi outputokat, így nem csökkentenek. 14. Futó számláló frissítése blokkonként: `UTXOCountAfter_b = UTXOCountBefore_b + CreatedSpendableOutputs_b − SpentOutputs_b`. 15. A futó számláló soha nem lehet negatív — ellenkező esetben inkonzisztens a checkpoint vagy a számolási szabály. 16. A blokk hozzárendelése UTC dátumhoz a blokk timestampje alapján. 17. Minden kiválasztott dátumra a naphoz tartozó legmagasabb blokk UTÁNI UTXO-szám tárolása. 18. A blokk nélküli dátumokra NaN kiírása. 19. Az eredmény-idősor kiírása CSV-be az OBM egységes sémája szerint: `date`, `series_id`, `value`, `unit`, `frequency`, `release_version`. 20. Opcionális plot készítése a `--plot` kapcsolóval. A szkript tehát kizárólag dekódolt blokk-adatokból dolgozik, nem kérdezi le a spent-output indexert, nem rekonstruálja a korábbi outputokat, és nem kell tárolnia a teljes UTXO-készletet — csak egy futó egész-számú számlálót tart karban. ### 2.6 Metrika-specifikus paraméterek - `--start_date_eod_utxo_count`: a `--start_date` nap végi megbízható UTXO-szám, ugyanabban a konvencióban. Kötelező, ha a start dátum nem `2009-01-03`. Ha meg van adva, a szkript ezt az értéket írja ki a start dátumra, és a következő láncpozíciótól indul a blokkonkénti számítás. - `--height_margin`: a checkpoint-határ és a közelítő végmagasság körül extra szkennelt blokkok száma. Alapérték: 288 blokk. A checkpoint-paraméter azért kell, mert a UTXO-szám **kumulatív** állapotváltozó: vagy egy teljes genesis-szkennelés, vagy egy megbízható checkpoint szükséges ahhoz, hogy egy adott későbbi dátumra vonatkozó UTXO-számot meghatározhassunk kizárólag az adott naphoz tartozó blokkokból. A margin pedig azért kell, mert a Bitcoin blokk-timestamp-ek nem szigorúan monotonok; az időbélyeg-alapú bináris keresés csak közelítő magasság-határt ad. A szkript `m` blokk szélességben kiterjeszti a határt: `h_max^scan = min(h_tip, h_max^approx + m)`. Checkpoint módban ugyanez a margin érvényesül a start dátum végi határ megkeresésénél. A szkript ezen felül fogadja a szokásos RPC-, output-, release-version- és plot-paramétereket: `--rpc_url`, `--rpc_user`, `--rpc_password`, `--cookie_path`, `--use_default_cookie`, `--rpc_timeout`, `--output`, `--release_version`, `--plot`, `--plot_output`, `--quiet`. ### 2.7 Aggregációs szabály A metrika **nem napi összegként** aggregálódik, hanem end-of-day állapotváltozó. A futó állapot blokkról blokkra fejlődik a fenti `UTXOCountAfter_b = UTXOCountBefore_b + CreatedSpendableOutputs_b − SpentOutputs_b` szabály szerint. Minden UTC naphoz a riportolt érték a naphoz rendelt legmagasabb blokk UTÁNI UTXO-szám. Havi verziót nem szabad a napi értékek összegzésével képezni. Mivel ez állapotváltozó, a havi értéket end-of-month megfigyelésként kell venni: `UTXOCountEOM_m = UTXOCountEOD_{d*}`, ahol `d*` a hónap utolsó olyan napja, amelyre van UTXO-megfigyelés. ### 2.8 Kimeneti formátum A kimeneti fájl soronként egy UTC dátumhoz tartozó megfigyelést tartalmaz. Az oszlopok: - **date** (pl. `2024-01-01`): UTC naptári dátum. - **series_id** (`obm_utxo_eod_count_daily`): stabil OBM sorozat-azonosító. - **value** (pl. `160123456`): end-of-day UTXO darabszám. - **unit** (`outputs`): UTXO-k száma. - **frequency** (`daily`): megfigyelés gyakorisága. - **release_version** (pl. `OBM v0.1.0`): dataset release verzió. Az értékek egész számok. A blokk nélküli dátumok NaN-ként íródnak ki. Checkpoint módban a megadott `--start_date_eod_utxo_count` a start dátumra kiírt értéke. ### 2.9 Technikai validáció A szkript futás közben tizenöt belső ellenőrzést végez: 1. Érvényes-e a kért dátum-intervallum, és a start dátum nem későbbi-e az end dátumnál. 2. A `--height_margin` nem negatív. 3. A `--start_date_eod_utxo_count` (ha megadták) nem negatív. 4. A `--start_date_eod_utxo_count` meg van adva, amikor a start dátum nem `2009-01-03`. 5. Az RPC hitelesítés érvényes — beleértve a cookie-fájl létezését és formátumát cookie-auth esetén. 6. A Bitcoin Core-hoz való csatlakozás és a lánc-csúcs lekérdezése `getblockchaininfo`-val. 7. A kért dátum-intervallum végmagasságának megkeresése és kiterjesztése. 8. Checkpoint módban a start dátumhoz vagy korábban rendelt legmagasabb blokk megkeresése, és a szkennelés a checkpoint-határ utáni láncpozícióról indul. 9. Blokkok szkennelése lánc-magasság szerint, dekódolt blokkok lekérése `getblock` verbosity 2-vel. 10. Provably unspendable outputok kizárása a létrehozás pillanatában. 11. Nem provably unspendable outputok megszámolása coinbase és nem coinbase tranzakciókban egyaránt. 12. Egy UTXO levonása minden nem coinbase input után. 13. A futó UTXO-szám soha nem lesz negatív. 14. Az egyes napokhoz a legmagasabb blokk UTÁNI UTXO-szám rögzítése. 15. Soronként egy kimeneti rekord kiírása a kiválasztott UTC dátumra. A release előtt további konzisztencia-ellenőrzéseket kell végezni: a definiált értékek nem-negatív egészek; ahol az `obm_block_count_daily` ugyanazzal a timestamp-konvencióval pozitív, ott általában van UTXO-megfigyelés; a blokk nélküli dátumok NaN-ként jelennek meg. A lánc-csúcs közelében az utolsó UTXO-szám összevethető a Bitcoin Core `gettxoutsetinfo` kimenetével, figyelembe véve a lánc-állapot, a timestamp-határ és az output-kezelési konvenciók közti eltéréseket. Checkpoint módban a megadott `--start_date_eod_utxo_count` értéket függetlenül ellenőrizni kell, és az első kimeneti sornak meg kell egyeznie vele. Ha rendelkezésre állnak a megfelelő napi flow-változók, a napi változásnak teljesítenie kell: `ΔUTXOCount_d = CreatedSpendableOutputs_d − SpentOutputs_d`. A nagy pozitív változás output-szétaprózódásra vagy intenzív output-létrehozásra utalhat; a nagy negatív konszolidációs epizódokra. A külső UTXO-számláló sorozatokkal való összevetést óvatosan kell kezelni, mert a szolgáltatók eltérhetnek a timestamp-konvencióban, a provably unspendable outputok kezelésében, a reorg-kezelésben, a checkpoint-konvencióban vagy a forward-fill szabályokban. ### 2.10 Ismert korlátok A metrika kilenc, explicit korláttal rendelkezik: 1. Állapotváltozó, ezért vagy genesis-szkennelés, vagy megbízható checkpoint szükséges. 2. Checkpoint módban minden későbbi érték helyessége a `--start_date_eod_utxo_count` helyességétől függ. 3. A metrika a blokk-timestamp UTC-dátumhoz rendelésének konvenciójától függ. 4. A blokk nélküli dátumok NaN-ként jelennek meg, nem forward-fill-elve. 5. A provably unspendable outputok kizárása a Bitcoin Core dekódolt script-információján alapul (különösen nulldata és OP_RETURN scriptek). 6. Az immature coinbase outputok **beleszámítanak**, noha a coinbase-maturitás szabálya szerint még nem spendable-ek — de a UTXO-készlet részei. 7. A metrika nem azonosít címeket, felhasználókat, tárcákat, entitásokat, tőzsdéket, custodianokat vagy tulajdonosi viszonyokat. 8. A metrika a UTXO-k **darabszámát** méri, nem a bennük tárolt BTC értéket. 9. A metrika közvetlenül dekódolt blokk-adatokból számol, és nem igényli a spent-output indexert. E korlátok ellenére az `obm_utxo_eod_count_daily` hasznos OBM hálózat-állapot sorozat: egyszerű, full-node-ból származtatott mérőszáma a UTXO-készlet méretének, és kiegészíti a block count, transaction count, spent-output count, raw output value, block weight és más aktivitás-metrikákat. --- ## 3. References (irodalomjegyzék) A cikk irodalomjegyzéke 15 forrásmunkát sorol fel, szinte kivétel nélkül szoftver-dokumentáció, weboldal és on-chain adatszolgáltató kategóriában (minden hozzáférés dátuma: 2026-05-04). A források és az OBM-beli hivatkozásaik: - **Bitbo (2026)** — Bitbo subscription pricing. *Hivatkozva: Table 1.* - **Bitcoin Core Project (2026)** — Bitcoin core. *Hivatkozva: Table 1, §2.* - **Bitcoin Magazine Pro (2026)** — Bitcoin magazine pro. *Hivatkozva: Table 1.* - **BitInfoCharts (2026)** — Bitcoin statistics. *Hivatkozva: Table 1.* - **Blockchain.com (2026)** — Blockchain.com charts: total transaction fees btc. *Hivatkozva: Table 1.* - **Blockchair (2026a)** — Blockchair api. *Hivatkozva: Table 1.* - **Blockchair (2026b)** — Blockchair database dumps. *Hivatkozva: Table 1.* - **Checkonchain (2026)** — Bitcoin on-chain analysis and charts. *Hivatkozva: Table 1.* - **Coin Metrics (2026)** — Coin metrics community data and api documentation. *Hivatkozva: Table 1.* - **CryptoQuant (2026)** — CryptoQuant pricing. *Hivatkozva: Table 1.* - **Glassnode (2026)** — Glassnode pricing: digital asset data and analytics. *Hivatkozva: Table 1.* - **mempool.space (2026)** — Mempool.space rest api documentation. *Hivatkozva: Table 1.* - **S. Nakamoto (2008)** — Bitcoin: a peer-to-peer electronic cash system. *Hivatkozva: §2.* (Az egyetlen klasszikus tudományos/technikai forrás a Bitcoin white paper.) - **Newhedge (2026)** — Newhedge api. *Hivatkozva: Table 1.* - **Trading Digits (2026)** — Bitcoin realized price chart. *Hivatkozva: Table 1.* - **YCharts (2026)** — Bitcoin total transaction fees per day. *Hivatkozva: Table 1.* A listán egyetlen peer-reviewed tudományos hivatkozás szerepel (Nakamoto 2008); a többi kizárólag iparági adatszolgáltatók, blokk-explorer szolgáltatások, szoftver-projektek és ár-chart oldalak. Ez összhangban áll a cikk önálló, módszertani jellegével: az OBM saját, full-node-ból közvetlenül származtatott metrikákat definiál, és a publikus komparátorokkal való összevetéshez használja ezeket a forrásokat — nem tudományos előzményekre, hanem szolgáltatói referencia-pontokra épít. --- ## 4. a rész záró megjegyzései - A huszadik rész ténylegesen a paper utolsó, lezárt része. A függelék-sorozat az A.23 metrikával zárul, az irodalomjegyzék a cikk References szekcióját adja vissza. - A korábbi részekben lefedett Methods, 4. fejezet és az A.1–A.22 metrikák kontextusába az A.23 metrika természetesen illeszkedik: ez az UTXO-készlet darabszámának végállapota, amely a cikk blokk- és tranzakció-szintű metrikáit az output-szintű, készlet-oldali állapotváltozóval egészíti ki. - A metrika — csakúgy, mint a többi OBM-sor — teljesen reprodukálható egy szinkronizált Bitcoin Core full node-ból, és a cikk filozófiájához híven minden egyes számolási lépést (genesis/checkpoint mód, OP_RETURN-szűrés, immature coinbase-ok kezelése, NaN a no-block napokra, magasság-margin) explicit módon dokumentál. - A függelék ezzel lezárul: a cikk a 23 Appendix-metrikával és a fenti irodalomjegyzékkel ér véget. ---