From e327e501676884f1366199439ef2d716b557fe13 Mon Sep 17 00:00:00 2001
From: Paolo Agazzone <aga@intercom.it>
Date: Tue, 26 Jan 2016 18:20:11 +0100
Subject: [PATCH 01/48] Added bip39 Italian wordlist

---
 bip-0039/bip-0039-wordlists.md | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 203ba06f..aef1a230 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -6,6 +6,7 @@
 * [Chinese (Simplified)](chinese_simplified.txt)
 * [Chinese (Traditional)](chinese_traditional.txt)
 * [French](french.txt)
+* [Italian](italian.txt)
 
 ##Wordlists (Special Considerations)
 
@@ -57,3 +58,26 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
 17. No identical words with the Spanish wordlist (as Y75QMO wants).
+
+### Italian
+
+Credits: @paoloaga @Polve
+
+Words chosen using the following rules:
+
+1. Simple and common italian words.
+2. Length between 4 and 8 characters.
+3. First 4 letters must be unique between all words.
+4. No accents or special characters.
+5. No complex verb forms.
+6. No plural words.
+7. No words that remind negative/sad/bad things.
+8. If both female/male words are available, choose male version.
+9. No words with double vocals (like: lineetta).
+10. No words already used in other language mnemonic sets.
+11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
+12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters.
+
+Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. 
+
+All the words have been manually selected and automatically checked against the rules.

From d3f34b99d05a45fe8ed9ac53cd0fabc4532fe4a3 Mon Sep 17 00:00:00 2001
From: Paolo Agazzone <aga@intercom.it>
Date: Tue, 26 Jan 2016 18:20:11 +0100
Subject: [PATCH 02/48] Added bip39 Italian wordlist

---
 bip-0039/bip-0039-wordlists.md |   24 +
 bip-0039/italian.txt           | 2048 ++++++++++++++++++++++++++++++++
 2 files changed, 2072 insertions(+)
 create mode 100644 bip-0039/italian.txt

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 203ba06f..aef1a230 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -6,6 +6,7 @@
 * [Chinese (Simplified)](chinese_simplified.txt)
 * [Chinese (Traditional)](chinese_traditional.txt)
 * [French](french.txt)
+* [Italian](italian.txt)
 
 ##Wordlists (Special Considerations)
 
@@ -57,3 +58,26 @@ Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch
 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
 17. No identical words with the Spanish wordlist (as Y75QMO wants).
+
+### Italian
+
+Credits: @paoloaga @Polve
+
+Words chosen using the following rules:
+
+1. Simple and common italian words.
+2. Length between 4 and 8 characters.
+3. First 4 letters must be unique between all words.
+4. No accents or special characters.
+5. No complex verb forms.
+6. No plural words.
+7. No words that remind negative/sad/bad things.
+8. If both female/male words are available, choose male version.
+9. No words with double vocals (like: lineetta).
+10. No words already used in other language mnemonic sets.
+11. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there must be at least other 3 different letters.
+12. If 3 of the first 4 letters are already used in the same sequence in another mnemonic word, there not must be the same sequence of 3 or more letters.
+
+Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. 
+
+All the words have been manually selected and automatically checked against the rules.
diff --git a/bip-0039/italian.txt b/bip-0039/italian.txt
new file mode 100644
index 00000000..c47370f4
--- /dev/null
+++ b/bip-0039/italian.txt
@@ -0,0 +1,2048 @@
+abaco
+abbaglio
+abbinato
+abete
+abisso
+abolire
+abrasivo
+abrogato
+accadere
+accenno
+accusato
+acetone
+achille
+acido
+acqua
+acre
+acrilico
+acrobata
+acuto
+adagio
+addebito
+addome
+adeguato
+aderire
+adipe
+adottare
+adulare
+affabile
+affetto
+affisso
+affranto
+aforisma
+afoso
+africano
+agave
+agente
+agevole
+aggancio
+agire
+agitare
+agonismo
+agricolo
+agrumeto
+aguzzo
+alabarda
+alato
+albatro
+alberato
+albo
+albume
+alce
+alcolico
+alettone
+alfa
+algebra
+aliante
+alibi
+alimento
+allagato
+allegro
+allievo
+allodola
+allusivo
+almeno
+alogeno
+alpaca
+alpestre
+altalena
+alterno
+alticcio
+altrove
+alunno
+alveolo
+alzare
+amalgama
+amanita
+amarena
+ambito
+ambrato
+ameba
+america
+ametista
+amico
+ammasso
+ammenda
+ammirare
+ammonito
+amore
+ampio
+ampliare
+amuleto
+anacardo
+anagrafe
+analista
+anarchia
+anatra
+anca
+ancella
+ancora
+andare
+andrea
+anello
+angelo
+angolare
+angusto
+anima
+annegare
+annidato
+anno
+annuncio
+anonimo
+anticipo
+anzi
+apatico
+apertura
+apode
+apparire
+appetito
+appoggio
+approdo
+appunto
+aprile
+arabica
+arachide
+aragosta
+araldica
+arancio
+aratura
+arazzo
+arbitro
+archivio
+ardito
+arenile
+argento
+argine
+arguto
+aria
+armonia
+arnese
+arredato
+arringa
+arrosto
+arsenico
+arso
+artefice
+arzillo
+asciutto
+ascolto
+asepsi
+asettico
+asfalto
+asino
+asola
+aspirato
+aspro
+assaggio
+asse
+assoluto
+assurdo
+asta
+astenuto
+astice
+astratto
+atavico
+ateismo
+atomico
+atono
+attesa
+attivare
+attorno
+attrito
+attuale
+ausilio
+austria
+autista
+autonomo
+autunno
+avanzato
+avere
+avvenire
+avviso
+avvolgere
+azione
+azoto
+azzimo
+azzurro
+babele
+baccano
+bacino
+baco
+badessa
+badilata
+bagnato
+baita
+balcone
+baldo
+balena
+ballata
+balzano
+bambino
+bandire
+baraonda
+barbaro
+barca
+baritono
+barlume
+barocco
+basilico
+basso
+batosta
+battuto
+baule
+bava
+bavosa
+becco
+beffa
+belgio
+belva
+benda
+benevole
+benigno
+benzina
+bere
+berlina
+beta
+bibita
+bici
+bidone
+bifido
+biga
+bilancia
+bimbo
+binocolo
+biologo
+bipede
+bipolare
+birbante
+birra
+biscotto
+bisesto
+bisnonno
+bisonte
+bisturi
+bizzarro
+blando
+blatta
+bollito
+bonifico
+bordo
+bosco
+botanico
+bottino
+bozzolo
+braccio
+bradipo
+brama
+branca
+bravura
+bretella
+brevetto
+brezza
+briglia
+brillante
+brindare
+broccolo
+brodo
+bronzina
+brullo
+bruno
+bubbone
+buca
+budino
+buffone
+buio
+bulbo
+buono
+burlone
+burrasca
+bussola
+busta
+cadetto
+caduco
+calamaro
+calcolo
+calesse
+calibro
+calmo
+caloria
+cambusa
+camerata
+camicia
+cammino
+camola
+campale
+canapa
+candela
+cane
+canino
+canotto
+cantina
+capace
+capello
+capitolo
+capogiro
+cappero
+capra
+capsula
+carapace
+carcassa
+cardo
+carisma
+carovana
+carretto
+cartolina
+casaccio
+cascata
+caserma
+caso
+cassone
+castello
+casuale
+catasta
+catena
+catrame
+cauto
+cavillo
+cedibile
+cedrata
+cefalo
+celebre
+cellulare
+cena
+cenone
+centesimo
+ceramica
+cercare
+certo
+cerume
+cervello
+cesoia
+cespo
+ceto
+chela
+chiaro
+chicca
+chiedere
+chimera
+china
+chirurgo
+chitarra
+ciao
+ciclismo
+cifrare
+cigno
+cilindro
+ciottolo
+circa
+cirrosi
+citrico
+cittadino
+ciuffo
+civetta
+civile
+classico
+clinica
+cloro
+cocco
+codardo
+codice
+coerente
+cognome
+collare
+colmato
+colore
+colposo
+coltivato
+colza
+coma
+cometa
+commando
+comodo
+computer
+comune
+conciso
+condurre
+conferma
+congelare
+coniuge
+connesso
+conoscere
+consumo
+continuo
+convegno
+coperto
+copione
+coppia
+copricapo
+corazza
+cordata
+coricato
+cornice
+corolla
+corpo
+corredo
+corsia
+cortese
+cosmico
+costante
+cottura
+covato
+cratere
+cravatta
+creato
+credere
+cremoso
+crescita
+creta
+criceto
+crinale
+crisi
+critico
+croce
+cronaca
+crostata
+cruciale
+crusca
+cucire
+cuculo
+cugino
+cullato
+cupola
+curatore
+cursore
+curvo
+cuscino
+custode
+dado
+daino
+dalmata
+damerino
+daniela
+dannoso
+danzare
+datato
+davanti
+davvero
+debutto
+decennio
+deciso
+declino
+decollo
+decreto
+dedicato
+definito
+deforme
+degno
+delegare
+delfino
+delirio
+delta
+demenza
+denotato
+dentro
+deposito
+derapata
+derivare
+deroga
+descritto
+deserto
+desiderio
+desumere
+detersivo
+devoto
+diametro
+dicembre
+diedro
+difeso
+diffuso
+digerire
+digitale
+diluvio
+dinamico
+dinnanzi
+dipinto
+diploma
+dipolo
+diradare
+dire
+dirotto
+dirupo
+disagio
+discreto
+disfare
+disgelo
+disposto
+distanza
+disumano
+dito
+divano
+divelto
+dividere
+divorato
+doblone
+docente
+doganale
+dogma
+dolce
+domato
+domenica
+dominare
+dondolo
+dono
+dormire
+dote
+dottore
+dovuto
+dozzina
+drago
+druido
+dubbio
+dubitare
+ducale
+duna
+duomo
+duplice
+duraturo
+ebano
+eccesso
+ecco
+eclissi
+economia
+edera
+edicola
+edile
+editoria
+educare
+egemonia
+egli
+egoismo
+egregio
+elaborato
+elargire
+elegante
+elencato
+eletto
+elevare
+elfico
+elica
+elmo
+elsa
+eluso
+emanato
+emblema
+emesso
+emiro
+emotivo
+emozione
+empirico
+emulo
+endemico
+enduro
+energia
+enfasi
+enoteca
+entrare
+enzima
+epatite
+epilogo
+episodio
+epocale
+eppure
+equatore
+erario
+erba
+erboso
+erede
+eremita
+erigere
+ermetico
+eroe
+erosivo
+errante
+esagono
+esame
+esanime
+esaudire
+esca
+esempio
+esercito
+esibito
+esigente
+esistere
+esito
+esofago
+esortato
+esoso
+espanso
+espresso
+essenza
+esso
+esteso
+estimare
+estonia
+estroso
+esultare
+etilico
+etnico
+etrusco
+etto
+euclideo
+europa
+evaso
+evidenza
+evitato
+evoluto
+evviva
+fabbrica
+faccenda
+fachiro
+falco
+famiglia
+fanale
+fanfara
+fango
+fantasma
+fare
+farfalla
+farinoso
+farmaco
+fascia
+fastoso
+fasullo
+faticare
+fato
+favoloso
+febbre
+fecola
+fede
+fegato
+felpa
+feltro
+femmina
+fendere
+fenomeno
+fermento
+ferro
+fertile
+fessura
+festivo
+fetta
+feudo
+fiaba
+fiducia
+fifa
+figurato
+filo
+finanza
+finestra
+finire
+fiore
+fiscale
+fisico
+fiume
+flacone
+flamenco
+flebo
+flemma
+florido
+fluente
+fluoro
+fobico
+focaccia
+focoso
+foderato
+foglio
+folata
+folclore
+folgore
+fondente
+fonetico
+fonia
+fontana
+forbito
+forchetta
+foresta
+formica
+fornaio
+foro
+fortezza
+forzare
+fosfato
+fosso
+fracasso
+frana
+frassino
+fratello
+freccetta
+frenata
+fresco
+frigo
+frollino
+fronde
+frugale
+frutta
+fucilata
+fucsia
+fuggente
+fulmine
+fulvo
+fumante
+fumetto
+fumoso
+fune
+funzione
+fuoco
+furbo
+furgone
+furore
+fuso
+futile
+gabbiano
+gaffe
+galateo
+gallina
+galoppo
+gambero
+gamma
+garanzia
+garbo
+garofano
+garzone
+gasdotto
+gasolio
+gastrico
+gatto
+gaudio
+gazebo
+gazzella
+geco
+gelatina
+gelso
+gemello
+gemmato
+gene
+genitore
+gennaio
+genotipo
+gergo
+ghepardo
+ghiaccio
+ghisa
+giallo
+gilda
+ginepro
+giocare
+gioiello
+giorno
+giove
+girato
+girone
+gittata
+giudizio
+giurato
+giusto
+globulo
+glutine
+gnomo
+gobba
+golf
+gomito
+gommone
+gonfio
+gonna
+governo
+gracile
+grado
+grafico
+grammo
+grande
+grattare
+gravoso
+grazia
+greca
+gregge
+grifone
+grigio
+grinza
+grotta
+gruppo
+guadagno
+guaio
+guanto
+guardare
+gufo
+guidare
+ibernato
+icona
+identico
+idillio
+idolo
+idra
+idrico
+idrogeno
+igiene
+ignaro
+ignorato
+ilare
+illeso
+illogico
+illudere
+imballo
+imbevuto
+imbocco
+imbuto
+immane
+immerso
+immolato
+impacco
+impeto
+impiego
+importo
+impronta
+inalare
+inarcare
+inattivo
+incanto
+incendio
+inchino
+incisivo
+incluso
+incontro
+incrocio
+incubo
+indagine
+india
+indole
+inedito
+infatti
+infilare
+inflitto
+ingaggio
+ingegno
+inglese
+ingordo
+ingrosso
+innesco
+inodore
+inoltrare
+inondato
+insano
+insetto
+insieme
+insonnia
+insulina
+intasato
+intero
+intonaco
+intuito
+inumidire
+invalido
+invece
+invito
+iperbole
+ipnotico
+ipotesi
+ippica
+iride
+irlanda
+ironico
+irrigato
+irrorare
+isolato
+isotopo
+isterico
+istituto
+istrice
+italia
+iterare
+labbro
+labirinto
+lacca
+lacerato
+lacrima
+lacuna
+laddove
+lago
+lampo
+lancetta
+lanterna
+lardoso
+larga
+laringe
+lastra
+latenza
+latino
+lattuga
+lavagna
+lavoro
+legale
+leggero
+lembo
+lentezza
+lenza
+leone
+lepre
+lesivo
+lessato
+lesto
+letterale
+leva
+levigato
+libero
+lido
+lievito
+lilla
+limatura
+limitare
+limpido
+lineare
+lingua
+liquido
+lira
+lirica
+lisca
+lite
+litigio
+livrea
+locanda
+lode
+logica
+lombare
+londra
+longevo
+loquace
+lorenzo
+loto
+lotteria
+luce
+lucidato
+lumaca
+luminoso
+lungo
+lupo
+luppolo
+lusinga
+lusso
+lutto
+macabro
+macchina
+macero
+macinato
+madama
+magico
+maglia
+magnete
+magro
+maiolica
+malafede
+malgrado
+malinteso
+malsano
+malto
+malumore
+mana
+mancia
+mandorla
+mangiare
+manifesto
+mannaro
+manovra
+mansarda
+mantide
+manubrio
+mappa
+maratona
+marcire
+maretta
+marmo
+marsupio
+maschera
+massaia
+mastino
+materasso
+matricola
+mattone
+maturo
+mazurca
+meandro
+meccanico
+mecenate
+medesimo
+meditare
+mega
+melassa
+melis
+melodia
+meninge
+meno
+mensola
+mercurio
+merenda
+merlo
+meschino
+mese
+messere
+mestolo
+metallo
+metodo
+mettere
+miagolare
+mica
+micelio
+michele
+microbo
+midollo
+miele
+migliore
+milano
+milite
+mimosa
+minerale
+mini
+minore
+mirino
+mirtillo
+miscela
+missiva
+misto
+misurare
+mitezza
+mitigare
+mitra
+mittente
+mnemonico
+modello
+modifica
+modulo
+mogano
+mogio
+mole
+molosso
+monastero
+monco
+mondina
+monetario
+monile
+monotono
+monsone
+montato
+monviso
+mora
+mordere
+morsicato
+mostro
+motivato
+motosega
+motto
+movenza
+movimento
+mozzo
+mucca
+mucosa
+muffa
+mughetto
+mugnaio
+mulatto
+mulinello
+multiplo
+mummia
+munto
+muovere
+murale
+musa
+muscolo
+musica
+mutevole
+muto
+nababbo
+nafta
+nanometro
+narciso
+narice
+narrato
+nascere
+nastrare
+naturale
+nautica
+naviglio
+nebulosa
+necrosi
+negativo
+negozio
+nemmeno
+neofita
+neretto
+nervo
+nessuno
+nettuno
+neutrale
+neve
+nevrotico
+nicchia
+ninfa
+nitido
+nobile
+nocivo
+nodo
+nome
+nomina
+nordico
+normale
+norvegese
+nostrano
+notare
+notizia
+notturno
+novella
+nucleo
+nulla
+numero
+nuovo
+nutrire
+nuvola
+nuziale
+oasi
+obbedire
+obbligo
+obelisco
+oblio
+obolo
+obsoleto
+occasione
+occhio
+occidente
+occorrere
+occultare
+ocra
+oculato
+odierno
+odorare
+offerta
+offrire
+offuscato
+oggetto
+oggi
+ognuno
+olandese
+olfatto
+oliato
+oliva
+ologramma
+oltre
+omaggio
+ombelico
+ombra
+omega
+omissione
+ondoso
+onere
+onice
+onnivoro
+onorevole
+onta
+operato
+opinione
+opposto
+oracolo
+orafo
+ordine
+orecchino
+orefice
+orfano
+organico
+origine
+orizzonte
+orma
+ormeggio
+ornativo
+orologio
+orrendo
+orribile
+ortensia
+ortica
+orzata
+orzo
+osare
+oscurare
+osmosi
+ospedale
+ospite
+ossa
+ossidare
+ostacolo
+oste
+otite
+otre
+ottagono
+ottimo
+ottobre
+ovale
+ovest
+ovino
+oviparo
+ovocito
+ovunque
+ovviare
+ozio
+pacchetto
+pace
+pacifico
+padella
+padrone
+paese
+paga
+pagina
+palazzina
+palesare
+pallido
+palo
+palude
+pandoro
+pannello
+paolo
+paonazzo
+paprica
+parabola
+parcella
+parere
+pargolo
+pari
+parlato
+parola
+partire
+parvenza
+parziale
+passivo
+pasticca
+patacca
+patologia
+pattume
+pavone
+peccato
+pedalare
+pedonale
+peggio
+peloso
+penare
+pendice
+penisola
+pennuto
+penombra
+pensare
+pentola
+pepe
+pepita
+perbene
+percorso
+perdonato
+perforare
+pergamena
+periodo
+permesso
+perno
+perplesso
+persuaso
+pertugio
+pervaso
+pesatore
+pesista
+peso
+pestifero
+petalo
+pettine
+petulante
+pezzo
+piacere
+pianta
+piattino
+piccino
+picozza
+piega
+pietra
+piffero
+pigiama
+pigolio
+pigro
+pila
+pilifero
+pillola
+pilota
+pimpante
+pineta
+pinna
+pinolo
+pioggia
+piombo
+piramide
+piretico
+pirite
+pirolisi
+pitone
+pizzico
+placebo
+planare
+plasma
+platano
+plenario
+pochezza
+poderoso
+podismo
+poesia
+poggiare
+polenta
+poligono
+pollice
+polmonite
+polpetta
+polso
+poltrona
+polvere
+pomice
+pomodoro
+ponte
+popoloso
+porfido
+poroso
+porpora
+porre
+portata
+posa
+positivo
+possesso
+postulato
+potassio
+potere
+pranzo
+prassi
+pratica
+precluso
+predica
+prefisso
+pregiato
+prelievo
+premere
+prenotare
+preparato
+presenza
+pretesto
+prevalso
+prima
+principe
+privato
+problema
+procura
+produrre
+profumo
+progetto
+prolunga
+promessa
+pronome
+proposta
+proroga
+proteso
+prova
+prudente
+prugna
+prurito
+psiche
+pubblico
+pudica
+pugilato
+pugno
+pulce
+pulito
+pulsante
+puntare
+pupazzo
+pupilla
+puro
+quadro
+qualcosa
+quasi
+querela
+quota
+raccolto
+raddoppio
+radicale
+radunato
+raffica
+ragazzo
+ragione
+ragno
+ramarro
+ramingo
+ramo
+randagio
+rantolare
+rapato
+rapina
+rappreso
+rasatura
+raschiato
+rasente
+rassegna
+rastrello
+rata
+ravveduto
+reale
+recepire
+recinto
+recluta
+recondito
+recupero
+reddito
+redimere
+regalato
+registro
+regola
+regresso
+relazione
+remare
+remoto
+renna
+replica
+reprimere
+reputare
+resa
+residente
+responso
+restauro
+rete
+retina
+retorica
+rettifica
+revocato
+riassunto
+ribadire
+ribelle
+ribrezzo
+ricarica
+ricco
+ricevere
+riciclato
+ricordo
+ricreduto
+ridicolo
+ridurre
+rifasare
+riflesso
+riforma
+rifugio
+rigare
+rigettato
+righello
+rilassato
+rilevato
+rimanere
+rimbalzo
+rimedio
+rimorchio
+rinascita
+rincaro
+rinforzo
+rinnovo
+rinomato
+rinsavito
+rintocco
+rinuncia
+rinvenire
+riparato
+ripetuto
+ripieno
+riportare
+ripresa
+ripulire
+risata
+rischio
+riserva
+risibile
+riso
+rispetto
+ristoro
+risultato
+risvolto
+ritardo
+ritegno
+ritmico
+ritrovo
+riunione
+riva
+riverso
+rivincita
+rivolto
+rizoma
+roba
+robotico
+robusto
+roccia
+roco
+rodaggio
+rodere
+roditore
+rogito
+rollio
+romantico
+rompere
+ronzio
+rosolare
+rospo
+rotante
+rotondo
+rotula
+rovescio
+rubizzo
+rubrica
+ruga
+rullino
+rumine
+rumoroso
+ruolo
+rupe
+russare
+rustico
+sabato
+sabbiare
+sabotato
+sagoma
+salasso
+saldatura
+salgemma
+salivare
+salmone
+salone
+saltare
+saluto
+salvo
+sapere
+sapido
+saporito
+saraceno
+sarcasmo
+sarto
+sassoso
+satellite
+satira
+satollo
+saturno
+savana
+savio
+saziato
+sbadiglio
+sbalzo
+sbancato
+sbarra
+sbattere
+sbavare
+sbendare
+sbirciare
+sbloccato
+sbocciato
+sbrinare
+sbruffone
+sbuffare
+scabroso
+scadenza
+scala
+scambiare
+scandalo
+scapola
+scarso
+scatenare
+scavato
+scelto
+scenico
+scettro
+scheda
+schiena
+sciarpa
+scienza
+scindere
+scippo
+sciroppo
+scivolo
+sclerare
+scodella
+scolpito
+scomparto
+sconforto
+scoprire
+scorta
+scossone
+scozzese
+scriba
+scrollare
+scrutinio
+scuderia
+scultore
+scuola
+scuro
+scusare
+sdebitare
+sdoganare
+seccatura
+secondo
+sedano
+seggiola
+segnalato
+segregato
+seguito
+selciato
+selettivo
+sella
+selvaggio
+semaforo
+sembrare
+seme
+seminato
+sempre
+senso
+sentire
+sepolto
+sequenza
+serata
+serbato
+sereno
+serio
+serpente
+serraglio
+servire
+sestina
+setola
+settimana
+sfacelo
+sfaldare
+sfamato
+sfarzoso
+sfaticato
+sfera
+sfida
+sfilato
+sfinge
+sfocato
+sfoderare
+sfogo
+sfoltire
+sforzato
+sfratto
+sfruttato
+sfuggito
+sfumare
+sfuso
+sgabello
+sgarbato
+sgonfiare
+sgorbio
+sgrassato
+sguardo
+sibilo
+siccome
+sierra
+sigla
+signore
+silenzio
+sillaba
+simbolo
+simpatico
+simulato
+sinfonia
+singolo
+sinistro
+sino
+sintesi
+sinusoide
+sipario
+sisma
+sistole
+situato
+slitta
+slogatura
+sloveno
+smarrito
+smemorato
+smentito
+smeraldo
+smilzo
+smontare
+smottato
+smussato
+snellire
+snervato
+snodo
+sobbalzo
+sobrio
+soccorso
+sociale
+sodale
+soffitto
+sogno
+soldato
+solenne
+solido
+sollazzo
+solo
+solubile
+solvente
+somatico
+somma
+sonda
+sonetto
+sonnifero
+sopire
+soppeso
+sopra
+sorgere
+sorpasso
+sorriso
+sorso
+sorteggio
+sorvolato
+sospiro
+sosta
+sottile
+spada
+spalla
+spargere
+spatola
+spavento
+spazzola
+specie
+spedire
+spegnere
+spelatura
+speranza
+spessore
+spettrale
+spezzato
+spia
+spigoloso
+spillato
+spinoso
+spirale
+splendido
+sportivo
+sposo
+spranga
+sprecare
+spronato
+spruzzo
+spuntino
+squillo
+sradicare
+srotolato
+stabile
+stacco
+staffa
+stagnare
+stampato
+stantio
+starnuto
+stasera
+statuto
+stelo
+steppa
+sterzo
+stiletto
+stima
+stirpe
+stivale
+stizzoso
+stonato
+storico
+strappo
+stregato
+stridulo
+strozzare
+strutto
+stuccare
+stufo
+stupendo
+subentro
+succoso
+sudore
+suggerito
+sugo
+sultano
+suonare
+superbo
+supporto
+surgelato
+surrogato
+sussurro
+sutura
+svagare
+svedese
+sveglio
+svelare
+svenuto
+svezia
+sviluppo
+svista
+svizzera
+svolta
+svuotare
+tabacco
+tabulato
+tacciare
+taciturno
+tale
+talismano
+tampone
+tannino
+tara
+tardivo
+targato
+tariffa
+tarpare
+tartaruga
+tasto
+tattico
+taverna
+tavolata
+tazza
+teca
+tecnico
+telefono
+temerario
+tempo
+temuto
+tendone
+tenero
+tensione
+tentacolo
+teorema
+terme
+terrazzo
+terzetto
+tesi
+tesserato
+testato
+tetro
+tettoia
+tifare
+tigella
+timbro
+tinto
+tipico
+tipografo
+tiraggio
+tiro
+titanio
+titolo
+titubante
+tizio
+tizzone
+toccare
+tollerare
+tolto
+tombola
+tomo
+tonfo
+tonsilla
+topazio
+topologia
+toppa
+torba
+tornare
+torrone
+tortora
+toscano
+tossire
+tostatura
+totano
+trabocco
+trachea
+trafila
+tragedia
+tralcio
+tramonto
+transito
+trapano
+trarre
+trasloco
+trattato
+trave
+treccia
+tremolio
+trespolo
+tributo
+tricheco
+trifoglio
+trillo
+trincea
+trio
+tristezza
+triturato
+trivella
+tromba
+trono
+troppo
+trottola
+trovare
+truccato
+tubatura
+tuffato
+tulipano
+tumulto
+tunisia
+turbare
+turchino
+tuta
+tutela
+ubicato
+uccello
+uccisore
+udire
+uditivo
+uffa
+ufficio
+uguale
+ulisse
+ultimato
+umano
+umile
+umorismo
+uncinetto
+ungere
+ungherese
+unicorno
+unificato
+unisono
+unitario
+unte
+uovo
+upupa
+uragano
+urgenza
+urlo
+usanza
+usato
+uscito
+usignolo
+usuraio
+utensile
+utilizzo
+utopia
+vacante
+vaccinato
+vagabondo
+vagliato
+valanga
+valgo
+valico
+valletta
+valoroso
+valutare
+valvola
+vampata
+vangare
+vanitoso
+vano
+vantaggio
+vanvera
+vapore
+varano
+varcato
+variante
+vasca
+vedetta
+vedova
+veduto
+vegetale
+veicolo
+velcro
+velina
+velluto
+veloce
+venato
+vendemmia
+vento
+verace
+verbale
+vergogna
+verifica
+vero
+verruca
+verticale
+vescica
+vessillo
+vestale
+veterano
+vetrina
+vetusto
+viandante
+vibrante
+vicenda
+vichingo
+vicinanza
+vidimare
+vigilia
+vigneto
+vigore
+vile
+villano
+vimini
+vincitore
+viola
+vipera
+virgola
+virologo
+virulento
+viscoso
+visione
+vispo
+vissuto
+visura
+vita
+vitello
+vittima
+vivanda
+vivido
+viziare
+voce
+voga
+volatile
+volere
+volpe
+voragine
+vulcano
+zampogna
+zanna
+zappato
+zattera
+zavorra
+zefiro
+zelante
+zelo
+zenzero
+zerbino
+zibetto
+zinco
+zircone
+zitto
+zolla
+zotico
+zucchero
+zufolo
+zulu
+zuppa

From 3b058bba32645a834c6da306db1a68d4a24ca236 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Sat, 30 Jan 2016 18:46:54 +0000
Subject: [PATCH 03/48] Initial draft of GBT updated for SegWit

---
 bip-segwit-gbt.mediawiki | 94 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 bip-segwit-gbt.mediawiki

diff --git a/bip-segwit-gbt.mediawiki b/bip-segwit-gbt.mediawiki
new file mode 100644
index 00000000..75b5097a
--- /dev/null
+++ b/bip-segwit-gbt.mediawiki
@@ -0,0 +1,94 @@
+<pre>
+  BIP: x
+  Title: getblocktemplate Updates for Segregated Witness
+  Author: Luke Dashjr <luke+bip22@dashjr.org>
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-30
+</pre>
+
+==Abstract==
+
+This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].
+
+==Specification==
+
+The notion of "cost" is introduced 
+
+===Block Template===
+
+The template Object is revised to include these keys:
+
+{| class="wikitable"
+!colspan=4| template
+|-
+! Key !! Required !! Type !! Description
+|-
+| costlimit || {{No}} || Number || total cost allowed in blocks
+|-
+| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4
+|-
+| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5)
+|}
+
+====Transactions Object Format====
+
+The Objects listed in the response's "transactions" key is revised to include these keys:
+
+{| class="wikitable"
+!colspan=3|template "transactions" element
+|-
+! Key !! Type !! Description
+|-
+| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data
+|-
+| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves
+|-
+| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal
+|}
+
+Transactions with witness data may only be included if the template's block version is at least 5.
+
+===Block Assembly with Witness Transactions===
+
+When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously.
+
+When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.
+
+Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.
+
+==Motivation==
+
+Segregated witness substatially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
+It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.
+
+==Rationale==
+
+Why doesn't "costlimit" simply redefine the existing "sizelimit"?
+* "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys.
+* Servers may wish to limit the overall size of a block, independently from the "cost" of the block.
+
+Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added?
+* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used.
+
+Why is "sigoplimit" divided by 4?
+* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?)
+
+Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else?
+* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it.
+
+Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data?
+* It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment.
+* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose.
+* BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data.
+
+==Reference Implementation==
+
+* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker]
+* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool]
+* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core]
+
+==See Also==
+* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
+* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
+* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]

From d3aa9b3f5759c7899ef2d9f11e5287d026507e6e Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 20:02:03 +0000
Subject: [PATCH 04/48] Fix typo

---
 bip-segwit-gbt.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-segwit-gbt.mediawiki b/bip-segwit-gbt.mediawiki
index 75b5097a..0ad10c28 100644
--- a/bip-segwit-gbt.mediawiki
+++ b/bip-segwit-gbt.mediawiki
@@ -59,7 +59,7 @@ Servers MUST NOT include a commitment in the "coinbasetxn" key on the template.
 
 ==Motivation==
 
-Segregated witness substatially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
+Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
 It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.
 
 ==Rationale==

From f31f7d43473fadcfafbc886b15e8c488654839c2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 20:14:22 +0000
Subject: [PATCH 05/48] Promote Accepted->Final BIPs 11, 14, 21, 22, 23, 31,
 32, 34, 35, 37, 65

---
 README.mediawiki   | 22 +++++++++++-----------
 bip-0011.mediawiki |  2 +-
 bip-0014.mediawiki |  2 +-
 bip-0021.mediawiki |  2 +-
 bip-0022.mediawiki |  2 +-
 bip-0023.mediawiki |  2 +-
 bip-0031.mediawiki |  2 +-
 bip-0032.mediawiki |  2 +-
 bip-0034.mediawiki |  2 +-
 bip-0035.mediawiki |  2 +-
 bip-0037.mediawiki |  2 +-
 bip-0065.mediawiki |  2 +-
 12 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbfd..4bfdc548 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -35,7 +35,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | M-of-N Standard Transactions
 | Gavin Andresen
 | Standard
-| Accepted
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0012.mediawiki|12]]
 | OP_EVAL
@@ -53,7 +53,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Protocol Version and User Agent
 | Amir Taaki, Patrick Strateman
 | Standard
-| Accepted
+| Final
 |- style="background-color: #ffcfcf"
 | [[bip-0015.mediawiki|15]]
 | Aliases
@@ -95,19 +95,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | URI Scheme
 | Nils Schneider, Matt Corallo
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0022.mediawiki|22]]
 | getblocktemplate - Fundamentals
 | Luke Dashjr
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0023.mediawiki|23]]
 | getblocktemplate - Pooled Mining
 | Luke Dashjr
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0030.mediawiki|30]]
 | Duplicate transactions
@@ -119,13 +119,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pong message
 | Mike Hearn
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0032.mediawiki|32]]
 | Hierarchical Deterministic Wallets
 | Pieter Wuille
 | Informational
-| Accepted
+| Final
 |-
 | [[bip-0033.mediawiki|33]]
 | Stratized Nodes
@@ -137,13 +137,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Block v2, Height in coinbase
 | Gavin Andresen
 | Standard
-| Accepted
+| Final
 |- style="background-color: #cfffcf"
 | [[bip-0035.mediawiki|35]]
 | mempool message
 | Jeff Garzik
 | Standard
-| Accepted
+| Final
 |-
 | [[bip-0036.mediawiki|36]]
 | Custom Services
@@ -155,7 +155,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Bloom filtering
 | Mike Hearn, Matt Corallo
 | Standard
-| Accepted
+| Final
 |-
 | [[bip-0038.mediawiki|38]]
 | Passphrase-protected private key
@@ -252,7 +252,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | OP_CHECKLOCKTIMEVERIFY
 | Peter Todd
 | Standard
-| Accepted
+| Final
 |-
 | [[bip-0066.mediawiki|66]]
 | Strict DER signatures
diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki
index 2499ac03..4b12340d 100644
--- a/bip-0011.mediawiki
+++ b/bip-0011.mediawiki
@@ -2,7 +2,7 @@
   BIP: 11
   Title: M-of-N Standard Transactions
   Author: Gavin Andresen <gavinandresen@gmail.com>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2011-10-18
   Post-History: 2011-10-02
diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki
index 111eb78b..cf7594b2 100644
--- a/bip-0014.mediawiki
+++ b/bip-0014.mediawiki
@@ -3,7 +3,7 @@
   Title: BIP Protocol Version and User Agent
   Author: Amir Taaki <genjix@riseup.net>
           Patrick Strateman <bitcoin-bips@covertinferno.org>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2011-11-10
   Post-History: 2011-11-02
diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index 27069264..4cbbc034 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -3,7 +3,7 @@
   Title: URI Scheme
   Author: Nils Schneider <nils.schneider@gmail.com>
           Matt Corallo <bip21@bluematt.me>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-01-29
 </pre>
diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki
index b39f9573..35b59be7 100644
--- a/bip-0022.mediawiki
+++ b/bip-0022.mediawiki
@@ -2,7 +2,7 @@
   BIP: 22
   Title: getblocktemplate - Fundamentals
   Author: Luke Dashjr <luke+bip22@dashjr.org>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-02-28
 </pre>
diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki
index a53b00bf..874e60a1 100644
--- a/bip-0023.mediawiki
+++ b/bip-0023.mediawiki
@@ -2,7 +2,7 @@
   BIP: 23
   Title: getblocktemplate - Pooled Mining
   Author: Luke Dashjr <luke+bip22@dashjr.org>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-02-28
 </pre>
diff --git a/bip-0031.mediawiki b/bip-0031.mediawiki
index 8adcd295..1bfe143c 100644
--- a/bip-0031.mediawiki
+++ b/bip-0031.mediawiki
@@ -2,7 +2,7 @@
   BIP: 31
   Title: Pong message
   Author: Mike Hearn <hearn@google.com>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-04-11
 </pre>
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index ac0ed991..52e20320 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -8,7 +8,7 @@ RECENT CHANGES:
   BIP: 32
   Title: Hierarchical Deterministic Wallets
   Author: Pieter Wuille
-  Status: Accepted
+  Status: Final
   Type: Informational
   Created: 2012-02-11
 </pre>
diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki
index 245985c7..1d88781d 100644
--- a/bip-0034.mediawiki
+++ b/bip-0034.mediawiki
@@ -2,7 +2,7 @@
   BIP: 34
   Title: Block v2, Height in Coinbase
   Author: Gavin Andresen <gavinandresen@gmail.com>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-07-06
 </pre>
diff --git a/bip-0035.mediawiki b/bip-0035.mediawiki
index cdadd1d7..c66735ca 100644
--- a/bip-0035.mediawiki
+++ b/bip-0035.mediawiki
@@ -2,7 +2,7 @@
   BIP: 35
   Title: mempool message
   Author: Jeff Garzik <jgarzik@exmulti.com>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-08-16
 </pre>
diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki
index 77b917b3..93296b5d 100644
--- a/bip-0037.mediawiki
+++ b/bip-0037.mediawiki
@@ -2,7 +2,7 @@
   BIP: 37
   Title: Connection Bloom filtering
   Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2012-10-24
 </pre>
diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index df995deb..99298bf1 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -2,7 +2,7 @@
   BIP: 65
   Title: OP_CHECKLOCKTIMEVERIFY
   Author: Peter Todd <pete@petertodd.org>
-  Status: Accepted
+  Status: Final
   Type: Standards Track
   Created: 2014-10-01
 </pre>

From ebba30aa86452590f2d505e0ed058f0b64586258 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 22:34:17 +0000
Subject: [PATCH 06/48] New BIP to revise BIP 1

---
 bip-biprevised.mediawiki | 91 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 bip-biprevised.mediawiki

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
new file mode 100644
index 00000000..7b3c00b4
--- /dev/null
+++ b/bip-biprevised.mediawiki
@@ -0,0 +1,91 @@
+<pre>
+  BIP: x
+  Title: BIP Status and Comments
+  Status: Draft
+  Type: Process
+  Created: 2016-02-01
+</pre>
+
+==Abstract==
+
+BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
+Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
+Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
+This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
+
+==Copyright==
+
+This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
+
+==Specification==
+
+===BIP status field===
+
+Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
+
+A BIP may only change status from Draft (or Rejected) to Accepted, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
+
+BIPs should be changed from Draft or Accepted status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Accepted status if it meets the criteria required as described in the previous paragraph.
+
+An Accepted BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
+
+When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
+
+A process BIP may change status from Draft to Active when it achieves consensus on the mailing list.
+
+====Progression to Final status====
+
+See BIP 123 for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
+
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+
+A hard-fork BIP requires consensus from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Consensus must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish pre-Final status consensus to adopt a BIP). This consensus cannot be reached merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
+
+Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
+
+API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
+
+Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [Bitcoin Core's doc/bips.md file](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) as well as [Bitcoin Wallet for Android's wallet/README.specs file](https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs).
+
+====Formally defining consensus====
+
+A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
+
+===BIP comments===
+
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+
+Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
+
+Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
+
+* Unanimously Recommended for implementation
+* Unanimously Discourage for implementation
+* Mostly Recommended for implementation, with some Discouragement
+* Mostly Discouraged for implementation, with some Recommendation
+
+To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
+
+===BIP licensing===
+
+New BIPs may be accepted with the following licenses:
+
+====Recommended licenses====
+
+* OSI-approved BSD 1, 2, or 3 clause licenses
+* Creative Commons CC0 1.0 Universal
+* GNU All-Permissive License
+
+====Not recommented, but acceptable licenses====
+
+* Apache License, version 2.0
+* Apple's Common Documentation License, version 1.0
+* Boost Software License, version 1.0
+* Creative Commons Attribution 4.0 International
+* Creative Commons Attribution-ShareAlike 4.0 International
+* Expat/MIT/X11 license
+* GNU Affero General Public License (AGPL), version 3
+* GNU Free Documentation License
+* GNU General Public License (GPL), version 2 or 3
+* GNU Lesser General Public License (LGPL), version 2.1 or 3
+* Open Publication License, version 1.0

From 6e34af58f9923f1af64c7a0b3d1920ad0ef69d25 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 23:18:33 +0000
Subject: [PATCH 07/48] bip-biprevised: See Also links

---
 bip-biprevised.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7b3c00b4..39853af3 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -35,7 +35,7 @@ A process BIP may change status from Draft to Active when it achieves consensus
 
 ====Progression to Final status====
 
-See BIP 123 for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
+See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
 A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
@@ -89,3 +89,8 @@ New BIPs may be accepted with the following licenses:
 * GNU General Public License (GPL), version 2 or 3
 * GNU Lesser General Public License (LGPL), version 2.1 or 3
 * Open Publication License, version 1.0
+
+==See Also==
+
+* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
+* [[bip-0123.mediawiki|BIP 123: BIP Classification]]

From c61f4d83009fa11bc72203e0ecdface08f4626f2 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 23:20:58 +0000
Subject: [PATCH 08/48] Bugfix: bip-biprevised: MediaWiki linking

---
 bip-biprevised.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 39853af3..efbfa78a 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -45,7 +45,7 @@ Peer services BIPs should be observed to be adopted by at least 1% of public lis
 
 API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications.
 
-Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [Bitcoin Core's doc/bips.md file](https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md) as well as [Bitcoin Wallet for Android's wallet/README.specs file](https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs).
+Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
 
 ====Formally defining consensus====
 

From cfbde44a3c7020ee26be39205ab685c383a3b4d1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 23:29:07 +0000
Subject: [PATCH 09/48] bip-biprevised: Link licenses, and remove obsolete
 Apple licence and non-existent OSI-approved 1-clause BSD license

---
 bip-biprevised.mediawiki | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index efbfa78a..07749629 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -72,23 +72,23 @@ New BIPs may be accepted with the following licenses:
 
 ====Recommended licenses====
 
-* OSI-approved BSD 1, 2, or 3 clause licenses
-* Creative Commons CC0 1.0 Universal
-* GNU All-Permissive License
+* [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
+* [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license]
+* [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
+* [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
 ====Not recommented, but acceptable licenses====
 
-* Apache License, version 2.0
-* Apple's Common Documentation License, version 1.0
-* Boost Software License, version 1.0
-* Creative Commons Attribution 4.0 International
-* Creative Commons Attribution-ShareAlike 4.0 International
-* Expat/MIT/X11 license
-* GNU Affero General Public License (AGPL), version 3
-* GNU Free Documentation License
-* GNU General Public License (GPL), version 2 or 3
-* GNU Lesser General Public License (LGPL), version 2.1 or 3
-* Open Publication License, version 1.0
+* [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
+* [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]
+* [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International]
+* [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
+* [https://opensource.org/licenses/MIT Expat/MIT/X11 license]
+* [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer]
+* [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License]
+* [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer]
+* [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
+* [http://opencontent.org/openpub/ Open Publication License, version 1.0]
 
 ==See Also==
 

From 97655c211a7454b4bcc01acefd4b88f979e7853f Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 23:49:37 +0000
Subject: [PATCH 10/48] bip-biprevised: Clarify licensing of literal code
 inclusion in BIPs

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 07749629..18ec1ddd 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -77,6 +77,8 @@ New BIPs may be accepted with the following licenses:
 * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
 * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
+In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text.
+
 ====Not recommented, but acceptable licenses====
 
 * [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]

From fe0870ed0630f663c6d2df8626780b5800241a56 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 00:37:08 +0000
Subject: [PATCH 11/48] bip-biprevised: Add Rationales and clarify literal code
 licensing

---
 bip-biprevised.mediawiki | 43 +++++++++++++++++++++++++++++++++++-----
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 18ec1ddd..93af1b8d 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -17,9 +17,9 @@ This BIP intends to address these problems by more specifically defining the Sta
 
 This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.
 
-==Specification==
+==BIP status field==
 
-===BIP status field===
+===Specification===
 
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
 
@@ -51,7 +51,24 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
 
-===BIP comments===
+===Rationale===
+
+Why can the economic consensus veto a soft-fork?
+
+* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.
+
+What is the ideal percentage of listening nodes needed to adopt peer services proposals?
+
+* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
+
+Should two software projects need to release an implementation of API/RPC and application layer BIPs?
+
+* With only one implementation of these, there is no other program for which a standard interface is used with or needed.
+* Even if there are only two projects, some standard coordination between them exists.
+
+==BIP comments==
+
+===Specification===
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 
@@ -66,10 +83,19 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
-===BIP licensing===
+===Rationale===
+
+Will BIP comments be censored or limited to particular participants/"experts"?
+
+* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
+* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed.
+
+==BIP licensing==
 
 New BIPs may be accepted with the following licenses:
 
+===Specification===
+
 ====Recommended licenses====
 
 * [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license]
@@ -77,7 +103,7 @@ New BIPs may be accepted with the following licenses:
 * [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal]
 * [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License]
 
-In addition, it is recommended that literal code included in the BIP be available under the same license terms as the project it modifies, when that license is acceptable within a BIP. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms (listed below, as not recommended but acceptable) as well as one of the above with the rest of the BIP text.
+In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
 ====Not recommented, but acceptable licenses====
 
@@ -92,6 +118,13 @@ In addition, it is recommended that literal code included in the BIP be availabl
 * [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer]
 * [http://opencontent.org/openpub/ Open Publication License, version 1.0]
 
+===Rationale===
+
+Why are there software licenses included?
+
+* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.
+* Despite this, not all software licenses would be acceptable for content included in BIPs.
+
 ==See Also==
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]

From 81741909838adc2e2c0f4d7f3c66f54a01e6e010 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 04:14:26 +0000
Subject: [PATCH 12/48] bip-biprevised: Add Rationale for defining of the
 economy

---
 bip-biprevised.mediawiki | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 93af1b8d..a4746de2 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -53,6 +53,17 @@ A proposal is said to have achieved consensus if it has been open to discussion
 
 ===Rationale===
 
+How is the entire Bitcoin economy defined by people selling goods/services and holders?
+
+* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
+
+Why aren't <x> included in the economy?
+
+* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as <x>) be involved in the economy.
+* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules.
+* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
+* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
+
 Why can the economic consensus veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.

From 9906db4b7a1ee58f688431f02af500de3ac351df Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 06:10:52 +0000
Subject: [PATCH 13/48] bip-biprevised: Add Rationale explaining how-it-is

---
 bip-biprevised.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index a4746de2..29de31a5 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -64,6 +64,10 @@ Why aren't <x> included in the economy?
 * Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges.
 * Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not.
 
+But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
+
+* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
+
 Why can the economic consensus veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.

From ae7cc37fe00e17e433a3b2d536737be5439c7ac0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 07:51:09 +0000
Subject: [PATCH 14/48] bip-biprevised: Address comments by Dave Scotese and
 Ryan Grant

---
 bip-biprevised.mediawiki | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 29de31a5..b9efbc64 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -49,7 +49,7 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 ====Formally defining consensus====
 
-A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion.
+A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.
 
 ===Rationale===
 
@@ -76,26 +76,35 @@ What is the ideal percentage of listening nodes needed to adopt peer services pr
 
 * This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.
 
-Should two software projects need to release an implementation of API/RPC and application layer BIPs?
+Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final?
 
-* With only one implementation of these, there is no other program for which a standard interface is used with or needed.
-* Even if there are only two projects, some standard coordination between them exists.
+* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed.
+* Even if there are only two projects rather than more, some standard coordination between them exists.
+
+What if a BIP is proposed that only makes sense for a single specific project?
+
+* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place.
 
 ==BIP comments==
 
 ===Specification===
 
-Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
+* No comments yet.
 * Unanimously Recommended for implementation
 * Unanimously Discourage for implementation
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation
 
+For example, the preamble to BIP 1 would be updated to include the (markup) line:
+
+    Comments: <nowiki>[https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 No comments yet.]</nowiki>
+
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 
 ===Rationale===

From ddd34bf496f2cbd1fad7e2ac14c080ffa1b88e0a Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 07:54:03 +0000
Subject: [PATCH 15/48] Bugfix: bip-biprevised: Preamble cannot use links due
 to <pre>

---
 bip-biprevised.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index b9efbc64..7c759954 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -103,7 +103,8 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 
 For example, the preamble to BIP 1 would be updated to include the (markup) line:
 
-    Comments: <nowiki>[https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 No comments yet.]</nowiki>
+    Comments-Summary: No comments yet.
+    Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 

From c79db0a9eced8e6baa76a7f16153572e5749321b Mon Sep 17 00:00:00 2001
From: emeth- <seanybob@gmail.com>
Date: Tue, 2 Feb 2016 06:19:47 -0600
Subject: [PATCH 16/48] fix typo

---
 bip-biprevised.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7c759954..094d156f 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -130,7 +130,7 @@ New BIPs may be accepted with the following licenses:
 
 In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text.
 
-====Not recommented, but acceptable licenses====
+====Not recommended, but acceptable licenses====
 
 * [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0]
 * [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0]

From 56eb7958bd380010117a68bb438c5683026ee6a5 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 19:03:28 +0000
Subject: [PATCH 17/48] bip-biprevised: Clarify informational nature of Final
 status change criteria

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 7c759954..174c9f9b 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -47,6 +47,8 @@ API/RPC and application layer BIPs must be implemented by at least two independe
 
 Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file].
 
+These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
+
 ====Formally defining consensus====
 
 A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.

From c5f9a101111276b5e27cbe2bca1cd4942ebca508 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 2 Feb 2016 19:07:14 +0000
Subject: [PATCH 18/48] bip-biprevised: Allow for a second forum for BIP
 comments

---
 bip-biprevised.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 174c9f9b..4e30f242 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -95,6 +95,8 @@ Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary ton
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
+In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may also choose to list a second forum for BIP comments.
+
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
 * No comments yet.

From 4edd6d2badd9a6ad2ff09bb6792fe0d0e365a7de Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 3 Feb 2016 07:02:36 +0000
Subject: [PATCH 19/48] Lots of formatting fixes

---
 README.mediawiki   | 98 +++++++++++++++++++++++-----------------------
 bip-0001.mediawiki |  1 +
 bip-0009.mediawiki |  7 +++-
 bip-0010.mediawiki |  4 +-
 bip-0014.mediawiki |  2 +-
 bip-0015.mediawiki |  2 +-
 bip-0032.mediawiki |  2 +-
 bip-0037.mediawiki |  3 +-
 bip-0038.mediawiki |  4 +-
 bip-0039.mediawiki | 16 ++++----
 bip-0043.mediawiki | 12 +++---
 bip-0044.mediawiki | 12 +++---
 bip-0045.mediawiki | 14 +++----
 bip-0047.mediawiki | 13 +++---
 bip-0067.mediawiki |  5 ++-
 bip-0069.mediawiki | 12 +++---
 bip-0070.mediawiki |  3 +-
 bip-0074.mediawiki |  3 ++
 bip-0080.mediawiki | 12 +++---
 bip-0081.mediawiki | 12 +++---
 bip-0083.mediawiki | 10 ++---
 bip-0099.mediawiki |  2 +-
 bip-0107.mediawiki |  2 +-
 bip-0111.mediawiki |  3 +-
 bip-0112.mediawiki |  6 +--
 bip-0113.mediawiki |  2 +-
 bip-0122.mediawiki |  2 +-
 bip-0123.mediawiki |  2 +-
 bip-0124.mediawiki | 12 +++---
 bip-0125.mediawiki |  3 +-
 bip-0132.mediawiki |  2 +-
 bip-0144.mediawiki |  2 +-
 32 files changed, 147 insertions(+), 138 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbfd..8067faee 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -24,13 +24,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
 | Informational
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0010.mediawiki|10]]
 | Multi-Sig Transaction Distribution
 | Alan Reiner
 | Informational
 | Withdrawn
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0011.mediawiki|11]]
 | M-of-N Standard Transactions
 | Gavin Andresen
@@ -48,13 +48,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Gavin Andresen
 | Standard
 | Final
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0014.mediawiki|14]]
 | Protocol Version and User Agent
 | Amir Taaki, Patrick Strateman
 | Standard
 | Accepted
-|- style="background-color: #ffcfcf"
+|-
 | [[bip-0015.mediawiki|15]]
 | Aliases
 | Amir Taaki
@@ -62,7 +62,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Deferred
 |- style="background-color: #cfffcf"
 | [[bip-0016.mediawiki|16]]
-| Pay To Script Hash
+| Pay to Script Hash
 | Gavin Andresen
 | Standard
 | Final
@@ -90,19 +90,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Luke Dashjr
 | Standard
 | Replaced
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0021.mediawiki|21]]
 | URI Scheme
 | Nils Schneider, Matt Corallo
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0022.mediawiki|22]]
 | getblocktemplate - Fundamentals
 | Luke Dashjr
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0023.mediawiki|23]]
 | getblocktemplate - Pooled Mining
 | Luke Dashjr
@@ -114,13 +114,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille
 | Standard
 | Final
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0031.mediawiki|31]]
 | Pong message
 | Mike Hearn
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0032.mediawiki|32]]
 | Hierarchical Deterministic Wallets
 | Pieter Wuille
@@ -132,13 +132,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Amir Taaki
 | Standard
 | Draft
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0034.mediawiki|34]]
-| Block v2, Height in coinbase
+| Block v2, Height in Coinbase
 | Gavin Andresen
 | Standard
 | Accepted
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0035.mediawiki|35]]
 | mempool message
 | Jeff Garzik
@@ -150,34 +150,34 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Stefan Thomas
 | Standard
 | Draft
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0037.mediawiki|37]]
-| Bloom filtering
+| Connection Bloom filtering
 | Mike Hearn, Matt Corallo
 | Standard
 | Accepted
 |-
 | [[bip-0038.mediawiki|38]]
 | Passphrase-protected private key
-| Mike Caldwell
+| Mike Caldwell, Aaron Voisine
 | Standard
 | Draft
 |-
 | [[bip-0039.mediawiki|39]]
 | Mnemonic code for generating deterministic keys
-| Slush
+| Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe
 | Standard
 | Draft
 |-
 | 40
 | Stratum wire protocol
-| Slush
+| Marek Palatinus
 | Standard
 | BIP number allocated
 |-
 | 41
 | Stratum mining protocol
-| Slush
+| Marek Palatinus
 | Standard
 | BIP number allocated
 |-
@@ -189,19 +189,19 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0043.mediawiki|43]]
 | Purpose Field for Deterministic Wallets
-| Slush
+| Marek Palatinus, Pavol Rusnak
 | Standard
 | Draft
 |-
 | [[bip-0044.mediawiki|44]]
 | Multi-Account Hierarchy for Deterministic Wallets
-| Slush
+| Marek Palatinus, Pavol Rusnak
 | Standard
 | Draft
 |-
 | [[bip-0045.mediawiki|45]]
 | Structure for Deterministic P2SH Multisignature Wallets
-| Manuel Araoz
+| Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
 | Standard
 | Draft
 |-
@@ -223,13 +223,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Amir Taaki
 | Standard
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0061.mediawiki|61]]
-| "reject" P2P message
+| Reject P2P message
 | Gavin Andresen
 | Standard
 | Final
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0062.mediawiki|62]]
 | Dealing with malleability
 | Pieter Wuille
@@ -243,80 +243,80 @@ Those proposing changes should consider that ultimately consent may rest with th
 | BIP number allocated
 |-
 | [[bip-0064.mediawiki|64]]
-| getutxos message
+| getutxo message
 | Mike Hearn
 | Standard
 | Draft
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0065.mediawiki|65]]
 | OP_CHECKLOCKTIMEVERIFY
 | Peter Todd
 | Standard
 | Accepted
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0066.mediawiki|66]]
 | Strict DER signatures
 | Pieter Wuille
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0067.mediawiki|67]]
-| Deterministic P2SH multi-signature addresses
-| Thomas Kerin
+| Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
+| Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
 | Standard
 | Draft
 |-
 | [[bip-0068.mediawiki|68]]
-| Relative lock-time through consensus-enforced sequence numbers
-| Mark Friedenbach, BtcDrak, Nicolas Dorier
+| Relative lock-time using consensus-enforced sequence numbers
+| Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona
 | Standard
 | Draft
 |-
 | [[bip-0069.mediawiki|69]]
 | Lexicographical Indexing of Transaction Inputs and Outputs
 | Kristov Atlas
-| Standard
+| Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0070.mediawiki|70]]
-| Payment protocol
-| Gavin Andresen
+| Payment Protocol
+| Gavin Andresen, Mike Hearn
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0071.mediawiki|71]]
-| Payment protocol MIME types
+| Payment Protocol MIME types
 | Gavin Andresen
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0072.mediawiki|72]]
-| Payment protocol URIs
+| bitcoin: uri extensions for Payment Protocol
 | Gavin Andresen
 | Standard
 | Final
 |-
 | [[bip-0073.mediawiki|73]]
-| Use "Accept" header with Payment Request URLs
+| Use "Accept" header for response type negotiation with Payment Request URLs
 | Stephen Pair
 | Standard
 | Draft
 |-
 | [[bip-0074.mediawiki|74]]
-| Support zero value OP_RETURN in Payment Requests
+| Allow zero value OP_RETURN in Payment Protocol
 | Toby Padilla
 | Standard
 | Draft
 |-
 | [[bip-0080.mediawiki|80]]
 | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-| Monetas
+| Justus Ranvier, Jimmy Song
 | Informational
 | Draft
 |-
 | [[bip-0081.mediawiki|81]]
 | Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
-| Monetas
+| Justus Ranvier, Jimmy Song
 | Informational
 | Draft
 |-
@@ -329,7 +329,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0099.mediawiki|99]]
 | Motivation and deployment of consensus rule changes ([soft/hard]forks)
 | Jorge Timón
-| Informational / Process
+| Informational
 | Draft
 |-
 | [[bip-0101.mediawiki|101]]
@@ -376,7 +376,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0112.mediawiki|112]]
 | CHECKSEQUENCEVERIFY
-| BtcDrak, Mark Friedenbach
+| BtcDrak, Mark Friedenbach, Eric Lombrozo
 | Standard
 | Draft
 |-
@@ -407,7 +407,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | [[bip-0123.mediawiki|123]]
 | BIP Classification
 | Eric Lombrozo
-| Informational
+| Process
 | Draft
 |-
 | [[bip-0124.mediawiki|124]]
@@ -418,7 +418,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0125.mediawiki|125]]
 | Opt-in Full Replace-by-Fee Signaling
-| David Harding, Peter Todd
+| David A. Harding, Peter Todd
 | Standard
 | Draft
 |-
diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index e1abaddc..4f91a394 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -1,6 +1,7 @@
 <pre>
   BIP: 1
   Title: BIP Purpose and Guidelines
+  Author: Amir Taaki <genjix@riseup.net>
   Status: Active
   Type: Process
   Created: 2011-08-19
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index b160810f..78298f09 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -1,9 +1,12 @@
 <pre>
   BIP: 9
   Title: Version bits with timeout and delay
-  Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au>
+  Author: Pieter Wuille <pieter.wuille@gmail.com>
+          Peter Todd <pete@petertodd.org>
+          Greg Maxwell <greg@xiph.org>
+          Rusty Russell <rusty@rustcorp.com.au>
   Status: Draft
-  Type: Informational Track
+  Type: Informational
   Created: 2015-10-04
 </pre>
 
diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki
index 4307f3e4..d15cd77e 100644
--- a/bip-0010.mediawiki
+++ b/bip-0010.mediawiki
@@ -1,8 +1,8 @@
 <pre>
   BIP: 10
   Title: Multi-Sig Transaction Distribution
-  Author: Alan Reiner
-  Status: Withdrawn 
+  Author: Alan Reiner <etotheipi@gmail.com>
+  Status: Withdrawn
   Type: Informational
   Created: 2011-10-28
 </pre>
diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki
index 111eb78b..2cfb3277 100644
--- a/bip-0014.mediawiki
+++ b/bip-0014.mediawiki
@@ -1,6 +1,6 @@
 <pre>
   BIP: 14
-  Title: BIP Protocol Version and User Agent
+  Title: Protocol Version and User Agent
   Author: Amir Taaki <genjix@riseup.net>
           Patrick Strateman <bitcoin-bips@covertinferno.org>
   Status: Accepted
diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki
index c08498f1..b90539da 100644
--- a/bip-0015.mediawiki
+++ b/bip-0015.mediawiki
@@ -1,6 +1,6 @@
 <pre>
   BIP: 15
-  Title: BIP Aliases
+  Title: Aliases
   Author: Amir Taaki <genjix@riseup.net>
   Status: Deferred
   Type: Standards Track
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index ac0ed991..ec5ddf4e 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -7,7 +7,7 @@ RECENT CHANGES:
 <pre>
   BIP: 32
   Title: Hierarchical Deterministic Wallets
-  Author: Pieter Wuille
+  Author: Pieter Wuille <pieter.wuille@gmail.com>
   Status: Accepted
   Type: Informational
   Created: 2012-02-11
diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki
index 77b917b3..224fef52 100644
--- a/bip-0037.mediawiki
+++ b/bip-0037.mediawiki
@@ -1,7 +1,8 @@
 <pre>
   BIP: 37
   Title: Connection Bloom filtering
-  Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me>
+  Author: Mike Hearn <hearn@google.com>
+          Matt Corallo <bip@bluematt.me>
   Status: Accepted
   Type: Standards Track
   Created: 2012-10-24
diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki
index 4fc3207b..6107e0a5 100644
--- a/bip-0038.mediawiki
+++ b/bip-0038.mediawiki
@@ -1,8 +1,8 @@
 <pre>
   BIP: 38
   Title: Passphrase-protected private key
-  Authors: Mike Caldwell
-           Aaron Voisine <voisine@gmail.com>
+  Author: Mike Caldwell <mcaldwell@swipeclock.com>
+          Aaron Voisine <voisine@gmail.com>
   Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
   Type: Standards Track
   Created: 2012-11-20
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index da59124c..c44ad3e8 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -1,12 +1,12 @@
 <pre>
-  BIP:     BIP-0039
-  Title:   Mnemonic code for generating deterministic keys
-  Authors: Marek Palatinus <slush@satoshilabs.com>
-           Pavol Rusnak <stick@satoshilabs.com>
-           Aaron Voisine <voisine@gmail.com>
-           Sean Bowe <ewillbefull@gmail.com>
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 39
+  Title: Mnemonic code for generating deterministic keys
+  Author: Marek Palatinus <slush@satoshilabs.com>
+          Pavol Rusnak <stick@satoshilabs.com>
+          Aaron Voisine <voisine@gmail.com>
+          Sean Bowe <ewillbefull@gmail.com>
+  Status: Draft
+  Type: Standards Track
   Created: 2013-09-10
 </pre>
 
diff --git a/bip-0043.mediawiki b/bip-0043.mediawiki
index 8f20fc8c..4c57935e 100644
--- a/bip-0043.mediawiki
+++ b/bip-0043.mediawiki
@@ -1,10 +1,10 @@
 <pre>
-  BIP:     BIP-0043
-  Title:   Purpose Field for Deterministic Wallets
-  Authors: Marek Palatinus <slush@satoshilabs.com>
-           Pavol Rusnak <stick@satoshilabs.com>
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 43
+  Title: Purpose Field for Deterministic Wallets
+  Author: Marek Palatinus <slush@satoshilabs.com>
+          Pavol Rusnak <stick@satoshilabs.com>
+  Status: Draft
+  Type: Standards Track
   Created: 2014-04-24
 </pre>
 
diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index ef7254c1..6012ff52 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -1,10 +1,10 @@
 <pre>
-  BIP:     BIP-0044
-  Title:   Multi-Account Hierarchy for Deterministic Wallets
-  Authors: Marek Palatinus <slush@satoshilabs.com>
-           Pavol Rusnak <stick@satoshilabs.com>
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 44
+  Title: Multi-Account Hierarchy for Deterministic Wallets
+  Author: Marek Palatinus <slush@satoshilabs.com>
+          Pavol Rusnak <stick@satoshilabs.com>
+  Status: Draft
+  Type: Standards Track
   Created: 2014-04-24
 </pre>
 
diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki
index f93319d4..1550467d 100644
--- a/bip-0045.mediawiki
+++ b/bip-0045.mediawiki
@@ -1,11 +1,11 @@
 <pre>
-  BIP:     BIP-0045
-  Title:   Structure for Deterministic P2SH Multisignature Wallets
-  Authors: Manuel Araoz <manu@bitpay.com>
-           Ryan X. Charles <ryan@bitpay.com>
-           Matias Alejo Garcia <matias@bitpay.com>
-  Status:  Draft
-  Type:    Standards Track
+  BIP: 45
+  Title: Structure for Deterministic P2SH Multisignature Wallets
+  Author: Manuel Araoz <manu@bitpay.com>
+          Ryan X. Charles <ryan@bitpay.com>
+          Matias Alejo Garcia <matias@bitpay.com>
+  Status: Draft
+  Type: Standards Track
   Created: 2014-04-25
 </pre>
 
diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index c3c50586..1a05730d 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,17 +1,14 @@
 RECENT CHANGES:
-
 * (18 Dec 2015) Update explanations to resolve FAQs
-
 * (12 Oct 2015) Revise blinding method for notification transactions
-
 * (21 Sep 2015) Correct base58check version byte
 
 <pre>
-  BIP:     47
-  Title:   Reusable Payment Codes for Hierarchical Deterministic Wallets
-  Authors: Justus Ranvier <justus@openbitcoinprivacyproject.org>
-  Status:  Draft
-  Type:    Informational
+  BIP: 47
+  Title: Reusable Payment Codes for Hierarchical Deterministic Wallets
+  Author: Justus Ranvier <justus@openbitcoinprivacyproject.org>
+  Status: Draft
+  Type: Informational
   Created: 2015-04-24
 </pre>
 
diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki
index 8be5c9b2..d26df9c5 100644
--- a/bip-0067.mediawiki
+++ b/bip-0067.mediawiki
@@ -1,8 +1,9 @@
-
 <pre>
   BIP: 67
   Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
-  Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
+  Author: Thomas Kerin <thomas@ribbit.me>
+          Jean-Pierre Rupp <root@haskoin.com>
+          Ruben de Vries <ruben@rubensayshi.com>
   Status: Draft
   Type: Standards Track
   Created: 2015-02-08
diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki
index e23ff042..0eca369f 100644
--- a/bip-0069.mediawiki
+++ b/bip-0069.mediawiki
@@ -1,10 +1,10 @@
 <pre>
-  BIP:     BIP: 69
-  Title:   Lexicographical Indexing of Transaction Inputs and Outputs
-  Authors: Kristov Atlas <kristov@openbitcoinprivacyproject.org>
-  Editors: Daniel Cousens <bips@dcousens.com>
-  Status:  Draft
-  Type:    Informational
+  BIP: 69
+  Title: Lexicographical Indexing of Transaction Inputs and Outputs
+  Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org>
+  Editor: Daniel Cousens <bips@dcousens.com>
+  Status: Draft
+  Type: Informational
   Created: 2015-06-12
 </pre>
 
diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 36427849..e3c17cf0 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -1,7 +1,8 @@
 <pre>
   BIP: 70
   Title: Payment Protocol
-  Authors: Gavin Andresen <gavinandresen@gmail.com>, Mike Hearn <mhearn@bitcoinfoundation.org>
+  Author: Gavin Andresen <gavinandresen@gmail.com>
+          Mike Hearn <mhearn@bitcoinfoundation.org>
   Status: Final
   Type: Standards Track
   Created: 2013-07-29
diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki
index 0790b12f..a860b381 100644
--- a/bip-0074.mediawiki
+++ b/bip-0074.mediawiki
@@ -2,6 +2,9 @@
   BIP: 74
   Title: Allow zero value OP_RETURN in Payment Protocol
   Author: Toby Padilla <tobypadilla@gmail.com>
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-29
 </pre>
 
 ==Abstract==
diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
index f28bb70f..7c13a6ed 100644
--- a/bip-0080.mediawiki
+++ b/bip-0080.mediawiki
@@ -1,10 +1,10 @@
 <pre>
-  BIP:     80
-  Title:   Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-  Authors: Justus Ranvier <justus@monetas.net>
-           Jimmy Song <jimmy@monetas.net>
-  Status:  Draft
-  Type:    Informational
+  BIP: 80
+  Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
+  Author: Justus Ranvier <justus@monetas.net>
+          Jimmy Song <jimmy@monetas.net>
+  Status: Draft
+  Type: Informational
   Created: 2014-08-11
 </pre>
 
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index 5157c094..774166ea 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -1,10 +1,10 @@
 <pre>
-  BIP:     81
-  Title:   Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
-  Authors: Justus Ranvier <justus@monetas.net>
-           Jimmy Song <jimmy@monetas.net>
-  Status:  Draft
-  Type:    Informational
+  BIP: 81
+  Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
+  Author: Justus Ranvier <justus@monetas.net>
+          Jimmy Song <jimmy@monetas.net>
+  Status: Draft
+  Type: Informational
   Created: 2014-08-11
 </pre>
 
diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki
index d1da6459..f6aa8e77 100644
--- a/bip-0083.mediawiki
+++ b/bip-0083.mediawiki
@@ -1,9 +1,9 @@
 <pre>
-  BIP:     BIP-83
-  Title:   Dynamic Hierarchical Deterministic Key Trees
-  Author:  Eric Lombrozo <eric@ciphrex.com>
-  Status:  Draft
-  Type:    Standard
+  BIP: 83
+  Title: Dynamic Hierarchical Deterministic Key Trees
+  Author: Eric Lombrozo <eric@ciphrex.com>
+  Status: Draft
+  Type: Standards Track
   Created: 2015-11-16
 </pre>
 
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki
index b416e686..3e0a43a8 100644
--- a/bip-0099.mediawiki
+++ b/bip-0099.mediawiki
@@ -3,7 +3,7 @@
   Title: Motivation and deployment of consensus rule changes ([soft/hard]forks)
   Author: Jorge Timón <jtimon@jtimon.cc>
   Status: Draft
-  Type: Informational / Process
+  Type: Informational
   Created: 2015-06-20
   Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
 </pre>
diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki
index 4e96173a..86edd995 100644
--- a/bip-0107.mediawiki
+++ b/bip-0107.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 107
   Title: Dynamic limit on the block size
-  Author: Dr Washington Y. Sanchez <washington.sanchez@gmail.com>
+  Author: Washington Y. Sanchez <washington.sanchez@gmail.com>
   Status: Draft
   Type: Standards Track
   Created: 2015-09-11
diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki
index d3bd630b..e0ae9e85 100644
--- a/bip-0111.mediawiki
+++ b/bip-0111.mediawiki
@@ -1,7 +1,8 @@
 <pre>
   BIP: 111
   Title: NODE_BLOOM service bit
-  Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org>
+  Author: Matt Corallo <bip@bluematt.me>
+          Peter Todd <pete@petertodd.org>
   Status: Draft
   Type: Standards Track
   Created: 2015-08-20
diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 643c6176..9c2d199a 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -1,9 +1,9 @@
 <pre>
   BIP: 112
   Title: CHECKSEQUENCEVERIFY
-  Authors: BtcDrak <btcdrak@gmail.com>
-           Mark Friedenbach <mark@friedenbach.org>
-           Eric Lombrozo <elombrozo@gmail.com>
+  Author: BtcDrak <btcdrak@gmail.com>
+          Mark Friedenbach <mark@friedenbach.org>
+          Eric Lombrozo <elombrozo@gmail.com>
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index 190fb4cc..15fa4f3f 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -2,7 +2,7 @@
   BIP: 113
   Title: Median time-past as endpoint for lock-time calculations
   Author: Thomas Kerin <me@thomaskerin.io>
-          Mark Friedenbach <mark@friedenbach.org>	
+          Mark Friedenbach <mark@friedenbach.org>
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki
index 17003aa5..5386dd27 100644
--- a/bip-0122.mediawiki
+++ b/bip-0122.mediawiki
@@ -4,7 +4,7 @@
   Author: Marco Pontello <marcopon@gmail.com>
   Status: Draft
   Type: Standards Track
-  Created: 29 August 2015
+  Created: 2015-08-29
   Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html
 </pre>
 
diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki
index 348c6c06..3d40326b 100644
--- a/bip-0123.mediawiki
+++ b/bip-0123.mediawiki
@@ -2,7 +2,7 @@
   BIP: 123
   Layer: Process
   Title: BIP Classification
-  Author: Eric Lombrozo
+  Author: Eric Lombrozo <elombrozo@gmail.com>
   Status: Draft
   Type: Process
   Created: 2015-08-26
diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki
index 1c98db87..2f9f4ad7 100644
--- a/bip-0124.mediawiki
+++ b/bip-0124.mediawiki
@@ -1,11 +1,11 @@
 <pre>
-  BIP:     BIP-124
-  Title:   Hierarchical Deterministic Script Templates
-  Authors: Eric Lombrozo <eric@ciphrex.com>, William Swanson
-  Status:  Draft
-  Type:    Informational
+  BIP: 124
+  Title: Hierarchical Deterministic Script Templates
+  Author: Eric Lombrozo <eric@ciphrex.com>
+          William Swanson <swansontec@gmail.com>
+  Status: Draft
+  Type: Informational
   Created: 2015-11-20
-
   Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html
 </pre>
 
diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki
index 63788e9d..7d884690 100644
--- a/bip-0125.mediawiki
+++ b/bip-0125.mediawiki
@@ -1,7 +1,8 @@
 <pre>
   BIP: 125
   Title: Opt-in Full Replace-by-Fee Signaling
-  Author: David A. Harding <dave@dtrt.org>, Peter Todd <pete@petertodd.org>
+  Author: David A. Harding <dave@dtrt.org>
+          Peter Todd <pete@petertodd.org>
   Status: Draft
   Type: Standards Track
   Created: 2015-12-04
diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki
index 814e20a5..90c09b1b 100644
--- a/bip-0132.mediawiki
+++ b/bip-0132.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 132
   Title: Committee-based BIP Acceptance Process
-  Author: Andy Chase
+  Author: Andy Chase <theandychase@gmail.com>
   Status: Draft
   Type: Process
   Created: 2015-08-31
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 9b2422bb..2da222cf 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -5,7 +5,7 @@
           Pieter Wuille <pieter.wuille@gmail.com>
   Status: Draft
   Type: Standards Track
-  Created: 2015-12
+  Created: 2016-01-08
 </pre>
 
 ==Abstract==

From 3cc727b99fddc8af5a64fa32edeaeb571ccb5b4b Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 3 Feb 2016 19:07:55 +0000
Subject: [PATCH 20/48] BIP 67: Update email for Thomas Kerin

---
 bip-0067.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki
index d26df9c5..3864c63c 100644
--- a/bip-0067.mediawiki
+++ b/bip-0067.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 67
   Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
-  Author: Thomas Kerin <thomas@ribbit.me>
+  Author: Thomas Kerin <me@thomaskerin.io>
           Jean-Pierre Rupp <root@haskoin.com>
           Ruben de Vries <ruben@rubensayshi.com>
   Status: Draft

From 37ef0f9f79295ae8f1cb1a5c7950e59c1302fef9 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 3 Feb 2016 19:20:12 +0000
Subject: [PATCH 21/48] bip-biprevised: Avoid "consensus" outside of "consensus
 rules", and move formal definition thereof to the only location it matters
 (Process BIPs becoming Active)

---
 bip-biprevised.mediawiki | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index 4e30f242..a7de3a1e 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -31,15 +31,15 @@ An Accepted BIP may progress to Final only when specific criteria reflecting rea
 
 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
 
-A process BIP may change status from Draft to Active when it achieves consensus on the mailing list.
+A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances.
 
 ====Progression to Final status====
 
 See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
-A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic consensus may reject a soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic agreement to block the soft-fork with a hard-fork, may be cause to reject that soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
-A hard-fork BIP requires consensus from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Consensus must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish pre-Final status consensus to adopt a BIP). This consensus cannot be reached merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
+A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
 
 Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
 
@@ -49,10 +49,6 @@ Software authors are encouraged to publish summaries of what BIPs their software
 
 These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status.
 
-====Formally defining consensus====
-
-A proposal is said to have achieved consensus if it has been open to discussion in applicable forums for communication for at least one month, and has not maintained any substantiated objection by any person. Should objections to be made on a strictly obstructive basis, those obstructing may be ignored/overruled by agreement that they are merely being obstructive from all other persons involved in the discussion. Objections are assumed to be either substantiated or obstructive, and when giving a determination of an objection being obstructive, clear reasoning must be offered.
-
 ===Rationale===
 
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
@@ -70,9 +66,9 @@ But they're doing something important and have invested a lot in Bitcoin! Should
 
 * This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
 
-Why can the economic consensus veto a soft-fork?
+How can economic agreement veto a soft-fork?
 
-* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economic consensus can decide to replace them with another group of would-be miners who do not support the soft-fork.
+* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
 
 What is the ideal percentage of listening nodes needed to adopt peer services proposals?
 
@@ -158,3 +154,4 @@ Why are there software licenses included?
 
 * [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]]
 * [[bip-0123.mediawiki|BIP 123: BIP Classification]]
+* [https://tools.ietf.org/html/rfc7282 RBF 7282: On Consensus and Humming in the IETF]

From 3f859450dd209796bf50bf344cb8bf0a212c5417 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 3 Feb 2016 21:09:08 +0000
Subject: [PATCH 22/48] BIP 80/81: Update email for Justus Ranvier

BIP 47/69 are fine as-is
---
 bip-0080.mediawiki | 2 +-
 bip-0081.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0080.mediawiki b/bip-0080.mediawiki
index 7c13a6ed..13d8597d 100644
--- a/bip-0080.mediawiki
+++ b/bip-0080.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 80
   Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
-  Author: Justus Ranvier <justus@monetas.net>
+  Author: Justus Ranvier <justus@opentransactions.org>
           Jimmy Song <jimmy@monetas.net>
   Status: Draft
   Type: Informational
diff --git a/bip-0081.mediawiki b/bip-0081.mediawiki
index 774166ea..b3060751 100644
--- a/bip-0081.mediawiki
+++ b/bip-0081.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 81
   Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
-  Author: Justus Ranvier <justus@monetas.net>
+  Author: Justus Ranvier <justus@opentransactions.org>
           Jimmy Song <jimmy@monetas.net>
   Status: Draft
   Type: Informational

From 04fce4aa75f6c69b57850070c2e837cd7671f233 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Thu, 4 Feb 2016 04:10:30 +0000
Subject: [PATCH 23/48] bip-biprevised: Clarify soft-fork blocking by ec.
 consensus

---
 bip-biprevised.mediawiki | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bip-biprevised.mediawiki b/bip-biprevised.mediawiki
index a7de3a1e..b496149a 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-biprevised.mediawiki
@@ -37,7 +37,7 @@ A process BIP may change status from Draft to Active when it achieves rough cons
 
 See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123.
 
-A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9), as well as not meeting the inverse criteria for a hard-fork BIP (that is, economic agreement to block the soft-fork with a hard-fork, may be cause to reject that soft-fork BIP despite miner adoption). Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
+A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold.
 
 A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document).
 
@@ -70,6 +70,10 @@ How can economic agreement veto a soft-fork?
 
 * The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork.
 
+What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later?
+
+* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork.
+
 What is the ideal percentage of listening nodes needed to adopt peer services proposals?
 
 * This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront.

From a2e87c208f45072f266f9d5788664209aaeccfcc Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Thu, 4 Feb 2016 04:12:03 +0000
Subject: [PATCH 24/48] Assign BIP 2: BIP Status and Comments

---
 README.mediawiki                               | 6 ++++++
 bip-biprevised.mediawiki => bip-0002.mediawiki | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)
 rename bip-biprevised.mediawiki => bip-0002.mediawiki (99%)

diff --git a/README.mediawiki b/README.mediawiki
index eda7fbfd..389d21e5 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -19,6 +19,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Process
 | Active
 |-
+| [[bip-0002.mediawiki|2]]
+| BIP Status and Comments
+| Luke Dashjr
+| Process
+| Draft
+|-
 | [[bip-0009.mediawiki|9]]
 | Version bits with timeout and delay
 | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
diff --git a/bip-biprevised.mediawiki b/bip-0002.mediawiki
similarity index 99%
rename from bip-biprevised.mediawiki
rename to bip-0002.mediawiki
index b496149a..ee3ae3a0 100644
--- a/bip-biprevised.mediawiki
+++ b/bip-0002.mediawiki
@@ -1,9 +1,10 @@
 <pre>
-  BIP: x
+  BIP: 2
   Title: BIP Status and Comments
+  Author: Luke Dashjr <luke+bip@dashjr.org>
   Status: Draft
   Type: Process
-  Created: 2016-02-01
+  Created: 2016-02-03
 </pre>
 
 ==Abstract==

From 2d909ad98a999a77bfcf8393a60166f1eabd22a4 Mon Sep 17 00:00:00 2001
From: Johnson Lau <jl2012@users.noreply.github.com>
Date: Fri, 5 Feb 2016 02:13:31 +0800
Subject: [PATCH 25/48] BIP34 correction

---
 bip-0034.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki
index 245985c7..3c0e770f 100644
--- a/bip-0034.mediawiki
+++ b/bip-0034.mediawiki
@@ -19,7 +19,7 @@ Bitcoin blocks and transactions are versioned binary structures. Both currently
 ==Specification==
 
 # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
-# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number.  Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
+# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit).  Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
 # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
 # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)
 

From 4a515ee2dc5917066a8b126187cd733f4d252a82 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Thu, 4 Feb 2016 20:38:33 +0000
Subject: [PATCH 26/48] Minor update of implementation for BIP68

This patch syncronised latest implementation
Adds comments, adds assert()
---
 bip-0068.mediawiki | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index e93d7488..3183cff6 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -89,10 +89,10 @@ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
 static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
     
 /**
- * Calculates the block height and time which the transaction must be later than
- * in order to be considered final in the context of BIP 68.  It also removes
- * from the vector of input heights any entries which did not correspond to sequence
- * locked inputs as they do not affect the calculation.
+ * Calculates the block height and previous block's median time past at
+ * which the transaction will be considered final in the context of BIP 68.
+ * Also removes from the vector of input heights any entries which did not
+ * correspond to sequence locked inputs as they do not affect the calculation.
  */
 static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeights, const CBlockIndex& block)
 {
@@ -134,6 +134,14 @@ static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, in
 
         if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) {
             int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast();
+            // NOTE: Subtract 1 to maintain nLockTime semantics
+            // BIP 68 relative lock times have the semantics of calculating
+            // the first block or time at which the transaction would be
+            // valid. When calculating the effective block time or height
+            // for the entire transaction, we switch to using the
+            // semantics of nLockTime which is the last invalid block
+            // time or height.  Thus we subtract 1 from the calculated
+            // time or height.
 
             // Time-based relative lock-times are measured from the
             // smallest allowed timestamp of the block containing the
@@ -141,10 +149,6 @@ static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, in
             // block prior.
             nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1);
         } else {
-            // We subtract 1 from relative lock-times because a lock-
-            // time of 0 has the semantics of "same block," so a lock-
-            // time of 1 should mean "next block," but nLockTime has
-            // the semantics of "last invalid block height."
             nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1);
         }
     }
@@ -154,7 +158,8 @@ static std::pair<int, int64_t> CalculateSequenceLocks(const CTransaction &tx, in
 
 static bool EvaluateSequenceLocks(const CBlockIndex& block, std::pair<int, int64_t> lockPair)
 {
-    int64_t nBlockTime = block.pprev ? block.pprev->GetMedianTimePast() : 0;
+    assert(block.pprev);
+    int64_t nBlockTime = block.pprev->GetMedianTimePast();
     if (lockPair.first >= block.nHeight || lockPair.second >= nBlockTime)
         return false;
 
@@ -189,7 +194,7 @@ bool CheckSequenceLocks(const CTransaction &tx, int flags)
         const CTxIn& txin = tx.vin[txinIndex];
         CCoins coins;
         if (!viewMemPool.GetCoins(txin.prevout.hash, coins)) {
-            return  error("%s: Missing input", __func__);
+            return error("%s: Missing input", __func__);
         }
         if (coins.nHeight == MEMPOOL_HEIGHT) {
             // Assume all mempool transaction confirm in the next block

From d21c27b96efc0072d4884fb321b3b171c340c4ac Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 5 Feb 2016 00:04:55 +0000
Subject: [PATCH 27/48] bip-0002: Clarify that BIP comments are intended for
 final reviews, not suggestions to drafts

---
 bip-0002.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index bf0a768f..6690bc28 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -92,7 +92,12 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 ===Specification===
 
-Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. If a BIP is not yet completed, reviewers should plan to review the new version and remove or revise their comments as applicable, updating the timestamp in the review. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
+Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
+The comments page should generally only be used to post final comments for a completed BIP.
+If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
+
+Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still cross-post their review on the comments page, provided they plan to review any new versions and remove or revise their comments as applicable. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 

From 8c50a8012ea4fcabf35f06683d7859c0bcef8e6c Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 5 Feb 2016 00:18:02 +0000
Subject: [PATCH 28/48] bip-0002: Rewrite Abstract, and move rationale
 previously included in it to the applicable Rationale sections

---
 bip-0002.mediawiki | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 6690bc28..4d3bab0b 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -9,10 +9,7 @@
 
 ==Abstract==
 
-BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion.
-Additionally, some BIPs have been adopted which are deemed unadvisable or unsafe by experts in the field, and there is no indication of this at present.
-Finally, BIP 1 only allows a single copyright license generally considered deprecated, or publication under the public domain (which is not legally recognised in all jurisdictions).
-This BIP intends to address these problems by more specifically defining the Status field, recommending a forum for people to comment on BIPs, and expanding the list of allowable BIP licenses.
+This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options.
 
 ==Copyright==
 
@@ -52,6 +49,10 @@ These criteria are considered objective ways to observe the de facto adoption of
 
 ===Rationale===
 
+Why is this necessary at all?
+
+* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date.
+
 How is the entire Bitcoin economy defined by people selling goods/services and holders?
 
 * For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price.
@@ -65,7 +66,7 @@ Why aren't <x> included in the economy?
 
 But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision?
 
-* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to enforce it. The BIP process does not aim to be a kind of "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
+* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*.
 
 How can economic agreement veto a soft-fork?
 
@@ -120,6 +121,10 @@ To avoid doubt: comments and status are unrelated metrics to judge a BIP, and ne
 
 ===Rationale===
 
+What is the purpose of BIP comments?
+
+* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion.
+
 Will BIP comments be censored or limited to particular participants/"experts"?
 
 * The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public.
@@ -155,6 +160,12 @@ In addition, it is recommended that literal code included in the BIP be dual-lic
 
 ===Rationale===
 
+BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient?
+
+* The OPL is generally regarded as obsolete, and not a license suitable for new publications.
+* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms.
+* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.
+
 Why are there software licenses included?
 
 * Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP.

From 438bb6bbab2822b1a093957b006f9f109b8a13e0 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 5 Feb 2016 00:22:05 +0000
Subject: [PATCH 29/48] bip-0002: Be more specific on how additional comments
 forums can be specified

---
 bip-0002.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 4d3bab0b..2558f205 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -102,7 +102,7 @@ Some BIPs receive exposure outside the development community prior to completion
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 
-In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may also choose to list a second forum for BIP comments.
+In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI.
 
 Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances:
 
@@ -112,10 +112,11 @@ Summary tones may be chosen from the following, but this BIP does not intend to
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation
 
-For example, the preamble to BIP 1 would be updated to include the (markup) line:
+For example, the preamble to BIP 1 might be updated to include the line:
 
     Comments-Summary: No comments yet.
     Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001
+                  https://some-other-wiki.org/BIP_1_Comments
 
 To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other.
 

From fc352d54e825c04527d5573bed90fb8a3463fe2f Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 5 Feb 2016 01:06:08 +0000
Subject: [PATCH 30/48] bip-0002: Be more explicit on the need for review to
 primarily occur on the ML during drafting

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 2558f205..571361c1 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -98,7 +98,7 @@ Reviewers of the BIP who consider themselves qualified, should post their own co
 The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
-Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still cross-post their review on the comments page, provided they plan to review any new versions and remove or revise their comments as applicable. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
+Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).
 
 Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 .
 

From 54a753d6c913077acd5621989fa51c04b88ea4ad Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 5 Feb 2016 01:08:39 +0000
Subject: [PATCH 31/48] bip-0002: Note that the comments must address the
 proposal itself

---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 571361c1..e5e50ba0 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -95,7 +95,7 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
-The comments page should generally only be used to post final comments for a completed BIP.
+The comments page should generally only be used to post final comments for a completed BIP, and must address the proposal itself (explicitly *not* including the merits of the author(s) nor discussions/processes involved in the drafting of it).
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).

From 32231cddc6db33f2557a0bd0e6a143b90c99203f Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 5 Feb 2016 01:32:59 +0000
Subject: [PATCH 32/48] Revert "bip-0002: Note that the comments must address
 the proposal itself"

This reverts commit 54a753d6c913077acd5621989fa51c04b88ea4ad.
---
 bip-0002.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index e5e50ba0..571361c1 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -95,7 +95,7 @@ What if a BIP is proposed that only makes sense for a single specific project?
 
 Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page.
 Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format].
-The comments page should generally only be used to post final comments for a completed BIP, and must address the proposal itself (explicitly *not* including the merits of the author(s) nor discussions/processes involved in the drafting of it).
+The comments page should generally only be used to post final comments for a completed BIP.
 If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review.
 
 Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month).

From 04bc8408cf146995470efbe03863316da53477c8 Mon Sep 17 00:00:00 2001
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 5 Feb 2016 20:30:12 -0800
Subject: [PATCH 33/48] BIP 68 Nit: fix spelling Contrats -> Contracts

---
 bip-0068.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 3183cff6..b7bb0db1 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -249,5 +249,5 @@ BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
 
 BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
 
-Hashed Timelock Contrats (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
+Hashed Timelock Contracts (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf
 

From 072173f3c5290a355e5696b669c3703fcdd47ae3 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 9 Feb 2016 04:56:36 +0000
Subject: [PATCH 34/48] bip-0050: Final update to what actually occurred

---
 bip-0050.mediawiki | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index 9ff29d6f..31070700 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -8,27 +8,29 @@
 </pre>
 
 ==What went wrong==
-A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.
+A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain).
 
-In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.
+In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain.
 
 During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend].  However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.
 
 ==What went right==
 * The split was detected very quickly.
-* The right people were online and available in IRC or could be raised via Skype.
-* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.
+* The right people were online and available in IRC or could be contacted directly.
+* Marek Palatinus (Slush) and Michael Marsee (Eleuthria of BTCGuild) quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money.
 * Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.
-* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money
+* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money.
 
 ==Root cause==
-Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
+Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:
 
 :The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.
 
+With the insufficiently high BDB lock configuration, it implicitly had become a network consensus rule determining block validity (albeit an inconsistent and unsafe rule, since the lock usage could vary from node to node).
+
 Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.
 
-Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.
+Bitcoin Core 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
 
 Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.
 
@@ -39,10 +41,10 @@ This would be an issue even if the entire network was running version 0.7.2. It
 ===Immediately===
 
 '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
-# Reject blocks that could cause more than 10,000 locks to be taken.
+# Reject blocks that would probably could cause more than 10,000 locks to be taken.
 # Limit the maximum block-size created to 500,000 bytes
-# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000
-# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.
+# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
+# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
 # Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.
 
 ===Alert system===
@@ -70,3 +72,7 @@ A double spend attack was successful, despite that both sides of the chain heard
 ===Resolution===
 
 On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.
+
+==Copyright==
+
+This document is placed in the public domain.

From 421577d6cf26bb21bebcb4da5f04e183d2859d0a Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 9 Feb 2016 05:12:38 +0000
Subject: [PATCH 35/48] Assign BIP 145: getblocktemplate Updates for Segregated
 Witness

---
 README.mediawiki                               | 6 ++++++
 bip-segwit-gbt.mediawiki => bip-0145.mediawiki | 6 +++++-
 2 files changed, 11 insertions(+), 1 deletion(-)
 rename bip-segwit-gbt.mediawiki => bip-0145.mediawiki (97%)

diff --git a/README.mediawiki b/README.mediawiki
index 045fd28f..b6e8fa49 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -463,6 +463,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Eric Lombrozo, Pieter Wuille
 | Standard
 | Draft
+|-
+| [[bip-0145.mediawiki|145]]
+| getblocktemplate Updates for Segregated Witness
+| Luke Dashjr
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-segwit-gbt.mediawiki b/bip-0145.mediawiki
similarity index 97%
rename from bip-segwit-gbt.mediawiki
rename to bip-0145.mediawiki
index 0ad10c28..9274b6cf 100644
--- a/bip-segwit-gbt.mediawiki
+++ b/bip-0145.mediawiki
@@ -1,5 +1,5 @@
 <pre>
-  BIP: x
+  BIP: 145
   Title: getblocktemplate Updates for Segregated Witness
   Author: Luke Dashjr <luke+bip22@dashjr.org>
   Status: Draft
@@ -92,3 +92,7 @@ Why shouldn't the server simply add the commitment upfront in the "coinbasetxn",
 * [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
 * [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
 * [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]
+
+==Copyright==
+
+This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.

From ebf5c289882d7128e71a91e0a5bd90c1e8e90464 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 3 Feb 2016 21:47:48 +0000
Subject: [PATCH 36/48] Travis: Initial formatting tests

---
 .travis.yml           |   7 +++
 scripts/buildtable.pl | 136 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 143 insertions(+)
 create mode 100644 .travis.yml
 create mode 100755 scripts/buildtable.pl

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 00000000..ed99de0f
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,7 @@
+os: linux
+language: generic
+sudo: false
+script:
+    - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1
+    - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true
+    - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
new file mode 100755
index 00000000..568b8eb0
--- /dev/null
+++ b/scripts/buildtable.pl
@@ -0,0 +1,136 @@
+#!/usr/bin/perl
+use strict;
+use warnings;
+
+my $topbip = 9999;
+
+my %RequiredFields = (
+	BIP => undef,
+	Title => undef,
+	Author => undef,
+	Status => undef,
+	Type => undef,
+	Created => undef,
+);
+my %MayHaveMulti = (
+	Author => undef,
+	'Post-History' => undef,
+);
+my %DateField = (
+	Created => undef,
+);
+my %EmailField = (
+	Author => undef,
+	Editor => undef,
+);
+my %MiscField = (
+	'Post-History' => undef,
+);
+
+my %ValidLayer = (
+	Process => undef,
+);
+my %ValidStatus = (
+	Draft => undef,
+	Deferred => undef,
+	Accepted => "background-color: #ffffcf",
+	Rejected => "background-color: #ffcfcf",
+	Withdrawn => "background-color: #ffcfcf",
+	Final => "background-color: #cfffcf",
+	Active => "background-color: #cfffcf",
+	Replaced => "background-color: #ffcfcf",
+);
+my %ValidType = (
+	'Standards Track' => 'Standard',
+	'Informational' => undef,
+	'Process' => undef,
+);
+
+my %emails;
+
+my $bipnum = 0;
+while (++$bipnum <= $topbip) {
+	my $fn = sprintf "bip-%04d.mediawiki", $bipnum;
+	-e $fn || next;
+	open my $F, "<$fn";
+	while (<$F> !~ m[^(?:\xef\xbb\xbf)?<pre>$]) {
+			die "No <pre> in $fn" if eof $F;
+	}
+	my %found;
+	my ($title, $author, $status, $type);
+	my ($field, $val);
+	while (<$F>) {
+		m[^</pre>$] && last;
+		if (m[^  ([\w-]+)\: (.*\S)$]) {
+			$field = $1;
+			$val = $2;
+			die "Duplicate $field field in $fn" if exists $found{$field};
+		} elsif (m[^  ( +)(.*\S)$]) {
+			die "Continuation of non-field in $fn" unless defined $field;
+			die "Too many spaces in $fn" if length $1 != 2 + length $field;
+			die "Not allowed for multi-value in $fn" unless exists $MayHaveMulti{$field};
+			$val = $2;
+		} else {
+			die "Bad line in $fn preamble";
+		}
+		++$found{$field};
+		die "Extra spaces in $fn" if $val =~ /^\s/;
+		if ($field eq 'BIP') {
+			die "$fn claims to be BIP $val" if $val ne $bipnum;
+		} elsif ($field eq 'Title') {
+			$title = $val;
+		} elsif ($field eq 'Author') {
+			$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn";
+			my ($authorname, $authoremail) = ($1, $2);
+			$authoremail =~ s/(?<=\D)$bipnum(?=\D)/<BIPNUM>/g;
+			$emails{$authorname}->{$authoremail} = undef;
+			if (defined $author) {
+				$author .= ", $authorname";
+			} else {
+				$author = $authorname;
+			}
+		} elsif ($field eq 'Status') {
+			if ($bipnum == 38) {  # HACK
+				$val =~ s/\s+\(.*\)$//;
+			}
+			die "Invalid status in $fn" unless exists $ValidStatus{$val};
+			$status = $val;
+		} elsif ($field eq 'Type') {
+			die "Invalid type in $fn" unless exists $ValidType{$val};
+			if (defined $ValidType{$val}) {
+				$type = $ValidType{$val};
+			} else {
+				$type = $val;
+			}
+		} elsif ($field eq 'Layer') {  # BIP 123
+			die "Invalid layer $val in $fn" unless exists $ValidLayer{$val};
+		} elsif (exists $DateField{$field}) {
+			die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/;
+		} elsif (exists $EmailField{$field}) {
+			$val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn";
+		} elsif (not exists $MiscField{$field}) {
+			die "Unknown field $field in $fn";
+		}
+	}
+	for my $field (keys %RequiredFields) {
+		die "Missing $field in $fn" unless $found{$field};
+	}
+	print "|-";
+	if (defined $ValidStatus{$status}) {
+		print " style=\"" . $ValidStatus{$status} . "\"";
+	}
+	print "\n";
+	print "| [[${fn}|${bipnum}]]\n";
+	print "| ${title}\n";
+	print "| ${author}\n";
+	print "| ${type}\n";
+	print "| ${status}\n";
+	close $F;
+}
+
+for my $author (sort keys %emails) {
+	my @emails = sort keys %{$emails{$author}};
+	my $email_count = @emails;
+	next unless $email_count > 1;
+	warn "NOTE: $author has $email_count email addresses: @emails\n";
+}

From 42777fed36a9482fc0d35733204b2fdaecec36b1 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 9 Feb 2016 05:26:28 +0000
Subject: [PATCH 37/48] bip-0145: Remove incomplete thought

---
 bip-0145.mediawiki | 2 --
 1 file changed, 2 deletions(-)

diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki
index 9274b6cf..b90725e0 100644
--- a/bip-0145.mediawiki
+++ b/bip-0145.mediawiki
@@ -13,8 +13,6 @@ This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-00
 
 ==Specification==
 
-The notion of "cost" is introduced 
-
 ===Block Template===
 
 The template Object is revised to include these keys:

From 37b988a035b25b75fb0c8cf0a36030a5756cb0e2 Mon Sep 17 00:00:00 2001
From: Dan Gershony <dan.gershony@gmail.com>
Date: Wed, 10 Feb 2016 17:23:28 +0000
Subject: [PATCH 38/48] Adding crypzo to BIP44 supported wallets

---
 bip-0044.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki
index 6012ff52..64358d8c 100644
--- a/bip-0044.mediawiki
+++ b/bip-0044.mediawiki
@@ -267,7 +267,7 @@ is required and a pull request to the above file should be created.
 * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]])
 * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]])
 * [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]])
-
+* [[https://www.crypzo.com/|Crypzo]] 
 ==Reference==
 
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]

From 0c0ac09ccf8586335ea93cd1d0ae550862a370e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E0=B8=BFtcDrak?= <btcdrak@users.noreply.github.com>
Date: Wed, 10 Feb 2016 17:25:52 +0000
Subject: [PATCH 39/48] Correct typo

Bitcoin Core didn't exist until 0.9.
---
 bip-0050.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index 31070700..a5953216 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -30,7 +30,7 @@ With the insufficiently high BDB lock configuration, it implicitly had become a
 
 Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.
 
-Bitcoin Core 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
+Bitcoin 0.8 did not use Berkeley DB. It switched to LevelDB instead, which did not implement the same locking limits as BDB. Therefore it was able to process the forking block successfully.
 
 Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.
 

From 6cf43331706934e6e5c97e4a57e0f6be8eb0899e Mon Sep 17 00:00:00 2001
From: Gavin Andresen <gavinandresen@gmail.com>
Date: Thu, 28 Jan 2016 10:53:43 -0500
Subject: [PATCH 40/48] BIP102 variation for a 2mb block size bump

---
 README.mediawiki   |  6 ++++
 bip-0109.mediawiki | 78 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 84 insertions(+)
 create mode 100644 bip-0109.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 3e9215de..13012595 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -374,6 +374,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0109.mediawiki|109]]
+| 2MB size limit with sigop and sighash limits
+| Gavin Andresen
+| Standard
+| Draft
+|-
 | [[bip-0111.mediawiki|111]]
 | NODE_BLOOM service bit
 | Matt Corallo, Peter Todd
diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
new file mode 100644
index 00000000..e7cf9e73
--- /dev/null
+++ b/bip-0109.mediawiki
@@ -0,0 +1,78 @@
+<pre>
+  BIP: 109
+  Title: Block size increase to 2MB
+  Author: Gavin Andresen <gavinandresen@gmail.com>
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-28
+</pre>
+
+==Abstract==
+
+One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing.
+
+==Motivation==
+
+# Continue current economic policy.
+# Exercise hard fork network upgrade.
+# Mitigate potential CPU exhaustion attacks
+
+==Specification==
+
+=== MAX_BLOCK_SIZE increased to 2,000,000 bytes ===
+
+The maximum number of bytes in a canonically serialized block shall be increased from
+1,000,000 bytes to 2,000,000 bytes.
+
+=== Switch to accurately-counted sigop limit of 20,000 per block ===
+
+The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained,
+but only ECDSA verifications actually performed to validate the block shall be counted.
+
+In particular:
+
+* The coinbase scriptSig is not counted
+* Signature operations in un-executed branches of a Script are not counted
+* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations.
+* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit
+
+=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block ===
+
+The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations.
+
+=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' ===
+
+Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits.
+
+As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support.
+
+=== Expiration: 1-Jan-2018 ===
+
+If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn.
+
+Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades.
+
+==Backward compatibility==
+
+Fully validating older clients are not compatible with this change.
+The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network.
+
+SPV (simple payment validation) wallets are compatible with this change.
+
+==Rationale==
+
+In the short term, an increase is needed to handle increasing transaction volume. 
+
+The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
+
+The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules:
+
+* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks
+* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion.
+* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade.
+
+==Implementation==
+
+https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump
+
+See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork

From c469bd930b3caca250f885785375474aacc55759 Mon Sep 17 00:00:00 2001
From: Gavin Andresen <gavinandresen@gmail.com>
Date: Thu, 11 Feb 2016 09:27:01 -0500
Subject: [PATCH 41/48] Add copyright

---
 bip-0109.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
index e7cf9e73..5e67e395 100644
--- a/bip-0109.mediawiki
+++ b/bip-0109.mediawiki
@@ -76,3 +76,7 @@ The choices of constants for the deployment scheme were motivated by prior exper
 https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump
 
 See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
+
+==Copyright==
+
+This work is placed in the public domain.

From 0e7466abc281aaf9b6f620b0c6004f8fae592df5 Mon Sep 17 00:00:00 2001
From: Gavin Andresen <gavinandresen@gmail.com>
Date: Thu, 11 Feb 2016 11:37:13 -0500
Subject: [PATCH 42/48] Tweaked BIP 109 title

---
 README.mediawiki   | 2 +-
 bip-0109.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 13012595..5a01d4d2 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -375,7 +375,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0109.mediawiki|109]]
-| 2MB size limit with sigop and sighash limits
+| Two million byte size limit with sigop and sighash limits
 | Gavin Andresen
 | Standard
 | Draft
diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki
index 5e67e395..667ef5f5 100644
--- a/bip-0109.mediawiki
+++ b/bip-0109.mediawiki
@@ -1,6 +1,6 @@
 <pre>
   BIP: 109
-  Title: Block size increase to 2MB
+  Title: Two million byte size limit with sigop and sighash limits
   Author: Gavin Andresen <gavinandresen@gmail.com>
   Status: Draft
   Type: Standards Track

From 0c956f8f64288b5a1a7c4c7c7d9f2beac74bb7cc Mon Sep 17 00:00:00 2001
From: Gavin Andresen <gavinandresen@gmail.com>
Date: Thu, 11 Feb 2016 15:25:06 -0500
Subject: [PATCH 43/48] Withdraw BIP 101 proposal

---
 README.mediawiki   | 2 +-
 bip-0101.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 3e9215de..d723f007 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -342,7 +342,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Increase maximum block size
 | Gavin Andresen
 | Standard
-| Draft
+| Withdrawn
 |-
 | [[bip-0102.mediawiki|102]]
 | Block size increase to 2MB
diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki
index a76db0f9..cc8cfd5f 100644
--- a/bip-0101.mediawiki
+++ b/bip-0101.mediawiki
@@ -2,7 +2,7 @@
   BIP: 101
   Title: Increase maximum block size
   Author: Gavin Andresen <gavinandresen@gmail.com>
-  Status: Draft
+  Status: Withdrawn
   Type: Standards Track
   Created: 2015-06-22
 </pre>

From 0e48a2466c18de67fa0e1c80facb9b7cdf598f3e Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Fri, 12 Feb 2016 04:10:24 +0000
Subject: [PATCH 44/48] Update BIP68 implementation to match spec

---
 bip-0068.mediawiki | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index b7bb0db1..fd17ea5d 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -64,21 +64,21 @@ enum {
 /* Setting nSequence to this value for every input in a transaction
  * disables nLockTime. */
 static const uint32_t SEQUENCE_FINAL = 0xffffffff;
-    
+
+/* Below flags apply in the context of BIP 68*/
 /* If this flag set, CTxIn::nSequence is NOT interpreted as a
- * relative lock-time. Setting the most significant bit of a
- * sequence number disabled relative lock-time. */
+ * relative lock-time. */
 static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31);
-    
+
 /* If CTxIn::nSequence encodes a relative lock-time and this flag
  * is set, the relative lock-time has units of 512 seconds,
  * otherwise it specifies blocks with a granularity of 1. */
 static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
-    
+
 /* If CTxIn::nSequence encodes a relative lock-time, this mask is
  * applied to extract that lock-time from the sequence field. */
 static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
-    
+
 /* In order to use the same number of bits to encode roughly the
  * same wall-clock duration, and because blocks are naturally
  * limited to occur every 600s on average, the minimum granularity
@@ -87,7 +87,7 @@ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
  * multiplying by 512 = 2^9, or equivalently shifting up by
  * 9 bits. */
 static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
-    
+
 /**
  * Calculates the block height and previous block's median time past at
  * which the transaction will be considered final in the context of BIP 68.
@@ -174,16 +174,17 @@ bool SequenceLocks(const CTransaction &tx, int flags, std::vector<int>* prevHeig
 bool CheckSequenceLocks(const CTransaction &tx, int flags)
 {
     AssertLockHeld(cs_main);
+    AssertLockHeld(mempool.cs);
 
     CBlockIndex* tip = chainActive.Tip();
     CBlockIndex index;
     index.pprev = tip;
     // CheckSequenceLocks() uses chainActive.Height()+1 to evaluate
     // height based locks because when SequenceLocks() is called within
-    // CBlock::AcceptBlock(), the height of the block *being*
-    // evaluated is what is used. Thus if we want to know if a
-    // transaction can be part of the *next* block, we need to call
-    // SequenceLocks() with one more than chainActive.Height().
+    // ConnectBlock(), the height of the block *being*
+    // evaluated is what is used.
+    // Thus if we want to know if a transaction can be part of the
+    // *next* block, we need to use one more than chainActive.Height()
     index.nHeight = tip->nHeight + 1;
 
     // pcoinsTip contains the UTXO set for chainActive.Tip()

From cde1e50d9d3cd522463216889485fe5324a4df3d Mon Sep 17 00:00:00 2001
From: paveljanik <Pavel@Janik.cz>
Date: Fri, 12 Feb 2016 18:52:13 +0100
Subject: [PATCH 45/48] ISM: Proper case

---
 bip-0112.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 9c2d199a..71fbc2a1 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -350,7 +350,7 @@ https://github.com/bitcoin/bitcoin/pull/6564
 
 ==Deployment==
 
-This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
+This BIP is to be deployed by either version-bits BIP9 or by IsSuperMajority(). Exact details TDB.
 
 It is recommended to deploy BIP68 and BIP113 at the same time as this BIP.
 

From 545017feb4bcb9ad00c435c528643a483d6ffa16 Mon Sep 17 00:00:00 2001
From: paveljanik <Pavel@Janik.cz>
Date: Fri, 12 Feb 2016 19:01:52 +0100
Subject: [PATCH 46/48] PR 6564 -> 7524

New PR number.
---
 bip-0112.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 71fbc2a1..cb9f2066 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -345,7 +345,7 @@ semantics and detailed rationale for those semantics.
 
 A reference implementation is provided by the following pull request:
 
-https://github.com/bitcoin/bitcoin/pull/6564
+https://github.com/bitcoin/bitcoin/pull/7524
 
 
 ==Deployment==

From 92586a1e3891bffd58046ea3eaa2fc682a82ecf4 Mon Sep 17 00:00:00 2001
From: Gavin Andresen <gavinandresen@gmail.com>
Date: Fri, 12 Feb 2016 17:33:05 -0500
Subject: [PATCH 47/48] Set background to withdrawn color

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index d723f007..32333af8 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -337,7 +337,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Jorge Timón
 | Informational
 | Draft
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0101.mediawiki|101]]
 | Increase maximum block size
 | Gavin Andresen

From a74ea14bc66d6be699f3e3d5aae2fa308ad7adad Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 1 Feb 2016 21:17:02 +0000
Subject: [PATCH 48/48] Promote Draft->Final BIPs: 50 and 73

BIP 50: Proposed action items, including the hardfork, are completed.

BIP 73: Implemented by at least Bitcoin Core and BitPay.
---
 README.mediawiki   | 8 ++++----
 bip-0050.mediawiki | 2 +-
 bip-0073.mediawiki | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index ce40a649..3c6b227d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -216,12 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0050.mediawiki|50]]
 | March 2013 Chain Fork Post-Mortem
 | Gavin Andresen
 | Informational
-| Draft
+| Final
 <!-- 50 series reserved for a group of post-mortems -->
 |-
 | [[bip-0060.mediawiki|60]]
@@ -301,12 +301,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Gavin Andresen
 | Standard
 | Final
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0073.mediawiki|73]]
 | Use "Accept" header for response type negotiation with Payment Request URLs
 | Stephen Pair
 | Standard
-| Draft
+| Final
 |-
 | [[bip-0074.mediawiki|74]]
 | Allow zero value OP_RETURN in Payment Protocol
diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki
index a5953216..4f48fcac 100644
--- a/bip-0050.mediawiki
+++ b/bip-0050.mediawiki
@@ -2,7 +2,7 @@
   BIP: 50
   Title: March 2013 Chain Fork Post-Mortem
   Author: Gavin Andresen <gavinandresen@gmail.com>
-  Status: Draft
+  Status: Final
   Type: Informational
   Created: 2013-03-20
 </pre>
diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki
index a020fb56..41c89a30 100644
--- a/bip-0073.mediawiki
+++ b/bip-0073.mediawiki
@@ -2,7 +2,7 @@
   BIP: 73
   Title: Use "Accept" header for response type negotiation with Payment Request URLs
   Author: Stephen Pair <stephen@bitpay.com>
-  Status: Draft
+  Status: Final
   Type: Standards Track
   Created: 2013-08-27
 </pre>