La comunità Bitcoin è conflittuale, e sulle proposte alla modifica del protocollo ci sono state delle controversie intense.

Probabilmente quella più importante, e che ha lasciato il segno, è nota come Blocksize war.

Si è svolta tra il 2015 e il 2019, e ha visto la comunità dividersi in small-blocker che si opponevano ad ingrandire la dimensione dei blocchi della block chain bitcoin, e big-blocker che proponevano di aumentare la dimensione dei blocchi per scalare bitcoin.

Il 15 luglio 2010, Satoshi aggiunse la seguente riga di codice al repository del software:

static const unsigned int MAX_BLOCK_SIZE = 1000000;

Il software contenente questo aggiornamento venne rilasciato il 19 luglio 2010. Il nuovo limite di 1 MB non entrò in vigore fino al 7 settembre 2010, all'altezza del blocco 79.400 (79.400 blocchi dal lancio di Bitcoin).

All'epoca i blocchi più grandi erano di pochi kilobyte.

Satoshi non fornì una ragione chiara per aver posto questo limite alla dimensione del blocco.

Secondo Gavin Andresen, lo sviluppatore che ha ricevuto il testimone dello sviluppo bitcoin direattamente da Satoshi Nakamoto, si trattava di impedire ai miner di eseguire un attacco DDoS e che doveva essere solo una misura temporanea. Ma persone come Gregory Maxwell hanno suggerito che si trattava di un limite permanente per evitare che la blockchain diventasse troppo grande.

Jeff Garzik propose di eliminare il limite già nel 2010, sostenendo che il limite basso era un "problema di marketing". Theymos evidenziò il rischio di un fork della chain, poiché il software non aggiornato avrebbe rifiutato blocchi di grandi dimensioni.

Satoshi scrisse che i tempi non erano maturi per un aumento, ma che si sarebbe potuto fare codificando la modifica in modo che si applicasse a partire da un timestamp o da un'altezza di blocco futuri (nel suo esempio, il 2011), dando alle persone il tempo sufficiente per aggiornarsi.

Nel periodo 2010-2014 ci furono molte discussioni sul tema; alcuni erano infastiditi dal fatto di dover sostenere il costo dell'archiviazione di gigabyte di spam per sempre creati da applicazioni per il gambling.
E in tale fase vennero introdotti i concetti di soft fork e hard fork. E che "gli hard fork sono intrinsecamente insicuri e ci sia bisogno di un consenso assolutamente completo per implementarli".

Nel 2015 Sidechain e Lightning vennero presentati come soluzioni per lo scaling.

Tra il 2014 e il 2015 avvennero i primi veri tentativi di affrontare il limite della dimensione dei blocchi. La prima grande spinta per aumentare il limite arrivò nel maggio 2015, quando Gavin Andressen e Mike Hearn proposero di aumentare il limite di dimensione dei blocchi a 20 MB. Dopo le discussioni con i miner, il limite proposto fu ridotto a 8 MB. In realtà, a quel tempo, qualsiasi dimensione effettiva dei blocchi superiore a 1 MB avrebbe dato grandi vantaggi ai più grandi miner/pool cinesi. Mike Hearn aveva previsto che i manutentori del repo github di Bitcoin Core avrebbero posto il veto a qualsiasi aumento della dimensione dei blocchi e decise di imporre il BIP-101, un blocco da 8 MB con una road map di aggiornamenti futuri tramite un hard fork (XT). La comunità che sosteneva Core reagì negativamente ritenendo che la sua road map per gli aggiornamenti futuri fosse troppo aggressiva.

In quel periodo, la moderazione del sub reddit r/bitcoin, uno dei principali social che accoglieva le discussioni della comunità Bitcoin, ha iniziato ad applicare una più aggressiva politica di moderazione, e ogni discussione su XT venica bollata alla stregua di "discussione sulle altcoin fuori tema", radicalizzando ulteriormente le due fazioni.

Molti miner manifestarono un interesse per un aggiornamento a 8 MB di dimensione del blocco senza alcuna tabella di marcia per gli aggiornamenti futuri, anche tramite il BIP-100 che raccolse più del 50% di sostegno da parte dei miner, ha delineando un modo per i miner di votare sulle modifiche al limite di dimensione dei blocchi.

I limiti di dimensione dei blocchi a 4 MB e oltre probabilmente avrebbero dato ai miner cinesi un vantaggio inaccettabile.

Jeff Garzik presentò il suo piano "2 MB upgrade ASAP" (BIP-102), e anche questo fu respinto.

La situazione rimase a lungo in stallo, con numerose diverse proposte.

Blockstream, il MIT e altri proposero il workshop Scaling Bitcoin. Erano consentiti solo discorsi tecnici, nessuna "politica", nessuna decisione; qualsiasi richiesta di aumentare il limite di dimensione dei blocchi era specificamente off-topic.

A Peter R. Rizun è stato permesso di tenere un discorso alla conferenza di Montreal del settembre 2015 in cui si diceva che il limite di dimensione dei blocchi poteva essere tranquillamente rimosso, ma non è stato invitato alla successiva conferenza di Hong Kong del dicembre 2015.

Peter R Rizun e Andrew Stone iniziarono a lavorare su Bitcoin Unlimited (rilascio iniziale gennaio 2016).

Peter Wuille presentò SegWit al workshop Scaling Bitcoin di Hong Kong nel dicembre 2015, e in un primo momento è stato etichettato come un "aumento della dimensione dei blocchi di 4 volte attraverso un softfork" - anche se questo non ha retto all'esame, e nelle diapositive l'aumento della capacità per una transazione normale è dato a 1,75 volte. La tabella di marcia per la scalabilità di Bitcoin Core è stata redatta e conteneva molte ottimizzazioni, che rendevano il software di Bitcoin Core meno esigente in termini di risorse (e quindi rendevano più sicuro l'aumento della capacità).

Ma l'unica promessa di aumento della capacità era l'aumento teorico di ~1,7x offerto da SegWit.

Il 2016 fu l'anno del lungo stallo. Nella conferenza Hong Kong Roundtable Consensus si raggiunse un accordo su una tabella di marcia con SegWit prima e un aumento della dimensione dei blocchi di 2 MB poi. Alcuni considerarono l'accordo nullo già pochi giorni dopo la sua stipula. Con il gruppo di Bitcoin Core che negava di supportare un aumento della dimensione dei blocchi e i miner che negavano di implementare SegWit prima di ricevere la promessa di un aumento della dimensione dei blocchi, ci fu uno stallo di lunga durata.

Gavin Andressen tentò di imporre un aggiornamento "di compromesso" di 2 MB (BIP-109) attraverso il suo fork di Bitcoin Classic, tentativo che non solo non andò a buon fine, ma portò anche ad un allonanamento di Andressen. Con la morte di BIP-109, ci fu la spinta per il "consenso emergente" come implementato in Bitcoin Unlimited. Alla fine, la maggior parte dei big-blocker si è trovata d'accordo nel sostenere Emergent Consensus, che a un certo punto ottenne quasi il 50% di consenso da parte dei miner.

2017: UASF, SegWit2X, ASICBOOST, Bitcoin Cash

Gli small-blocker cominciarono ad arrabbiarsi per la mancata attivazione di SegWit da parte dei miner; la tesi sostenuta era che le fee elevate e i problemi di congestione fossero dovuti al fatto che i miner privassero la comunità del tanto necessario aggiornamento di SegWit. Arrivò quindi la proposta di UASF, un tentativo altamente pericoloso di forzare l'aggiornamento di SegWit, definito da alcuni come sybil attack. Chiunque avesse eseguito Bitcoin Core con UASF abilitato avrebbe ignorato i blocchi provenienti da miner che non supportavano SegWit. Con meno del 50% dei miner che supportavano UASF, ci sarebbe stata uno spit della rete, con una rete UASF e una rete non UASF in disaccordo sulla blockchain.

Si scoprì poi che il più grande operatore di mining Bitmain utilizzava un metodo brevettato di "covert asic boost" per effettuare il mining più velocemente, avendo così un vantaggio sugli altri miner che erano anche i suoi stessi clienti. Il metodo utilizzato era incompatibile con SegWit e questo poteva essere motivo dell'ostilità verso SegWit. Dopo aver appreso questa notizia, ci fu uno spostamento della comunità verso gli small-blocker.

A causa della lunga situazione di stallo e con l'imminente disastro dell'UASF che si avvicinava ogni giorno di più, Jeff Garzik e altri proposero il compromesso SegWit2X. Si trattava sostanzialmente di una ripresa dell'accordo della conferenza di Hong Kong. I miner e gli altri principali attori del settore si riunirono e promisero di sostenere l'iniziativa SegWit2X e di utilizzare software alternativi nell'improbabile caso in cui Core non avrebbe supportato l'aggiornamento a 2MB. Il progetto BitcoinABC venne creato come piano di emergenza nel caso in cui UASF sarebbe diventato reale o l'iniziativa SegWit2X avrebbe fallito per altri motivi.

1° agosto, a sorpresa, venne attivato il fork Bitcoin Cash, spinto anche dal fork tra Ethereum e Ethereum Classic che aveva mostrato come un fork potesse consentire a due catene di potersi evolvere indipendentemente dal momento del fork, contraddicendo la regola del whitepaper di Satoshi Nakamoto secondo il quale solo la chain più lunga possa sopravvivere.

Con la paura delle conseguenze dello UASF, i miner decidono di adottare Segwit e l'iniziativa SegWit2X viene abbandonata.