Compact Block Relay Isa sa paraan upang mapabilis ang pagkalat ng block sa network ay ang paggamit ng compact block relay, na nasasaad sa BIP-0152. Ang bawat node kasi ay may mempool kung saan malaki ang tsansa na maraming pinagkaparehas sa ibang node. Kaya, ang miner ay maaaring magpasa lamang ng partial na block data. Ang makakatanggap na node ay maaaring makuha ang kabuuan ng block dahil sa naiipon nitong mempool transactions. At gayun din ang node na ito, kahit compact block lang muna ang ipasa sa iba. Hihingin nalang ang kulang kung sakaling hindi pa kayang buuin ang block mula sa sariling mempool transactions.

Compact Block Relay – Bitcoin ba kamo?

Fork sa Block Chain Sa mga bagong blocks na idinudugtong, hindi pa agad tiyak ang ayos blockchain. Ito ay dahil sa distribusyon ng mga nodes at miners ng network sa iba’t ibang panig ng mundo. May mga miners na makakabuo ng nais na block sa halos parehas na oras. Sa ganitong sitwasyon, may 2 o higit pang blocks na parehas ng block height. At habang kumakalat palang ang impormasyon sa mga nodes, nagkakaroon ng magkaibang kopya ng blockchain. Ang pangyayaring ito ay tinatawag na fork. Ituloy ang paksa:

Fork sa block chain – Bitcoin ba kamo?

Pagdudugtong ng Blocks Ang block hash ay double-SHA256 ng block header, at ginagamit na pamberipika ng mga nodes sa isang block. Ang isang node ay maaaring magtago o mag-index ng mga block hash sa disk nito, para madaling mahanap ang isang block. Sa blockchain kasi, ang block hash ay maitatago roon kapag naisama na sa block header ng susunod na block bilang: previous block hash. Ang previous block hash ang sangkap ng block header na syang nagkokonekta sa mga blocks para makabuo ng chain. Bawat block ay may bahid ng nakaraang block. Kapag susundan ang bawat bahid pabalik, matutunton ang pinakauna o genesis block (block 0). Ilustrasyon:

Pagdudugtong ng Blocks – Bitcoin ba kamo?

Sa mga bagong blocks na idinudugtong, hindi pa agad tiyak ang ayos blockchain. Pag-usapan natin iyan sa susunod.

Istraktura ng Block Ang data ng buong block ay nakaayos na: - Block size - Block header - Transaction counter - kung ilang transaksyon ang naisama - Transactions

Istraktura ng Block – Bitcoin ba kamo?

Identipikasyon ng Block: Block Header Ang nakuhang Merkle root, ay kasama sa mga data na inilalagay sa Block Header. Ito ang metadata na nagsasalarawan ng laman ng block. Ang mga laman ng block header ay: Version Previous block hash - double-SHA256 ng nakaraang block header Merkle root Timestamp - Unix epoch time nung nabuo ang block Target - tumutukoy sa proof-of-work target nung ginawa ang block na ito Nonce - “number used only once” - pinkahuling arbitraryong data na nagresulta sa pagkamit ng proof-of-work target Laman ng block header:

Identipikasyon ng Block: Block Header – Bitcoin ba kamo?

Kaya ang mga lightweight/SPV clients ng Bitcoin network tulad ng wallets ay nakakakumpirma ng transaksyon na kailangan nitong ipaalam sa user. Malalaman nito gamit ang block headers kung pinakamahabang chain ang nakuha nitong impormasyon. Kapag kumbinsido na ito, kailangan lang alamin ng SPV client ang Merkle branch ng transaksyon para makumpirma na naisama ito sa isang block. Kaya nakakatulong rin na ipinapakita ng wallet software sa user kapag nakailang kumpirmasyon na ang transaksyon.

Bili lang ng kayang isantabi ng 4 na taon, at wala kang alalahanin. #Bitcoin

Nagiging posible ang pruned node at SPV client dahil sa pagkakakuha ng halaga ng block header. Ang karamihan sa laman ng block header ay: hash ng nakaraang block header at hash ng mga transaksyon sa loob ng block, na isang Merkle Root. Ibig sabihin, bumubuo ng Merkle Tree mula sa mga transaksyon sa loob ng block. Ano ang Merkle Tree? Basahin sa bagong post na ito:

Merkle Tree – Bitcoin ba kamo?

#BahaSaLuneta #TrillionPesoMarch #KurakotManagot Filipinos: Make noise against corruption, stack Bitcoin in silence.

Paunang Salita sa Blockchain Sa mga susunod na posts, hihimayin natin ang pagbuo ng blockchain, mula sa loob ng isang block. Ito ay parte ng Kabanata 7 (

Kabanata 7: Ang mga Sangkap na Nagpapatibay sa Bitcoin Network – Bitcoin ba kamo?

kung gusto mo nang pag-aralan. Napag-usapan na natin sa Kabanata 5 (

Kabanata 5: Mekanismo ng Pakikipagtransaksyon sa Bitcoin – Bitcoin ba kamo?

ang pagbuo ng transaksyon; at ang mga bagong transaksyon ay napupunta muna sa mempool. Mula rito, ang mga miners ay pumipili ng isasamang mga transaksyon na ilalagay sa isang block base sa fees at prayoridad. Kaya hindi garantisado ng oras kung kailan ginawa ang transaksyon na makukumpirma ito agad, lalo na kung mababa lang ang fee na katumbas. Ang isang transaksyon ay makukumpirma kung: > Ito ay naisama ng isang miner sa block, at ang miner na ito ang nanalo sa proof-of-work. > Ang naturang block ay ang naipakalat sa mas maraming nodes, kaya ito ang madudugtungan ng mas maraming blocks sa susunod. At habang humahaba ang blockchain, mas tumataas ang seguridad na ang isang transaksyon sa mas malalim na block ay kumpirmado na. Bahala na ang mga miner na mag-ayos ng transaksyon, basta: > Pinakauna ang coinbase > Kung sakaling nasa parehas na block maisasama ang mga transaksyon na konektado, mauuna dapat ang parent transaction na panggagalingan ng UTXO na gagamiting input ng isang child transaction. > Ang isang UTXO ay isang beses lang pwede gamiting input ng transaksyon (bawal ang double spending) > Ipagkakasya sa loob ng block ang kayang ipagkasya nang hindi lalagpas sa 4Mb, kasama na ang iba pang kinakailangang parte. Paano inaayos ang mga transaksyon sa loob ng block? Pag-usapan natin iyan sa susunod.

The exposition of the corruption using flood control projects in the Philippines is yet another reason why we Bitcoin. They steal our time and energy through inflation and taxation.

Ang Solusyon ng Bitcoin sa Byzantine Generals Problem Naiangat ng Bitcoin ang limitasyon ng Byzantine Generals Problem sa pamamagitan ng 2 sangkap: Ang Blockchain at ang Proof-of-Work. Dahil sa mga sangkap na ito, kayang tumakbo ng tama ng network hanggat mahigit 50% ang nodes na tapat. Ito ang sa madaling sabi, bilang palatandaan ng konsepto. Sa mga susunod na mga posts, hihimayin natin ang Blockchain, tapos, Proof-of-Work. Pero maaari mo nang basahin ang mga konseptong isinulat sa Kabanata 7, ha?

Kabanata 7: Ang mga Sangkap na Nagpapatibay sa Bitcoin Network – Bitcoin ba kamo?

Byzantine Generals Problem Isa pang palaisipan sa mga distributed systems ay ang Byzantine Generals Problem. May mga hukbo na gustong umatake sa isang syudad. Sa senaryo na ito, 3 o higit pang hukbo ang dapat magkatugma-tugma sa oras ng pag-atake. Ang mensahe ay ipinagpapalagay na laging nakakarating. Subalit, ang hamon ay maaaring traydor ang ibang heneral. Malisyoso, “malicious” ang heneral na ganito. At tapat, “honest” ang matinong heneral. Ang dapat makamit ng hukbo sa ganitong sitwasyon ay magkasang-ayon ang mga honest na heneral. At kung ang pinunong heneral ay tapat, masusunod ng mga honest din na heneral ang kanyang utos. Tignan ang ilustrasyon at ipagpatuloy ang pagbabasa sa:

Byzantine Generals Problem – Bitcoin ba kamo?

Pagpapakalat ng Bagong Block Kapag nakabuo ng block na may tamang kondisyon ang miner, ipapasa na ito gamit ang alin sa mga sumusunod: > Unsolicited Block Push - ito ay lumang paraan kung saan magpapasa ng block na mensahe sa full nodes na konektado. Kumbaga, ito ay eager push na pagtsismis ng impormasyon. > Standard Block Relay - ito ay mas bagong paraan para sa miner na nagpapaalam ng matagumpay na block. Magpapadala muna ng inv na mensahe sa full node at SPV node na konektado ang miner, na naglalaman ng bagong block header. Na sasagutin naman ng: >>Getdata kung ang isang node ay gumagana pa rin bilang blocks-first. Kaya sasagot na ng block na mensahe ang miner. >>Sa mga headers-first na peers naman, getheaders ang isasagot, kung saan may ilang headers ng mga naunang blocks ang titignan para makumpirma ang bagong block header. Susundan ito ng getdata para makuha na ang block. Pero kung sa pananaw nito ay hindi kompirmado ang bagong block header, itatapon na nito ang buong block. Sa paraang ito, maiiwasan ang orphan block, o block na hindi nakikita ang parent block. >>Ang SPV na client ay sasagot ng getdata pero ang tinutukoy ay Merkle block. >Direct headers - ito ay mas bago pang paraan kumpara sa standard block relay na pwedeng gamitin ng miners at relay nodes para sa mga mas updated na software. Ang isang node na sumusunod dito ay nagpapadala ng “sendheaders” na mensahe sa inisyal na koneksyon. Kaya, twing may bagong block, header nito muna ang ipapadala ng miner. Tapos, ang full node ay hihingi ng data ng buong block, samantalang ang SPV client ay hihingi ng data ng Merkle block. >Compact Block Relay - ito ay mas bagong paraan pa uli ng pagpapakalat ng block, na naglalayong matipid ang bandwidth na gamit. Nakakatulong din ito na bumilis ang pasahan ng block. Ito ay ginagamit ang konsepto na ang mga transaksyon sa isang block ay malamang makikita rin sa kani-kaniyang mempool ng mga nodes. Kaya, sa halip na buong block ang ipadala, magpapadala ng compact block. Ang tatanggap na node ay dapat kayang buuin ang block base sa compact block. Ang node na pwedeng tumanggap ng compact block ay dapat magpadala muna ng “sendcmpct” na mensahe sa inisyal na koneksyon. Ang standard block relay at direct headers na paraan ng pagtsismis ng bagong block ay lazy push na stratehiya, diba? Ang compact block relay naman ay maaaring eager push at lazy push.

Mga klase ng Bitcoin network nodes Mainam na ang mga lumalahok na nodes ay may kopya ng buong blockchain. Subalit hindi lahat ay may badyet para sa pagpapanatili ng lumalaking disk space. Sa Bitcoin White Paper palang, nakini-kinita na ang pangangailangan ng mga nodes na magaan lang ang gamit na memorya. Narito ang iba-ibang klase ng nodes sa Bitcoin network. > Full nodes - ito ay mga nodes na dina-download ang buong block at ibeberipika ito bago ipasa sa iba. Ang nailarawan nating initial block download kanina ay tumutukoy sa pagbuo ng isang full node. Ang full node noon ay kaya magawa lahat ng sangkap ng Bitcoin, gaya ng pagpapanatili ng blockchain, pagmimina at wallet. Subalit ngayon, hindi na madali na isang device lang para sa lahat. May pagkakaiba na ngayon sa full node: > Archival full node - ito ay full node na merong kopya ng blockchain, pero hindi na nagmimina. > Pruned node - ito ay full node sa isang kahulugan dahil nagbeberipika ito ng buong block bago ipasa sa iba. Pero, hindi ito nagpapanatili ng kopya ng buong blockchain, sa halip, puputulin ito sa isang punto, depende sa kapasidad ng computer (halimbawa, 2 GB). Tutal, ang block header naman ay may marka ng nakaraang block. > Simplified Payment Verification (SPV) client - tinatawag ding isang lightweight client, ay dina-download lang ang block headers, at kukuha lang ng mga transaksyon sa full nodes kapag kailangan. Ganito ang mga wallet apps, na mahalaga lamang ang partikular na transaksyon para sa may-ari. Nagiging posible ang pruned node at SPV client dahil sa konsepto ng Merkle Tree na gamit para makuha ang hash na nagrerepresenta ng mga transaksyon sa loob ng isang block. Kaugnay rin sa Merkle Tree ang paggamit ng bloom filter ng mga SPV para magkaroon kahit papano ng privacy. Ipagpaliban natin para sa susunod na kabanata ang konseptong ito.

Initial Block Download Mula sa matagumpay na koneksyon, ang isang node ay mag-uupdate na ng kanyang impormasyon patungkol sa blockchain. Initial Block Download (IBD) ang tawag dito. Tutulungan ito ng peer na mas updated o sync node. Ang bagong saltang node ay mayroon lamang block 0 - ang genesis block na hard coded sa Bitcoin Core. Mag-uumpisa itong humingi ng block headers muna, gamit ang “getheaders” na mensahe. Ang sagot ng sync node ay headers na mensahe na maaaring maglaman ng hanggang 2000 block headers. Ang IBD node ay magsisimula nang patunayan ang data ng mga headers na natanggap. Tapos, magkahilerang gagawin nito na: > Mag download ng karagdagang headers - tig 2000 libong headers ang matatanggap sa bawat sagot ng sync node hanggang sa ang huli ay mas konti na. Bilang proteksyon, magpapadala ang IBD node sa lahat ng outbound peers nito ng getheaders na mensahe. Ikukumpara nito ang matatanggap na headers para matukoy kung ano ang pinakamahusay na chain. > Magdownload ng blocks - Ito ay gagawin sa pamamagitan ng “getdata” na mensahe, na pwedeng ipadala sa 8 full relay outgoing nodes. Hanggang 16 na blocks ang maaaring hilingin kada ougoing node, o 128 na magkakasabay na hiling ang magaganap. Ang sync node ay sasagot ng block na mensahe na naglalaman na nga ng 1 block. Ang IBD node ay nagpapatunay (o validate) na ng bawat block na natatanggap. Sunud-sunod dapat ang pag validate ng blocks. Kaya, kapag may inaabangang block na hindi pa dumarating, at naunahan na ng mas bagong blocks galing sa ibang node, maghihintay ng 2 segundo o higit pa ang Bitcoin Core. Kapag wala pa rin, puputulin na ang koneksyon sa node na hindi agad nakapadala, at maghahanap ng ibang node na pwedeng magbigay ng kailangang block. Ang moving download window na ito ay may taas na 1024 blocks. Tandaan lang na ang getdata ay may iba-ibang identifiers ng data na hinihingi, hindi lang ito para sa paghingi ng block. Sa mga naunang bersyon ng Bitcoin Core, blocks-first ang operasyon. “Getblocks” ang mensahe na ipapadala ng IBD node, na sasagutin naman ng “inv” (inventory) na mensahe ng sync node. Ang inv ay mensahe na maaring magbigay ng block headers o transaksyon. Maaaring maglaman ng hanggang 500 na block headers ang isasagot na inv ng sync node sa IBD node. Tapos, hihiling na ito ng getdata message na tumutukoy sa mga blocks, na pwedeng 128 magkakasabay, pero sa iisang sync node lamang. Isa-isa nang magpapadala ng buong block. Makikita mo ang kalamangan ng bagong implementasyon na getheaders, na tinalakay kanina. Headers-first ang operasyon ng mga peers na mas bago ang software. Kapag ang IBD node ay nai-sync na sa dulo ng blockchain, maaari na itong tumanggap ng bagong blocks mula sa miner nodes o kung sinumang naunang nakaalam na node. --------------- Ang post na ito ay kasama sa Kabanata 6 ng bitcoinbakamo website, na ukol sa peer-to-peer network.

Kabanata 6: Ang Pagpili ng Peer-to-Peer na Network – Bitcoin ba kamo?

Pag-aayos ng mga address (ng Bitcoin nodes) Paano inaayos ang bultong (IP) address na natatanggap ng isang node? Ang protocol ay gumagamit ng stochastic address manager, kung saan random ang pagposisyon at pagpili ng mga kokonektahang IP address sa memorya ng kompyuter. Ang buong talaan ng address ay inilalagay sa peers.dat kada 5 minuto. Ang address manager na ito ay layunin ding maiwasang mapuno ng masasamang nodes. Ang mga IP addresses ay inilalagay sa mga balde (buckets) na hanggang 64 ang kayang itago. > “new” - balde sa memorya na may mga address na hindi pa nakokonektahan > “tried” - balde sa memorya na may mga address na subok na ang koneksyon Mayroong 1024 na baldeng new, kung saan twing namimili ang node, 64 na balde ang kukunin nang random, bago pa piliin ang baldeng paglalagyan o susubukang hanapan ng ibang node na kokonektahan. Samantala, may 256 tried na mga balde, kung saan twing namimili ang node, 8 balde ang kukunin nang random, bago pa piliin ang baldeng paglalagyan ng ibang node, o papanatilihan ng koneksyon. Ang isang new address ay maaaring mapabilang sa hanggang 8 balde, samantalang 1 beses lang pwede makita sa tried. Cryptographic hashing ang basehan ng pagpili ng balde. Ipagpatuloy ang pagbasa at tignan ang ilustrasyon sa:

Pag-aayos ng mga address (ng Bitcoin nodes) – Bitcoin ba kamo?

I have not encountered a Bitcoin person in my day-to-day world. It's like having a double life. There's this one thing that keeps me busy, these small wins, progress that makes me happy and filled, and yet almost don't talk about it. Nasaan ang mga Bitcoiners sa Pilipinas?

Kabanata 7: Ang mga Sangkap na Nagpapatibay sa Bitcoin Network Maligayang Araw ng Kalayaan Pilipinas! Sakto, may bagong kabanata na sa Bitcoin educational website. Ipagtibay ang prinsipyo ng kalayaan, na isinusulong ng kilusang Bitcoin. Basahin ang Kabanata 7:

Kabanata 7: Ang mga Sangkap na Nagpapatibay sa Bitcoin Network – Bitcoin ba kamo?

Inisyal na Pagkonekta sa Bitcoin Network Puntahan na natin ang protocol ng Bitcoin network. Kagaya ng nabanggit sa peer sampling service, may paraan sa pagkonekta ng makaunang beses sa ibang nodes. Mula roon, makakaipon ng maraming addresses base sa matatanggap mula sa ibang nodes; subalit may nakatakdang maximum na aktibong koneksyon. Ang Bitcoin ay umaasa sa TCP para sa maasahang pagpasa ng mensahe. Sa mga susunod na posts sa paksang ito, buurin natin ang mga batayan ng network galing sa source code mismo ng Bitcoin, partikular na ang napapaloob sa net.h, net.cpp, addrman.h at addrman.cpp. Inisyal na pagkonekta Ang bagong node na sumasali sa network ay kokonekta sa DNS seeds. Ang mga DNS seeds ay kasama sa code ng Bitcoin Core. May mga DNS seeds na matagal nang naka-hard code sa Bitcoin Core, pero maaari itong mabagu-bago ng komunidad sa kada update ng version. Syempre, hindi naman pwedeng asahan na tatagal higit pa sa buhay ng mga may-ari ng DNS seeds ang mga iyon. Kapag ang isang node ay nakakonekta na dati sa network, uunahin muna nitong humanap ng koneksyon sa mga address na nasa memorya. Kaya, kapag ang node ay may < 1000 node address sa memorya, may 11 segundong delay bago kumonekta sa DNS seeds. Ang <1000 nodes ay kinokonsiderang “few” peers. Kapag 1000 pataas, ito ay “many” peers. Sa lagay na iyon, 5 minuto naman ang delay bago subukang kumonekta sa DNS seeds. Kapag few ang peers, 3 DNS seeds ang pagtatanungan ng isang node. Isa pang paraan kung sakaling walang makonektahang node mula sa DNS seeds matapos ang 60 segundo, ay ang paghahanap sa fixed seed nodes. Ito ay mga hard coded na mga identifier ng nodes na aktibo nung panahong nilabas ang partikular na bersyon ng Bitcoin Core. Ang pagkonekta ng isang node sa peer ay nag-uumpisa sa pagpadala ng “version” na mensahe. Ang nakatanggap ng ganitong mensahe ay dapat magpadala rin ng version. Matapos iyon, magpapadala na sa isa’t isa ng “verack” na mensahe. Ibig sabihin nun ay acknowledgment o pagkilala sa bersyon ng node na nagpadala. Ito na ang hudyat ng matagumpay na koneksyon ng 2 nodes. Unang pagkonekta (initial handshake) ng mga peers Ang unang hihingin ng isang node ay address ng iba pang peers. Magpapadala ito ng “getaddr” (get address) request. Ang makakatanggap na node ay reresponde ng “addr” (address) o “addrv2” (address version 2). Naglalaman ito ng bilang ng IP addresses at ng listahan nito. Ang addrv2 ay may ibang encoding ng mga network address at sumusuporta sa mas mahaba sa 16 bytes. Ang addr o addrv2 na mensahe ay hanggang 1,000 addresses ang pwedeng ipadala. Samantala, ang isang node ay maaaring tumanggap ng hanggang 5,000 IP addresses. Ang pagpadala ng bultuhang mga address ay gagawin kada 15 minuto. At ang peer timeout ay 60 segundo, ibig sabihin, ipagpapalagay na may problema sa koneksyon kaya ititigil muna ang pagpapadala. Kapag umabot sa 20 minuto na walang sagot, tuluyan nang magdidiskonekta sa node. Ang 20 minuto ang hangganan din ng paghihintay sa ping at pong na sagutan ng nodes, bago putulin ang koneksyon. Sa paglaon, ang isang node na nananatiling konektado ay maaaring magpadala ng addr o addrv2 ng kusa sa mapipiling random na koneksyon. Ibig sabihin, hindi lang sagot sa getaddr request ang addr at addrv2. Basta, ang bawat protocol na mensahe ay hindi lalagpas sa 4MB. Ang default na dami ng koneksyon sa mga peers ay hanggang 125. Maaari itong baguhin ng sadya, pero hindi nirerekomenda. 8 ang maximum na outgoing nodes na may “full relay,” kaya ang natitirang 117 ang hangganan sa incoming nodes. Ang minimum na outbound connections ay 2, kaya hanggat hindi ito naaabot, patuloy lang ang paghahanap ng bagong saltang node sa mga seed nodes. Ibalik lang natin sa pangkalahatang konsepto ng gossip protocol: ang aktibong koneksyon ng isang node (125 man o hindi) ang kanyang aktibong partial view. Samantalang ang pwedeng umabot sa halos 5000 address sa memorya nito ang passive partial view ng node. May nagawang paraan ang mga developers para maprotektahan ang node mula sa partition attack. Ang partition attack ay kung saan ang isang node ay ihihiwalay ng umaatake sa tamang impormasyon ng network. Pupunuin ang memorya ng node ng mga address ng malisyosong nodes. Kaya pag ang biktima ay nag-restart, ang kokonektahan nito ay puro masasamang nodes, na magdudulot sa pagkakahiwalay sa tamang network. Paano na? Bukod sa 8 full relay na outgoing nodes, may 2 block-relay-only connection na pinapanatili. Ang koneksyong ito sa 2 nodes ay hindi ginagamit sa pagpasa ng IP address at mga transaksyon. Dahil dito, ang koneksyon ay mahirap matunton ng mga masasamang loob. Ang block-relay-only connections ay ginagamit ding anchor connections, o mga uunahing koneksyon matapos mag restart. Kaya hanggat may honest o tapat na node na konektado sayo, hindi mahihiwalay ang iyong node sa tamang impormasyon ng network. Ang block-relay-only connection loop ay pinapatakbo kada 5 minuto. Mayroon ding ginagawang ASmap health check kada 24 oras. Ang AS o Autonomous System ay malaking network o grupo ng networks, na kontrolado ng isang administrasyon, mapa pribado, publiko o gobyerno. Ang layunin ng ASmap health check ay maiwasang galing lang sa 1 AS ang mga peers na kinokonektahan ng isang node. Kaugnay dito, sinusubukan ding kumonekta sa ibang peer sa ibang network ang node, kada 5 minuto. Mayroon ding feeler connection na sinusubukan kada 2 minuto. Ito ay kaugnay na sa pag-aayos ng mga IP address sa loob ng memorya ng node.

Peer Sampling Service Ang paghahanapan ng mga nodes at paggawa ng bawat node ng listahan ng peers sa network ay maibabalot sa peer sampling service. Sa malaking network, hindi praktikal at kailangan malaman lahat ng iba pang kasamang nodes, kundi subset lamang. Simple lang ang implementasyon nito. Pwedeng dalawang paraan lang ang gamitin: init() - Pansimula o initialize ng serbisyo kung hindi pa ito nagagawa ng isang node. getPeer() - Ang pagbalik ng peer address o node identifier basta may iba pang kasapi sa network. Partial View Ito ay ang pangkat ng mga pagkakakilanlan ng mga nodes, o node identifiers, na ibibigay sa bawat isang node. Tipikal na node identifier ay ang tuple ng (ip : port). May nakatakdang bilang ng kasapi sa listahang ito. Ang bilang na nakukuha ng bawat node ay pare-parehas, subalit magkakaiba ang nilalaman. Ang pagkakaayos ng node identifier ay nakabase sa hop count, mula sa pinakamababa, pataas. Ang hop count ay ang bilang ng pagtalon ng mensahe mula sa pinanggagalingang node. Kaya mayroong mga magkakaparehas ang hop count sa isang partial view. Bakit? Balikan ang ilustrasyon sa pagkalat ng mensahe sa Gossip protocol. Ang partial view ay overlay network (nanaman), sa pananaw ng node. May 2 stratehiya para magpanatili ng partial views: > Reactive - ina-update lamang ang partial view kapag mayroong pangyayari na nakakaapekto sa overlay. Halimbawa, kapag may bagong node na sumali o pag may umalis sa network. > Cyclic - Dito naman, ang partial view ay ina-update kada takdang oras, kung saan nagkakaroon ng pagpapalit ng impormasyon ng mga magkakapitbahay. Kapag stable ang network, ang partial view ay hindi nagbabago sa reactive na stratehiya. Samantalang sa cyclic na stratehiya, nagbabagu-bago ang partial view kahit stable ang network. Mga katangian ng Partial View Ang mga sumusunod ay maaaring magamit para sukatin ang kalidad ng partial view. > Connectivity - Syempre, dapat konektado ang mga nodes sa partial view. Kahit isang koneksyon lang ng bawat node sa iba ang kailangan para masabing walang nahiwalay na node. > Degree Distribution - sa isang graph na hindi mahalaga ang direksyon (undirected), ang degree ay ang dami ng edges. Pero sa usapan ng partial views, directed ang graph, ang direksyon palabas at papasok ng isang node ay tinuturing na magkaiba. Mayroong in-degree at out-degree ang node. Ang in-degree ng isang node, n, ay ang dami ng nodes na mayroong identifier ni n sa kanilang partial view. Dito masusukat kung gaaano kadali maabot ang node, ang probability na matatanggap nito ang mensahe at ang maximum na redundant na mensahe. Ang out-degree naman ng n ay ang dami ng nodes sa sarili nyang partial view. Dito masusukat kung gaano kahalaga ang node na iyon para mapanatili ang overlay. >Average Path Length - Ito ay average ng lahat ng pinakamaiksing paths sa pagitan ng mga pares ng nodes sa partial view. Mas mainan na mababa ito dahil sa relasyon nito sa tagal ng pagpasa ng mensahe sa lahat ng nodes. > Clustering Coefficient - sa isang node, ang clustering coefficient ay makukuha sa pagbilang ng dami ng edges sa pagitan ng mga kapitbahay nito, at idi-divide sa maximum na posibleng edges sa mga naturang kapitbahay. Ito ay may value na 0 hanggang 1. Ang clustering coefficient ng graph ng partial view ay ang average ng lahat ng clustering coefficients. Hindi natin gusto na masyadong konektado ang mga kapitbahay na nodes sa isa’t isa. Bakit? Kapag mataas kasi ang clustering coefficient, mas mataas ang redundancy ng mga mensahe. Kapag mataas din ang clustering coefficient, sa isang panig ng graph, mas madali itong mahiwalay, dahil posibleng umiikot lang sa isang cluster ng mga nodes ang mensahe, sa halip na maabot ang mas malayong nodes. > Accuracy - makukuha naman ito kapag binilang ang mga kapitbahay ng isang node na hindi pumalya (not failed) at idi-divide sa pangkalahatang dami ng kapitbahay. Ang accuracy ng graph ay ang average ng accuracy ng lahat ng correct nodes. Kapag mababa ang accuracy, maraming palyadong node ang mapipiling gossip target, na makakasira ng proseso. Kailangang taasan ang fanout kung ganun. Ngayon at napag-usapan na natin ang mga basic na konsepto ng gossip protocol, pwede na natin tignan ang pangkalahatang ideya ng Bitcoin P2P Network.