Det er behov for å styrke Bitcoin-økosystemet for folk hvis eneste databehandlingsenhet er en smarttelefon og som bor der mobil internettilgang dyrt, treg, upålitelig eller sensurert. Senegalesisk Bitcoin-utvikler Fodé Diop har poengtert at mange deler av verden er “bare mobile”, ikke bare “mobile først.”

Mobile lommebokapper som tillater brukere å beholde kontrollen over sine private nøkler for signering av transaksjoner, men ikke fungerer som fulle Bitcoin-noder, blir vanligvis referert til som “lette” klienter. Lette klienter avveier privatliv og tillitsminimering for å redusere minnet, vedvarende lagring og kommunikasjonsbåndbredde de trenger. Denne artikkelen fokuserer på hvordan du minimerer båndbredden som brukes av lette klientlommebøker som kjører på en mobiltelefon.

Lette klienter har mye lavere krav til båndbredde enn fulle noder fordi de ikke laster ned hele Bitcoin blockchain. I stedet bruker lette kunder en eller annen form for “enkel betalingsbekreftelse” (SPV) for å bekrefte transaksjoner. I stedet for å bekrefte gyldigheten av alle transaksjoner som ble lagt til Bitcoins hovedbok siden opprinnelsesblokken, bekrefter en SPV-lommebok bare at de spesifikke transaksjonene som er knyttet til lommeboken, ble lagt til en blokk, og at denne blokken er en del av kjeden av blokker med de fleste jobber med å sikre det. En SPV-lommebok antar, men verifiserer ikke, at de fleste ærlige gruvearbeidere bare vil bidra til å utvide blockchain bygget fra transaksjoner som følger konsensusreglene til Bitcoin.

I denne tekniske diskusjonen undersøker vi kravene til lett klientbåndbredde og de subtile sikkerhets- og personvernkompromissene som finnes for lette klienter designet for å operere med begrenset internettforbindelse..

Lette klientavveier

Den sikreste løsningen for brukere er å kjøre og bekrefte betalinger med sin egen Bitcoin full node. Imidlertid er det en viss sammenheng mellom land der folk er avhengige av relativt dyre eller upålitelige målte internettforbindelser – hvor Bitcoins sensurmotstand er mest nødvendig – og de der det er lite sannsynlig at folk har de tekniske eller økonomiske ressursene til å kjøre en full Bitcoin-node. I mange deler av verden vil Bitcoin-brukere ikke ha noe annet alternativ enn å bruke online-varetekt bitcoin-lommebøker på grunn av båndbreddekostnader. Ved hjelp av lav båndbredde kan den eneste mobile klienten fungere som et mellomtrinn mot å til slutt kjøre en dedikert full node.

En fordel med utveksling av bitcoin-utvekslinger er at risikoen for brukernes personvern og midler er veldig lik den fra andre pålitelige betalingsleverandører som PayPal og Western Union. Lette klientlommebøker krever en mer nyansert forståelse av sikkerhets- og personvernutvekslingene som kommer fra bruk av anonyme offentlige noder og komplekse peer-to-peer-protokoller..

Det er også et argument for at lette klienter generelt kan være skadelige for Bitcoin-nettverket. Ettersom flere kjører lette klienter, øker det båndbredden og beregningskravene til de offentlige fullnodene som betjener dem. Dette kan føre til en reduksjon i antall offentlige fullnoder, spesielt de som serverer informasjon til lette klienter. Hvis alle lette klienter stoler på et lite sett med offentlige fullnoder, kan deres sikkerhet og personvern kompromitteres hvis de fulle nodene konspirerer mot dem.

Vi tror at påvirkningen på Bitcoin-nettverket kan minimeres hvis lette kunder også utveksler data direkte med andre lette kunder. Spredningen av lette klienter vil til slutt føre til at flere brukere kjører hele noder, spesielt i utviklingsland der tilkobling er dyrere og personlige datamaskiner ikke er i utstrakt bruk.

Nettverkslag

Lette klienter må støtte mange av de samme nettverksprotokollagene som Bitcoin-fullnoder. Begge begynner med å kommunisere direkte med et første sett med Bitcoin-noder. Fra disse innledende nodene bytter de adressene til andre noder som er en del av Bitcoin-nettverket.

Både lette klienter og fulle noder må også lære av sine jevnaldrende om beviset på arbeidet som sikrer og kobler alternative blockchain-tips tilbake til genese-blokken. Hele noder skiller seg hovedsakelig fra lette klienter i hvordan de deler informasjon om transaksjoner. Hele noder utveksler informasjon om transaksjoner i blokker og validerer uavhengig av at nye blokker følger konsensusreglene til Bitcoin. Lette klienter bekrefter bare at spesifikke transaksjoner er til stede i blokker bekreftet av fulle noder.

Tilkobling

I motsetning til kablet internettforbindelse med fast kostnad som vanligvis brukes til fulle noder, bruker mobiltelefoner målte internettforbindelser der overføring av store datamengder kan være kostbart. Mobiltelefoner går også tom for batterier, som blir brukt opp raskere når du overfører data. De kan heller ikke dra direkte nytte av kringkastingsdatafeeder som krever faste parabolantenner eller store radioantenner.

Mobile enheter har noen fordeler og fortrolighetsfordeler i forhold til noder med fast strøm og dataforbindelser. De kan operere utenfor nettet eller under strømbrudd, og i noen områder kan de kjøpe forhåndsbetalte internettabonnementer anonymt. Mobilenheter kan også motstå personvern og sensur ved å koble til forskjellige lokale jevnaldrende via ad-hoc-nettverk når de beveger seg rundt.

Lette klienter laget for mobiltelefoner bør tillate brukere å konfigurere hvor mye mobil båndbredde de skal bruke, og være klar over når datatildelingene fornyes eller snart skal utløpe. Alternative ikke-målte lokale tilkoblinger, som et WiFi-hotspot, bør brukes opportunistisk når det er tilgjengelig for båndbreddekrevende oppgaver som å laste ned blokker for å bevare målt båndbredde.

Kolleger

Både fulle noder og lette klienter er avhengige av en robust peer discovery prosess for å sikre at de kobler seg til et mangfoldig sett med ærlige node-noder. Bitcoin-noder kobles opprinnelig til forhåndsinnstilte frø-noder, men må alltid oppdage nye jevnaldrende for å holde kontakten med det “ærlige” Bitcoin-nettverket. Fullstendig node-programvaren Bitcoin Core har utviklet robuste heuristikker for å redusere formørkelsesangrep fra ondsinnede jevnaldrende og koble fra noder som ikke oppfører seg. Fordi peer-adresser bare er 30 byte hver, kan lette klienter bruke samme heuristikk som fullnoder for ofte å spørre flere kollegaer om nye adresser..

Den beste måten å forhindre å bli isolert fra det ærlige Bitcoin-nettverket, er å opprettholde et stort, vedvarende og mangfoldig sett med kolleger. For å opprettholde batterilevetiden, bør lett klientprogramvare være forsiktig med å ikke vekke en mobiltelefon for ofte for å sladre om kollegeadresser eller utføre andre oppgaver. Lette klienter bør synkronisere med sine jevnaldrende med samme faste tidsintervall for å minimere både batteribruk og peerfrakobling.

Blokker topptekster

Både full node og lett klientsikkerhet avhenger av muligheten til å oppdage kjedespissen på blockchain med mest arbeid for å sikre den. Denne prosessen starter med å spørre alle jevnaldrende om det siste blokk overskrifter de vet om for blockchain. En node kan trenge å spørre sine jevnaldrende på forskjellige punkter for å finne poenget når de først er uenige om hvilken kjedegaffel som er riktig. Lette klienter bør også validere bevis på arbeid, tidsstempel, Merkle-rot og forrige toppblokk-hash for hver blokkoverskrift de mottar, og forby jevnaldrende som serverer ugyldige blokkoverskrifter. Fullstendige noder validerer også overskrifter før nedlasting av blokker for å forhindre denial-of-service (DoS) -angrep.

Når den kanoniske kjedespissen er bestemt, kan en lett klient synkronisere blokkoverskrifter tilbake for å sikre at kjedespissen kobles til Bitcoin-genese-blokken – omtrent 50 MB data. Noen lette klienter som bruker langsomme eller målte tilkoblinger, kan i utgangspunktet bare laste blokkoverskrifter tilbake til et kontrollpunkt i stedet for genese-blokken. Fullstendige noder skal alltid synkronisere alle blokkoverskrifter. Brukere bør advares om risikoen for å akseptere betalinger til hele topptekstkjeden er sjekket. Lette klienter og fulle noder må fortsette å laste ned 80 byteblokkoverskrifter fra hver kollega for å holde seg synkronisert med blockchain når den vokser, og også spørre flere kollegaer for blokkoverskrifter for å sikre at de alltid følger den nåværende beste blokktekstkjeden.

Moderne lette klientlommebøker kan oppdage når en transaksjon de sporer vises i en blokk med BIP-157 blokker filtre. I likhet med blokkoverskrifter spør lette kunder også sine jevnaldrende for å bestemme den nåværende spissen av en filterhodekjede. BIP-157 lette klienter laster ned 32 byte-blokkfilteroverskrifter per blokk for å forbli synkronisert med blokkfilteroverskriftskjeden. I tilfelle uenighet mellom jevnaldrende om riktig filterhodekjede, kan lette klienter laste ned den tilsvarende blokken for å bestemme hvilken jevnaldrende som følger den rette kjeden. Lette klienter bør ignorere blokkeringsfilterkjeder som inkluderer ugyldige overskrifter og svartelister som viser ugyldige blokkerings- eller filteroverskrifter.

Blokkeringsfiltre gir større personvern enn utfaset BIP-37 blomstre filtersystem fordi lette klienter ikke lekker til en full node hvilke transaksjoner de er interessert i. Blokkfilter skalerer også bedre enn blomstringsfiltre. Fordi det bare genereres ett blokkfilter per blokk, trenger en full node bare en konstant mengde beregning for å betjene flere lette klientfeller. Lette klienter selv kan også hjelpe reléblokkfiltre og sladderblokkfilteroverskrifter for å øke antall lette klientmedlemmer hver full node støtter.

En lett klient krever i det minste blokkeringsfiltrene for blokker som kan inneholde relevante transaksjoner. Filtre er omtrent 15 kB per blokk, så for en transaksjon som tar seks blokker (omtrent en time) å bekrefte, vil en lett klient trenge å laste ned 90 kB filterdata for å få en indikasjon på hvilken blokkering transaksjonen vises i. I tilfelle av en protokoll fra andre lag som Lyn-nettverk, perioden for å se etter en transaksjon vil være åpen med mindre Vakttårn blir brukt. Vakttårnene er spesielt nyttige for lette kunder på mobile enheter, både fordi de sannsynligvis vil være frakoblet i lange perioder og fordi de er begrenset med båndbredde.

Transaksjoner

Blokker bare full node

For å redusere båndbreddeforbruket kan full noder konfigureres til å bruke bare blokkeringsmodus for å laste ned fulle blokkeringer, men ikke sladre om transaksjoner. Dette er en trygg og privat måte å bekrefte transaksjoner på og krever ikke blokkeringsfiltre fordi hver blokk er lastet ned. En mobil klient som fungerer som en beskjæres blokkerende fullnode vil kreve opptil 2 GB nedlastingsbåndbredde per uke. En mobil klient med raskt og billig eller ikke-målt internett kan operere i denne modusen for å oppnå sikkerhets- og personvernfordelene ved å kjøre en full node, men fremdeles støtter lett klientmodus når båndbredde måles eller batteristrøm er begrenset. Fleksibiliteten for en mobil lettklient til opportunistisk å fungere som en blokk som bare er fullnode, kan bidra til å øke antall fulle noder i land der bruk av PC er mindre vanlig. Mobile blokker bare fullnoder kan også betjene blokkeringsfiltre for lette klienter uten å øke deres egen båndbreddes bruk betydelig.

Blokker Filter Light Client

Det nye BIP-157 blokkfiltersystemet lastes ned strippet blokker på opptil 1 MB bare når en sporet transaksjon blir oppdaget i kjeden av nedlastede blokkfiltre. Dette er en stor forbedring i forhold til 2 GB per uke med båndbredde som er nødvendig for å se etter transaksjoner med en eneste Bitcoin-full node. Nedlastede blokker kan brukes til å validere blokkeringsfiltre, ugyldiggjøre blokkeringsfilterkjeder og koble fra jevnaldrende som deler ugyldige filtre. Dette skaper en måte for lette klienter å forhindre ugyldige filterkjeder i å forplante seg, og gjør det mulig for lette klienter å dele filterinformasjon med hverandre og redusere belastningen på fulle noder. Lette klienter kan spørre hele settet med fulle noder for nylige blokker, ikke bare fulle noder som betjener blokkeringsfiltre. Dette forhindrer lekkasje av informasjon om transaksjonene en lett klient er interessert i og sprer belastningen blant et større sett med fulle noder.

Lette klienter som bruker BIP-157-blokkeringsfiltre, bekrefter ikke uavhengig at alle transaksjoner i en blokk overholder Bitcoins konsensusregler, men antar i stedet at kjeden som er bekreftet av mest hash-kraft, følger de riktige reglene. Disse nodene kan lures til å følge et flertall av gruvearbeidere som samarbeider om å vedta forskjellige utgiftsregler. I en situasjon som SegWit2x omstridt hard gaffel, kunne en lett klientbruker ha blitt villedet til å akseptere en ugyldig betaling fra en gaffel i Bitcoin blockchain. Klientbrukere med lav båndbredde er også mer utsatt for en rekke formørkelsesangrep som er lettere å forsøke forsiktig enn en gruvearbeidet hard gaffel. Brukere av andre lag protokoller som Lightning Network er også potensielt sårbare for lave kostnader tidsutvidelsesangrep.

Electrum Light Client

En annen populær løsning for lette enheter er Electrum klient-server-protokollen. I stedet for å laste ned blokkeringsfiltre og blokkeringer fra fulle noder for å bekrefte transaksjoner, an Electrum lett klientlommebok forespørsel om liten Merkle bevis for spesifikke transaksjoner (referert til av en unik transaksjons-ID) direkte fra en eller flere servere som kjører Electrum-protokollen. Fordi Electrum-servere kan logge de nøyaktige transaksjonene som hver lette klient ber om, er det viktig at klienter anonymiserer forespørslene sine ved hjelp av en Tor løk service eller lignende tjenester. Det er mulig at mange av de nåværende offentlige Electrum-serverne drives av private kjedeovervåkingsfirmaer med det formål å samle inn data for å deanonymisere Bitcoin-transaksjoner. En ytterligere risiko for å stole på Electrum-servermodellen er at serveroperatører ondsinnet kan holde tilbake (sensur) som gir bevis for bestemte transaksjoner, noe som er vanskeligere å gjøre i henhold til BIP-157-modellen..

Mens det er mange færre offentlige Electrum-servere enn Bitcoin-fullnoder, serverer for tiden svært få fulle noder blokkfiltre til lette klienter. Dette forventes å endre seg ettersom BIP-157-blokkfilterstøtte nå har vært slått sammen inn i Bitcoin Core-programvaren.

En Electrum-basert lettklient vil kreve enda mindre båndbredde enn en blokkfilterbasert lettklient fordi den ikke trenger å laste ned blokkfilterhoder, blokkfilter eller strippede fulle blokker for å bekrefte transaksjoner. I stedet trenger Electrum-klienter bare be om et Merkle-bevis på ca. 400 B for å bekrefte hver transaksjon.

Sammendrag

Tabellen nedenfor oppsummerer hvor mye avmålte data som vil bli brukt av en blokk med bare full node, en blokkfilterbasert lysklient og en Electrum-basert lysklient. Som du kan se i sammendraget, bruker en hvilken som helst type lettklient dramatisk mindre båndbredde per uke enn til og med en minimal, fullstendig node..

	Datastørrelse	Jevnaldrende spurte	Returnerte verdier	Blokker bare full node	Blokker Filter Light Client	Electrum Light Client
Peer-adresser	30 B	8	1000	234 kB	234 kB	234 kB
Blokkoverskrifter for gjeldende kjedespiss	80 B	8	1	640 B.	640 B.	640 B.
Filteroverskrifter for filterkjedespiss	32 B	8	1	–	256 B	–
Block Headers tilbake til Genesis Block	80 B	1	650.000	50 MB	50 MB	50 MB
Nye blokkoverskrifter (1 uke)	80 B	8	1008	630 kB	630 kB	630 kB
Nye blokkfiltre (1 uke)	15 KB	1	1008	–	15 MB	–
Blokkerer tilbake til Genesis Block	1 til 1,5 MB	1	650.000	200 GB	–	–
Nye blokker (1 uke)	~ 2 MB	1	1008	2 GB	–	–
Blokker per transaksjon	1 MB	1	1	–	1 MB	–
Merkle-bevis per transaksjon	~ 400 B	1	1	–	–	400 B
Maks. Innledende synkronisering				200 GB	50 MB	50 MB
Max Ukentlig				2 GB	15 MB	630 kB
Maks per transaksjon				–	1 MB	400 B

Lyn

En mobil lynklient kan bruke en lett klient som beskrevet ovenfor for å opprette, lukke og overvåke lynkanaler. En mobil lynklient kan også redusere båndbredden den bruker til å sladre om nettverksruter, og i stedet bruke lokal ruting til stevnemøte eller trampoline Lynnoder. Når en lynkanal er forankret i Bitcoin-blockchain, krever ikke oppdateringer til kanalen internettilgang, men bare en direkte peer-to-peer-dataforbindelse til kanalpartnere. Overvåkingskanaler for ridebukser kan konfigureres til å matche hvor ofte en lett klient har internettilgang. Finansieringstransaksjonen for kanaler kan også periodisk forankres / spleises hvis båndbredden som kreves for oppdatering av Vakttårnene vil være dyrere enn en enkelt on-chain-transaksjon. Forhandlinger om kanaloppdateringsretning med jevnaldrende over et LAN eller en radioforbindelse kan også øke motstandsdyktigheten, redusere måling av internettbruk og øke personvernet.

Brukere av Layer 2-protokoller som Lightning som overvåker og reagerer på kanalbrudd ved hjelp av lette klienter, er potensielt mer sårbare for lavprisangrep som f.eks. tidsutvidelse eller flom-og-plyndring. En lett klient kan ikke finne ut om brudd på transaksjoner før de vises i en blokk fordi de ikke sladrer om ventende transaksjoner. Lette klienter kan også være lettere å formørke hvis de stoler på et lite sett med jevnaldrende for blokkfiltre.

Eksempler

For disse eksemplene beskriver vi hvordan en lett klient kan brukes til å sende og motta både bitcoinbetalinger i kjeden og ved hjelp av Lightning:

On-Chain

For å bekrefte at en transaksjon er mottatt på blockchain, må en lett klient utføre følgende trinn:

1. Synkroniser blokkoverskrifter til gjeldende kjedespiss
2. Synkroniser filterhoder til gjeldende kjedespiss
3. Send inn en transaksjon til en full node for inkludering i en blokk
4. Synkroniser blokkeringsfiltre fra det punktet transaksjonen sendes til en full node
5. Når et blokkfilter samsvarer med transaksjonen, laster du ned den tilsvarende strippede blokken

I dette eksemplet antar vi at blokkoverskrifter og blokkfilteroverskrifter allerede er blitt synkronisert til genese-blokken. Dette krever 50 MB data i utgangspunktet og ca. 1 MB per uke etterpå for å holde seg synkronisert med gjeldende kjedespiss fra flere jevnaldrende. Mengden data som trengs for å synkronisere blokkoverskrifter (1) og blokkere filteroverskrifter (2) til gjeldende blockchain-tips etter en stund offline, avhenger av hvor nylig denne informasjonen sist er oppdatert.

Nedlasting av blokkfiltre (4) for å se etter en bestemt transaksjon avhenger av hvor raskt transaksjonen bekrefter. Det er en avveining mellom å betale lave transaksjonsgebyrer og bruke mer båndbredde for å laste ned blokkfiltre. En times verdi av blokkfiltre krever at du bare laster ned 90 KB filterdata. Den største faste datakostnaden for lette klienter er å laste ned en strippet blokk som tilsvarer blokkfilteret som samsvarer med transaksjonen de er interessert i. Dette krever opptil 1 MB blokkdata per transaksjon. Hvis flere transaksjoner av interesse vises i den samme blokken, vil dette bare kreve nedlasting av en blokk.

Selv brukere med dyre eller langsomme mobildata bør kunne bekrefte Bitcoin-transaksjoner fra mobiltelefonen deres ved hjelp av dette systemet hvis de har råd til 1 MB data per transaksjon og 1 MB per uke for å holde seg synkronisert med blockchain.

“Med hensyn til dine estimater; Hvis det kan implementeres, vil det være aktuelt, og økonomien til det kan føre flere bitcoin-brukere til egen varetekt, sier utvikleren Emmanuel Ndangurura fra Nairobi, Kenya. Emmanuel bemerket at en dataplan på 175 MB som ikke utløper, eller en ukentlig pakke på 500 MB, kan kjøpes i Nairobi for bare $ 0,50. Ved å bruke dataestimatene ovenfor, med bare 175 MB, kan en bruker laste ned en 50 MB app, synkronisere blokkoverskrifter og fortsatt ha data for å sende og motta betalinger på en privat og selvstendig måte ved hjelp av blokkfiltre.

Lyn

En lynnode må utføre trinnene på kjeden som er beskrevet ovenfor for å åpne kanaler, lukke kanaler og svare på kanalbrudd. De må også få tilgang til en internettforbindelse for følgende:

1. Monitor for feil kanal lukkes ved hjelp av en av følgende teknikker:
2. a) Abonner på og send avtaler til Vakttårn for hver kanaloppdatering
3. b) Last ned blokkfiltre for hele perioden Lynkanaler er åpne
4. Motta sladder med nettverkstopologi for kildesending
5. Forhandle lynprotokollen direkte med kanalpartnere

I motsetning til transaksjoner i kjeden, trenger du ikke tilgang til Bitcoin-nettverket for hver Lightning-betaling. I stedet må lette klienter få tilgang til Bitcoin-jevnaldrende innen et konfigurerbart tidsvindu (f.eks. En uke) for å sjekke at kanalens motpart ikke har forsøkt å lukke kanalen med en eldre kanaltilstand. Ideelt sett kan kanaltilstandsovervåking utføres når en ikke-måltilkobling er tilgjengelig. For situasjoner der bare dyre målte tilkoblinger er tilgjengelige, er bruk av Watchtowers (6a) overlegen for overvåking av kanaltilstand. Imidlertid risikerer kunder som ikke uavhengig overvåker blockchain (6b) å miste penger hvis Vakttårnene deres ikke reagerer på kanalbukser.

Vakttårnene (6a) vil kreve noe i størrelsesorden 500 B per Lynbetaling utført av eller dirigert gjennom en likemann for å bli sendt til Vakttårnet via en internettportal. Dette er mye mindre enn å overvåke direkte setetransaksjoner (6b), som krever nedlasting av ca. 15 MB blokkfilterdata per uke. En kanal kan også være lukket i samarbeid eller re-forankret / spleiset on-chain før overvåkingsvinduet utløper hvis det ville være billigere med tanke på båndbredde eller vakttårnets abonnementspris.

I stedet for å sladre om nettverkstopologi (7), bør lette klienter bruke private lynnoder og ikke rute betalinger for andre der båndbredde er dyrt. I stedet bør de bruke trampolinruting eller lignende trinnvise ruteteknikker. Dette vil redusere bruken av båndbredde på bekostning av ruting av personvern.

Faktisk forhandling av en kanaloppdatering (8) krever så lite som 2 KB per betaling utført av noden eller videresendt til en likemann. Kanaloppdateringer kan gjøres mellom noder på samme lokale nettverk, selv når internett-gateways ikke er tilgjengelige.

En mobil lynnode vil trenge 1 MB båndbredde for hver kanal de oppretter eller lukker i kjeden. De trenger 2 KB for å forhandle hver kanaloppdatering og ytterligere 500 B for å registrere hver oppdatering med et Watchtower eller 15 MB per uke for å overvåke blockchain direkte ved hjelp av blokkfiltre..

Konklusjon

Mobillysklienter kan øke sikkerheten til Bitcoin-brukere som for tiden er avhengige av Bitcoin-lommebøker. Nye blokkfilterbaserte lette klienter vil tillate brukere med så lite som 2 MB båndbredde per uke for å bekrefte transaksjoner i kjeden.

Ved å bruke Vakttårnene kan mobile lynnoder utføre mange lave gebyrtransaksjoner uten å kreve mer målt båndbredde enn nåværende onchain-transaksjoner. Eller lynnoder kan bruke blokkeringsfiltre til å uavhengig overvåke blokkeringen ved å bruke mindre enn 20 MB per uke.

Mobillysklienter kan også opportunistisk dra nytte av internettilgang uten måler for å fungere som beskjærte blokkerende fullnoder i “bare mobile” deler av verden. Vi tror at et fokus på Bitcoin light-klienter med lav båndbredde vil bidra til å gi fordelene med selvtillit til mer av verden og til slutt føre til større geografisk mangfold av Bitcoin fullnoder..

En spesiell takk til Karim Helmy og Vil Clark for nyttige diskusjoner og for å lese utkast til denne artikkelen; takk også til Alejandro Machado for hans oppmuntring til å forfølge dette prosjektet.