Der er behov for at styrke Bitcoin-økosystemet for folk, hvis eneste computerenhed er en smartphone, og som bor, hvor mobil internetadgang er dyrt, langsom, upålidelig eller Censoreret. Senegalesisk Bitcoin-udvikler Fodé Diop har pointeret, at mange dele af verden er “kun mobile”, ikke kun “mobile først.”

Mobile wallet-apps, der giver brugerne mulighed for at beholde kontrol over deres private nøgler til signering af transaktioner, men ikke fungerer som fulde Bitcoin-noder, kaldes normalt “lette” klienter. Lette kunder foretager afvejninger af privatlivets fred og minimering af tillid for at reducere den hukommelse, vedvarende opbevaring og kommunikationsbåndbredde, de har brug for. Denne artikel fokuserer på, hvordan man minimerer båndbredden, der bruges af lette klientpunge, der kører på en mobiltelefon.

Letklienter har meget lavere båndbreddekrav end fulde noder, fordi de ikke downloader den fulde Bitcoin blockchain. I stedet for bruger lette klienter en eller anden form for “simpel betalingsbekræftelse” (SPV) for at bekræfte transaktioner. I stedet for direkte at bekræfte gyldigheden af ​​hver transaktion, der er føjet til Bitcoins hovedbog siden oprindelsesblokken, bekræfter en SPV-tegnebog kun, at de særlige transaktioner, der er knyttet til tegnebogen, blev føjet til en blok, og at denne blok er en del af kæden af ​​blokke med de fleste arbejder på at sikre det. En SPV-tegnebog antager, men verificerer ikke, at størstedelen af ​​ærlige minearbejdere kun vil bidrage med arbejde for at udvide blockchain bygget fra transaktioner, der følger konsensusreglerne for Bitcoin.

I denne tekniske diskussion undersøger vi de lette klienters båndbreddekrav og de subtile sikkerheds- og privatlivets afvejninger, der findes for lette klienter designet til at fungere med begrænset internetforbindelse..

Let kundeafvejninger

Den mest sikre løsning for brugerne er at køre og bekræfte betalinger med deres egen Bitcoin fulde node. Der er dog en vis sammenhæng mellem lande, hvor folk stoler på relativt dyre eller upålidelige målte internetforbindelser – hvor Bitcoins censurmodstand er mest nødvendigt – og dem, hvor folk sandsynligvis ikke har de tekniske eller økonomiske ressourcer til at køre en fuld Bitcoin-node. I mange dele af verden har Bitcoin-brugere ingen anden mulighed end at bruge online-depot-bitcoin-tegnebøger på grund af båndbreddepriser. Ved hjælp af en lav båndbredde kan kun en mobil mobilklient fungere som et mellemliggende skridt mod til sidst at køre en dedikeret fuld node.

En fordel ved udveksling af bitcoin-udvekslinger er, at deres risici for brugernes privatliv og midler er meget lig dem fra andre pålidelige betalingsudbydere som PayPal og Western Union. Let klientpunge kræver en mere nuanceret forståelse af sikkerheds- og privatlivets kompromiser, der kommer fra brug af anonyme offentlige noder og komplekse peer-to-peer-protokoller..

Der er også et argument for, at lette klienter generelt kan være skadelige for Bitcoin-netværket. Da flere mennesker kører lette klienter, øger det båndbredde og beregningskrav for de offentlige fulde noder, der betjener dem. Dette kan føre til et fald i antallet af offentlige fulde noder, især dem der serverer information til lette klienter. Hvis alle lette klienter er afhængige af et lille sæt offentlige fulde noder, kan deres sikkerhed og privatliv blive kompromitteret, hvis de fulde noder konspirerer imod dem.

Vi mener, at indvirkningen på Bitcoin-netværket kan minimeres, hvis lette kunder også udveksler data direkte med andre lette kunder. Spredningen af ​​lette klienter vil i sidste ende føre til, at flere brugere kører fulde noder, især i udviklingslande, hvor tilslutningsmuligheder er dyrere, og personlige computere ikke er i udbredt anvendelse.

Netværkslag

Lette klienter skal understøtte mange af de samme netværksprotokollag som Bitcoin fulde noder. Begge starter med direkte kommunikation med et indledende sæt Bitcoin-noder. Fra disse indledende noder udveksler de adresserne på andre noder, der er en del af Bitcoin-netværket.

Både lette klienter og fulde noder skal også lære af deres jævnaldrende om beviset på arbejde, der sikrer og forbinder alternative blockchain-tip tilbage til genesisblokken. Fuld noder adskiller sig primært fra lette kunder i, hvordan de deler information om transaktioner. Fuld noder udveksler oplysninger om transaktioner i blokke og validerer uafhængigt af hinanden, at nye blokke følger konsensusreglerne for Bitcoin. Lette klienter bekræfter kun, at specifikke transaktioner er til stede i blokke, der er bekræftet af fulde noder.

Forbindelse

I modsætning til faste internetforbindelser med fast pris, der typisk bruges til fulde noder, bruger mobiltelefoner afmålte internetforbindelser, hvor overførsel af store mængder data kan være dyrt. Mobiltelefoner løber også tør for batterier, som opbruges hurtigere, når data overføres. De kan heller ikke direkte udnytte udsendelsesdatafeeds, der kræver faste parabolantenner eller store radioantenner.

Mobilenheder har nogle fordele ved modstandsdygtighed og fortrolighed i forhold til noder med fast strøm og dataforbindelser. De kan fungere uden for nettet eller under strømafbrydelser og i nogle områder kan de købe forudbetalte internetabonnementer anonymt. Mobilenheder kan også få modstandsdygtighed over for privatliv og censur ved at oprette forbindelse til forskellige lokale jævnaldrende via ad-hoc-netværk, når de bevæger sig rundt.

Lette klienter, der er lavet til mobiltelefoner, skal give brugerne mulighed for at konfigurere, hvor meget mobil båndbredde de skal bruge, og være opmærksomme på, når datatildeling fornys eller udløber. Alternative ikke-målte lokale forbindelser, som et WiFi-hotspot, skal anvendes opportunistisk, når de er tilgængelige til båndbreddekrævende opgaver som at downloade blokke for at bevare målt båndbredde.

Kammerater

Både fulde noder og lette klienter er afhængige af en robust peer discovery proces for at sikre, at de opretter forbindelse til et forskelligt sæt ærlige peer-noder. Bitcoin-noder oprindeligt opretter forbindelse til forudindstillede frø-noder, men skal altid finde nye jævnaldrende for at forblive forbundet med det “ærlige” Bitcoin-netværk. Bitcoin Core-fuldknudesoftwaren har udviklet robuste heuristikker til afbødning formørkelsesangreb fra ondsindede jævnaldrende og afbryde forbindelsen til misopførte noder. Da peer-adresser kun er 30 byte hver, kan lette klienter bruge den samme heuristik som fulde noder til ofte at spørge flere peers for nye adresser.

Den bedste måde at forhindre at blive isoleret fra det ærlige Bitcoin-netværk er at opretholde et stort, vedvarende og forskelligt sæt af peer-forbindelser. For at hjælpe med at bevare batteriets levetid bør let klientsoftware være forsigtig med ikke at vække en mobiltelefon for ofte til at sladre om peer-adresser eller udføre andre opgaver. Lette klienter skal synkronisere med deres jævnaldrende med det samme faste tidsinterval for at minimere både batteriforbrug og frakobling af peer.

Blokoverskrifter

Både fuld knudepunkt og let klientsikkerhed afhænger af evnen til at opdage kædespidsen af ​​blockchain med mest arbejde med at sikre det. Denne proces starter med at forespørge alle jævnaldrende om den seneste blokoverskrifter de kender til blockchain. En node skal muligvis spørge sine kollegaer på forskellige punkter for at finde det punkt, når de først er uenige om, hvilken kædegaffel der er korrekt. Lette klienter bør også validere proof-of-work, tidsstempel, Merkle root og tidligere header block hash for hver block header, de modtager, og forbyde peers, der tjener ugyldige block headers. Fuld noder validerer også overskrifter, inden de downloader blokke for at forhindre denial-of-service (DoS) -angreb.

Når den kanoniske kædespids er bestemt, kan en let klient synkronisere blokoverskrifter tilbage for at sikre, at kædespidsen opretter forbindelse til Bitcoin-genesisblokken – cirka 50 MB data. Nogle lette klienter, der bruger langsomme eller målte forbindelser, indlæser måske oprindeligt kun blokoverskrifter tilbage til et kontrolpunkt i stedet for oprindelsesblokken. Fuld noder skal altid synkronisere alle blokoverskrifter. Brugere skal advares om risikoen for at acceptere betalinger, indtil hele headerkæden er blevet kontrolleret. Lette klienter og fulde noder skal fortsætte med at downloade 80 byte-blokoverskrifter fra hver peer for at forblive synkroniseret med blockchain, når den vokser, og forespørge også flere peers for blokoverskrifter for at sikre, at de altid følger den nuværende bedste block header-kæde.

Moderne lette klientbøger kan registrere, hvornår en transaktion, de sporer, vises i en blok ved hjælp af BIP-157 blokere filtre. Ligesom blokoverskrifter forespørger lette kunder også deres jævnaldrende for at bestemme den aktuelle spids af en filterhovedkæde. BIP-157 lette klienter downloader 32 byte-blokfilterhoveder pr. Blok for at forblive synkroniseret med blokfilterhovedkæden. I tilfælde af uenighed mellem peers om den korrekte filterhovedkæde, kan lette klienter downloade den tilsvarende blok for at bestemme, hvilken peer der følger den rigtige kæde. Let klienter bør ignorere blokfilterkæder, der inkluderer ugyldige overskrifter og sortliste-kollegaer, der tjener ugyldige blok- eller filteroverskrifter.

Blokfiltre giver større fortrolighed end det forældede BIP-37 blomstringsfiltersystem, fordi lette klienter ikke lækker til en fuld node, hvilke transaktioner de er interesseret i. Blokfiltre skaleres også bedre end blomstringsfiltre. Da der kun genereres et blokfilter pr. Blok, behøver en fuld node kun en konstant mængde beregning for at betjene flere lette klientkammerater. Lette klienter selv kan også hjælpe med at videresende blokfiltre og sladderblokfilteroverskrifter for at øge antallet af lette klientkammerater, som hver fuld node understøtter.

En let klient kræver som minimum blokfiltrene for blokke, der kan indeholde relevante transaktioner. Filtre er ca. 15 KB pr. Blok, så for en transaktion, der tager seks blokke (ca. en time) at bekræfte, skal en let klient downloade 90 KB filterdata for at få en indikation af, hvilken blok transaktionen vises i. I tilfælde af et andet lag protokol som Lynnetværk, perioden til at se efter en transaktion ville være åben, medmindre Vagttårne bliver brugt. Vagttårne ​​er især nyttige for lette klienter på mobile enheder, både fordi de sandsynligvis vil være offline i lange perioder, og fordi de er båndbredde begrænsede.

Transaktioner

Blocks-Only Full Node

For at reducere båndbreddeforbruget kan fulde noder konfigureres til at bruge kun blok-tilstand for at downloade fulde blokke, men ikke sladder om transaktioner. Dette er en sikker og privat måde at bekræfte transaktioner på og kræver ikke blokfiltre, fordi hver blok downloades. En mobil klient, der fungerer som en beskåret kun blok med fuld node ville kræve op til 2 GB downloadbåndbredde om ugen. En mobil klient med hurtigt og billigt eller ikke-målret internet kan fungere i denne tilstand for at få sikkerheds- og fortrolighedsfordelene ved at køre en fuld node, men understøtter stadig lys klienttilstand, når båndbredde måles, eller batteristrøm er begrænset. Fleksibiliteten for en mobil lysklient til opportunistisk at fungere som en blok-kun fuld knude kan hjælpe med at øge antallet af fulde noder i lande, hvor brugen af ​​pc’er er mindre almindelig. Fuld noder med kun mobile blokke kunne også betjene blokfiltre til lette klienter uden at øge deres egen båndbreddes brug væsentligt.

Bloker filterlysklient

Det nye BIP-157 blokfiltersystem downloades strippet blokke på op til 1 MB kun, når der registreres en sporet transaktion i kæden af ​​downloadede blokfiltre. Dette er en stor forbedring i forhold til de 2 GB pr. Uge med båndbredde, der er nødvendig for at se efter transaktioner med en blok-kun Bitcoin fuld node. Downloadede blokke kan bruges til at validere blokfiltre, ugyldiggøre blokfilterkæder og afbryde forbindelsen fra jævnaldrende, der deler ugyldige filtre. Dette skaber en måde for lette klienter at forhindre ugyldige filterkæder i at udbrede sig og gør det muligt for lette klienter at dele filteroplysninger med hinanden og reducere belastningen på fulde noder. Lette klienter kan forespørge hele sættet med fulde noder for nylige blokke, ikke kun fulde noder, der tjener blokfiltre. Dette forhindrer lækket information om de transaktioner, som en let klient er interesseret i, og spreder belastningen blandt et større sæt fuld noder.

Lette klienter, der bruger BIP-157-blokfiltre, bekræfter ikke uafhængigt, at alle transaktioner i en blok overholder Bitcoins konsensusregler, men antager i stedet, at kæden, der er bekræftet med den mest hash-kraft, følger de korrekte regler. Disse noder kan narres til at følge et flertal af minearbejdere, der samarbejder om at vedtage forskellige udgiftsregler. I en situation som SegWit2x omstridt hård gaffel kunne en let klientbruger have været vildledt til at acceptere en ugyldig betaling fra en gaffel i Bitcoin blockchain. Klientbrugere med lav båndbredde er også mere modtagelige for en række formørkelsesangreb, der er lettere at skjule forsøg end en minearbejdet hård gaffel. Brugere af protokoller med andet lag som f.eks. Lightning Network er også potentielt sårbare over for lave omkostninger tidsudvidelsesangreb.

Electrum Light Client

En anden populær løsning til lette enheder er Electrum klient-server-protokollen. I stedet for at downloade blokfiltre og blokke fra fulde noder for at bekræfte transaktioner, an Electrum lys klient tegnebog anmodninger små Merkle bevis til specifikke transaktioner (der henvises til med et unikt transaktions-id) direkte fra en eller flere servere, der kører Electrum-protokollen. Da Electrum-servere kan logge de nøjagtige transaktioner, som hver enkelt klient anmoder om, er det vigtigt, at klienter anonymiserer deres anmodninger ved hjælp af en Tor løg service eller lignende service. Det er muligt, at mange af de nuværende offentlige Electrum-servere drives af private kædeovervågningsfirmaer med det formål at indsamle data til deanonymisering af Bitcoin-transaktioner. En yderligere risiko ved at stole på Electrum-servermodellen er, at serveroperatører ondsindet kan tilbageholde (censur), der leverer bevis for bestemte transaktioner, hvilket er sværere at gøre under BIP-157-modellen.

Mens der er mange færre offentlige Electrum-servere end Bitcoin-fulde noder, serverer i øjeblikket meget få fulde noder blokfiltre til lette klienter. Dette forventes at ændre sig, da BIP-157-understøttelse af blokfilter nu har været fusioneret ind i Bitcoin Core-softwaren.

En Electrum-baseret lysklient ville kræve endnu mindre båndbredde end en blokfilterbaseret lysklient, fordi den ikke behøver at downloade blokfilteroverskrifter, blokfiltre eller strippede fulde blokke for at bekræfte transaktioner. I stedet behøver Electrum-klienter kun at anmode om et Merkle-bevis på ca. 400 B for at bekræfte hver transaktion.

Resumé

Tabellen nedenfor opsummerer, hvor meget målte data, der ville blive brugt af en blok-kun fuld knude, en blokfilterbaseret lysklient og en Electrum-baseret lysklient. Som du kan se i resuméet, bruger hver form for lysklient dramatisk mindre båndbredde pr. Uge end endda en minimal blok-kun fuld knude.

	Datastørrelse	Peers forespurgt	Returnerede værdier	Blok-kun fuld knude	Bloker filterlysklient	Electrum Light Client
Peer-adresser	30 B	8	1000	234 KB	234 KB	234 KB
Blokoverskrifter til nuværende kædespids	80 B	8	1	640 B.	640 B.	640 B.
Filterhoveder til filterkædespids	32 B	8	1	–	256 B	–
Blok overskrifter tilbage til Genesis Block	80 B	1	650.000	50 MB	50 MB	50 MB
Nye blokhoveder (1 uge)	80 B	8	1008	630 KB	630 KB	630 KB
Nye blokfiltre (1 uge)	15 KB	1	1008	–	15 MB	–
Blokerer tilbage til Genesis Block	1 til 1,5 MB	1	650.000	200 GB	–	–
Nye blokke (1 uge)	~ 2 MB	1	1008	2 GB	–	–
Blokke pr. Transaktion	1 MB	1	1	–	1 MB	–
Merkle-bevis per transaktion	~ 400 B.	1	1	–	–	400 B
Maks. Indledende synkronisering				200 GB	50 MB	50 MB
Max ugentligt				2 GB	15 MB	630 KB
Maks. Pr. Transaktion				–	1 MB	400 B

Lyn

En mobil Lightning-klient kan bruge en light client som beskrevet ovenfor til oprettelse, lukning og overvågning af Lightning-kanaler. En mobil Lightning-klient kan også reducere båndbredden, den bruger til at sladre om netværksruter og i stedet bruge lokal routing til rendezvous eller trampolin Lynknudepunkter. Når en Lightning-kanal er forankret i Bitcoin blockchain, kræver opdateringer til kanalen ikke internetadgang, men kun en direkte peer-to-peer-dataforbindelse til kanalpartnere. Overvågningskanaler til ridebukser kan konfigureres til at matche, hvor ofte en let klient har internetadgang. Finansieringstransaktionen for kanaler kan også periodisk forankres / splejses, hvis den båndbredde, der kræves til opdatering af Vagttårne, ville være dyrere end en enkelt on-chain-transaktion. Forhandling af kanalopdateringsretning med jævnaldrende over et LAN eller en radioforbindelse kan også øge modstandsdygtigheden, reducere afmålt internetbrug og øge privatlivets fred.

Brugere af Layer 2-protokoller som Lightning, der overvåger og reagerer på kanalbrud ved hjælp af lette klienter, er potentielt mere sårbare over for lave omkostningsangreb som f.eks. tidsudvidelse eller oversvømmelse og plyndring. En let klient kan ikke finde ud af brudtransaktioner, før de vises i en blok, fordi de ikke sladrer om ventende transaktioner. Let klienter kan også være lettere at formørke, hvis de stoler på et lille sæt af jævnaldrende til blokfiltre.

Eksempler

For disse eksempler beskriver vi, hvordan en let klient kunne bruges til at sende og modtage både bitcoinbetalinger on-chain og brug af Lightning:

On-Chain

For at bekræfte, at en transaktion er modtaget på blockchain, skal en let klient gennemføre følgende trin:

1. Synkroniser blokhoveder til den aktuelle kædespids
2. Synkroniser filterfilterhoveder til den aktuelle kædespids
3. Indsend en transaktion til en fuld node for inkludering i en blok
4. Synkroniser blokfiltre fra det punkt, hvor transaktionen sendes til en fuld node
5. Når et blokfilter matcher transaktionen, skal du downloade den tilsvarende strippede blok

I dette eksempel antager vi, at blokoverskrifter og blokfilteroverskrifter allerede er synkroniseret til genesisblokken. Dette kræver oprindeligt 50 MB data og ca. 1 MB om ugen derefter for at blive synkroniseret med den aktuelle kædespids fra flere jævnaldrende. Mængden af ​​data, der er nødvendige for at re-synkronisere blokoverskrifter (1) og blokere filteroverskrifter (2) til det aktuelle blockchain-tip efter nogen tid offline afhænger af, hvor nylig disse oplysninger sidst er blevet opdateret.

Download af blokfiltre (4) for at se efter en bestemt transaktion afhænger af, hvor hurtigt transaktionen bekræfter. Der er en afvejning mellem at betale lave transaktionsgebyrer og bruge mere båndbredde til at downloade blokfiltre. En times blokfiltre kræver kun download af 90 KB filterdata. De største faste datapriser for lette klienter er at downloade en strippet blok svarende til blokfiltret, der svarer til den transaktion, de er interesseret i. Dette kræver op til 1 MB blokdata pr. Transaktion. Hvis der vises flere interessetransaktioner i samme blok, kræves der kun download af en blok.

Selv brugere med dyre eller langsomme mobildata skal kunne bekræfte Bitcoin-transaktioner fra deres mobiltelefon ved hjælp af dette system, hvis de har råd til 1 MB data pr. Transaktion og 1 MB om ugen for at forblive synkroniseret med blockchain.

”Med hensyn til dine skøn; Hvis det kan implementeres, ville det være relevant, og økonomien ved det kunne drive flere bitcoin-brugere til selvstændig forældremyndighed, ”sagde udvikleren Emmanuel Ndangurura fra Nairobi, Kenya. Emmanuel bemærkede, at en dataplan på 175 MB, der ikke udløber, eller en ugentlig pakke på 500 MB, kan købes i Nairobi for kun $ 0,50. Brug af dataestimaterne ovenfor, med kun 175 MB, kunne en bruger downloade en 50 MB app, synkronisere blokoverskrifter og stadig have data til at sende og modtage betalinger på en privat og selvstændig måde ved hjælp af blokfiltre.

Lyn

En lynknudepunkt skal udføre de kædetrin, der er beskrevet ovenfor for at åbne kanaler, lukke kanaler og reagere på kanalbrud. De skal også få adgang til en internetforbindelse for følgende:

1. Monitor for forkert kanal lukker ved hjælp af en af ​​følgende teknikker:
2. a) Abonner på og indsend aftaler til Vagttårne for hver kanalopdatering
3. b) Download blokfiltre i hele perioden Lynkanaler er åbne
4. Modtag sladder til netværkstopologi til kildedirigering
5. Forhandle Lightning-protokollen direkte med kanalpartnere

I modsætning til on-chain-transaktioner behøver man ikke få adgang til Bitcoin-netværket for hver Lightning-betaling. I stedet skal lette klienter få adgang til Bitcoin-jævnaldrende inden for et konfigurerbart tidsvindue (f.eks. En uge) for at kontrollere, at deres kanalmodpart ikke har forsøgt at bedrager lukning af kanalen ved hjælp af en ældre kanaltilstand. Ideelt set kan kanaltilstandsovervågning udføres, når der er en umetret forbindelse. I situationer, hvor kun dyre målte forbindelser er tilgængelige, er brug af Watchtowers (6a) overlegen til overvågning af kanaltilstand. Imidlertid risikerer kunder, der ikke uafhængigt overvåger blockchain (6b), at miste penge, hvis deres Vagttårne ​​ikke reagerer på kanalbukser.

Vagttårne ​​(6a) ville kræve noget i størrelsesordenen 500 B pr. Lynbetaling foretaget af eller dirigeret gennem en peer for at blive sendt til et vagttårn via en internet-gateway. Dette er meget mindre end overvågning af breech-transaktioner direkte (6b), hvilket kræver download af ca. 15 MB blokfilterdata om ugen. En kanal kan også være lukket i samarbejde eller genforankret / splejset i kæden, før det overvåger vinduet, udløber, hvis det ville være billigere set fra et båndbredde- eller vagttårn-abonnementsomkostningssynspunkt.

I stedet for at sladre om netværkstopologi (7), skal lette klienter bruge private Lightning-noder og ikke dirigere betalinger til andre, hvor båndbredde er dyrt. I stedet skal de bruge trampolin routing eller lignende inkrementelle routing teknikker. Dette ville mindske båndbreddebrugen på bekostning af routing af privatlivets fred.

Faktisk forhandling af en kanalopdatering (8) kræver så lidt som 2 KB pr. Betaling foretaget af noden eller videresendt til en peer. Kanalopdateringer kan foretages mellem noder på det samme lokale netværk, selv når internet-gateways ikke er tilgængelige.

En mobil Lightning-node ville have brug for 1 MB båndbredde for hver kanal, de opretter eller lukker on-chain. De har brug for 2 KB for at forhandle hver kanalopdatering og yderligere 500 B for at registrere hver opdatering med et Vagttårn eller 15 MB om ugen for at overvåge blockchain direkte ved hjælp af blokfiltre.

Konklusion

Mobile light-klienter kan øge sikkerheden væsentligt for Bitcoin-brugere, der i øjeblikket er afhængige af Bitcoin-tegnebøger. Nye blokfilterbaserede lette klienter giver brugere med så lidt som 2 MB båndbredde om ugen at bekræfte transaktioner i kæden.

Ved at bruge Vagttårne ​​kan mobile lynnoder udføre mange lave gebyrtransaktioner uden at kræve mere målt båndbredde end nuværende onchain-transaktioner. Eller lynnoder kan bruge blokfiltre til uafhængigt at overvåge blockchain ved hjælp af mindre end 20 MB om ugen.

Mobillysklienter kan også opportunistisk drage fordel af ikke-målret internetadgang til at fungere som beskærede blokke-kun fulde noder i “kun mobile” dele af verden. Vi mener, at et fokus på Bitcoin-lette klienter med lav båndbredde vil hjælpe med at bringe fordelene ved selvbevaring til mere af verden og til sidst føre til større geografisk mangfoldighed af Bitcoin-fulde noder.

Særlig tak til Karim Helmy og Vil Clark til nyttige diskussioner og til læsning af udkast til denne artikel; tak også til Alejandro Machado for hans opmuntring til at forfølge dette projekt.