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:

Ö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.
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.
Ö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.

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ő:

kiolvassa az értéket és a létrehozási időt,
frissíti a napi aggregátumokat,
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:

A drága spent-output rekonstrukciót csak egyszer kell elvégezni.
A metrika-specifikus scriptek egyszerűek és auditálhatók maradnak.
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_<metric>_<unit or variant>_<frequency>

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ő:

Mit mér a sor — a pontos matematikai definíciót és az adatforrást.
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).
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:

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.
A kezdődátum 00:00:00 UTC, a záródátum 23:59:59 UTC időbélyeggé konvertálódik.
A getblockchaininfo hívással lekérdezi a legfrissebb blokkmagasságot (h_tip).
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.
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).
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.
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.
A kimeneti CSV az egységes OBM-séma szerint íródik: date, series_id, value, unit, frequency, release_version.
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:

A metrika blokkokat mér, nem tranzakciókat, felhasználókat, tranzakciós keresletet vagy gazdasági aktivitást.
Nem tartalmaz információt a blokkméret, blocksúly, díjak, tranzakciós volumen vagy bányászbevétel szempontjából.
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.
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 <hash> 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:

Napi összeget mér, nem átlagot — ezért részben a napi blokkszám-ingadozást is tükrözi.
Blokktér-használat, nem tranzakciós kereslet vagy gazdasági aktivitás.
Függ a blokk-időbélyeg-konvenciótól.
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.
Eltérhet a bájtos, átlagos vagy kapacitás-kihasználtsági százalékos publikus mutatóktól.
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:

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.
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.
Validációs alap: a sor-összeg ellenőrzésével közvetlenül verifikálható az aggregált obm_cdd_btcxdays_daily.
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:

A felhasználó által megadott --start_date és --end_date (YYYY-MM-DD formátumú UTC dátumok, inkluzív) parse-olása.
A perzisztens SQLite adatbázis megnyitása a --state_db argumentumban megadott útvonalon.
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.
A daily_age_band_aggregates tábla és annak kötelező mezőinek (date, age_band, cdd_sats_days) meglétének vizsgálata.
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.
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.
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.
A daily_age_band_aggregates táblából az összes date-band megfigyelés lekérdezése a kért intervallumban.
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.
A cdd_sats_days érték nem-negativitásának és a date-band párok egyediségének ellenőrzése.
Átváltás satoshi-napokról BTC-napokra (osztás 100 000 000-rel).
A wide table kiírása CSV fájlba: soronként egy UTC dátum, oszloponként egy age-band.
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).
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_<alsó_határ>_<felső_határ>_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:

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.
A blokk időbélyeg-konvenciójától függ (mind az output-kor, mind a blokk-hozzárendelés szempontjából).
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.
A tábla örökli a CDD-nél használt törtrész-nap konvenciót.
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.
A self-transzferek, wallet consolidation, batching, exchange műveletek és custodial tárcakezelés torzíthatják a megfigyelt CDD-koreloszlást.
A metrika BTC-napokat jelent, nem BTC értéket vagy fiat-értéket.
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.
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:

feloldja az inputot a korábbi outputra (amit elkölt),
előhívja az előző output értékét és létrehozási időbélyegét az outpoint-állapotból,
kiszámolja az eltelt időt napokban,
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:

A felhasználó által megadott --start_date és --end_date UTC-dátumok értelmezése (YYYY-MM-DD).
A perzisztens SQLite adatbázis megnyitása a --state_db útvonalon.
Az adatbázis metaadatainak ellenőrzése (indexer_id, last_processed_height, last_processed_date, max_processed_date).
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.
A release-verzió kiolvasása az indexer metaadatából (vagy a --release_version fallback alkalmazása).
Minden egyes UTC naphoz a cdd_sats_days mező kiolvasása; ha nincs sor, a script nullát ír.
Átszámítás BTC·napra: CDD_d = cdd_sats_days_d / 100 000 000.
CSV kiírás a szabványos OBM séma szerint.
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:

A dátumintervallum érvényessége (--start_date ≤ --end_date).
SQLite adatbázis megléte, megnyitása query-only módban.
A indexer_id metaadat ellenőrzése.
A feldolgozottságot jelző mezők (last_processed_height, last_processed_date, max_processed_date) megléte.
A kért záró dátum nem lépheti túl az indexer által feldolgozott legnagyobb dátumot.
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¶

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.
A blokkok időbélyeg-konvenciója határozza meg mind az output korát, mind a napi besorolást.
A Bitcoin hajnalán a coinbase-outputok és az első nem-coinbase tranzakciók kezelése érzékenyen hat a CDD-re.
A reprodukálhatóság feltétele a perzisztens lokális állapotadatbázis megléte.
A egyszerű reorg-kezelés inkoherencia esetén leállítja a feldolgozást, de nem rollbackeli automatikusan az állapotot.
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:

Ö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.
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ő.
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.
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:

Beolvassa az obm_cdd_btcxdays_daily CSV-fájlt (első kötelező pozicionális argumentum).
Beolvassa az obm_supply_btc_daily CSV-fájlt (második kötelező pozicionális argumentum).
Mindkét fájlon sémavalidációt futtat: a kötelező mezők a date, series_id, value, unit, frequency, release_version.
Ellenőrzi, hogy a két sorozat azonosítója valóban obm_cdd_btcxdays_daily és obm_supply_btc_daily.
Ellenőrzi a mértékegységeket (a CDD-sorozat BTC-days, a supply-sorozat BTC) és a daily frekvenciát.
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.
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.
Minden d dátumra beolvassa a CDD_d és SupplyBTC_d értékeket, és meggyőződik arról, hogy mindkettő nem-negatív.
Ha SupplyBTC_d > 0, kiszámolja a hányadost: CDDPerSupply_d = CDD_d / SupplyBTC_d.
Ha SupplyBTC_d = 0, az eredményt nem nullaként, hanem hiányzó értékként rögzíti.
A kiválasztott intervallumban inferálja a release_version értéket; ha több release-verzió keveredne, a script leáll, nehogy összemossa azokat.
A kész idősort a szabványos OBM-sémával írja ki.
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 <block_hash> 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:

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.
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.
Kapcsolódik a helyi Bitcoin Core csomóponthoz (explicit RPC, környezeti változók vagy cookie-auth).
A getblockchaininfo hívással lekéri az aktuális fő lánc magasságot.
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.
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).
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.
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.
Minden kiválasztott UTC-dátumra a tárolt nehélységet írja ki, ha van blokk; egyébként NaN-t.
A kész idősort a szabványos OBM-sémával írja ki.
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:

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.
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ó.
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¶

A megadott dátumintervallum értelmezése UTC-ben, inkluzív határokkal.
A perzisztens SQLite adatbázis megnyitása read-only módban.
Az indexer metaadatok validálása (indexer_id, last_processed_height, last_processed_date, max_processed_date).
Annak ellenőrzése, hogy a kért --end_date nem haladja meg az indexer által feldolgozott maximális dátumot.
A release version kiolvasása az adatbázisból, fallback a --release_version paraméterre.
Minden UTC dátumra a cdd_sats_days és spent_value_sats kiolvasása a daily_aggregates táblából.
Ha spent_value_sats > 0, a dormancy kiszámítása a két érték hányadosaként.
Ha a sor hiányzik vagy a nevező nulla, a cella értéke NaN.
Az eredmény kiírása az OBM standard CSV sémába: date, series_id, value, unit, frequency, release_version.
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.$$} 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$$}} 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 <hash> 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:

A felhasználó által megadott --start_date / --end_date UTC dátumintervallum beolvasása.
Az ablakméret betöltése (--window_days, alapértelmezés 7) – ez határozza meg a series_id-t.
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.
RPC-kapcsolat (explicit user/pass, környezeti változók vagy cookie-alapú auth).
A jelenlegi lánctipp magasságának lekérése.
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.
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.
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.
A blokkok rendezése timestamp szerint (magasság szerinti tie-breaker).
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.
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.
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:

A hashrate nem on-chain megfigyelés, hanem a difficulty és a blokkidőzítés alapján becsült érték.
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.
A becslést a blokk-felfedezés sztochasztikus varianciája befolyásolja, különösen rövid ablakok esetén.
A metrika a blokk-timestamp konvenciójától függ (itt: UTC).
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.
A metrika nem azonosít bányászokat, pool-okat, hardvert, áramfogyasztást, földrajzi eloszlást vagy profittabilitást.
Csak blokk-metaadatokból dolgozik, nem igényli a spent-output indexelőt.
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}}}{\mathrm{Issuance{d} + \mathrm{FeesBTC}$$}

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:

Beolvassa az obm_issuance_btc_daily CSV-fájlt (első kötelező pozicionális argumentum).
Beolvassa az obm_fees_btc_daily CSV-fájlt (második kötelező pozicionális argumentum).
Ellenőrzi mindkét fájl OBM-sémáját.
Ellenőrzi, hogy a sorozat-azonosítók a vártak (obm_issuance_btc_daily és obm_fees_btc_daily).
Ellenőrzi, hogy mindkét sorozat BTC egységű és daily gyakoriságú.
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.
Ellenőrzi, hogy mindkét forrásfájl pontosan egy megfigyelést tartalmaz minden kiválasztott dátumra.
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.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:

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).
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.
Ellenőrzi, hogy a forrásértékek nem negatívak.
Kiszámítja a MinerRevenueBTC_d = Issuance_d + FeesBTC_d nevezőt.
Ha a nevező pozitív, kiszámítja a hányadost; ha nulla, a megfigyelést „missing”-ként jelöli.
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.
Az eredményt a szabványos OBM CSV-sémával írja ki: date, series_id, value, unit, frequency, release_version.
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:

A felhasználó által megadott dátumintervallumot (--start_date, --end_date) UTC-dátumként értelmezi és beolvassa (YYYY-MM-DD formátumban).
Megnyitja a megadott --state_db SQLite-adatbázist.
Ellenőrzi, hogy az adatbázis metaadatai valóban OBM spent-output indexerhez tartoznak-e (indexer_id ellenőrzés).
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.
A release-verziót az indexer metaadatából veszi, vagy a --release_version fallback értéket használja, ha a metaadat hiányzik.
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.
Átváltja az értéket satoshiból BTC-be (osztás 100 000 000-rel).
A szabványos OBM-sémával (date, series_id, value, unit, frequency, release_version) kiírja a CSV-t.
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:

Beolvassa a két CSV bemenetet, ellenőrzi a séma érvényességét.
A dátumokat YYYY-MM-DD formátumban, UTC-ként értelmezi.
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.
A kiválasztott dátumintervallumban megköveteli a teljes supply-sort, a CDD-rést nullaként kezeli.
A kiválasztott időszakra vonatkozóan egy közös release_version meglétét ellenőrzi.
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.
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.
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:

A felhasználó által megadott --start_date és --end_date UTC dátumokat parseolja YYYY-MM-DD formátumban.
Megnyitja az indexer által generált SQLite adatbázist a --state_db útvonalon.
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.
Ellenőrzi, hogy a kért --end_date nem későbbi, mint az indexer által feldolgozott maximális dátum.
A release_version-t az indexer metaadatából veszi, vagy a --release_version fallback értéket használja.
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.
Satiról BTC-re konvertál (osztás 100 000 000-zal).
Az eredményt az OBM szabványos CSV sémába írja.
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:

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.
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.
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.
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.
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.
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:

A felhasználó által megadott dátumintervallum (--start_date, --end_date) értelmezése YYYY-MM-DD formátumban, UTC-ben.
Annak ellenőrzése, hogy a kezdő dátum nem későbbi a végdátumnál.
Az OBM spent-output indexer SQLite adatbázis megnyitása a --state_db útvonalon; ha nem létezik, a script leáll hibával.
A daily_aggregates (vagy --table argumentumban megadott) tábla azonosítása – automatikus detektálással vagy explicit megadással.
A dátumoszlop azonosítása (date, day, utc_date – vagy --date_column).
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.
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.
Az adatbázis-lekérdezés: minden sor, amelynek dátuma a kért intervallumba esik.
Duplikált dátumok ellenőrzése – hiba, ha egy naptári nap kétszer szerepel.
Szatomi-oszlopoknál integer-ellenőrzés; BTC-oszlopoknál decimal-aritmetika.
A nyers output-érték kiszámítása: RawOutputValue(d) = SpentValue(d) − Fees(d).
Negatív eredmény elutasítása (ez adatbázis-inkonzisztenciát jelezne).
Átváltás BTC-be: osztás 100 000 000-zal.
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).
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.
Opcionális ábragenerálás a --plot kapcsolóval (alapértelmezetten a CSV neve mellé, .png kiterjesztéssel).
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:

A dátumintervallum érvényessége (--start_date ≤ --end_date).
A megadott SQLite állapotadatbázis létezése.
A választott aggregált tábla létezése (explicit megadás vagy auto-detect).
A választott dátum, spent-value és fee oszlopok létezése.
Satomi-oszlopok esetén az értékek integer volta.
Minden numerikus érték decimal-aritmetikával való parse-olása (a bináris lebegőpontos artefaktumok elkerülése végett).
Az adatbázis-lekérdezés által visszaadott dátumok egyediségi ellenőrzése.
A raw output value kiszámítása a könyvelési azonossággal, és a negatív eredmény elutasítása.
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.
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:

Értelmezi a spent_value, CDD, dormancy és age-threshold metrikák változásait.
Segít azonosítani a tárcakonszolidációs epizódokat, amelyek jellemzően sok inputot költenek el egyszerre.
Nevezőül szolgálhat származtatott mutatókhoz, például az „átlagos elköltött érték outputonként” mérőszámhoz.
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:

A felhasználó által megadott --start_date és --end_date (YYYY-MM-DD, UTC) értelmezése.
Az obm_spent_output_indexer.py által generált SQLite-adatbázis megnyitása a --state_db argumentumon keresztül.
Az adatbázis metaadatainak (pl. indexer_id, last_processed_height, last_processed_date, max_processed_date) ellenőrzése.
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.
A release-verzió kiolvasása az adatbázisból, vagy a --release_version fallback használata.
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.
A sor kiírása a szabványos OBM CSV-sémába: date, series_id, value, unit, frequency, release_version.
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:

A teljes elköltött érték kor szerinti dekompozíciója – részletesebb, mint egy skalár sorozat.
A fiatal-output forgalom és az alvó készlet aktiválódásának szétválasztása.
Annak vizsgálata, hogy a forgalmi kiugrásokat rövid UTXO-churn, tárcakonszolidáció vagy idősebb coinok mozgása okozza-e.
A küszöbérték-metrikák validációja (obm_cdd_155d_btc_daily, obm_cdd_365d_btc_daily).
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}$$

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{a_i \in k}$$} \sum_{i \in I_b} v_i^{\mathrm{sats}} \cdot \mathbf{1

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ó:

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.
Megnyitja a --state_db útvonalon megadott SQLite adatbázist.
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.
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).
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.
A release-verziót az adatbázis metaadatából veszi, vagy a --release_version fallback értéket használja.
Minden kért dátumra létrehoz egy teljes sort, ahol minden korosztály oszlop értéke kezdetben nulla.
Lekéri a daily_age_band_aggregates táblából az összes dátum–sáv rekordot az intervallumban.
Minden lekért sornál ellenőrzi, hogy az age_band a várt címkék halmazába tartozik – ellenkező esetben leáll.
Ellenőrzi, hogy az érték nem negatív, és nincs duplikátum ugyanarra a dátum–sáv párra.
Átváltja az értéket satoshiból BTC-re.
Az eredményt CSV-fájlba írja; minden sor egy UTC-dátum, minden oszlop egy korosztály.
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.
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{a_i \in k}$$} \sum_{i \in I_b} v_i \cdot \mathbf{1

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$$} \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 v_i$$} \sum_{i \in I_b

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:

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.
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.
BTC-denomináció: a metrikák nem USD- vagy fiat-értéken vannak, így az árszint változása nem befolyásolja őket.
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.
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.
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:

Azon napok azonosítása, amikor hosszabb ideig inaktív coinok mozognak.
Szétválasztás a régebbi és a frissen forgó coinok aktivitása között.
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.
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.
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:

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.
SQLite adatbázis megnyitása — az indexer által generált perzisztens adatbázis, amelyet a --state_db argumentummal ad meg a felhasználó.
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.
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.
Release-verzió kikövetkeztetése — az indexer metaadatából; ha nincs release_version mező, a --release_version fallback értéket használja.
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.
Sat → BTC konverzió — osztás 100 000 000-rel.
CSV kiírás — az egységes OBM séma szerint: date, series_id, value, unit, frequency, release_version.
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:

Dátumtartomány érvényessége — start_date ≤ end_date.
SQLite adatbázis létezik — read-only módban nyitja.
Indexer-azonosító egyezés — az indexer_id metaadat megfelelősége.
Field-ek megléte — last_processed_height, last_processed_date, max_processed_date.
daily_aggregates tábla jelenléte.
--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:

Nem entitás-korrigált LTH metrika — nem azonosít felhasználókat, entitásokat, custodianokat, tőzsdéket, self-transzfereket vagy change outputokat.
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.
É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.
Mértékegység — BTC, nem BTC-days, noha a CDD-családba tartozik.
Self-transzferek, konszolidáció, batching, tőzsdei műveletek, custodian wallet menedzsment — mind torzíthatják a metrikát.
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.
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<155}$$}}\sum_{i\in I_{b}}v_{i}\mathbf{1}{a_{i

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ő:

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.
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.
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.
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:

obm_spent_value_btc_daily – teljes napi költött output-érték BTC-ben.
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:

Beolvassa a teljes költött érték CSV-fájlt (1. pozicionális argumentum).
Beolvassa a ≥ 155 napos költött érték CSV-fájlt (2. pozicionális argumentum).
Ellenőrzi, hogy mindkét fájl létezik, nem üres, és tartalmazza a kötelező oszlopokat.
A dátumokat YYYY-MM-DD formátumban, UTC-ként értelmezi.
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.
Ellenőrzi, hogy egyik fájlban sincs duplikált dátum.
Ellenőrzi, hogy az 1. fájl series_id értéke obm_spent_value_btc_daily, unit = BTC, frequency = daily.
Ellenőrzi, hogy a 2. fájl series_id értéke obm_spent_value_ge155d_btc_daily, unit = BTC, frequency = daily.
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.
Ellenőrzi, hogy mindkét forrás teljes a kiválasztott intervallumban.
Ellenőrzi, hogy a két fájl közös release_version-t használ az intervallumban.
Minden d dátumra kiszámítja a különbséget: SpentValueLT155BTC_d = SpentValueBTC_d − SpentValueGE155BTC_d.
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.
Ha az eredmény ennél nagyobb negatív, a script leáll, mert ez inkonzisztens forrásfájlokra utal.
Az eredményt a standard OBM-sémával írja ki (CSV).
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}=\sum01,\ s\leq d\leq e$$}^{d}\mathrm{Issuance}_{k},\qquad s=2009\text{-}01\text{-

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ő:

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.
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.
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.
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:

A bemeneti CSV beolvasása (kötelező pozicionális argumentum).
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.
A 2009-01-01 és --end_date közötti megfigyelések kiválasztása.
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.
A kumulatív számláló nulláról indul.
Kronologikus iteráció: Supply_{d;s} = Supply_{d-1;s} + Issuance_d, ahol a Supply_{s-1;s} = 0 konvenció érvényesül.
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.
Az eredmény kiírása a szabványos OBM-sémával.
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:

A --start_date és --end_date argumentumok értelmezése UTC-ben.
A kezdő és záró dátum átalakítása a nap 00:00:00, illetve 23:59:59 UTC timestampjeivé.
getblockchaininfo hívás a jelenlegi láncmagasság meghatározásához.
getblockhash + getblock hívásokkal bináris keresés a kért dátumtartományt lefedő hozzávetőleges magasságtartományra.
A tartomány kibővítése a --height_margin biztonsági paraméterrel.
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.
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).
A szabványos OBM-séma szerinti CSV kiírása.
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 <block_hash> 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:

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.
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.
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.
Csatlakozás a helyi Bitcoin Core node-hoz JSON-RPC-n keresztül (credentials, környezeti változók vagy cookie-auth).
A lánc aktuális csúcs-magasságának lekérdezése getblockchaininfo-val.
Az --end_date-et lefedő közelítő végmagasság meghatározása bináris kereséssel a blokk-timestamp-ek alapján.
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).
Genesis módban: utxo_count = 0 inicializálás, szkennelés a 0. blokktól.
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.
Blokkok szkennelése lánc-magasság szerinti sorrendben; minden blokkhoz a getblock verbosity 2-vel lekérve.
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).
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.
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.
Futó számláló frissítése blokkonként: UTXOCountAfter_b = UTXOCountBefore_b + CreatedSpendableOutputs_b − SpentOutputs_b.
A futó számláló soha nem lehet negatív — ellenkező esetben inkonzisztens a checkpoint vagy a számolási szabály.
A blokk hozzárendelése UTC dátumhoz a blokk timestampje alapján.
Minden kiválasztott dátumra a naphoz tartozó legmagasabb blokk UTÁNI UTXO-szám tárolása.
A blokk nélküli dátumokra NaN kiírása.
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.
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:

Érvényes-e a kért dátum-intervallum, és a start dátum nem későbbi-e az end dátumnál.
A --height_margin nem negatív.
A --start_date_eod_utxo_count (ha megadták) nem negatív.
A --start_date_eod_utxo_count meg van adva, amikor a start dátum nem 2009-01-03.
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.
A Bitcoin Core-hoz való csatlakozás és a lánc-csúcs lekérdezése getblockchaininfo-val.
A kért dátum-intervallum végmagasságának megkeresése és kiterjesztése.
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.
Blokkok szkennelése lánc-magasság szerint, dekódolt blokkok lekérése getblock verbosity 2-vel.
Provably unspendable outputok kizárása a létrehozás pillanatában.
Nem provably unspendable outputok megszámolása coinbase és nem coinbase tranzakciókban egyaránt.
Egy UTXO levonása minden nem coinbase input után.
A futó UTXO-szám soha nem lesz negatív.
Az egyes napokhoz a legmagasabb blokk UTÁNI UTXO-szám rögzítése.
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:

Állapotváltozó, ezért vagy genesis-szkennelés, vagy megbízható checkpoint szükséges.
Checkpoint módban minden későbbi érték helyessége a --start_date_eod_utxo_count helyességétől függ.
A metrika a blokk-timestamp UTC-dátumhoz rendelésének konvenciójától függ.
A blokk nélküli dátumok NaN-ként jelennek meg, nem forward-fill-elve.
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).
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.
A metrika nem azonosít címeket, felhasználókat, tárcákat, entitásokat, tőzsdéket, custodianokat vagy tulajdonosi viszonyokat.
A metrika a UTXO-k darabszámát méri, nem a bennük tárolt BTC értéket.
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.

Open Bitcoin Metrics: Verifiable Full-Node-Derived Bitcoin Time Series for Economic Research¶

Epizód áttekintés¶

1. rész¶

1. Absztrakt és a projekt célja¶

2. Bevezetés — miért van szükség ilyen adathalmazra?¶

3. Kapcsolódó munkák (Related Work) — 1. táblázat¶

4. Az OBM 23 metrikája (a cikk 4. fejezetének és A. függelékének felsorolása)¶

5. Az adat-előállítási folyamat (Methods, 3. fejezet)¶

5.1 Kétféle idősor: elsődleges és származtatott¶

5.2 A teljes csomópont konfigurációja¶

5.3 Idő-konvenció és aggregáció¶

5.4 A spent-output indexelő (az architektúra kulcseleme)¶

5.5 Metrika-export scriptek és a származtatott pipeline¶

6. Összegzés és a rész határai¶

2. rész¶

1. A Methods fejezet lezárása (3.5–3.6)¶

Hiányzó értékek és származtatott metrikák kezelése (3.5)¶

Változó-elnevezési konvenció (3.6)¶

2. A 4. fejezet szerkezete¶

3. A metrikák részletes ismertetése (4.1–4.15)¶

4.1 obm_block_count_daily — Napi blokkszám¶

4.2 obm_block_weight_wu_daily — Napi blokksúly weight unitban¶

4.3 obm_cdd_age_band_btcxdays_daily — Napi CDD életkor-sávok szerint¶

4.4 obm_cdd_btcxdays_daily — Bitcoin Days Destroyed¶

4.5 obm_cdd_per_supply_days_daily — CDD per kínálategység¶

4.6 obm_difficulty_eod_daily — Napi bányászati nehézség (nap végén)¶

4.7 obm_dormancy_days_daily — Napi dormancy¶

4.8 obm_est7d_hashrate_ehs_daily — Becsült 7 napos hálózati hashrate EH/s-ban¶

4.9 obm_fee_share_revenue_ratio_daily — Díjak mint a bányászbevétel részaránya¶

4.10 obm_fees_btc_daily — Napi tranzakciós díjak¶

4.11 obm_issuance_btc_daily — Napi Bitcoin-kibocsátás¶

4.12 obm_liveliness_ratio_daily — Napi liveliness arány¶

4.13 obm_miner_revenue_btc_daily — Napi bányászbevétel BTC-ben¶

4.14 obm_raw_output_value_btc_daily — Napi nyers output-érték BTC-ben¶

4.15 obm_spent_output_count_daily — Napi elköltött outputok száma¶

4. Összegzés és kitekintés¶

3. rész¶

4.15 obm_spent_output_count_daily — naponta elköltött output-ok száma¶

4.16 obm_spent_value_age_band_btc_daily — daily spent output value by age band (wide table)¶

4.17 obm_spent_value_btc_daily — daily spent output value BTC-ben¶

4.18 obm_spent_value_ge155d_btc_daily — 155 napnál idősebb spent output-ok értéke¶

6. Usage notes¶

7. Code and data availability¶

8. Limitations¶

9. Acknowledgements¶

10. Author contributions¶

11. Declaration of Competing interests¶

Appendix A.1 obm_block_count_daily — kezdet¶

4. rész¶

1. Kontextus: hol tartunk a cikkben?¶

2. A 4.1-es metrika: obm_block_count_daily — napi blokkszám¶

2.1 Definíció és aggregáció¶

2.2 Algoritmus és a --height_margin paraméter¶

2.3 Kimeneti formátum és validáció¶

2.4 Ismert korlátok és közgazdasági értelmezés¶

3. A 4.2-es metrika: obm_block_weight_wu_daily — napi blokksúly weight unitban¶

3.1 Definíció és aggregáció¶

3.2 Algoritmus és biztonsági paraméterek¶

3.3 Kimeneti formátum és származtatott diagnosztikák¶

3.4 Hasonló nyilvános metrikák és összehasonlításuk¶

3.5 Ismert korlátok és közgazdasági értelmezés¶

3.6 Technikai validáció¶

4. Az Appendix A első két referenciabejegyzése¶

4.1 A.2 — obm_block_weight_wu_daily (ismételt, referencia-formátumban)¶

4.2 A.3 — obm_cdd_age_band_btcxdays_daily (részleges, a 4. rész végén)¶

5. Miért fontos ez a két metrika a teljes OBM-rendszerben?¶

6. Összegzés¶

5. rész¶

1. A.3 — obm_cdd_age_band_btcxdays_daily: napi CDD korosztály-sávok szerint¶

Definíció és aggregációs szabály¶

Gazdasági értelmezés¶

Hasonló nyilvános metrikák és összehasonlítás¶

Adatforrás és bemeneti követelmények¶

Algoritmus (export_obm_cdd_age_band_btcxdays_daily.py)¶

Metrika-specifikus bemeneti paraméterek¶

Kimeneti formátum¶

Technikai validáció és ismert korlátok¶

2. A.4 — obm_cdd_btcxdays_daily: napi összesített Bitcoin Days Destroyed¶

Definíció és aggregációs szabály¶

Gazdasági értelmezés¶

4.1 `obm_block_count_daily` — Napi blokkszám¶

4.2 `obm_block_weight_wu_daily` — Napi blokksúly weight unitban¶

4.3 `obm_cdd_age_band_btcxdays_daily` — Napi CDD életkor-sávok szerint¶

4.4 `obm_cdd_btcxdays_daily` — Bitcoin Days Destroyed¶

4.5 `obm_cdd_per_supply_days_daily` — CDD per kínálategység¶

4.6 `obm_difficulty_eod_daily` — Napi bányászati nehézség (nap végén)¶

4.7 `obm_dormancy_days_daily` — Napi dormancy¶

4.8 `obm_est7d_hashrate_ehs_daily` — Becsült 7 napos hálózati hashrate EH/s-ban¶

4.9 `obm_fee_share_revenue_ratio_daily` — Díjak mint a bányászbevétel részaránya¶

4.10 `obm_fees_btc_daily` — Napi tranzakciós díjak¶

4.11 `obm_issuance_btc_daily` — Napi Bitcoin-kibocsátás¶

4.12 `obm_liveliness_ratio_daily` — Napi liveliness arány¶

4.13 `obm_miner_revenue_btc_daily` — Napi bányászbevétel BTC-ben¶

4.14 `obm_raw_output_value_btc_daily` — Napi nyers output-érték BTC-ben¶

4.15 `obm_spent_output_count_daily` — Napi elköltött outputok száma¶

2. A 4.1-es metrika: `obm_block_count_daily` — napi blokkszám¶

2.2 Algoritmus és a `--height_margin` paraméter¶

3. A 4.2-es metrika: `obm_block_weight_wu_daily` — napi blokksúly weight unitban¶

4.1 A.2 — `obm_block_weight_wu_daily` (ismételt, referencia-formátumban)¶

4.2 A.3 — `obm_cdd_age_band_btcxdays_daily` (részleges, a 4. rész végén)¶

1. A.3 — `obm_cdd_age_band_btcxdays_daily`: napi CDD korosztály-sávok szerint¶

2. A.4 — `obm_cdd_btcxdays_daily`: napi összesített Bitcoin Days Destroyed¶

A.5 folytatása — `obm_cdd_per_supply_days_daily` (lezáró rész)¶

A.6 — `obm_difficulty_eod_daily`: nap végi bányászati nehézség¶

A.7 — `obm_dormancy_days_daily`: napi dormancy (definíció nyitánya)¶

1. A.8 `obm_est7d_hashrate_ehs_daily` – a 7 napos hálózati hashrate-becslés közérthetően¶

2. A.9 `obm_fee_share_revenue_ratio_daily` – a díjak aránya a bányász-bevételben¶