From 3d297861eb78db6151f282e4eaff0be4cd819aec Mon Sep 17 00:00:00 2001 From: "Dr. Maxim Orlovsky" Date: Mon, 7 Sep 2020 13:06:43 +0200 Subject: [PATCH 01/50] Require creator to initialize empty output fields The current version of the spec requires creator role to initialize empty input fields, but says nothing about output field initialization. At the same time, the following role, updater, "should also add redeemScripts, witnessScripts, and BIP 32 derivation paths to the input and output data if it knows them.", which does not make any sense if the fields were uninitialized. The [current Bitcoin Core implementation does this](https://github.com/bitcoin/bitcoin/blob/a24806c25d7a81a9c436de58eb5778d93abab16b/src/psbt.cpp#L12), and [other PSBT implementations, like rust-bitcoin, follow this practice](https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/psbt/mod.rs#L59) --- bip-0174.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 65fa9a97..9bb35c84 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -357,7 +357,7 @@ Using the transaction format involves many different responsibilities. Multiple ===Creator=== The Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT. -The Creator must create empty input fields. +The Creator must create empty input and output fields fields. ===Updater=== From d509aa2110cf46a697356f7a83c7356e7f5b2650 Mon Sep 17 00:00:00 2001 From: "Dr. Maxim Orlovsky" Date: Mon, 7 Sep 2020 18:38:23 +0200 Subject: [PATCH 02/50] BIP 174: removing extra "fields" word --- bip-0174.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 9bb35c84..80c7284b 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -357,7 +357,7 @@ Using the transaction format involves many different responsibilities. Multiple ===Creator=== The Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT. -The Creator must create empty input and output fields fields. +The Creator must create empty input and output fields. ===Updater=== From d353c54154bac64a88eb18cf2d47d15ead083de4 Mon Sep 17 00:00:00 2001 From: sabotag3x Date: Tue, 1 Sep 2020 10:58:18 -0300 Subject: [PATCH 03/50] Create portuguese.txt Co-authored-by: Breno Rodrigues Brito Co-authored-by: ninjastic Co-authored-by: sabotag3x Co-authored-by: bitmover <67111541+bitmover-studio@users.noreply.github.com> Co-authored-by: alegotardo <40860228+alegotardo@users.noreply.github.com> Co-authored-by: kuthullu Co-authored-by: Trimegistus --- bip-0039/bip-0039-wordlists.md | 17 + bip-0039/portuguese.txt | 2048 ++++++++++++++++++++++++++++++++ 2 files changed, 2065 insertions(+) create mode 100644 bip-0039/portuguese.txt diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 0940f35b..59711972 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -9,6 +9,7 @@ * [French](french.txt) * [Italian](italian.txt) * [Czech](czech.txt) +* [Portuguese](portuguese.txt) ## Wordlists (Special Considerations) @@ -98,3 +99,19 @@ Words chosen using the following rules: 6. No very similar words with 1 letter of difference. 7. Words are sorting according English alphabet (Czech sorting has difference in "ch"). 8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks. + +### Portuguese + +Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus + +1. Words can be uniquely determined typing the first 4 characters. +2. No accents or special characters. +3. No complex verb forms. +4. No plural words, unless there's no singular form. +5. No words with double spelling. +6. No words with the exact sound of another word with different spelling. +7. No offensive words. +8. No words already used in other language mnemonic sets. +9. The words which have not the same spelling in Brazil and in Portugal are excluded. +10. No words that remind negative/sad/bad things. +11. No very similar words with 1 letter of difference. diff --git a/bip-0039/portuguese.txt b/bip-0039/portuguese.txt new file mode 100644 index 00000000..4a891055 --- /dev/null +++ b/bip-0039/portuguese.txt @@ -0,0 +1,2048 @@ +abacate +abaixo +abalar +abater +abduzir +abelha +aberto +abismo +abotoar +abranger +abreviar +abrigar +abrupto +absinto +absoluto +absurdo +abutre +acabado +acalmar +acampar +acanhar +acaso +aceitar +acelerar +acenar +acervo +acessar +acetona +achatar +acidez +acima +acionado +acirrar +aclamar +aclive +acolhida +acomodar +acoplar +acordar +acumular +acusador +adaptar +adega +adentro +adepto +adequar +aderente +adesivo +adeus +adiante +aditivo +adjetivo +adjunto +admirar +adorar +adquirir +adubo +adverso +advogado +aeronave +afastar +aferir +afetivo +afinador +afivelar +aflito +afluente +afrontar +agachar +agarrar +agasalho +agenciar +agilizar +agiota +agitado +agora +agradar +agreste +agrupar +aguardar +agulha +ajoelhar +ajudar +ajustar +alameda +alarme +alastrar +alavanca +albergue +albino +alcatra +aldeia +alecrim +alegria +alertar +alface +alfinete +algum +alheio +aliar +alicate +alienar +alinhar +aliviar +almofada +alocar +alpiste +alterar +altitude +alucinar +alugar +aluno +alusivo +alvo +amaciar +amador +amarelo +amassar +ambas +ambiente +ameixa +amenizar +amido +amistoso +amizade +amolador +amontoar +amoroso +amostra +amparar +ampliar +ampola +anagrama +analisar +anarquia +anatomia +andaime +anel +anexo +angular +animar +anjo +anomalia +anotado +ansioso +anterior +anuidade +anunciar +anzol +apagador +apalpar +apanhado +apego +apelido +apertada +apesar +apetite +apito +aplauso +aplicada +apoio +apontar +aposta +aprendiz +aprovar +aquecer +arame +aranha +arara +arcada +ardente +areia +arejar +arenito +aresta +argiloso +argola +arma +arquivo +arraial +arrebate +arriscar +arroba +arrumar +arsenal +arterial +artigo +arvoredo +asfaltar +asilado +aspirar +assador +assinar +assoalho +assunto +astral +atacado +atadura +atalho +atarefar +atear +atender +aterro +ateu +atingir +atirador +ativo +atoleiro +atracar +atrevido +atriz +atual +atum +auditor +aumentar +aura +aurora +autismo +autoria +autuar +avaliar +avante +avaria +avental +avesso +aviador +avisar +avulso +axila +azarar +azedo +azeite +azulejo +babar +babosa +bacalhau +bacharel +bacia +bagagem +baiano +bailar +baioneta +bairro +baixista +bajular +baleia +baliza +balsa +banal +bandeira +banho +banir +banquete +barato +barbado +baronesa +barraca +barulho +baseado +bastante +batata +batedor +batida +batom +batucar +baunilha +beber +beijo +beirada +beisebol +beldade +beleza +belga +beliscar +bendito +bengala +benzer +berimbau +berlinda +berro +besouro +bexiga +bezerro +bico +bicudo +bienal +bifocal +bifurcar +bigorna +bilhete +bimestre +bimotor +biologia +biombo +biosfera +bipolar +birrento +biscoito +bisneto +bispo +bissexto +bitola +bizarro +blindado +bloco +bloquear +boato +bobagem +bocado +bocejo +bochecha +boicotar +bolada +boletim +bolha +bolo +bombeiro +bonde +boneco +bonita +borbulha +borda +boreal +borracha +bovino +boxeador +branco +brasa +braveza +breu +briga +brilho +brincar +broa +brochura +bronzear +broto +bruxo +bucha +budismo +bufar +bule +buraco +busca +busto +buzina +cabana +cabelo +cabide +cabo +cabrito +cacau +cacetada +cachorro +cacique +cadastro +cadeado +cafezal +caiaque +caipira +caixote +cajado +caju +calafrio +calcular +caldeira +calibrar +calmante +calota +camada +cambista +camisa +camomila +campanha +camuflar +canavial +cancelar +caneta +canguru +canhoto +canivete +canoa +cansado +cantar +canudo +capacho +capela +capinar +capotar +capricho +captador +capuz +caracol +carbono +cardeal +careca +carimbar +carneiro +carpete +carreira +cartaz +carvalho +casaco +casca +casebre +castelo +casulo +catarata +cativar +caule +causador +cautelar +cavalo +caverna +cebola +cedilha +cegonha +celebrar +celular +cenoura +censo +centeio +cercar +cerrado +certeiro +cerveja +cetim +cevada +chacota +chaleira +chamado +chapada +charme +chatice +chave +chefe +chegada +cheiro +cheque +chicote +chifre +chinelo +chocalho +chover +chumbo +chutar +chuva +cicatriz +ciclone +cidade +cidreira +ciente +cigana +cimento +cinto +cinza +ciranda +circuito +cirurgia +citar +clareza +clero +clicar +clone +clube +coado +coagir +cobaia +cobertor +cobrar +cocada +coelho +coentro +coeso +cogumelo +coibir +coifa +coiote +colar +coleira +colher +colidir +colmeia +colono +coluna +comando +combinar +comentar +comitiva +comover +complexo +comum +concha +condor +conectar +confuso +congelar +conhecer +conjugar +consumir +contrato +convite +cooperar +copeiro +copiador +copo +coquetel +coragem +cordial +corneta +coronha +corporal +correio +cortejo +coruja +corvo +cosseno +costela +cotonete +couro +couve +covil +cozinha +cratera +cravo +creche +credor +creme +crer +crespo +criada +criminal +crioulo +crise +criticar +crosta +crua +cruzeiro +cubano +cueca +cuidado +cujo +culatra +culminar +culpar +cultura +cumprir +cunhado +cupido +curativo +curral +cursar +curto +cuspir +custear +cutelo +damasco +datar +debater +debitar +deboche +debulhar +decalque +decimal +declive +decote +decretar +dedal +dedicado +deduzir +defesa +defumar +degelo +degrau +degustar +deitado +deixar +delator +delegado +delinear +delonga +demanda +demitir +demolido +dentista +depenado +depilar +depois +depressa +depurar +deriva +derramar +desafio +desbotar +descanso +desenho +desfiado +desgaste +desigual +deslize +desmamar +desova +despesa +destaque +desviar +detalhar +detentor +detonar +detrito +deusa +dever +devido +devotado +dezena +diagrama +dialeto +didata +difuso +digitar +dilatado +diluente +diminuir +dinastia +dinheiro +diocese +direto +discreta +disfarce +disparo +disquete +dissipar +distante +ditador +diurno +diverso +divisor +divulgar +dizer +dobrador +dolorido +domador +dominado +donativo +donzela +dormente +dorsal +dosagem +dourado +doutor +drenagem +drible +drogaria +duelar +duende +dueto +duplo +duquesa +durante +duvidoso +eclodir +ecoar +ecologia +edificar +edital +educado +efeito +efetivar +ejetar +elaborar +eleger +eleitor +elenco +elevador +eliminar +elogiar +embargo +embolado +embrulho +embutido +emenda +emergir +emissor +empatia +empenho +empinado +empolgar +emprego +empurrar +emulador +encaixe +encenado +enchente +encontro +endeusar +endossar +enfaixar +enfeite +enfim +engajado +engenho +englobar +engomado +engraxar +enguia +enjoar +enlatar +enquanto +enraizar +enrolado +enrugar +ensaio +enseada +ensino +ensopado +entanto +enteado +entidade +entortar +entrada +entulho +envergar +enviado +envolver +enxame +enxerto +enxofre +enxuto +epiderme +equipar +ereto +erguido +errata +erva +ervilha +esbanjar +esbelto +escama +escola +escrita +escuta +esfinge +esfolar +esfregar +esfumado +esgrima +esmalte +espanto +espelho +espiga +esponja +espreita +espumar +esquerda +estaca +esteira +esticar +estofado +estrela +estudo +esvaziar +etanol +etiqueta +euforia +europeu +evacuar +evaporar +evasivo +eventual +evidente +evoluir +exagero +exalar +examinar +exato +exausto +excesso +excitar +exclamar +executar +exemplo +exibir +exigente +exonerar +expandir +expelir +expirar +explanar +exposto +expresso +expulsar +externo +extinto +extrato +fabricar +fabuloso +faceta +facial +fada +fadiga +faixa +falar +falta +familiar +fandango +fanfarra +fantoche +fardado +farelo +farinha +farofa +farpa +fartura +fatia +fator +favorita +faxina +fazenda +fechado +feijoada +feirante +felino +feminino +fenda +feno +fera +feriado +ferrugem +ferver +festejar +fetal +feudal +fiapo +fibrose +ficar +ficheiro +figurado +fileira +filho +filme +filtrar +firmeza +fisgada +fissura +fita +fivela +fixador +fixo +flacidez +flamingo +flanela +flechada +flora +flutuar +fluxo +focal +focinho +fofocar +fogo +foguete +foice +folgado +folheto +forjar +formiga +forno +forte +fosco +fossa +fragata +fralda +frango +frasco +fraterno +freira +frente +fretar +frieza +friso +fritura +fronha +frustrar +fruteira +fugir +fulano +fuligem +fundar +fungo +funil +furador +furioso +futebol +gabarito +gabinete +gado +gaiato +gaiola +gaivota +galega +galho +galinha +galocha +ganhar +garagem +garfo +gargalo +garimpo +garoupa +garrafa +gasoduto +gasto +gata +gatilho +gaveta +gazela +gelado +geleia +gelo +gemada +gemer +gemido +generoso +gengiva +genial +genoma +genro +geologia +gerador +germinar +gesso +gestor +ginasta +gincana +gingado +girafa +girino +glacial +glicose +global +glorioso +goela +goiaba +golfe +golpear +gordura +gorjeta +gorro +gostoso +goteira +governar +gracejo +gradual +grafite +gralha +grampo +granada +gratuito +graveto +graxa +grego +grelhar +greve +grilo +grisalho +gritaria +grosso +grotesco +grudado +grunhido +gruta +guache +guarani +guaxinim +guerrear +guiar +guincho +guisado +gula +guloso +guru +habitar +harmonia +haste +haver +hectare +herdar +heresia +hesitar +hiato +hibernar +hidratar +hiena +hino +hipismo +hipnose +hipoteca +hoje +holofote +homem +honesto +honrado +hormonal +hospedar +humorado +iate +ideia +idoso +ignorado +igreja +iguana +ileso +ilha +iludido +iluminar +ilustrar +imagem +imediato +imenso +imersivo +iminente +imitador +imortal +impacto +impedir +implante +impor +imprensa +impune +imunizar +inalador +inapto +inativo +incenso +inchar +incidir +incluir +incolor +indeciso +indireto +indutor +ineficaz +inerente +infantil +infestar +infinito +inflamar +informal +infrator +ingerir +inibido +inicial +inimigo +injetar +inocente +inodoro +inovador +inox +inquieto +inscrito +inseto +insistir +inspetor +instalar +insulto +intacto +integral +intimar +intocado +intriga +invasor +inverno +invicto +invocar +iogurte +iraniano +ironizar +irreal +irritado +isca +isento +isolado +isqueiro +italiano +janeiro +jangada +janta +jararaca +jardim +jarro +jasmim +jato +javali +jazida +jejum +joaninha +joelhada +jogador +joia +jornal +jorrar +jovem +juba +judeu +judoca +juiz +julgador +julho +jurado +jurista +juro +justa +labareda +laboral +lacre +lactante +ladrilho +lagarta +lagoa +laje +lamber +lamentar +laminar +lampejo +lanche +lapidar +lapso +laranja +lareira +largura +lasanha +lastro +lateral +latido +lavanda +lavoura +lavrador +laxante +lazer +lealdade +lebre +legado +legendar +legista +leigo +leiloar +leitura +lembrete +leme +lenhador +lentilha +leoa +lesma +leste +letivo +letreiro +levar +leveza +levitar +liberal +libido +liderar +ligar +ligeiro +limitar +limoeiro +limpador +linda +linear +linhagem +liquidez +listagem +lisura +litoral +livro +lixa +lixeira +locador +locutor +lojista +lombo +lona +longe +lontra +lorde +lotado +loteria +loucura +lousa +louvar +luar +lucidez +lucro +luneta +lustre +lutador +luva +macaco +macete +machado +macio +madeira +madrinha +magnata +magreza +maior +mais +malandro +malha +malote +maluco +mamilo +mamoeiro +mamute +manada +mancha +mandato +manequim +manhoso +manivela +manobrar +mansa +manter +manusear +mapeado +maquinar +marcador +maresia +marfim +margem +marinho +marmita +maroto +marquise +marreco +martelo +marujo +mascote +masmorra +massagem +mastigar +matagal +materno +matinal +matutar +maxilar +medalha +medida +medusa +megafone +meiga +melancia +melhor +membro +memorial +menino +menos +mensagem +mental +merecer +mergulho +mesada +mesclar +mesmo +mesquita +mestre +metade +meteoro +metragem +mexer +mexicano +micro +migalha +migrar +milagre +milenar +milhar +mimado +minerar +minhoca +ministro +minoria +miolo +mirante +mirtilo +misturar +mocidade +moderno +modular +moeda +moer +moinho +moita +moldura +moleza +molho +molinete +molusco +montanha +moqueca +morango +morcego +mordomo +morena +mosaico +mosquete +mostarda +motel +motim +moto +motriz +muda +muito +mulata +mulher +multar +mundial +munido +muralha +murcho +muscular +museu +musical +nacional +nadador +naja +namoro +narina +narrado +nascer +nativa +natureza +navalha +navegar +navio +neblina +nebuloso +negativa +negociar +negrito +nervoso +neta +neural +nevasca +nevoeiro +ninar +ninho +nitidez +nivelar +nobreza +noite +noiva +nomear +nominal +nordeste +nortear +notar +noticiar +noturno +novelo +novilho +novo +nublado +nudez +numeral +nupcial +nutrir +nuvem +obcecado +obedecer +objetivo +obrigado +obscuro +obstetra +obter +obturar +ocidente +ocioso +ocorrer +oculista +ocupado +ofegante +ofensiva +oferenda +oficina +ofuscado +ogiva +olaria +oleoso +olhar +oliveira +ombro +omelete +omisso +omitir +ondulado +oneroso +ontem +opcional +operador +oponente +oportuno +oposto +orar +orbitar +ordem +ordinal +orfanato +orgasmo +orgulho +oriental +origem +oriundo +orla +ortodoxo +orvalho +oscilar +ossada +osso +ostentar +otimismo +ousadia +outono +outubro +ouvido +ovelha +ovular +oxidar +oxigenar +pacato +paciente +pacote +pactuar +padaria +padrinho +pagar +pagode +painel +pairar +paisagem +palavra +palestra +palheta +palito +palmada +palpitar +pancada +panela +panfleto +panqueca +pantanal +papagaio +papelada +papiro +parafina +parcial +pardal +parede +partida +pasmo +passado +pastel +patamar +patente +patinar +patrono +paulada +pausar +peculiar +pedalar +pedestre +pediatra +pedra +pegada +peitoral +peixe +pele +pelicano +penca +pendurar +peneira +penhasco +pensador +pente +perceber +perfeito +pergunta +perito +permitir +perna +perplexo +persiana +pertence +peruca +pescado +pesquisa +pessoa +petiscar +piada +picado +piedade +pigmento +pilastra +pilhado +pilotar +pimenta +pincel +pinguim +pinha +pinote +pintar +pioneiro +pipoca +piquete +piranha +pires +pirueta +piscar +pistola +pitanga +pivete +planta +plaqueta +platina +plebeu +plumagem +pluvial +pneu +poda +poeira +poetisa +polegada +policiar +poluente +polvilho +pomar +pomba +ponderar +pontaria +populoso +porta +possuir +postal +pote +poupar +pouso +povoar +praia +prancha +prato +praxe +prece +predador +prefeito +premiar +prensar +preparar +presilha +pretexto +prevenir +prezar +primata +princesa +prisma +privado +processo +produto +profeta +proibido +projeto +prometer +propagar +prosa +protetor +provador +publicar +pudim +pular +pulmonar +pulseira +punhal +punir +pupilo +pureza +puxador +quadra +quantia +quarto +quase +quebrar +queda +queijo +quente +querido +quimono +quina +quiosque +rabanada +rabisco +rachar +racionar +radial +raiar +rainha +raio +raiva +rajada +ralado +ramal +ranger +ranhura +rapadura +rapel +rapidez +raposa +raquete +raridade +rasante +rascunho +rasgar +raspador +rasteira +rasurar +ratazana +ratoeira +realeza +reanimar +reaver +rebaixar +rebelde +rebolar +recado +recente +recheio +recibo +recordar +recrutar +recuar +rede +redimir +redonda +reduzida +reenvio +refinar +refletir +refogar +refresco +refugiar +regalia +regime +regra +reinado +reitor +rejeitar +relativo +remador +remendo +remorso +renovado +reparo +repelir +repleto +repolho +represa +repudiar +requerer +resenha +resfriar +resgatar +residir +resolver +respeito +ressaca +restante +resumir +retalho +reter +retirar +retomada +retratar +revelar +revisor +revolta +riacho +rica +rigidez +rigoroso +rimar +ringue +risada +risco +risonho +robalo +rochedo +rodada +rodeio +rodovia +roedor +roleta +romano +roncar +rosado +roseira +rosto +rota +roteiro +rotina +rotular +rouco +roupa +roxo +rubro +rugido +rugoso +ruivo +rumo +rupestre +russo +sabor +saciar +sacola +sacudir +sadio +safira +saga +sagrada +saibro +salada +saleiro +salgado +saliva +salpicar +salsicha +saltar +salvador +sambar +samurai +sanar +sanfona +sangue +sanidade +sapato +sarda +sargento +sarjeta +saturar +saudade +saxofone +sazonal +secar +secular +seda +sedento +sediado +sedoso +sedutor +segmento +segredo +segundo +seiva +seleto +selvagem +semanal +semente +senador +senhor +sensual +sentado +separado +sereia +seringa +serra +servo +setembro +setor +sigilo +silhueta +silicone +simetria +simpatia +simular +sinal +sincero +singular +sinopse +sintonia +sirene +siri +situado +soberano +sobra +socorro +sogro +soja +solda +soletrar +solteiro +sombrio +sonata +sondar +sonegar +sonhador +sono +soprano +soquete +sorrir +sorteio +sossego +sotaque +soterrar +sovado +sozinho +suavizar +subida +submerso +subsolo +subtrair +sucata +sucesso +suco +sudeste +sufixo +sugador +sugerir +sujeito +sulfato +sumir +suor +superior +suplicar +suposto +suprimir +surdina +surfista +surpresa +surreal +surtir +suspiro +sustento +tabela +tablete +tabuada +tacho +tagarela +talher +talo +talvez +tamanho +tamborim +tampa +tangente +tanto +tapar +tapioca +tardio +tarefa +tarja +tarraxa +tatuagem +taurino +taxativo +taxista +teatral +tecer +tecido +teclado +tedioso +teia +teimar +telefone +telhado +tempero +tenente +tensor +tentar +termal +terno +terreno +tese +tesoura +testado +teto +textura +texugo +tiara +tigela +tijolo +timbrar +timidez +tingido +tinteiro +tiragem +titular +toalha +tocha +tolerar +tolice +tomada +tomilho +tonel +tontura +topete +tora +torcido +torneio +torque +torrada +torto +tostar +touca +toupeira +toxina +trabalho +tracejar +tradutor +trafegar +trajeto +trama +trancar +trapo +traseiro +tratador +travar +treino +tremer +trepidar +trevo +triagem +tribo +triciclo +tridente +trilogia +trindade +triplo +triturar +triunfal +trocar +trombeta +trova +trunfo +truque +tubular +tucano +tudo +tulipa +tupi +turbo +turma +turquesa +tutelar +tutorial +uivar +umbigo +unha +unidade +uniforme +urologia +urso +urtiga +urubu +usado +usina +usufruir +vacina +vadiar +vagaroso +vaidoso +vala +valente +validade +valores +vantagem +vaqueiro +varanda +vareta +varrer +vascular +vasilha +vassoura +vazar +vazio +veado +vedar +vegetar +veicular +veleiro +velhice +veludo +vencedor +vendaval +venerar +ventre +verbal +verdade +vereador +vergonha +vermelho +verniz +versar +vertente +vespa +vestido +vetorial +viaduto +viagem +viajar +viatura +vibrador +videira +vidraria +viela +viga +vigente +vigiar +vigorar +vilarejo +vinco +vinheta +vinil +violeta +virada +virtude +visitar +visto +vitral +viveiro +vizinho +voador +voar +vogal +volante +voleibol +voltagem +volumoso +vontade +vulto +vuvuzela +xadrez +xarope +xeque +xeretar +xerife +xingar +zangado +zarpar +zebu +zelador +zombar +zoologia +zumbido From dfa5042dc57bde230dea7a74f151efe58c632586 Mon Sep 17 00:00:00 2001 From: richard <36215881+hoganri@users.noreply.github.com> Date: Fri, 16 Oct 2020 21:18:20 -0400 Subject: [PATCH 04/50] Update bip-0085.mediawiki --- bip-0085.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7c4cbcab..659d5fc2 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -72,6 +72,7 @@ OUTPUT ==Reference Implementation== Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy] +JavaScript library implementation: [https://github.com/hoganri/bip85-js] ===Other Implementations=== From 9a119ce46af235a7711c137f8683e5c499cca026 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Sat, 17 Oct 2020 17:47:19 +1000 Subject: [PATCH 05/50] BIP8: Make signalling during LOCKED_IN recommended rather than mandatory --- bip-0008.mediawiki | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index dc2291a1..565331b0 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -77,12 +77,13 @@ for the purposes of this proposal, and support two future upgrades for different When a block nVersion does not have top bits 001, it is treated as if all bits are 0 for the purposes of deployments. +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules. + ===New consensus rules=== The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. -During the MUST_SIGNAL and LOCKED_IN phases, blocks that fail to signal are invalid. -For flexibility, during the LOCKED_IN phase only, this rule does NOT require the top 3 bits to be set any particular way. +During the MUST_SIGNAL phase, blocks that fail to signal are invalid. ===State transitions=== @@ -174,18 +175,13 @@ block, indexed by its parent. ===Mandatory signalling=== -Blocks received while in the MUST_SIGNAL and LOCKED_IN phases must be checked to ensure that they signal. For example: +Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal. For example: if (GetStateForBlock(block) == MUST_SIGNAL) { if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) { return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); } } - if (GetStateForBlock(block) == LOCKED_IN) { - if (((block.nVersion >> bit) & 1) != 1) { - return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-locked-in"); - } - } Implementations should be careful not to ban peers that send blocks that are invalid due to not signalling (or blocks that build on those blocks), as that would allow an incompatible chain that is only briefly longer than the compliant chain to cause a split of the p2p network. If that occurred, nodes that have not set ''lockinontimeout'' may not see new blocks in the compliant chain, and thus not reorg to it at the point when it has more work, and would thus not be following the valid chain with the most work. @@ -224,7 +220,7 @@ The template Object is also extended: The "version" key of the template is retained, and used to indicate the server's preference of deployments. If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". -Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL and LOCKED_IN states, to ensure blocks produced are valid. +Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid. Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. From afe97b2eeeeaf8cd1a0658bb191da15b36a4dd3a Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Sat, 17 Oct 2020 18:18:27 +1000 Subject: [PATCH 06/50] BIP8: allow some MUST_SIGNAL blocks to not signal Using the same threshold for MUST_SIGNAL as STARTED means that any chain that would have resulted in activation with lockinontimeout=false will also result in activation with lockinontimeout=true (and vice-versa). This reduces the ways in which a consensus split can occur, and avoids a way in which miners could attempt to discourage users from setting lockinontimeout=true. --- bip-0008.mediawiki | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 565331b0..394b80d2 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -83,7 +83,7 @@ Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. -During the MUST_SIGNAL phase, blocks that fail to signal are invalid. +During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid. ===State transitions=== @@ -175,11 +175,23 @@ block, indexed by its parent. ===Mandatory signalling=== -Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal. For example: +Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example: if (GetStateForBlock(block) == MUST_SIGNAL) { - if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) { - return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); + int nonsignal = 0; + int count = 1 + (block.nHeight % 2016); + walk = block; + while (count > 0) { + --count; + if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) { + ++nonsignal; + if (nonsignal + threshold > 2016) { + return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); + } + } else if (nonsignal == 0) { + break; + } + walk = walk.parent; } } From 77ed66afd5331414ee0d46611d612bb24eb78693 Mon Sep 17 00:00:00 2001 From: richard <36215881+hoganri@users.noreply.github.com> Date: Wed, 21 Oct 2020 20:31:29 -0400 Subject: [PATCH 07/50] Update bip-0085.mediawiki --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 659d5fc2..b6c13332 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -71,7 +71,7 @@ OUTPUT ==Reference Implementation== -Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy] +Python library implementation: [https://github.com/ethankosakovsky/bip85] JavaScript library implementation: [https://github.com/hoganri/bip85-js] ===Other Implementations=== From d771818c9e96b1d9bfa62efdee3a24ae903a7a03 Mon Sep 17 00:00:00 2001 From: richard <36215881+hoganri@users.noreply.github.com> Date: Wed, 21 Oct 2020 21:41:59 -0400 Subject: [PATCH 08/50] Update formatting --- bip-0085.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index b6c13332..40cff9b3 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -71,12 +71,12 @@ OUTPUT ==Reference Implementation== -Python library implementation: [https://github.com/ethankosakovsky/bip85] -JavaScript library implementation: [https://github.com/hoganri/bip85-js] +* Python library implementation: [https://github.com/ethankosakovsky/bip85] +* JavaScript library implementation: [https://github.com/hoganri/bip85-js] ===Other Implementations=== -Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] +* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] ==Applications== From 8744a4dd11e207953e2544d40fab3c7204434031 Mon Sep 17 00:00:00 2001 From: Rita Kitic Date: Tue, 27 Oct 2020 19:15:49 +0100 Subject: [PATCH 09/50] fix typo --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7c4cbcab..02b1879b 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -81,7 +81,7 @@ Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] Application number define how entropy will be used post processing. Some basic examples follow: -Derivation path uses the format m/83696968/' + /app_no' + /index' where ''app_no'' path for the application, and `index` in the index. +Derivation path uses the format m/83696968' + /app_no' + /index' where ''app_no'' path for the application, and `index` in the index. ===BIP39=== Application number: 39' From dfbbe04ddf9644e49eefb3de437d092c8563ef8f Mon Sep 17 00:00:00 2001 From: Meheret Tesfaye Date: Tue, 3 Nov 2020 11:31:20 +0300 Subject: [PATCH 10/50] Update bip-0039.mediawiki Add Python-HDWallet on Other Implementation. --- bip-0039.mediawiki | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c5ab9bb9..8241da71 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -137,6 +137,9 @@ http://github.com/trezor/python-mnemonic Go: * https://github.com/tyler-smith/go-bip39 +Python: +* https://github.com/meherett/python-hdwallet + Elixir: * https://github.com/aerosol/mnemo From fcd5c5d4ca6cac8027e4c5f4dee864f7743740f7 Mon Sep 17 00:00:00 2001 From: PandaBread2 <72713080+PandaBread2@users.noreply.github.com> Date: Sat, 7 Nov 2020 22:52:14 +0000 Subject: [PATCH 11/50] Update bip-0079.mediawiki --- bip-0079.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index c8f2104b..797c8f14 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -68,7 +68,7 @@ The template transaction should be sent to the receiver via an HTTP POST to the The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user. -Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid. +Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefore assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid. === Contributed Input Choice === @@ -118,7 +118,7 @@ For anyone wanting to implement bustapay payments, here are some notes for recei == Backwards Compatibility == -Bustapay is an optional payment protocol and therefor has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior. +Bustapay is an optional payment protocol and therefore has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior. == Credits == From 1a7eaa9c7f3c38221e63b6b3b001054e4502fe79 Mon Sep 17 00:00:00 2001 From: Karl-Johan Alm Date: Fri, 30 Oct 2020 16:00:54 +0900 Subject: [PATCH 12/50] BIP-322: minor clarification --- bip-0322.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index e515b56c..7aca5d12 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -25,7 +25,7 @@ More importantly, it does not prove ownership nor access to any funds, even if t == Specification == -This BIP follows the specification of BIP-325 challenges and solutions (see Signet comparison below). +This BIP follows the specification of BIP-325 challenges and solutions. Let there be two virtual transactions to_spend and to_sign. @@ -63,7 +63,7 @@ When a proof of funds is being created, additional inputs should be included for Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness. -A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below. +A validator must verify the proof is valid and meets the description of virtual transactions as specified above. See "Validation" below. === Validation === From c12af49c17b1bcf19cc73703bded3bd6abfa570d Mon Sep 17 00:00:00 2001 From: fametrano Date: Sun, 15 Nov 2020 09:53:06 +0100 Subject: [PATCH 13/50] fixed typos --- bip-0174.mediawiki | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index c424c5d7..b2b996e3 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -129,7 +129,7 @@ The currently defined global types are as follows: * Type: Version Number PSBT_GLOBAL_VERSION = 0xFB ** Key: None. The key must only contain the 1 byte type. *** {0xFB} -** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. +** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0. *** {32-bit uint} * Type: Proprietary Use Type PSBT_GLOBAL_PROPRIETARY = 0xFC @@ -549,55 +549,55 @@ The following are invalid PSBTs: ** Bytes in Hex: 
70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000000
** Base64 String: 
cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQA/AgAAAAH//////////////////////////////////////////wAAAAAA/////wEAAAAAAAAAAANqAQAAAAAAAAAA
-* Case: PSBT With invalid global transaction typed key +* Case: PSBT with invalid global transaction typed key ** Bytes in Hex: 
70736274ff020001550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8CAAFVAgAAAAEnmiMjpd+1H8RfIg+liw/BPh4zQnkqhdfjbNYzO1y8OQAAAAAA/////wGgWuoLAAAAABl2qRT/6cAGEJfMO2NvLLBGD6T8Qn0rRYisAAAAAAABASCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
-* Case: PSBT With invalid input witness utxo typed key +* Case: PSBT with invalid input witness utxo typed key ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac000000000002010020955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAIBACCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
-* Case: PSBT With invalid pubkey length for input partial signature typed key +* Case: PSBT with invalid pubkey length for input partial signature typed key ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87210203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd46304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIQIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYwQwIgBCS1jv+qppThVZ6lyTu/1KiQZCJAVc3wcLZ3FGlELQcCH1yOsP6mUW1guKyzOtZO3mDoeFv7OqlLmb34YVHbmpoBAQQiACB3H9GK1FlmbdSfPVZOPbxC9MhHdONgraFoFqjtSI1WgQEFR1IhA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GIQPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvVKuIgYDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYQtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==
-* Case: PSBT With invalid redeemscript typed key +* Case: PSBT with invalid redeemscript typed key ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a01020400220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQIEACIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
-* Case: PSBT With invalid witnessscript typed key +* Case: PSBT with invalid witnessscript typed key ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
-* Case: PSBT With invalid bip32 typed key +* Case: PSBT with invalid bip32 typed key ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==
-* Case: PSBT With invalid non-witness utxo typed key +* Case: PSBT with invalid non-witness utxo typed key ** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f0000000000020000bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAIAALsCAAAAAarXOTEBi9JfhK5AC2iEi+CdtwbqwqwYKYur7nGrZW+LAAAAAEhHMEQCIFj2/HxqM+GzFUjUgcgmwBW9MBNarULNZ3kNq2bSrSQ7AiBKHO0mBMZzW2OT5bQWkd14sA8MWUL7n3UYVvqpOBV9ugH+////AoDw+gIAAAAAF6kUD7lGNCFpa4LIM68kHHjBfdveSTSH0PIKJwEAAAAXqRQpynT4oI+BmZQoGFyXtdhS5AY/YYdlAAAAAQfaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
-* Case: PSBT With invalid final scriptsig typed key +* Case: PSBT with invalid final scriptsig typed key ** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000020700da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAACBwDaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
-* Case: PSBT With invalid final script witness typed key +* Case: PSBT with invalid final script witness typed key ** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903020800da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAggA2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=
-* Case: PSBT With invalid pubkey in output BIP 32 derivation paths typed key +* Case: PSBT with invalid pubkey in output BIP 32 derivation paths typed key ** Bytes in Hex: 
70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00210203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58710d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000
** Base64 String: 
cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIQIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1PtnuylhxDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA
-* Case: PSBT With invalid input sighash type typed key +* Case: PSBT with invalid input sighash type typed key ** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0203000100000000010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00
** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wCAwABAAAAAAEAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A
-* Case: PSBT With invalid output redeemScript typed key +* Case: PSBT with invalid output redeemScript typed key ** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0002000016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00
** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A
-* Case: PSBT With invalid output witnessScript typed key +* Case: PSBT with invalid output witnessScript typed key ** Bytes in Hex: 
70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00
** Base64 String: 
cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A
From 456c8c50886bbddb7c6e3a36ccc6e8adf330aba1 Mon Sep 17 00:00:00 2001 From: "Ferdinando M. Ametrano" Date: Mon, 16 Nov 2020 21:58:41 +0100 Subject: [PATCH 14/50] fixed input test case description as per output test case description --- bip-0174.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index b2b996e3..09b4b7df 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -569,7 +569,7 @@ The following are invalid PSBTs: ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA
-* Case: PSBT with invalid bip32 typed key +* Case: PSBT with invalid pubkey in input BIP 32 derivation paths typed key ** Bytes in Hex: 
70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000
** Base64 String: 
cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==
From 08844fd6eff55e756c453c6d2e16de40e8f80e73 Mon Sep 17 00:00:00 2001 From: Greg-Griffith Date: Wed, 18 Nov 2020 12:17:04 -0800 Subject: [PATCH 15/50] BIP34 specifies it requires minimal encoding. Non minimal encodings are rejected by the bitcoin-core client because it only checks against a specific encoding --- bip-0034.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki index a993b7e7..88073c5c 100644 --- a/bip-0034.mediawiki +++ b/bip-0034.mediawiki @@ -22,7 +22,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 150 or so years with 223-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). +# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "minimally encoded 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 223-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 6fb34f2a510391a80371a4616577b5615e494700 Mon Sep 17 00:00:00 2001 From: Ethan Kosakovsky Date: Fri, 30 Oct 2020 12:47:29 +0000 Subject: [PATCH 16/50] Add BIP85-DRNG and other key derivations --- bip-0085.mediawiki | 60 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 57 insertions(+), 3 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7c4cbcab..b9bafdba 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -25,6 +25,8 @@ As HD keychains are essentially derived from initial entropy, this proposal prov ==Definitions== +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + The terminology related to keychains used in the wild varies widely, for example `seed` has various different meanings. In this document we define the terms # '''BIP32 root key''' is the root extended private key that is represented as the top root of the keychain in BIP32. @@ -69,19 +71,41 @@ OUTPUT * DERIVED KEY=503776919131758bb7de7beb6c0ae24894f4ec042c26032890c29359216e21ba * DERIVED ENTROPY=70c6e3e8ebee8dc4c0dbba66076819bb8c09672527c4277ca8729532ad711872218f826919f6b67218adde99018a6df9095ab2b58d803b5b93ec9802085a690e +==BIP85-DRNG== + +BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic functions that require deterministic outputs, but where the input to that function requires more than the 64 bytes provided by BIP85's HMAC output. BIP85-DRNG-SHAKE256 uses BIP85 to seed a SHAKE256 stream (from the SHA-3 standard). The input must be exactly 64 bytes long (from the BIP85 HMAC output). + +RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed. + + drng_reader = BIP85DRNG.new(bip85_entropy) + rsa_key = RSA.generate_key(4096, drng_reader.read()) + +===Test Vectors=== +INPUT: +xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* MASTER BIP32 ROOT KEY: m/83696968'/0'/0' + +OUTPUT +* DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0 +* DERIVED ENTROPY=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc + +* DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111 + ==Reference Implementation== -Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy] +Python library implementation: [https://github.com/ethankosakovsky/bip85] ===Other Implementations=== -Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] +* JavaScript library implementation: [https://github.com/hoganri/bip85-js] + +* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39] ==Applications== Application number define how entropy will be used post processing. Some basic examples follow: -Derivation path uses the format m/83696968/' + /app_no' + /index' where ''app_no'' path for the application, and `index` in the index. +Derivation path uses the format m/83696968/{app_no}'/{index}' where ''{app_no}'' path for the application, and ''{index}'' in the index. ===BIP39=== Application number: 39' @@ -231,6 +255,36 @@ INPUT: OUTPUT * DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c +===RSA=== + +Application number: 828365' + +The derivation path format is: m/83696968'/828365'/{key_bits}'/{key_index}' + +The RSA key generator should use BIP85-DRNG as the input RNG function. + +===RSA GPG=== + +Keys allocated for RSA-GPG purposes use the following scheme: + + - Main key m/83696968'/828365'/{key_bits}'/{key_index}' + - Sub keys: m/83696968'/828365'/{key_bits}'/{key_index}'/{sub_key}' + + - key_index is the parent key for CERTIFY capability + - sub_key 0' is used as the ENCRYPTION key + - sub_key 1' is used as the AUTHENTICATION key + - sub_key 2' is usually used as SIGNATURE key + +Note on timestamps: + +The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time '2009-01-03 18:05:05' UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of faketime). + +Note on GPG key capabilities on smartcard/hardware devices: + +GPG capable smart-cards SHOULD be be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key. + +However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves dual purpose. + ==Backwards Compatibility== This specification is not backwards compatible with any other existing specification. From cf32b7bd397607a972eb1e0be311ce919c01cd47 Mon Sep 17 00:00:00 2001 From: Orfeas Litos Date: Mon, 30 Nov 2020 12:31:10 +0000 Subject: [PATCH 17/50] Say that public nonce is R and private nonce is s --- bip-0340.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index f22194f4..97c1db4c 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -227,7 +227,7 @@ Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20 === Adaptor Signatures === -[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce with a known point ''T = t⋅G'', but not offsetting his secret nonce. +[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting his secret nonce ''s''. A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by ''t'', meaning that learning ''t'' is equivalent to learning a correct signature. This can be used to enable atomic swaps or even [https://eprint.iacr.org/2018/472 general payment channels] in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic. From 23782b869342a59340a3d842ddf01a5e5495a91b Mon Sep 17 00:00:00 2001 From: Orfeas Litos Date: Mon, 30 Nov 2020 14:30:47 +0000 Subject: [PATCH 18/50] Remove the term "secret nonce", only refer to s --- bip-0340.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index 97c1db4c..1de7faa5 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -227,7 +227,7 @@ Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20 === Adaptor Signatures === -[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting his secret nonce ''s''. +[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting the signature's ''s'' value. A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by ''t'', meaning that learning ''t'' is equivalent to learning a correct signature. This can be used to enable atomic swaps or even [https://eprint.iacr.org/2018/472 general payment channels] in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic. From e963414eee7ac8f85a5a92f9d170f5f3d38f816d Mon Sep 17 00:00:00 2001 From: koushiro Date: Thu, 17 Dec 2020 22:20:40 +0800 Subject: [PATCH 19/50] Add a link of another Rust implmentation of BIP-0039 Signed-off-by: koushiro --- bip-0039.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c5ab9bb9..30e02e63 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -164,6 +164,7 @@ Ruby: Rust: * https://github.com/maciejhirsz/tiny-bip39/ +* https://github.com/koushiro/bip0039-rs Swift: * https://github.com/CikeQiu/CKMnemonic From 518bb8bf4f62ce9f40bff4fb3084cc63b736726c Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Fri, 18 Dec 2020 03:53:37 +0000 Subject: [PATCH 20/50] README: Link BIP 2 for submissions --- README.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.mediawiki b/README.mediawiki index 83120ab8..294b02f9 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,4 +1,4 @@ -People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (do not assign a number - read BIP 2 for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. From a78b211d23788dd0bcbc57f54abf6a223356b839 Mon Sep 17 00:00:00 2001 From: Pavol Rusnak Date: Sun, 20 Dec 2020 16:39:42 +0100 Subject: [PATCH 21/50] bip39: discourage from using localized wordlists --- bip-0039.mediawiki | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c5ab9bb9..08985ac1 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -113,7 +113,14 @@ will make the desired wallet available. ==Wordlists== -* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]] +Since the vast majority of BIP39 wallets supports only the English wordlist, +it is '''strongly discouraged''' to use non-English wordlists for generating +the mnemonic sentences. + +If you still feel your application really needs to use a localized wordlist, +use one of the following instead of inventing your own. + +* [[bip-0039/bip-0039-wordlists.md|Wordlists]] ==Test vectors== From f778098debfbc31a4c98dc569fc9cd407b65407a Mon Sep 17 00:00:00 2001 From: Andrew Poelstra Date: Wed, 23 Dec 2020 15:39:45 +0000 Subject: [PATCH 22/50] bip-0322: replace motivation, add myself to the "thanks to" list --- bip-0322.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index e515b56c..f13544f2 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -17,11 +17,11 @@ A standard for interoperable signed messages based on the Bitcoin Script format, == Motivation == -The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This approach minimizes the burden for implementers as message signing can be expected to be part of a library or project that includes Bitcoin Script interpreters already. +The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network). -Additionally, the current message signing only proves that the message has been committed to by the recipient of a given invoice address. -It does not prove anything about the invoice address itself, nor that the signer has access to the private keys used to implement this invoice. -More importantly, it does not prove ownership nor access to any funds, even if the same private key would be a valid signer for spending them - and this is a commonly desired use case. +Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.) + +Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations. == Specification == @@ -121,7 +121,7 @@ TODO == Acknowledgements == -Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many others for their feedback on the specification. +Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others for their feedback on the specification. == References == From dbb81b36525aabf4ae5d0ad015b4865494aed33e Mon Sep 17 00:00:00 2001 From: Andrew Poelstra Date: Wed, 23 Dec 2020 15:42:41 +0000 Subject: [PATCH 23/50] bip-0322: move "legacy" section up, separate "proof of funds", summarize the signature types --- bip-0322.mediawiki | 42 +++++++++++++++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 9 deletions(-) diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index f13544f2..065eb7bd 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -23,11 +23,31 @@ Additionally, the current message signature format uses ECDSA signatures which d Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations. -== Specification == +== Types of Signatures == -This BIP follows the specification of BIP-325 challenges and solutions (see Signet comparison below). +This BIP specifies three formats for signing messages: ''legacy'', ''simple'' and ''full''. Additionally, a variant of the ''full'' format can be used to demonstrate control over a set of UTXOs. -Let there be two virtual transactions to_spend and to_sign. +=== Legacy === + +New proofs should use the new format for all invoice address formats, including P2PKH. + +The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format. + +=== Simple === + +A ''simple'' signature consists of a witness stack, consensus encoded as a vector of vectors of bytes, and base64-encoded. Validators should construct to_spend and to_sign as defined below, with default values for all fields except that + +* message_hash is a BIP340-tagged hash of the message, as specified below +* message_challenge in to_spend is set to the scriptPubKey being signed with +* message_signature in to_sign is set to the provided simple signature. + +and then proceed as they would for a full signature. + +=== Full === + +Full signatures follow an analogous specification to the BIP-325 challenges and solutions used by Signet. + +Let there be two virtual transactions to_spend and to_sign. The "to_spend" transaction is: @@ -63,6 +83,16 @@ When a proof of funds is being created, additional inputs should be included for Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness. +=== Full (Proof of Funds) === + +A signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a full signature as above, with the following modifications. + +* message_challenge is unused and shall be set to OP_TRUE +* Similarly, message_signature is then empty. +* All outputs that the signer wishes to demonstrate control of are included as additional inputs of to_sign, and their witness and scriptSig data should be set as though these outputs were actually being spent. + +Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys. + A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below. === Validation === @@ -83,12 +113,6 @@ To validate a proof of funds, the following steps must be taken: # for each proof of fund input, set the corresponding values in the coins map; abort if the input cannot be found # check the signature of each input using consensus rules, then upgradable rules -== Legacy format == - -New proofs should use the new format for all invoice address formats, including P2PKH. - -The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format. - === Signing === Given the P2PKH invoice address a and the message m, and the pubkey-hash function pkh(P) = ripemd160(sha256(P)): From 9e1beef6acabffd4a53ff1396b4cb453615de19f Mon Sep 17 00:00:00 2001 From: Andrew Poelstra Date: Wed, 23 Dec 2020 15:47:27 +0000 Subject: [PATCH 24/50] bip-0322: overhaul/rewrite verification rules --- bip-0322.mediawiki | 118 +++++++++++++++++---------------------------- 1 file changed, 45 insertions(+), 73 deletions(-) diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 065eb7bd..4eda7b0b 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -49,7 +49,7 @@ Full signatures follow an analogous specification to the BIP-325 challenges and Let there be two virtual transactions to_spend and to_sign. -The "to_spend" transaction is: +The to_spend transaction is: nVersion = 0 nLockTime = 0 @@ -61,10 +61,9 @@ The "to_spend" transaction is: vout[0].nValue = 0 vout[0].scriptPubKey = message_challenge -where message_hash is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = "BIP0322-signed-message", and message_challenge is the to be proven (public) key script. -For proving funds, message_challenge shall be simply OP_TRUE. +where message_hash is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = BIP0322-signed-message, and message_challenge is the to be proven (public) key script. -The "to_sign" transaction is: +The to_sign transaction is: nVersion = 0 or as appropriate (e.g. 2, for time locks) nLockTime = 0 or as appropriate (for time locks) @@ -75,13 +74,7 @@ The "to_sign" transaction is: vout[0].nValue = 0 vout[0].scriptPubKey = OP_RETURN -When a proof of funds is being created, additional inputs should be included for virtually spending transaction outputs of desired value. - -* All signatures must use the SIGHASH_ALL flag. -* The proof is considered valid, inconclusive, or invalid based on whether the to_sign transaction is a valid spend of the to_spend transaction or not, according to the rules specified in the "Consensus and standard flags" section below. -* Proofs of funds may be encumbered with the in_future flag, according to the rules specified in the "Locktime and Sequence" section below, in which case we refer to the result in text form as "valid_in_future", "inconclusive_in_future", etc. - -Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness. +A full signature consists of the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation. === Full (Proof of Funds) === @@ -93,47 +86,58 @@ A signer may construct a proof of funds, demonstrating control of a set of UTXOs Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys. -A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below. +== Detailed Specification == -=== Validation === +For all signature types, except legacy, the to_spend and to_sign transactions must be valid transactions which pass all consensus checks, except of course that the output with prevout 000...000:FFFFFFFF does not exist. -To validate a simple proof, the following steps must be taken: +=== Verification === -# construct the to_spend and to_sign transactions, based on the specification above -# check the signature using consensus rules, then upgradable rules +A validator is given as input an address ''A'' (which may be omitted in a proof-of-funds), signature ''s'' and message ''m'', and outputs one of three states +* ''valid at time T and age S'' indicates that the signature has set timelocks but is otherwise valid +* ''inconclusive'' means the validator was unable to check the scripts +* ''invalid'' means that some check failed -To validate a proof of funds, the following steps must be taken: +==== Verification Process ==== -# deserialize the to_spend and to_sign transactions from the proof, and fail if the proof contains extraneous bytes -# verify that the to_sign transaction uses all inputs covered by the proof of funds, exactly once -# reconstruct the to_spend' and to_sign' transactions, based on the specification above, copying the version, lock time, and sequence values -# verify that to_spend = to_spend', that to_sign has at least 1 input, has exactly 1 output, and that to_sign.vin[0] = to_sign'.vin[0] -# set the "in_future" flag if the transaction's lock time is in the future according to consensus rules -# establish a "coins map", a mapping of outpoints (hash, vout) to coins (scriptPubKey, amount), initialized to coins_map(to_spend.txid, 0) = (to_spend.vout[0], 0) -# for each proof of fund input, set the corresponding values in the coins map; abort if the input cannot be found -# check the signature of each input using consensus rules, then upgradable rules +Validation consists of the following steps: + +# Basic validation +## Decode ''s'' as the transactions to_sign and to_spend +## Confirm that message_hash is the correct hash of ''m'' +## Confirm that message_challenge is the scriptPubKey corresponding to ''A'' if ''A'' is present, and otherwise must be OP_TRUE +## Confirm that all other fields are set as specified above; in particular that +##* to_spend has exactly one input and one output +##* to_sign has at least one input and its first input spends the output of to_spend +##* to_sign has exactly one output, as specified above +## Confirm that the two transactions together satisfy all consensus rules, except for to_spend's missing input, and except that ''nSequence'' of to_sign's first input and ''nLockTime'' of to_sign are not checked. +# (Optional) If the validator does not have a full script interpreter, it should check that it understands all scripts being satisfied. If not, it should stop here and output ''inconclusive''. +# Check the **required rules**: +## All signatures must use the SIGHASH_ALL flag. +## The use of CODESEPARATOR or FindAndDelete is forbidden. +## LOW_S, STRICTENC and NULLFAIL: valid ECDSA signatures must be strictly DER-encoded and have a low-S value; invalid ECDSA signature must be the empty push +## MINIMALDATA: all pushes must be minimally encoded +## CLEANSTACK: require that only a single stack element remains after evaluation +## MINIMALIF: the argument of IF/NOTIF must be exactly 0x01 or empty push +## If any of the above steps failed, the validator should stop and output the ''invalid'' state. +# Check the **upgradeable rules** +## The use of NOPs reserved for upgrades is forbidden. +## The use of segwit versions greater than 0 are forbidden. +## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state. +# Let ''T'' by the nLockTime of to_sign and ''S'' be the nSequence of the first input of to_sign. Output the state ''valid at time T and age S''. === Signing === -Given the P2PKH invoice address a and the message m, and the pubkey-hash function pkh(P) = ripemd160(sha256(P)): +Signers who control an address ''A'' who wish to sign a message ''m'' act as follows: -# let p be the pubkey-hash pkh(P) for the pubkey P, contained in a -# let x be the private key associated with P so that pkh(xG) = p -# let digest be SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m) -# create a compact signature sig (aka "recoverable ECDSA signature") using x on digest +# They construct to_spend and to_sign as specified above, using the scriptPubKey of ''A'' for message_challenge and tagged hash of ''m'' as message_hash. +# Optionally, they may set nLockTime of to_sign or nSequence of its first input. +# Optionally, they may add any additional outputs to to_sign that they wish to prove control of. +# They satisfy to_sign as they would any other transaction. -The resulting proof is sig, serialized using the base64 encoding. +They then encode their signature, choosing either ''simple'' or ''full'' as follows: -=== Verifying === - -Given the P2PKH invoice address a, the message m, the compact signature sig, and the pubkey-hash function pkh(P) = ripemd160(sha256(P)): - -# let p be the pubkey-hash pkh(P) for the pubkey P, contained in a -# let digest be SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m) -# attempt pubkey recovery for digest using the signature sig and store the resulting pubkey into Q -## fail verification if pubkey recovery above fails -# let q be the pubkey-hash pkh(Q) for the pubkey Q -# if p == q, the proof is valid, otherwise it is invalid +* If they added no inputs to to_sign, left nSequence and nLockTime at 0, and ''A'' is a Segwit address (either pure or P2SH-wrapped), then they may base64-encode message_signature +* Otherwise they must base64-encode the concatenation of to_spend followed by to_sign. == Compatibility == @@ -155,38 +159,6 @@ Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poels This document is licensed under the Creative Commons CC0 1.0 Universal license. -== Consensus and standard flags == - -Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and upgradable flags (which are typically policy-rejected by nodes specifically for the purpose of future network upgrades). The upgradable flags are a super-set of the consensus flags. - -This BIP specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for upgradable rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of upgradable rule validation). - -The ruleset sometimes changes. This BIP does not intend to be complete, nor does it indicate enforcement of rules, it simply lists the rules as they stand at the point of writing. - -=== Consensus rules === - -* P2SH: evaluate P2SH ([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16]) subscripts -* DERSIG: enforce strict DER ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]) compliance -* NULLDUMMY: enforce NULLDUMMY ([https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki BIP147]) -* CHECKLOCKTIMEVERIFY: enable CHECKLOCKTIMEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]) -* CHECKSEQUENCEVERIFY: enable CHECKSEQUENCEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112]) -* WITNESS: enable WITNESS ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) - -=== Upgradable rules === - -All of the above, plus (subject to change): - -* STRICTENC: non-strict DER signature or undefined hashtype -* MINIMALDATA: require minimal encodings for all push operations -* DISCOURAGE_UPGRADABLE_NOPS: discourage use of NOPs reserved for upgrades -* CLEANSTACK: require that only a single stack element remains after evaluation -* MINIMALIF: Segwit script only: require the argument of OP_IF/NOTIF to be exactly 0x01 or empty vector -* NULLFAIL: signature(s) must be empty vector if a CHECK(MULTI)SIG operation failed -* LOW_S: signature with S > order/2 in a checksig operation -* DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM: v1-16 witness programs are non-standard (i.e. forbidden) -* WITNESS_PUBKEYTYPE: public keys in segregated witness scripts must be compressed -* CONST_SCRIPTCODE: OP_CODESEPARATOR and FindAndDelete fail any non-segwit scripts - == Test vectors == TODO From c624414119573e41466dcf407b3c53507624678f Mon Sep 17 00:00:00 2001 From: Andrew Poelstra Date: Wed, 23 Dec 2020 15:35:47 +0000 Subject: [PATCH 25/50] bip-0322: remove the 'to_spend' transaction from serialization --- bip-0322.mediawiki | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 4eda7b0b..5f4704d0 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -74,7 +74,7 @@ The to_sign transaction is: vout[0].nValue = 0 vout[0].scriptPubKey = OP_RETURN -A full signature consists of the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation. +A full signature consists of the base64-encoding of the to_sign transaction in standard network serialisation. === Full (Proof of Funds) === @@ -102,11 +102,9 @@ A validator is given as input an address ''A'' (which may be omitted in a proof- Validation consists of the following steps: # Basic validation -## Decode ''s'' as the transactions to_sign and to_spend -## Confirm that message_hash is the correct hash of ''m'' -## Confirm that message_challenge is the scriptPubKey corresponding to ''A'' if ''A'' is present, and otherwise must be OP_TRUE -## Confirm that all other fields are set as specified above; in particular that -##* to_spend has exactly one input and one output +## Compute the transaction to_spend from ''m'' and ''A'' +## Decode ''s'' as the transaction to_sign +## If ''s'' was a full transaction, confirm all fields are set as specified above; in particular that ##* to_sign has at least one input and its first input spends the output of to_spend ##* to_sign has exactly one output, as specified above ## Confirm that the two transactions together satisfy all consensus rules, except for to_spend's missing input, and except that ''nSequence'' of to_sign's first input and ''nLockTime'' of to_sign are not checked. @@ -120,6 +118,7 @@ Validation consists of the following steps: ## MINIMALIF: the argument of IF/NOTIF must be exactly 0x01 or empty push ## If any of the above steps failed, the validator should stop and output the ''invalid'' state. # Check the **upgradeable rules** +## The version of to_sign must be 0 or 2. ## The use of NOPs reserved for upgrades is forbidden. ## The use of segwit versions greater than 0 are forbidden. ## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state. @@ -137,7 +136,7 @@ Signers who control an address ''A'' who wish to sign a message ''m'' act as fol They then encode their signature, choosing either ''simple'' or ''full'' as follows: * If they added no inputs to to_sign, left nSequence and nLockTime at 0, and ''A'' is a Segwit address (either pure or P2SH-wrapped), then they may base64-encode message_signature -* Otherwise they must base64-encode the concatenation of to_spend followed by to_sign. +* Otherwise they must base64-encode to_sign. == Compatibility == From 5f18700477e2c09653591b940caa40d285a21d95 Mon Sep 17 00:00:00 2001 From: Suhas Daftuar Date: Thu, 3 Sep 2020 16:51:17 -0400 Subject: [PATCH 26/50] p2p: Add disabletx message This message, valid between version/verack for peers with version >= 70017, would allow establishing at the time of connection that no transactions will be announced/requested between those peers. --- bip-disable-tx.mediawiki | 100 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 bip-disable-tx.mediawiki diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki new file mode 100644 index 00000000..c2bca255 --- /dev/null +++ b/bip-disable-tx.mediawiki @@ -0,0 +1,100 @@ +
+  BIP: XXX
+  Layer: Peer Services
+  Title: Disable transaction relay message
+  Author: Suhas Daftuar 
+  Comments-Summary: No comments yet.
+  Comments-URI:
+  Status: Draft
+  Type: Standards Track
+  Created: 2020-09-03
+  License: BSD-2-Clause
+
+ +==Abstract== + +This BIP describes a change to the p2p protocol to allow a node to tell a peer +that a connection will not be used for transaction relay, to support +block-relay-only connections that are currently in use on the network. + +==Motivation== + +For nearly the past year, software has been deployed[1] which initiates +connections on the Bitcoin network and sets the transaction relay field +(introduced by BIP 37 and also defined in BIP 60) to false, to prevent +transaction relay from occurring on the connection. Additionally, addr messages +received from the peer are ignored by this software. + +The purpose of these connections is two-fold: by making additional +low-bandwidth connections on which blocks can propagate, the robustness of a +node to network partitioning attacks is strengthened. Additionally, by not +relaying transactions and ignoring received addresses, the ability of an +adversary to learn the complete network graph (or a subgraph) is reduced[2], +which in turn increases the cost or difficulty to an attacker seeking to carry +out a network partitioning attack (when compared with having such knowledge). + +The low-bandwidth / minimal-resource nature of these connections is currently +known only by the initiator of the connection; this is because the transaction +relay field in the version message is not a permanent setting for the lifetime +of the connection. Consequently, a node receiving an inbound connection with +transaction relay disabled cannot distinguish between a peer that will never +enable transaction relay (as described in BIP 37) and one that will. Moreover, +the node also cannot determine that the incoming connection will ignore relayed +addresses; with that knowledge a node would likely choose other peers to +receive announced addresses instead. + +This proposal adds a new, optional message that a node can send a peer when +initiating a connection to that peer, to indicate that connection should not be +used for transaction-relay for the connection's lifetime. In addition, without +a current mechanism to negotiate whether addresses should be relayed on a +connection, this BIP suggests that address messages not be sent on links where +tx-relay has been disabled. + +==Specification== + +# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx". +# The protocol version of nodes implementing this BIP must be set to 70017 or higher. +# If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack. +# A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer: +## inv messages for transactions +## getdata messages for transactions +## getdata messages for merkleblock (BIP 37) +## filteradd/filterload/filterclear (BIP 37) +## mempool (BIP 35) +# It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer: +## addr/getaddr +## addrv2 (BIP 155) +# The behavior regarding sending or processing other message types is not specified by this BIP. +# Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions). + +==Compatibility== + +Nodes with protocol version >= 70017 that do not implement this BIP, and nodes +with protocol version < 70017, will continue to remain compatible with +implementing software: transactions would not be relayed to peers sending the +disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while +periodic address relay may still take place, software implementing this BIP +should not be disconnecting such peers solely for that reason. + +Disabling address relay is suggested but not required by this BIP, to allow for +future protocol extensions that might specify more carefully how address relay +is to be negotiated. This BIP's recommendations for software to not relay +addresses is intended to be interpreted as guidance in the absence of any such +future protocol extension, to accommodate existing software behavior. + +Note that all messages specified in BIP 152, including blocktxn and +getblocktxn, are permitted between peers that have sent/received a disabletx +message, subject to the feature negotiation of BIP 152. + +==Implementation== + +TBD + +==References== + +# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019. +# For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf. + +==Copyright== + +This BIP is licensed under the 2-clause BSD license. From 644610f7b87e3e5f4757fb9e80d24f8e6e75d93e Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sun, 10 Jan 2021 12:41:05 +0100 Subject: [PATCH 27/50] bip-0141: clarify the sigop count calculation for CHECKMULTISIG Since the sigOpCount calculation was copied from P2SH, and P2SH restricts the use of CHECKMULTISIG with pushed integers the reference implementation would not take into account the number of public keys for 17 to 20 keys (not representable with an OP_N) even for P2WSH. Therefore it fallbacks to accounting for 20 sigops in this case, which this sentence seemed to mismatch with. Btcd and Libbitcoin use the same calculation as in Bitcoin Core. Signed-off-by: Antoine Poinsot --- bip-0141.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 82f6abdc..85287296 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -127,7 +127,7 @@ Sigops per block is currently limited to 20,000. We change this restriction as f Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value. The sigop limit is likewise quadrupled to ≤ 80,000. -Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. +Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop. When preceded by OP_1 to OP_16 CHECKMULTISIG is counted as 1 to 16 sigops respectively, otherwise it is counted as 20 sigops. This rule applies to both native witness program and P2SH witness program. === Additional definitions === From 6057fede052900d442e8fe826f789263769b002d Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Tue, 28 Jul 2020 11:33:06 +0930 Subject: [PATCH 28/50] BIP 174: clarify format of proprietary extensions. "Variable length string identifier" is not defined anywhere, and the suggestion to use "0x00" is also deeply unclear. I assumed it meant a nul-terminated string! Be explicit: you mean it must be a compact siz1\e unsigned int length, followed by that many identifier bytes, followed by a compact size unsigned int subtype, followed by optional keydata. Signed-off-by: Rusty Russell --- bip-0174.mediawiki | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index c424c5d7..30a2bc25 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -133,8 +133,8 @@ The currently defined global types are as follows: *** {32-bit uint} * Type: Proprietary Use Type PSBT_GLOBAL_PROPRIETARY = 0xFC -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** {0xFC}||{subtype}|{key data} +** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself. +*** {0xFC}|{prefixlen}||{subtype}|{key data} ** Value: Any value data as defined by the proprietary type user. *** @@ -225,8 +225,8 @@ The currently defined per-input types are defined as follows: *** {preimage} * Type: Proprietary Use Type PSBT_IN_PROPRIETARY = 0xFC -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** {0xFC}||{subtype}|{key data} +** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself. +*** {0xFC}|{prefixlen}||{subtype}|{key data} ** Value: Any value data as defined by the proprietary type user. *** @@ -253,8 +253,8 @@ determine which outputs are change outputs and verify that the change is returni *** {master key fingerprint}|{32-bit uint}|...|{32-bit uint} * Type: Proprietary Use Type PSBT_OUT_PROPRIETARY = 0xFC -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** {0xFC}||{subtype}|{key data} +** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself. +*** {0xFC}|{prefixlen}||{subtype}|{key data} ** Value: Any value data as defined by the proprietary type user. *** @@ -336,10 +336,10 @@ values are valid, then it does not matter which is chosen as either way the tran ===Proprietary Use Type=== For all global, per-input, and per-output maps, the types 0xFC is reserved for proprietary use. -The proprietary use type requires keys that follow the type with a variable length string identifer, then a subtype. +The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data. The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it. -It can also be the empty string and just be a single 0x00 byte although this is not recommended. +It can also be the empty string although this is not recommended. The subtype is defined by the proprietary type user and can mean whatever they want it to mean. The subtype must also be a compact size unsigned integer in the same form as the normal types. From 50fdf5435ebbc2e9dfb98b74b2ff4a835ef94034 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Wed, 13 Jan 2021 17:09:35 -0500 Subject: [PATCH 29/50] Reformat BIP 174 --- bip-0174.mediawiki | 451 +++++++++++++++++++++------------------------ 1 file changed, 206 insertions(+), 245 deletions(-) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 30a2bc25..a20432a1 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -48,272 +48,233 @@ is the separator here 0x00 instead of 0xff?''' The separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that the unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus be used as a separator and allow for easier unserializer implementation.. -Each key-value pair must have a unique key within its scope; duplicates are not allowed. The format -of a record is as follows: -Note: <..> indicates that the data is prefixed by a compact size unsigned integer representing -the length of that data. {..} indicates the raw data itself. -
-|
-
+ := * * + := 0x70 0x73 0x62 0x74 0xFF + := * 0x00 + := * 0x00 + := * 0x00 + := + := + := -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Name -!Type -!Description -|- -| Key Length -| Compact Size Unsigned Integer -| Specify how long the key is -|- -| Key -| byte[] -| The Key itself -|- -| Value Length -| Compact Size Unsigned Integer -| Specify how long the value is -|- -| Value -| byte[] -| The Value itself -|} +Where: -The format of each key-value map is as follows: - -
-{key-value pair}|{key-value pair}|...|{0x00}
-
- -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description -|- -| 1+ -| Key-value pairs -| Array of key-value pairs -| varies -| The key-value pairs. -|- -| 1 -| separator -| char -| 0x00 -| Must be 0x00 at the end of the map. -|} - -At the beginning of each key is a compact size unsigned integer representing the type. -This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. -For convenience, this BIP will specify types using their full serialization, so a multi-byte type will have it's full prefix and zero padding as necessary. -There are global types, per-input types, and per-output types. +; +: A compact size unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. This must be unique within a specific . +; +: The compact size unsigned integer containing the combined length of and +; +: The compact size unsigned integer containing the length of . +; +: Magic bytes which are ASCII for psbt '''Why use 4 bytes for psbt?''' The +transaction format needed to start with a 5 byte header which uniquely identifies +it. The first bytes were chosen to be the ASCII for psbt because that stands for +Partially Signed Bitcoin Transaction. followed by a separator of 0xFF +'''Why Use a separator after the magic bytes?''' The separator +is part of the 5 byte header for PSBT. This byte is a separator of 0xff because +this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT +as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction +in the non-PSBT format will be able to be unserialized by a PSBT unserializer.. This integer must be serialized +in most significant byte order. The currently defined global types are as follows: -* Type: Unsigned Transaction PSBT_GLOBAL_UNSIGNED_TX = 0x00 -** Key: None. The key must only contain the 1 byte type. -*** {0x00} -** Value: The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). A PSBT must have a transaction, otherwise it is invalid. -*** {transaction} -** Note: Every PSBT must have a field with this type. - -* Type: Extended Public Key PSBT_GLOBAL_XPUB = 0x01 -** Key: The type followed by the 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived. -*** {0x01}|{xpub} -** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. -*** {master key fingerprint}|{32-bit uint}|...|{32-bit uint} - -* Type: Version Number PSBT_GLOBAL_VERSION = 0xFB -** Key: None. The key must only contain the 1 byte type. -*** {0xFB} -** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. -*** {32-bit uint} - -* Type: Proprietary Use Type PSBT_GLOBAL_PROPRIETARY = 0xFC -** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself. -*** {0xFC}|{prefixlen}||{subtype}|{key data} -** Value: Any value data as defined by the proprietary type user. -*** +{| +! Name +! +! +! Description +! +! Description +|- +| Unsigned Transaction +| PSBT_GLOBAL_UNSIGNED_TX = 0x00 +| None +| No key data +| +| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). A PSBT must have a transaction, otherwise it is invalid. +|- +| Extended Public Key +| PSBT_GLOBAL_XPUB = 0x01 +| +| The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived. +| <32-bit uint> <32-bit uint>* +| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. +|- +| PSBT Version Number +| PSBT_GLOBAL_VERSION = 0xFB +| None +| No key data +| <32-bit uint> +| The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. +|- +| Proprietary Use Type +| PSBT_GLOBAL_PROPRIETARY = 0xFC +| +| Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself . +| +| Any value data as defined by the proprietary type user. +|} The currently defined per-input types are defined as follows: -* Type: Non-Witness UTXO PSBT_IN_NON_WITNESS_UTXO = 0x00 -** Key: None. The key must only contain the 1 byte type. -***{0x00} -** Value: The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. '''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed. -*** {transaction} - -* Type: Witness UTXO PSBT_IN_WITNESS_UTXO = 0x01 -** Key: None. The key must only contain the 1 byte type. -*** {0x01} -** Value: The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO -*** {serialized transaction output({output value}|)} - -* Type: Partial Signature PSBT_IN_PARTIAL_SIG = 0x02 -** Key: The public key which corresponds to this signature. -*** {0x02}|{public key} -** Value: The signature as would be pushed to the stack from a scriptSig or witness. -*** {signature} - -* Type: Sighash Type PSBT_IN_SIGHASH_TYPE = 0x03 -** Key: None. The key must only contain the 1 byte type. -*** {0x03} -** Value: The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. -*** {sighash type} - -* Type: Redeem Script PSBT_IN_REDEEM_SCRIPT = 0x04 -** Key: None. The key must only contain the 1 byte type. -*** {0x04} -** Value: The redeemScript for this input if it has one. -*** {redeemScript} - -* Type: Witness Script PSBT_IN_WITNESS_SCRIPT = 0x05 -** Key: None. The key must only contain the 1 byte type. -*** {0x05} -** Value: The witnessScript for this input if it has one. -*** {witnessScript} - -* Type: BIP 32 Derivation Path PSBT_IN_BIP32_DERIVATION = 0x06 -** Key: The public key -*** {0x06}|{public key} -** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. -*** {master key fingerprint}|{32-bit uint}|...|{32-bit uint} - -* Type: Finalized scriptSig PSBT_IN_FINAL_SCRIPTSIG = 0x07 -** Key: None. The key must only contain the 1 byte type. -*** {0x07} -** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. -*** {scriptSig} - -* Type: Finalized scriptWitness PSBT_IN_FINAL_SCRIPTWITNESS = 0x08 -** Key: None. The key must only contain the 1 byte type. -*** {0x08} -** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. -*** {scriptWitness} - -* Type: Proof-of-reserves commitment PSBT_IN_POR_COMMITMENT = 0x09 -** Key: None. The key must only contain the 1 byte type. -*** {0x09} -** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. -*** {porCommitment} - -* Type: RIPEMD160 preimage PSBT_IN_RIPEMD160 = 0x0a -** Key: The resulting hash of the preimage -*** {0x0a}|{20-byte hash} -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm -*** {preimage} - -* Type: SHA256 preimage PSBT_IN_SHA256 = 0x0b -** Key: The resulting hash of the preimage -*** {0x0b}|{32-byte hash} -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm -*** {preimage} - -* Type: HASH160 preimage PSBT_IN_HASH160 = 0x0c -** Key: The resulting hash of the preimage -*** {0x0c}|{20-byte hash} -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm -*** {preimage} - -* Type: HASH256 preimage PSBT_IN_HASH256 = 0x0d -** Key: The resulting hash of the preimage -*** {0x0d}|{32-byte hash} -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice -*** {preimage} - -* Type: Proprietary Use Type PSBT_IN_PROPRIETARY = 0xFC -** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself. -*** {0xFC}|{prefixlen}||{subtype}|{key data} -** Value: Any value data as defined by the proprietary type user. -*** +{| +! Name +! +! +! Description +! +! Description +|- +| Non-Witness UTXO +| PSBT_IN_NON_WITNESS_UTXO = 0x00 +| None +| No key data +| +| The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. '''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed. +|- +| Witness UTXO +| PSBT_IN_WITNESS_UTXO = 0x01 +| None +| No key data +| <64-bit uint> +| The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO +|- +| Partial Signature +| PSBT_IN_PARTIAL_SIG = 0x02 +| +| The public key which corresponds to this signature. +| +| The signature as would be pushed to the stack from a scriptSig or witness. +|- +| Sighash Type +| PSBT_IN_SIGHASH_TYPE = 0x03 +| None +| No key data +| <32-bit uint> +| The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature. +|- +| Redeem Script +| PSBT_IN_REDEEM_SCRIPT = 0x04 +| None +| No key data +| +| The redeemScript for this input if it has one. +|- +| Witness Script +| PSBT_IN_WITNESS_SCRIPT = 0x05 +| None +| No key data +| +| The witnessScript for this input if it has one. +|- +| BIP 32 Derivation Path +| PSBT_IN_BIP32_DERIVATION = 0x06 +| +| The public key +| <32-bit uint> <32-bit uint>* +| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. +|- +| Finalized scriptSig +| PSBT_IN_FINAL_SCRIPTSIG = 0x07 +| None +| No key data +| +| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. +|- +| Finalized scriptWitness +| PSBT_IN_FINAL_SCRIPTWITNESS = 0x08 +| None +| No key data +| +| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. +|- +| Proof-of-reserves commitment +| PSBT_IN_POR_COMMITMENT = 0x09 +| None +| No key data +| +| The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. +|- +| RIPEMD160 preimage +| PSBT_IN_RIPEMD160 = 0x0a +| <20-byte hash> +| The resulting hash of the preimage +| +| The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm +|- +| SHA256 preimage +| PSBT_IN_SHA256 = 0x0b +| <32-byte hash> +| The resulting hash of the preimage +| +| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm +|- +| HASH160 preimage +| PSBT_IN_HASH160 = 0x0c +| <20-byte hash> +| The resulting hash of the preimage +| +| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm +|- +| HASH256 preimage +| PSBT_IN_HASH256 = 0x0d +| <32-byte hash> +| The resulting hash of the preimage +| +| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice +|- +| Proprietary Use Type +| PSBT_IN_PROPRIETARY = 0xFC +| +| Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself . +| +| Any value data as defined by the proprietary type user. +|} The currently defined per-output '''Why do we need per-output data?''' Per-output data allows signers to verify that the outputs are going to the intended recipient. The output data can also be use by signers to determine which outputs are change outputs and verify that the change is returning to the correct place. types are defined as follows: -* Type: Redeem Script PSBT_OUT_REDEEM_SCRIPT = 0x00 -** Key: None. The key must only contain the 1 byte type. -*** {0x00} -** Value: The redeemScript for this output if it has one. -*** {redeemScript} - -* Type: Witness Script PSBT_OUT_WITNESS_SCRIPT = 0x01 -** Key: None. The key must only contain the 1 byte type. -*** {0x01} -** Value: The witnessScript for this output if it has one. -*** {witnessScript} - -* Type: BIP 32 Derivation Path PSBT_OUT_BIP32_DERIVATION = 0x02 -** Key: The public key -*** {0x02}|{public key} -** Value: The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. -*** {master key fingerprint}|{32-bit uint}|...|{32-bit uint} - -* Type: Proprietary Use Type PSBT_OUT_PROPRIETARY = 0xFC -** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself. -*** {0xFC}|{prefixlen}||{subtype}|{key data} -** Value: Any value data as defined by the proprietary type user. -*** - -The transaction format is specified as follows: - - -
-    {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map}|{output key-value map}|...|{output key-value map}|
-
- -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description +{| +! Name +! +! +! Description +! +! Description |- -| 4 -| Magic Bytes -| int32_t -| 0x70736274 -| Magic bytes which are ASCII for psbt. '''Why use 4 bytes for psbt?''' The -transaction format needed to start with a 5 byte header which uniquely identifies -it. The first bytes were chosen to be the ASCII for psbt because that stands for -Partially Signed Bitcoin Transaction. This integer should be serialized -in most significant byte order. +| Redeem Script +| PSBT_OUT_REDEEM_SCRIPT = 0x00 +| None +| No key data +| +| The redeemScript for this output if it has one. |- -| 1 -| separator -| char -| 0xff -| Must be 0xff '''Why Use a separator after the magic bytes?''' The separator -is part of the 5 byte header for PSBT. This byte is a separator of 0xff because -this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT -as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction -in the non-PSBT format will be able to be unserialized by a PSBT unserializer. +| Witness Script +| PSBT_OUT_WITNESS_SCRIPT = 0x01 +| None +| No key data +| +| The witnessScript for this output if it has one. |- -| 1+ -| Global data -| Key-value Map -| varies -| The key-value pairs for all global data. +| BIP 32 Derivation Path +| PSBT_OUT_BIP32_DERIVATION = 0x02 +| +| The public key +| <{32-bit uint> <32-bit uint>* +| The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. |- -| 1+ -| Inputs -| Array of key-value maps -| varies -| The key-value pairs for each input as described above. Every input in the unsigned transaction must have a corresponding input map. -|- -| 1+ -| Outputs -| Array of key-value maps -| varies -| The key-value pairs for each output as described above. Every output in the unsigned transaction must have a corresponding output map. +| Proprietary Use Type +| PSBT_OUT_PROPRIETARY = 0xFC +| +| Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself . +| +| Any value data as defined by the proprietary type user. |} -Each block of data between separators can be viewed as a scope, and all separators -are required'''Why are all separators required?''' The separators are required -so that the unserializer knows which input it is unserializing data for.. Types can be skipped when they are unnecessary. For example, if an input is a witness input, then it should not have a Non-Witness UTXO key-value pair. From c0991047e25a35d1ddf241f304a079e9893eed69 Mon Sep 17 00:00:00 2001 From: Andrew Chow Date: Thu, 14 Jan 2021 13:31:15 -0500 Subject: [PATCH 30/50] Explicitly specify PSBTv0 --- README.mediawiki | 2 +- bip-0174.mediawiki | 13 +++++++++++-- scripts/buildtable.pl | 2 +- 3 files changed, 13 insertions(+), 4 deletions(-) diff --git a/README.mediawiki b/README.mediawiki index 83120ab8..e9fe7052 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -850,7 +850,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- style="background-color: #ffffcf" | [[bip-0174.mediawiki|174]] | Applications -| Partially Signed Bitcoin Transaction Format +| Partially Signed Bitcoin Transaction Format and Version 0 | Andrew Chow | Standard | Proposed diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index a20432a1..a1beaef7 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -1,7 +1,7 @@ 
   BIP: 174
   Layer: Applications
-  Title: Partially Signed Bitcoin Transaction Format
+  Title: Partially Signed Bitcoin Transaction Format and Version 0
   Author: Andrew Chow 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
@@ -21,6 +21,9 @@ signatures for an input while the input does not have a complete set of signatur
 The signer can be offline as all necessary information will be provided in the
 transaction.
 
+The generic format is described here in addition to the specification for version 0
+of this format.
+
 ===Copyright===
 
 This BIP is licensed under the 2-clause BSD license.
@@ -94,7 +97,7 @@ The currently defined global types are as follows:
 | None
 | No key data
 | 
-| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). A PSBT must have a transaction, otherwise it is invalid.
+| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses).
 |-
 | Extended Public Key
 | PSBT_GLOBAL_XPUB = 0x01
@@ -311,6 +314,12 @@ It is useful when there are additional data that they need attached to a PSBT bu
 The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes.
 This type must be used for internal processes only.
 
+==Version 0==
+
+Partially Signed Bitcoin Transactions version 0 is the first version of the PSBT format.
+Version 0 PSBTs must either omit PSBT_GLOBAL_VERSION or include it and set it to 0.
+Version 0 PSBTs must include PSBT_GLOBAL_UNSIGNED_TX, if omitted, the PSBT is invalid.
+
 ==Roles==
 
 Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing.
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index 1edd8c0d..ed71f7c4 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -89,7 +89,7 @@ my %DefinedLicenses = (
 );
 my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152);
 my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121);
-my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173);
+my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173 174);
 
 my %emails;
 

From a4fb1b9de0997ef5f47cca6e684353a89ad0b440 Mon Sep 17 00:00:00 2001
From: Andrew Chow 
Date: Thu, 14 Jan 2021 13:50:00 -0500
Subject: [PATCH 31/50] Specify procedure for new fields and versions

---
 bip-0174.mediawiki | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index a1beaef7..3ea95d5b 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -479,6 +479,18 @@ Updaters and combiners that need to add a version number to a PSBT should use th
 For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1.
 If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified.
 
+===Procedure For New Fields===
+
+New fields should first be proposed on the bitcoin-dev mailing list.
+If a field requires significatn description as to its usage, it should be accompanied by a separate BIP.
+The field must be added to the field listing tables in the Specification section.
+
+===Procedure For New Versions===
+
+New PSBT versions must be described in a separate BIP.
+The BIP may reference this BIP and any components of PSBT version 0 that are retained in the new version.
+Any new fields described in the new version must be added to the field listing tables in the Specification section.
+
 ==Compatibility==
 
 This transaction format is designed so that it is unable to be properly unserialized

From 80df41818ecbd2a16f351513da8e33e0ac17a4fd Mon Sep 17 00:00:00 2001
From: Andrew Chow 
Date: Thu, 14 Jan 2021 13:52:07 -0500
Subject: [PATCH 32/50] Include PSBT versions that can or must include field

---
 bip-0174.mediawiki | 78 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 3ea95d5b..9e1de135 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -91,6 +91,9 @@ The currently defined global types are as follows:
 !  Description
 ! 
 !  Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
 |-
 | Unsigned Transaction
 | PSBT_GLOBAL_UNSIGNED_TX = 0x00
@@ -98,6 +101,9 @@ The currently defined global types are as follows:
 | No key data
 | 
 | The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses).
+| 0
+|
+| 0
 |-
 | Extended Public Key
 | PSBT_GLOBAL_XPUB = 0x01
@@ -105,6 +111,9 @@ The currently defined global types are as follows:
 | The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.
 | <32-bit uint> <32-bit uint>*
 | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
+|
+|
+| 0
 |-
 | PSBT Version Number
 | PSBT_GLOBAL_VERSION = 0xFB
@@ -112,6 +121,9 @@ The currently defined global types are as follows:
 | No key data
 | <32-bit uint>
 | The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
+|
+|
+| 0
 |-
 | Proprietary Use Type
 | PSBT_GLOBAL_PROPRIETARY = 0xFC
@@ -119,6 +131,9 @@ The currently defined global types are as follows:
 | Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself .
 | 
 | Any value data as defined by the proprietary type user.
+|
+|
+| 0
 |}
 
 The currently defined per-input types are defined as follows:
@@ -130,6 +145,9 @@ The currently defined per-input types are defined as follows:
 !  Description
 ! 
 !  Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
 |-
 | Non-Witness UTXO
 | PSBT_IN_NON_WITNESS_UTXO = 0x00
@@ -137,6 +155,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | 
 | The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO. '''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed.
+|
+|
+| 0
 |-
 | Witness UTXO
 | PSBT_IN_WITNESS_UTXO = 0x01
@@ -144,6 +165,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <64-bit uint>  
 | The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO
+|
+|
+| 0
 |-
 | Partial Signature
 | PSBT_IN_PARTIAL_SIG = 0x02
@@ -151,6 +175,9 @@ The currently defined per-input types are defined as follows:
 | The public key which corresponds to this signature.
 | 
 | The signature as would be pushed to the stack from a scriptSig or witness.
+|
+|
+| 0
 |-
 | Sighash Type
 | PSBT_IN_SIGHASH_TYPE = 0x03
@@ -158,6 +185,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <32-bit uint>
 | The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.
+|
+|
+| 0
 |-
 | Redeem Script
 | PSBT_IN_REDEEM_SCRIPT = 0x04
@@ -165,6 +195,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | 
 | The redeemScript for this input if it has one.
+|
+|
+| 0
 |-
 | Witness Script
 | PSBT_IN_WITNESS_SCRIPT = 0x05
@@ -172,6 +205,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | 
 | The witnessScript for this input if it has one.
+|
+|
+| 0
 |-
 | BIP 32 Derivation Path
 | PSBT_IN_BIP32_DERIVATION = 0x06
@@ -179,6 +215,9 @@ The currently defined per-input types are defined as follows:
 | The public key
 | <32-bit uint> <32-bit uint>*
 | The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input.
+|
+|
+| 0
 |-
 | Finalized scriptSig
 | PSBT_IN_FINAL_SCRIPTSIG = 0x07
@@ -186,6 +225,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | 
 | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
+|
+|
+| 0
 |-
 | Finalized scriptWitness
 | PSBT_IN_FINAL_SCRIPTWITNESS = 0x08
@@ -193,6 +235,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | 
 | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
+|
+|
+| 0
 |-
 | Proof-of-reserves commitment
 | PSBT_IN_POR_COMMITMENT = 0x09
@@ -200,6 +245,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | 
 | The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
+|
+|
+| 0
 |-
 | RIPEMD160 preimage
 | PSBT_IN_RIPEMD160 = 0x0a
@@ -207,6 +255,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | 
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm
+|
+|
+| 0
 |-
 | SHA256 preimage
 | PSBT_IN_SHA256 = 0x0b
@@ -214,6 +265,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | 
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm
+|
+|
+| 0
 |-
 | HASH160 preimage
 | PSBT_IN_HASH160 = 0x0c
@@ -221,6 +275,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | 
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm
+|
+|
+| 0
 |-
 | HASH256 preimage
 | PSBT_IN_HASH256 = 0x0d
@@ -228,6 +285,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | 
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice
+|
+|
+| 0
 |-
 | Proprietary Use Type
 | PSBT_IN_PROPRIETARY = 0xFC
@@ -235,6 +295,9 @@ The currently defined per-input types are defined as follows:
 | Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself .
 | 
 | Any value data as defined by the proprietary type user.
+|
+|
+| 0
 |}
 
 The currently defined per-output '''Why do we need per-output data?''' Per-output data allows signers
@@ -248,6 +311,9 @@ determine which outputs are change outputs and verify that the change is returni
 !  Description
 ! 
 !  Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
 |-
 | Redeem Script
 | PSBT_OUT_REDEEM_SCRIPT = 0x00
@@ -255,6 +321,9 @@ determine which outputs are change outputs and verify that the change is returni
 | No key data
 | 
 | The redeemScript for this output if it has one.
+|
+|
+| 0
 |-
 | Witness Script
 | PSBT_OUT_WITNESS_SCRIPT = 0x01
@@ -262,6 +331,9 @@ determine which outputs are change outputs and verify that the change is returni
 | No key data
 | 
 | The witnessScript for this output if it has one.
+|
+|
+| 0
 |-
 | BIP 32 Derivation Path
 | PSBT_OUT_BIP32_DERIVATION = 0x02
@@ -269,6 +341,9 @@ determine which outputs are change outputs and verify that the change is returni
 | The public key
 | <{32-bit uint> <32-bit uint>*
 | The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output.
+|
+|
+| 0
 |-
 | Proprietary Use Type
 | PSBT_OUT_PROPRIETARY = 0xFC
@@ -276,6 +351,9 @@ determine which outputs are change outputs and verify that the change is returni
 | Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself .
 | 
 | Any value data as defined by the proprietary type user.
+|
+|
+| 0
 |}
 
 Types can be skipped when they are unnecessary. For example, if an input is a witness

From c27d5e8b9643a478ed7b6fd4e7cda15238f418fe Mon Sep 17 00:00:00 2001
From: Andrew Chow 
Date: Thu, 14 Jan 2021 14:38:36 -0500
Subject: [PATCH 33/50] Mark BIP 174 as final

---
 README.mediawiki   | 4 ++--
 bip-0174.mediawiki | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index e9fe7052..f77ce56f 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -847,13 +847,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Greg Maxwell
 | Informational
 | Final
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
 | Partially Signed Bitcoin Transaction Format and Version 0
 | Andrew Chow
 | Standard
-| Proposed
+| Final
 |-
 | [[bip-0175.mediawiki|175]]
 | Applications
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 9e1de135..303c0013 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -5,7 +5,7 @@
   Author: Andrew Chow 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
-  Status: Proposed
+  Status: Final
   Type: Standards Track
   Created: 2017-07-12
   License: BSD-2-Clause

From 88fb2052647f5f7a73127dad7ad6f4d46149cf79 Mon Sep 17 00:00:00 2001
From: Andrew Chow 
Date: Thu, 14 Jan 2021 16:09:52 -0500
Subject: [PATCH 34/50] Combine Appendix with field listing tables

---
 bip-0174.mediawiki | 152 ++++++++-------------------------------------
 1 file changed, 26 insertions(+), 126 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 303c0013..81958fdd 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -94,6 +94,7 @@ The currently defined global types are as follows:
 ! Versions Requiring Inclusion
 ! Versions Requiring Exclusion
 ! Versions Allowing Inclusion
+! Parent BIP
 |-
 | Unsigned Transaction
 | PSBT_GLOBAL_UNSIGNED_TX = 0x00
@@ -104,6 +105,7 @@ The currently defined global types are as follows:
 | 0
 |
 | 0
+| 174
 |-
 | Extended Public Key
 | PSBT_GLOBAL_XPUB = 0x01
@@ -114,6 +116,7 @@ The currently defined global types are as follows:
 |
 |
 | 0
+| 174
 |-
 | PSBT Version Number
 | PSBT_GLOBAL_VERSION = 0xFB
@@ -124,6 +127,7 @@ The currently defined global types are as follows:
 |
 |
 | 0
+| 174
 |-
 | Proprietary Use Type
 | PSBT_GLOBAL_PROPRIETARY = 0xFC
@@ -134,6 +138,7 @@ The currently defined global types are as follows:
 |
 |
 | 0
+| 174
 |}
 
 The currently defined per-input types are defined as follows:
@@ -148,6 +153,7 @@ The currently defined per-input types are defined as follows:
 ! Versions Requiring Inclusion
 ! Versions Requiring Exclusion
 ! Versions Allowing Inclusion
+! Parent BIP
 |-
 | Non-Witness UTXO
 | PSBT_IN_NON_WITNESS_UTXO = 0x00
@@ -158,6 +164,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Witness UTXO
 | PSBT_IN_WITNESS_UTXO = 0x01
@@ -168,6 +175,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Partial Signature
 | PSBT_IN_PARTIAL_SIG = 0x02
@@ -178,6 +186,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Sighash Type
 | PSBT_IN_SIGHASH_TYPE = 0x03
@@ -188,6 +197,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Redeem Script
 | PSBT_IN_REDEEM_SCRIPT = 0x04
@@ -198,6 +208,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Witness Script
 | PSBT_IN_WITNESS_SCRIPT = 0x05
@@ -208,6 +219,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | BIP 32 Derivation Path
 | PSBT_IN_BIP32_DERIVATION = 0x06
@@ -218,6 +230,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Finalized scriptSig
 | PSBT_IN_FINAL_SCRIPTSIG = 0x07
@@ -228,6 +241,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Finalized scriptWitness
 | PSBT_IN_FINAL_SCRIPTWITNESS = 0x08
@@ -238,6 +252,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Proof-of-reserves commitment
 | PSBT_IN_POR_COMMITMENT = 0x09
@@ -248,6 +263,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| [[bip-0127.mediawiki|127]]
 |-
 | RIPEMD160 preimage
 | PSBT_IN_RIPEMD160 = 0x0a
@@ -258,6 +274,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | SHA256 preimage
 | PSBT_IN_SHA256 = 0x0b
@@ -268,6 +285,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | HASH160 preimage
 | PSBT_IN_HASH160 = 0x0c
@@ -278,6 +296,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | HASH256 preimage
 | PSBT_IN_HASH256 = 0x0d
@@ -288,6 +307,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Proprietary Use Type
 | PSBT_IN_PROPRIETARY = 0xFC
@@ -298,6 +318,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |}
 
 The currently defined per-output '''Why do we need per-output data?''' Per-output data allows signers
@@ -314,6 +335,7 @@ determine which outputs are change outputs and verify that the change is returni
 ! Versions Requiring Inclusion
 ! Versions Requiring Exclusion
 ! Versions Allowing Inclusion
+! Parent BIP
 |-
 | Redeem Script
 | PSBT_OUT_REDEEM_SCRIPT = 0x00
@@ -324,6 +346,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |-
 | Witness Script
 | PSBT_OUT_WITNESS_SCRIPT = 0x01
@@ -334,6 +357,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |-
 | BIP 32 Derivation Path
 | PSBT_OUT_BIP32_DERIVATION = 0x02
@@ -344,6 +368,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |-
 | Proprietary Use Type
 | PSBT_OUT_PROPRIETARY = 0xFC
@@ -354,6 +379,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |}
 
 Types can be skipped when they are unnecessary. For example, if an input is a witness
@@ -817,129 +843,3 @@ and for coming up with the name and abbreviation of PSBT.
 
 Thanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, Daniel Cousens and those who commented on the bitcoin-dev mailing list for additional comments
 and suggestions for improving this proposal.
-
-==Appendix A: Data types and their specifications==
-
-Any data types, their associated scope and BIP number must be defined here
-
-{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
-!Scope
-!Type values
-!Name
-!BIP Number
-|-
-| Global
-| 0
-| PSBT_GLOBAL_UNSIGNED_TX
-| BIP 174
-|-
-| Global
-| 1
-| PSBT_GLOBAL_XPUB
-| BIP 174
-|-
-| Global
-| 251
-| PSBT_GLOBAL_VERSION
-| BIP 174
-|-
-| Global
-| 252
-| PSBT_GLOBAL_PROPRIETARY
-| BIP 174
-|-
-| Input
-| 0
-| PSBT_IN_NON_WITNESS_UTXO
-| BIP 174
-|-
-| Input
-| 1
-| PSBT_IN_WITNESS_UTXO
-| BIP 174
-|-
-| Input
-| 2
-| PSBT_IN_PARTIAL_SIG
-| BIP 174
-|-
-| Input
-| 3
-| PSBT_IN_SIGHASH_TYPE
-| BIP 174
-|-
-| Input
-| 4
-| PSBT_IN_REDEEM_SCRIPT
-| BIP 174
-|-
-| Input
-| 5
-| PSBT_IN_WITNESS_SCRIPT
-| BIP 174
-|-
-| Input
-| 6
-| PSBT_IN_BIP32_DERIVATION
-| BIP 174
-|-
-| Input
-| 7
-| PSBT_IN_FINAL_SCRIPTSIG
-| BIP 174
-|-
-| Input
-| 8
-| PSBT_IN_FINAL_SCRIPTWITNESS
-| BIP 174
-|-
-| Input
-| 9
-| PSBT_IN_POR_COMMITMENT
-| [[bip-0127.mediawiki|BIP 127]]
-|-
-| Input
-| 10
-| PSBT_IN_RIPEMD160
-| BIP 174
-|-
-| Input
-| 11
-| PSBT_IN_SHA256
-| BIP 174
-|-
-| Input
-| 12
-| PSBT_IN_HASH160
-| BIP 174
-|-
-| Input
-| 13
-| PSBT_IN_HASH256
-| BIP 174
-|-
-| Input
-| 252
-| PSBT_IN_PROPRIETARY
-| BIP 174
-|-
-| Output
-| 0
-| PSBT_OUT_REDEEM_SCRIPT
-| BIP 174
-|-
-| Output
-| 1
-| PSBT_OUT_WITNESS_SCRIPT
-| BIP 174
-|-
-| Output
-| 2
-| PSBT_OUT_BIP32_DERIVATION
-| BIP 174
-|-
-| Output
-| 252
-| PSBT_OUT_PROPRIETARY
-| BIP 174
-|}

From 794f20a13148536e7627451adaf0534e5862f7fa Mon Sep 17 00:00:00 2001
From: Suhas Daftuar 
Date: Tue, 26 Jan 2021 11:46:35 -0500
Subject: [PATCH 35/50] Add link to implementation

Also change the phrasing to more clearly indicate when block-relay-only peering
was deployed.
---
 bip-disable-tx.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index c2bca255..a5f2f77c 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -19,7 +19,7 @@ block-relay-only connections that are currently in use on the network.
 
 ==Motivation==
 
-For nearly the past year, software has been deployed[1] which initiates
+Since 2019, software has been deployed[1] which initiates
 connections on the Bitcoin network and sets the transaction relay field
 (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
 transaction relay from occurring on the connection. Additionally, addr messages
@@ -88,7 +88,7 @@ message, subject to the feature negotiation of BIP 152.
 
 ==Implementation==
 
-TBD
+https://github.com/bitcoin/bitcoin/pull/20726
 
 ==References==
 

From 6128a7bcb60ae2eca2461ccb17d29b5186d13820 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Thu, 24 Dec 2020 14:37:19 -0800
Subject: [PATCH 36/50] Add BIP 350 (bech32m)

---
 README.mediawiki   |   7 +
 bip-0350.mediawiki | 333 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 340 insertions(+)
 create mode 100644 bip-0350.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab8..e83769ba 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -980,6 +980,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Jonas Nick, Anthony Towns
 | Standard
 | Draft
+|-
+| [[bip-0350.mediawiki|350]]
+| Applications
+| Bech32m format for v1+ witness addresses
+| Pieter Wuille
+| Standard
+| Draft
 |}
 
 
diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
new file mode 100644
index 00000000..a7b50470
--- /dev/null
+++ b/bip-0350.mediawiki
@@ -0,0 +1,333 @@
+
+  BIP: 350
+  Layer: Applications
+  Title: Bech32m format for v1+ witness addresses
+  Author: Pieter Wuille 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0350
+  Status: Draft
+  Type: Standards Track
+  Created: 2020-12-16
+  License: BSD-2-Clause
+  Replaces: 173
+  Post-History: 2021-01-05: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018338.html [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address
+

+
+==Introduction==
+
+===Abstract===
+
+This document defines an improved variant of Bech32 called '''Bech32m''', and amends BIP173 to use Bech32m for native segregated witness outputs of version 1 and later. Bech32 remains in use for segregated witness outputs of version 0.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+[[bip-0173.mediawiki|BIP173]] defined a generic checksummed base 32 encoded format called Bech32. It is in use for segregated witness outputs of version 0 (P2WPKH and P2WSH, see [[bip-0141.mediawiki|BIP141]]), and other applications.
+
+Bech32 has an unexpected [https://github.com/sipa/bech32/issues/51 weakness]: whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum. This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths, but may affect future uses and/or other applications using the Bech32 encoding.
+
+This document addresses that by specifying Bech32m, a variant of Bech32 that mitigates this insertion weakness and related issues.
+
+==Specification==
+
+We first specify the new checksum algorithm, and then document how it should be used for future Bitcoin addresses.
+
+===Bech32m===
+
+Bech32m modifies the checksum of the Bech32 specification, replacing the constant ''1'' that is xored into the checksum at the end with ''0x2bc830a3''. The resulting checksum verification and creation algorithm (in Python, cf. the code in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32|BIP173 Bech32 section]):
+
+
+BECH32M_CONST = 0x2bc830a3
+
+def bech32m_polymod(values):
+  GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
+  chk = 1
+  for v in values:
+    b = (chk >> 25)
+    chk = (chk & 0x1ffffff) << 5 ^ v
+    for i in range(5):
+      chk ^= GEN[i] if ((b >> i) & 1) else 0
+  return chk
+
+def bech32m_hrp_expand(s):
+  return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]
+
+def bech32m_verify_checksum(hrp, data):
+  return bech32m_polymod(bech32m_hrp_expand(hrp) + data) == BECH32M_CONST
+
+def bech32m_create_checksum(hrp, data):
+  values = bech32m_hrp_expand(hrp) + data
+  polymod = bech32m_polymod(values + [0,0,0,0,0,0]) ^ BECH32M_CONST
+  return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]
+

+
+All other aspects of Bech32 remain unchanged, including its human-readable parts (HRPs).
+
+A combined function to decode both Bech32 and Bech32m simultaneously could be written using:
+
+
+class Encoding(Enum):
+    BECH32 = 1
+    BECH32M = 2
+
+def bech32_bech32m_verify_checksum(hrp, data):
+    check = bech32_polymod(bech32_hrp_expand(hrp) + data)
+    if check == 1:
+        return Encoding.BECH32
+    if const == BECH32M_CONST:
+        return Encoding.BECH32M
+    return None
+

+
+which returns either None for failure, or one of the BECH32 / BECH32M enumeration values to indicate successful decoding according to the respective standard.
+
+===Addresses for segregated witness outputs===
+
+Version 0 outputs (specifically, P2WPKH and P2WSH addresses) continue to use Bech32'''Why not permit both Bech32 and Bech32m for v0 addresses?''' Permitting both encodings reduces the error detection capabilities (it makes it equivalent to only have 29 bits of checksum). as specified in BIP173. Addresses for segregated witness outputs version 1 through 16 use Bech32m. Again, all other aspects of the encoding remain the same, including the 'bc' HRP.
+
+To generate an address for a segregated witness output:
+
+* If its witness version is 0, encode it using Bech32.
+* If its witness version is 1 or higher, encode it using Bech32m.
+
+To decode an address, client software should either decode with both a Bech32 and a Bech32m decoder'''Can a single string simultaneously be valid as Bech32 and Bech32m?''' No, a valid Bech32 and Bech32m string will always differ by at least 3 characters if they are the same length., or use a decoder that supports both simultaneously. In both cases, the address decoder has to verify that the encoding matches what is expected for the decoded witness version (Bech32 for version 0, Bech32m for others).
+
+The following code demonstrates the checks that need to be performed. Refer to the Python code linked in the reference implementation section below for full details of the called functions.
+
+
+def decode(hrp, addr):
+    hrpgot, data, spec = bech32_decode(addr)
+    if hrpgot != hrp:
+        return (None, None)
+    decoded = convertbits(data[1:], 5, 8, False)
+    # Witness programs are between 2 and 40 bytes in length.
+    if decoded is None or len(decoded) < 2 or len(decoded) > 40:
+        return (None, None)
+    # Witness versions are in range 0..16.
+    if data[0] > 16:
+        return (None, None)
+    # Witness v0 programs must be exactly length 20 or 32.
+    if data[0] == 0 and len(decoded) != 20 and len(decoded) != 32:
+        return (None, None)
+    # Witness v0 uses Bech32; v1 through v16 use Bech32m.
+    if data[0] == 0 and spec != Encoding.BECH32 or data[0] != 0 and spec != Encoding.BECH32M:
+        return (None, None)
+    # Success.
+    return (data[0], decoded)
+

+
+'''Error locating'''
+
+Bech32m, like Bech32m, does support locating'''What about error correction?''' As explained in BIP173, introducing error correction reduces the ability to detect errors. While it is technically possible to correct a small number of errors due to Bech32(m)'s nature as a BCH code, implementations should refrain from using this for more than indicating where an error may be present. the positions of a few substitution errors. To combine this functionality with
+the segregated witness addresses proposed by this document, simply try locating errors for both Bech32 and Bech32m. If only one finds error locations, report that one. If both do (which should be very rare),
+there are a number of options:
+* Report the one that needs fewer corrections (if they differ).
+* Eliminate the response(s) that are inconsistent. Any symbol that isn't on an error location can be checked. For example, if the witness version symbol is not an error location, and it doesn't correspond to the specification used (0 for Bech32, 1+ for Bech32m), that response can be eliminated.
+
+See the fancy Javascript decoder below for example of the above.
+
+==Compatibility==
+
+This document introduces a new encoding for v1 segregated witness outputs and higher versions. There should not be any compatibility issues on the receiver side; no wallets are creating v1 segregated witness addresses yet, as the output type is not usable on mainnet.
+
+On the other hand, the Bech32m proposal breaks forward-compatibility for sending to v1 and higher version segregated witness addresses. This incompatibility is [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018236.html intentional]. An alternative design was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017460.html considered] where Bech32 remained in use for certain subsets of future addresses, but ultimately [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018293.html discarded]. By introducing a clean break, we protect not only new software but also existing senders from the mutation issue, as new addresses will be incompatible with the existing Bech32 address validation. [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html Experiments] by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018298.html breaking] forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.
+
+==Reference implementations==
+
+* Reference encoder and decoder:
+** [https://github.com/sipa/bech32/tree/bech32m/ref/python Reference Python implementation]
+** [https://github.com/sipa/bech32/tree/bech32m/ref/c Reference C implementation]
+** [https://github.com/sipa/bech32/tree/bech32m/ref/c++ Reference C++ implementation]
+** [https://github.com/bitcoin/bitcoin/pull/20861 Bitcoin Core C++ implementation]
+** [https://github.com/sipa/bech32/tree/bech32m/ref/javascript Reference Javascript implementation]
+
+* Fancy decoder that localizes errors:
+** [https://github.com/sipa/bech32/tree/bech32m/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])
+
+==Test vectors==
+
+'''Implementation advice''' Experiments testing BIP173 implementations found that many wallets and services did not support sending to higher version segregated witness outputs. In anticipation of the proposed [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Taproot] soft fork introducing v1 segregated witness outputs on the network, we emphatically recommend employing the complete set of test vectors provided below as well as ensuring that your implementation supports sending to v1 '''and higher versions'''. All higher versions of native segregated witness outputs should be recognized as valid recipients. As higher versions are not defined on the network, no wallet should ever create them and no recipient should ever provide them to a sender. Nor should a recipient ever want to falsely provide them as the recipient would simply see a payment intended to themselves burned instead. However, by defining higher versions as valid recipients now, future soft forks introducing higher versions of native segwit outputs will be forward-compatible to all wallets correctly implementing the Bech32m specification.
+
+===Test vectors for Bech32m===
+
+The following strings are valid Bech32m:
+* A1LQFN3A
+* a1lqfn3a
+* an83characterlonghumanreadablepartthatcontainsthetheexcludedcharactersbioandnumber11sg7hg6
+* abcdef1l7aum6echk45nj3s0wdvt2fg8x9yrzpqzd3ryx
+* 11llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllludsr8
+* split1checkupstagehandshakeupstreamerranterredcaperredlc445v
+* ?1v759aa
+
+No string can be simultaneously valid Bech32 and Bech32m, so the above examples also serve as invalid test vectors for Bech32.
+
+The following string are not valid Bech32m (with reason for invalidity):
+* 0x20 + 1xj0phk: HRP character out of range
+* 0x7F + 1g6xzxy: HRP character out of range
+* 0x80 + 1vctc34: HRP character out of range
+* an84characterslonghumanreadablepartthatcontainsthetheexcludedcharactersbioandnumber11d6pts4: overall max length exceeded
+* qyrz8wqd2c9m: No separator character
+* 1qyrz8wqd2c9m: Empty HRP
+* y1b0jsk6g: Invalid data character
+* lt1igcx5c0: Invalid data character
+* in1muywd: Too short checksum
+* mm1crxm3i: Invalid character in checksum
+* au1s5cgom: Invalid character in checksum
+* M1VUXWEZ: checksum calculated with uppercase form of HRP
+* 16plkw9: empty HRP
+* 1p2gdwpf: empty HRP
+
+===Test vectors for v0-v16 native segregated witness addresses===
+
+The following list gives valid segwit addresses and the scriptPubKey that they
+translate to in hex.
+* BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4: 0014751e76e8199196d454941c45d1b3a323f1433bd6
+* tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7: 00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262
+* bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kt5nd6y: 5128751e76e8199196d454941c45d1b3a323f1433bd6751e76e8199196d454941c45d1b3a323f1433bd6
+* BC1SW50QGDZ25J: 6002751e
+* bc1zw508d6qejxtdg4y5r3zarvaryvaxxpcs: 5210751e76e8199196d454941c45d1b3a323
+* tb1qqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesrxh6hy: 0020000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433
+* tb1pqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesf3hn0c: 5120000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433
+* bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0: 512079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
+
+The following list gives invalid segwit addresses and the reason for
+their invalidity.
+* tc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq5zuyut: Invalid human-readable part
+* bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd: Invalid checksum (Bech32 instead of Bech32m)
+* tb1z0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqglt7rf: Invalid checksum (Bech32 instead of Bech32m)
+* BC1S0XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ54WELL: Invalid checksum (Bech32 instead of Bech32m)
+* bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kemeawh: Invalid checksum (Bech32m instead of Bech32)
+* tb1q0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq24jc47: Invalid checksum (Bech32m instead of Bech32)
+* bc1p38j9r5y49hruaue7wxjce0updqjuyyx0kh56v8s25huc6995vvpql3jow4: Invalid character in checksum
+* BC130XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ7ZWS8R: Invalid witness version
+* bc1pw5dgrnzv: Invalid program length (1 byte)
+* bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v8n0nx0muaewav253zgeav: Invalid program length (41 bytes)
+* BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P: Invalid program length for witness version 0 (per BIP141)
+* tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq47Zagq: Mixed case
+* bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v07qwwzcrf: zero padding of more than 4 bits
+* tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vpggkg4j: Non-zero padding in 8-to-5 conversion
+* bc1gmk9yu: Empty data section
+
+
+==Appendix: checksum design & properties==
+
+Checksums are used to detect errors introduced into data during transfer. A hash function-based checksum such as Base58Check detects any type of error uniformly, but not all classes of errors are equally likely to occur in practice. Bech32 prioritizes detection of substitution errors, but improving detection of one error class inevitably worsens detection of other error classes. During the design of Bech32, it was assumed that other simple error patterns beside substitutions would have a similar detection rate as in a hash function-based design, and detection would only be worse for complex, impractical errors. The discovered insertion weakness shows that this is not the case.
+
+For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but make sure that other common errors don't perform worse than a hash function-based checksum would. To make sure the new standard is easy to implement, we restrict the design space to only amending the final constant that is xored in, as it was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017521.html observed] that that is sufficient to mitigate the 'q' insertion issue while retaining the intended substitution error detection. In what follows, we explain how the new constant ''0x2bc830a3'' was chosen.
+
+===Error patterns & detection probability===
+
+We define an error pattern as a sequence of first one or more deletions, then swaps of adjacent characters, followed by substitutions, insertions, and duplications, in that order, all in specific positions, applied to a string with valid checksum that is otherwise randomly chosen. For insertions and substitutions we assume a uniformly random new character. For example, "delete the 17th character, swap the 11th character with the 12th character, and insert a random character in the 24th position" is an error pattern. "Replace the 43th through 48th character with 'aardvark'" is not a valid error pattern, because the new characters are not random and there is no reason why this particular string is more likely than any other to be substituted.
+
+A hash function-based checksum design with a 30-bit hash would have a probability of incorrectly accepting equal to ''2-30'', for every error pattern. Bech32 has a probability of 0 to incorrectly accept error patterns consisting of up to 4 substitutions—they are always detected. The 'q'-insertion issue shows that for Bech32 a simple error pattern ("insert a random character in the penultimate position") with probability ''2-10'' exists: it requires the final character to be 'p' (leaving only  1 in 32 strings), and requires the inserted character to be 'q' (permitting only 1 of 32 possible inserted characters).
+
+Note that the choice of ''what'' the error pattern is (which types of errors, and where) isn't part of our probabilities: we try to make sure that ''every'' pattern behaves well, not just randomly chosen ones, because presumably humans
+make some kinds of errors more than others, and we cannot easily model which ones.
+
+===Detection properties of Bech32m===
+
+The table below shows the error detection properties of Bech32m, and a comparison with Bech32. The code used for this analysis can be found [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e#file-const_analysis-cpp here]. Every row specifies one error pattern via the constraints in the left four columns. The remaining columns report what percentage of those patterns have certain probabilities of not being detected. The columns are:
+
+* '''errors''' The maximum number of individual errors considered
+* '''of type''' What type of errors are considered (either "subst. only" for just substitutions, or "any" to also include deletions, swaps, insertions, and duplications)
+* '''window''' The maximum size of the window in which the errors have to occur'''What is an error pattern’s window size?''' The window size of an error pattern is the length of the smallest consecutive range of characters that contains all modified characters (on input or output; whichever is larger). For example, an error pattern that turns "abcdef" into "accdbef" has a window size of 4, as it is replacing "bcd" with "ccdb", a 4 character string. Window size is only meaningful when the pattern consists of two or more errors.
+* '''code/verifier''' Whether it about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.
+* '''error patterns with failure probability''' For each probability (''0'', ''2-30'', ''2-25'', ''2-20'', ''2-15'', and ''2-10'') this reports what percentage of error patterns restricted by the constraints in the previous columns have those probabilities of being incorrectly accepted.
+
+The properties are divided into two classes: those that hold over all strings when averaged over all possible HRPs (human readable parts), and those specific to the "bc1" HRP with the length restrictions imposed by segregated witness addresses'''What restrictions were taken into account for the "bc1"-specific analysis?''' The minimum length (due to witness programs being at least 2 bytes), the maximum length (due to witness programs being at most 40 bytes), and the fact that the witness programs are a multiple of 8 bits. The fact that the first data symbol cannot be over 16, or that the padding has to be 0, is not taken into account..
+
+{| class="wikitable"
+! rowspan="2" | errors
+! rowspan="2" | of type
+! rowspan="2" | window
+! rowspan="2" | code/verifier
+! colspan="6" | error patterns with failure probability
+|-
+! ''0'' !! ''2-30'' !! ''2-25'' !! ''2-20'' !! ''2-15'' !! ''2-10''
+|-
+! colspan="10" | Properties averaged over all HRPs
+|-
+| ≤ 4 || only subst. || any      || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none(a)
+|-
+| any     || any         || ≤ 4  || 56.16%|| 43.84%|| colspan="4" | none(b)
+|-
+| ≤ 2 || any         || ≤ 68 || 7.71%|| 92.28%|| colspan="4" | none(b)
+|-
+| ≤ 2 || any         || any      || 7.79%|| 92.20%|| 0.004%|| colspan="3" | none(b)
+|-
+| ≤ 3 || any         || ≤ 69 || 7.73%|| 92.23%|| 0.033%(d) || colspan="3" | none(b)
+|-
+| ≤ 3 || any         || any      || 7.77%|| 92.19%|| 0.034%|| 0.000065% || colspan="2" | none(b)
+|-
+| ≤ 4 || only subst. || any      || rowspan="6" | Bech32/Bech32 || 100.00%|| colspan="5" | none
+|-
+| any     || any         || ≤ 4  || 54.00%|| 43.84%|| 1.08%|| 0.90%|| 0.17%|| 0.0091%
+|-
+| ≤ 2 || any         || ≤ 68 || 4.59%|| 92.29%|| 1.09%|| 1.01%|| 0.99%|| 0.039%
+|-
+| ≤ 2 || any         || any      || 4.58%|| 92.21%|| 1.11%|| 1.04%|| 1.02%|| 0.038%
+|-
+| ≤ 3 || any         || ≤ 69 || 6.69%|| 92.23%|| 0.56%|| 0.48%|| 0.041%|| 0.00055%
+|-
+| ≤ 3 || any         || any      || 6.66%|| 92.19%|| 0.59%|| 0.52%|| 0.041%|| 0.00053%
+|-
+| ≤ 1 || any         || -        || rowspan="3" | Bech32m/Bech32 ||  46.53%|| 53.46%|| colspan="4" | none(b)
+|-
+| 0       || -           || -        || 100.00%|| colspan="5" | none(a)
+|-
+| ≤ 2 || any         || any      || 22.18%|| 77.77%|| 0.048%|| colspan="3" | none(b)
+|-
+! colspan="10" | Properties for segregated witness addresses with HRP "bc"
+|-
+| ≤ 4 || only subst. || any      || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none(a)
+|-
+| ≤ 1 || any         || -        ||  24.34%|| 75.66%|| colspan="4" | none(c)
+|-
+| ≤ 2 || any         || ≤ 28 ||  16.85%|| 83.15%|| colspan="4" | none(c)
+|-
+| ≤ 2 || any         || any      ||  15.72%|| 84.23%|| 0.038%|| 0.0053%|| colspan="2" | none(c)
+|-
+| any     || any         || ≤ 4  ||  74.74%|| 25.25%|| 0.0015%|| colspan="3" | none(c)
+|-
+| ≤ 3 || any         || any      ||  13.98%|| 85.94%|| 0.078%|| 0.00063%|| colspan="2" | none(c)
+|-
+| ≤ 4 || only subst. || any      || rowspan="6" | Bech32/Bech32 || 100.00%|| colspan="5" | none
+|-
+| ≤ 1 || any         || -        ||  14.63%|| 75.71%|| 2.43%|| 2.43%|| 2.43%|| 2.38%
+|-
+| ≤ 2 || any         || ≤ 28 ||  14.22%|| 83.15%|| 0.94%|| 0.84%|| 0.79%|| 0.054%
+|-
+| ≤ 2 || any         || any      ||  12.79%|| 84.24%|| 1.06%|| 0.95%|| 0.92%|| 0.041%
+|-
+| any     || any         || ≤ 4  ||  73.23%|| 25.26%|| 0.76%|| 0.63%|| 0.12%|| 0.0064%
+|-
+| ≤ 3 || any         || any      ||  13.00%|| 85.94%|| 0.57%|| 0.45%|| 0.044%|| 0.00067%
+|-
+| ≤ 3 || only subst. || any      || rowspan="3" | Bech32m/Bech32 || 100.00%|| colspan="5" | none(c)
+|-
+| ≤ 1 || any         || -        ||  70.89%|| 29.11%|| colspan="4" | none(c)
+|-
+| ≤ 2 || any         || any      ||  36.12%|| 63.79%|| 0.092%|| 0.00049%|| colspan="2" | none(c)
+|}
+
+The numbers in this table, as well as a comparison with the numbers for the ‘’1’’ constant and earlier proposed improved constants, can be found [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e#file-results_final-txt here].
+
+
+===Selection process===
+
+The details of the selection process can be found [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e here], but in short:
+* Start with the set of all ''230-1'' constants different from Bech32's ''1''. All of these satisfy the properties marked (a) in the table above.
+* Through exhaustive analysis, reject all constants that do not exhibit the properties'''How were the properties to select for chosen?''' All these properties are as strong as they can be without rejecting every constant: rejecting constants with lower probabilities, or more errors, or wider windows all result in nothing left. marked (b) in the table above (e.g. all constants that permit any error pattern of 2 errors or less in a window of 68 characters or less with a detection probability ''≥ 2-20''). This selection leaves us with 12054 candidates.
+* Reject all constants that do not exhibit the (c) properties in the table above'''Why optimize for segregated witness addresses (with HRP "bc1") specifically?''' Our analysis for generic HRP has limitations (see the detailed description [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e#file-bech32m_mail-txt here], under "Technical details"). We optimize for generic usage first, but optimize for segregated witness addresses as a tiebreaker.. This leaves us with 79 candidates.
+* Finally, select the candidate that minimizes the number of error classes matching (d) in the table above as a final tiebreaker. The result is the single constant ''0x2bc830a3''.
+
+==Footnotes==
+
+
+
+==Acknowledgements==
+
+Thanks to Rusty Russell for starting the discussion around intentionally breaking compatibility with existing senders, which is used in this specification. Thanks to Greg Maxwell for doing most of the computation for code selection and analysis.

From e192983f5b1fc7a2a0739906103fd6ed8f383c8d Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Fri, 29 Jan 2021 11:33:20 -0800
Subject: [PATCH 37/50] Update bip-0350.mediawiki

Co-authored-by: andrewtoth 
---
 bip-0350.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index a7b50470..3ad41c81 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -234,7 +234,7 @@ The table below shows the error detection properties of Bech32m, and a compariso
 * '''errors''' The maximum number of individual errors considered
 * '''of type''' What type of errors are considered (either "subst. only" for just substitutions, or "any" to also include deletions, swaps, insertions, and duplications)
 * '''window''' The maximum size of the window in which the errors have to occur'''What is an error pattern’s window size?''' The window size of an error pattern is the length of the smallest consecutive range of characters that contains all modified characters (on input or output; whichever is larger). For example, an error pattern that turns "abcdef" into "accdbef" has a window size of 4, as it is replacing "bcd" with "ccdb", a 4 character string. Window size is only meaningful when the pattern consists of two or more errors.
-* '''code/verifier''' Whether it about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.
+* '''code/verifier''' Whether it is about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.
 * '''error patterns with failure probability''' For each probability (''0'', ''2-30'', ''2-25'', ''2-20'', ''2-15'', and ''2-10'') this reports what percentage of error patterns restricted by the constraints in the previous columns have those probabilities of being incorrectly accepted.
 
 The properties are divided into two classes: those that hold over all strings when averaged over all possible HRPs (human readable parts), and those specific to the "bc1" HRP with the length restrictions imposed by segregated witness addresses'''What restrictions were taken into account for the "bc1"-specific analysis?''' The minimum length (due to witness programs being at least 2 bytes), the maximum length (due to witness programs being at most 40 bytes), and the fact that the witness programs are a multiple of 8 bits. The fact that the first data symbol cannot be over 16, or that the padding has to be 0, is not taken into account..

From d3874ff3ec0ca090a12a0f48560f3d819d9bee10 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Fri, 29 Jan 2021 11:33:27 -0800
Subject: [PATCH 38/50] Update bip-0350.mediawiki

Co-authored-by: andrewtoth 
---
 bip-0350.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index 3ad41c81..d09ae6b3 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -220,7 +220,7 @@ For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but m
 
 ===Error patterns & detection probability===
 
-We define an error pattern as a sequence of first one or more deletions, then swaps of adjacent characters, followed by substitutions, insertions, and duplications, in that order, all in specific positions, applied to a string with valid checksum that is otherwise randomly chosen. For insertions and substitutions we assume a uniformly random new character. For example, "delete the 17th character, swap the 11th character with the 12th character, and insert a random character in the 24th position" is an error pattern. "Replace the 43th through 48th character with 'aardvark'" is not a valid error pattern, because the new characters are not random and there is no reason why this particular string is more likely than any other to be substituted.
+We define an error pattern as a sequence of first one or more deletions, then swaps of adjacent characters, followed by substitutions, insertions, and duplications, in that order, all in specific positions, applied to a string with valid checksum that is otherwise randomly chosen. For insertions and substitutions we assume a uniformly random new character. For example, "delete the 17th character, swap the 11th character with the 12th character, and insert a random character in the 24th position" is an error pattern. "Replace the 43rd through 48th character with 'aardvark'" is not a valid error pattern, because the new characters are not random and there is no reason why this particular string is more likely than any other to be substituted.
 
 A hash function-based checksum design with a 30-bit hash would have a probability of incorrectly accepting equal to ''2-30'', for every error pattern. Bech32 has a probability of 0 to incorrectly accept error patterns consisting of up to 4 substitutions—they are always detected. The 'q'-insertion issue shows that for Bech32 a simple error pattern ("insert a random character in the penultimate position") with probability ''2-10'' exists: it requires the final character to be 'p' (leaving only  1 in 32 strings), and requires the inserted character to be 'q' (permitting only 1 of 32 possible inserted characters).
 

From 6446f2af0a75e513a0c4bad0ddaad8d798bd5e2d Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Fri, 29 Jan 2021 11:33:33 -0800
Subject: [PATCH 39/50] Update bip-0350.mediawiki

Co-authored-by: andrewtoth 
---
 bip-0350.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index d09ae6b3..f34da56a 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -121,7 +121,7 @@ def decode(hrp, addr):
 
 '''Error locating'''
 
-Bech32m, like Bech32m, does support locating'''What about error correction?''' As explained in BIP173, introducing error correction reduces the ability to detect errors. While it is technically possible to correct a small number of errors due to Bech32(m)'s nature as a BCH code, implementations should refrain from using this for more than indicating where an error may be present. the positions of a few substitution errors. To combine this functionality with
+Bech32m, like Bech32, does support locating'''What about error correction?''' As explained in BIP173, introducing error correction reduces the ability to detect errors. While it is technically possible to correct a small number of errors due to Bech32(m)'s nature as a BCH code, implementations should refrain from using this for more than indicating where an error may be present. the positions of a few substitution errors. To combine this functionality with
 the segregated witness addresses proposed by this document, simply try locating errors for both Bech32 and Bech32m. If only one finds error locations, report that one. If both do (which should be very rare),
 there are a number of options:
 * Report the one that needs fewer corrections (if they differ).

From e2cfb55f2fa1c1dbac55ae3ccf0994d3e10aa375 Mon Sep 17 00:00:00 2001
From: omar shibli 
Date: Sun, 31 Jan 2021 21:38:39 +0200
Subject: [PATCH 40/50] reject BIP175

---
 README.mediawiki   | 4 ++--
 bip-0175.mediawiki | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab8..d3a4bdd0 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -854,13 +854,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Andrew Chow
 | Standard
 | Proposed
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0175.mediawiki|175]]
 | Applications
 | Pay to Contract Protocol
 | Omar Shibli, Nicholas Gregory
 | Informational
-| Draft
+| Rejected
 |-
 | [[bip-0176.mediawiki|176]]
 |
diff --git a/bip-0175.mediawiki b/bip-0175.mediawiki
index a3ffd1c9..30c79858 100644
--- a/bip-0175.mediawiki
+++ b/bip-0175.mediawiki
@@ -6,7 +6,7 @@
           Nicholas Gregory 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0175
-  Status: Draft
+  Status: Rejected
   Type: Informational
   Created: 2017-07-17
   License: BSD-2-Clause

From f70132e58bce9ad88844d0b5c5500f3a6c98557b Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Wed, 3 Feb 2021 22:33:18 +0000
Subject: [PATCH 41/50] BIP 174: Revert title change to fit length limit

This partially reverts c0991047e25a35d1ddf241f304a079e9893eed69.
---
 README.mediawiki      | 2 +-
 bip-0174.mediawiki    | 2 +-
 scripts/buildtable.pl | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index da943d9d..b8f971b5 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -850,7 +850,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |- style="background-color: #cfffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
-| Partially Signed Bitcoin Transaction Format and Version 0
+| Partially Signed Bitcoin Transaction Format
 | Andrew Chow
 | Standard
 | Final
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 81958fdd..235d01a5 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 174
   Layer: Applications
-  Title: Partially Signed Bitcoin Transaction Format and Version 0
+  Title: Partially Signed Bitcoin Transaction Format
   Author: Andrew Chow 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index ed71f7c4..1edd8c0d 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -89,7 +89,7 @@ my %DefinedLicenses = (
 );
 my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152);
 my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121);
-my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173 174);
+my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173);
 
 my %emails;
 

From c5b392cce1990134763d0b7604f51b8d5af057d4 Mon Sep 17 00:00:00 2001
From: Pieter Wuille 
Date: Wed, 3 Feb 2021 16:15:31 -0800
Subject: [PATCH 42/50] Add back a few lost improvements

---
 bip-0350.mediawiki | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index f34da56a..d70bc205 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -77,9 +77,10 @@ def bech32_bech32m_verify_checksum(hrp, data):
     check = bech32_polymod(bech32_hrp_expand(hrp) + data)
     if check == 1:
         return Encoding.BECH32
-    if const == BECH32M_CONST:
+    elif check == BECH32M_CONST:
         return Encoding.BECH32M
-    return None
+    else:
+        return None
 

 
 which returns either None for failure, or one of the BECH32 / BECH32M enumeration values to indicate successful decoding according to the respective standard.
@@ -234,7 +235,7 @@ The table below shows the error detection properties of Bech32m, and a compariso
 * '''errors''' The maximum number of individual errors considered
 * '''of type''' What type of errors are considered (either "subst. only" for just substitutions, or "any" to also include deletions, swaps, insertions, and duplications)
 * '''window''' The maximum size of the window in which the errors have to occur'''What is an error pattern’s window size?''' The window size of an error pattern is the length of the smallest consecutive range of characters that contains all modified characters (on input or output; whichever is larger). For example, an error pattern that turns "abcdef" into "accdbef" has a window size of 4, as it is replacing "bcd" with "ccdb", a 4 character string. Window size is only meaningful when the pattern consists of two or more errors.
-* '''code/verifier''' Whether it is about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.
+* '''code/verifier''' Whether this line is about Bech32 or Bech32m encoded strings, and whether those are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.
 * '''error patterns with failure probability''' For each probability (''0'', ''2-30'', ''2-25'', ''2-20'', ''2-15'', and ''2-10'') this reports what percentage of error patterns restricted by the constraints in the previous columns have those probabilities of being incorrectly accepted.
 
 The properties are divided into two classes: those that hold over all strings when averaged over all possible HRPs (human readable parts), and those specific to the "bc1" HRP with the length restrictions imposed by segregated witness addresses'''What restrictions were taken into account for the "bc1"-specific analysis?''' The minimum length (due to witness programs being at least 2 bytes), the maximum length (due to witness programs being at most 40 bytes), and the fact that the witness programs are a multiple of 8 bits. The fact that the first data symbol cannot be over 16, or that the padding has to be 0, is not taken into account..
@@ -274,9 +275,9 @@ The properties are divided into two classes: those that hold over all strings wh
 |-
 | ≤ 3 || any         || any      || 6.66%|| 92.19%|| 0.59%|| 0.52%|| 0.041%|| 0.00053%
 |-
-| ≤ 1 || any         || -        || rowspan="3" | Bech32m/Bech32 ||  46.53%|| 53.46%|| colspan="4" | none(b)
+|       0 || -           || -        || rowspan="3" | Bech32m/Bech32 ||  100.00%|| colspan="5" | none(a)
 |-
-| 0       || -           || -        || 100.00%|| colspan="5" | none(a)
+|       1 || any         || -        || 46.53%|| 53.46%|| colspan="4" | none(b)
 |-
 | ≤ 2 || any         || any      || 22.18%|| 77.77%|| 0.048%|| colspan="3" | none(b)
 |-
@@ -284,31 +285,31 @@ The properties are divided into two classes: those that hold over all strings wh
 |-
 | ≤ 4 || only subst. || any      || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none(a)
 |-
-| ≤ 1 || any         || -        ||  24.34%|| 75.66%|| colspan="4" | none(c)
+|       1 || any         || -        ||  24.34%|| 75.66%|| colspan="4" | none(c)
 |-
 | ≤ 2 || any         || ≤ 28 ||  16.85%|| 83.15%|| colspan="4" | none(c)
 |-
-| ≤ 2 || any         || any      ||  15.72%|| 84.23%|| 0.038%|| 0.0053%|| colspan="2" | none(c)
+| any     || any         || ≤ 4  ||  74.74%|| 25.25%|| 0.0016%|| colspan="3" | none(c)
 |-
-| any     || any         || ≤ 4  ||  74.74%|| 25.25%|| 0.0015%|| colspan="3" | none(c)
+| ≤ 2 || any         || any      ||  15.72%|| 84.23%|| 0.039%|| 0.0053%|| colspan="2" | none(c)
 |-
 | ≤ 3 || any         || any      ||  13.98%|| 85.94%|| 0.078%|| 0.00063%|| colspan="2" | none(c)
 |-
 | ≤ 4 || only subst. || any      || rowspan="6" | Bech32/Bech32 || 100.00%|| colspan="5" | none
 |-
-| ≤ 1 || any         || -        ||  14.63%|| 75.71%|| 2.43%|| 2.43%|| 2.43%|| 2.38%
+|       1 || any         || -        ||  14.63%|| 75.71%|| 2.43%|| 2.43%|| 2.43%|| 2.38%
 |-
 | ≤ 2 || any         || ≤ 28 ||  14.22%|| 83.15%|| 0.94%|| 0.84%|| 0.79%|| 0.054%
 |-
-| ≤ 2 || any         || any      ||  12.79%|| 84.24%|| 1.06%|| 0.95%|| 0.92%|| 0.041%
-|-
 | any     || any         || ≤ 4  ||  73.23%|| 25.26%|| 0.76%|| 0.63%|| 0.12%|| 0.0064%
 |-
+| ≤ 2 || any         || any      ||  12.79%|| 84.24%|| 1.06%|| 0.95%|| 0.92%|| 0.041%
+|-
 | ≤ 3 || any         || any      ||  13.00%|| 85.94%|| 0.57%|| 0.45%|| 0.044%|| 0.00067%
 |-
 | ≤ 3 || only subst. || any      || rowspan="3" | Bech32m/Bech32 || 100.00%|| colspan="5" | none(c)
 |-
-| ≤ 1 || any         || -        ||  70.89%|| 29.11%|| colspan="4" | none(c)
+|       1 || any         || -        ||  70.89%|| 29.11%|| colspan="4" | none(c)
 |-
 | ≤ 2 || any         || any      ||  36.12%|| 63.79%|| 0.092%|| 0.00049%|| colspan="2" | none(c)
 |}
@@ -330,4 +331,6 @@ The details of the selection process can be found [https://gist.github.com/sipa/
 
 ==Acknowledgements==
 
-Thanks to Rusty Russell for starting the discussion around intentionally breaking compatibility with existing senders, which is used in this specification. Thanks to Greg Maxwell for doing most of the computation for code selection and analysis.
+Thanks to Greg Maxwell for doing most of the computation for code selection and analysis, and comments.
+Thanks to Mark Erhardt for help with writing and editing this document.
+Thanks to Rusty Russell and others on the bitcoin-dev list for the discussion around intentionally breaking compatibility with existing senders, which is used in this specification.

From 63d2800fabe4393382f699ba1e41260ab7b01727 Mon Sep 17 00:00:00 2001
From: Anthony Towns 
Date: Thu, 4 Feb 2021 12:25:25 +1000
Subject: [PATCH 43/50] bip 8: simplify MUST_SIGNAL check

---
 bip-0008.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index d5cb1912..8800b437 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -181,16 +181,16 @@ Blocks received while in the MUST_SIGNAL phase must be checked to ensure that th
 
     if (GetStateForBlock(block) == MUST_SIGNAL) {
         int nonsignal = 0;
-        int count = 1 + (block.nHeight % 2016);
         walk = block;
-        while (count > 0) {
-            --count;
+        while (true) {
             if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) {
                 ++nonsignal;
-                if (nonsignal + threshold > 2016) {
+                if (nonsignal > 2016 - threshold) {
                     return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
                 }
-            } else if (nonsignal == 0) {
+            }
+            if (walk.nHeight % 2016 == 0) {
+                // checked every block in this retarget period
                 break;
             }
             walk = walk.parent;

From b58dd7bc1a15d91c979e1fa2ebbf1f1a83784547 Mon Sep 17 00:00:00 2001
From: SomberNight 
Date: Fri, 5 Feb 2021 18:36:34 +0100
Subject: [PATCH 44/50] bip-0350: fix links for reference implementations

---
 bip-0350.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index f34da56a..a1843807 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -138,14 +138,14 @@ On the other hand, the Bech32m proposal breaks forward-compatibility for sending
 ==Reference implementations==
 
 * Reference encoder and decoder:
-** [https://github.com/sipa/bech32/tree/bech32m/ref/python Reference Python implementation]
-** [https://github.com/sipa/bech32/tree/bech32m/ref/c Reference C implementation]
-** [https://github.com/sipa/bech32/tree/bech32m/ref/c++ Reference C++ implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/python Reference Python implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/c Reference C implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/c++ Reference C++ implementation]
 ** [https://github.com/bitcoin/bitcoin/pull/20861 Bitcoin Core C++ implementation]
-** [https://github.com/sipa/bech32/tree/bech32m/ref/javascript Reference Javascript implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/javascript Reference Javascript implementation]
 
 * Fancy decoder that localizes errors:
-** [https://github.com/sipa/bech32/tree/bech32m/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])
+** [https://github.com/sipa/bech32/blob/master/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])
 
 ==Test vectors==
 

From cd1f225a0bd008efe1be5a1d60af3f68573b0ff4 Mon Sep 17 00:00:00 2001
From: kiminuo <58662979+kiminuo@users.noreply.github.com>
Date: Tue, 15 Dec 2020 10:02:17 +0100
Subject: [PATCH 45/50] BIP 155: Remove bitcoin.org link.

---
 bip-0155.mediawiki | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index ab3c0fcb..19f92f24 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -44,8 +44,7 @@ interpreted as described in RFC 2119[https://tools.ietf.org/html/rfc2119 RF
 
 The addrv2 message is defined as a message where pchCommand == "addrv2".
 It is serialized in the standard encoding for P2P messages.
-Its format is similar to the current addr message format
-[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message], with the difference that the 
+Its format is similar to the current addr message format, with the difference that the 
 fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
 
 This means that the message contains a serialized std::vector of the following structure:

From 55a31eb8ee304984534e6de8a9ef18691defa983 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar 
Date: Thu, 11 Feb 2021 13:45:26 -0500
Subject: [PATCH 46/50] Add more language in hope of BIP number assignment

---
 bip-disable-tx.mediawiki | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index a5f2f77c..98789aeb 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -19,6 +19,10 @@ block-relay-only connections that are currently in use on the network.
 
 ==Motivation==
 
+This proposal is part of an effort to increase the number of inbound
+connections that a peer can service, by distinguishing peers which will not
+relay transactions from those that do.
+
 Since 2019, software has been deployed[1] which initiates
 connections on the Bitcoin network and sets the transaction relay field
 (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
@@ -45,10 +49,15 @@ receive announced addresses instead.
 
 This proposal adds a new, optional message that a node can send a peer when
 initiating a connection to that peer, to indicate that connection should not be
-used for transaction-relay for the connection's lifetime. In addition, without
+used for transaction relay for the connection's lifetime. In addition, without
 a current mechanism to negotiate whether addresses should be relayed on a
 connection, this BIP suggests that address messages not be sent on links where
-tx-relay has been disabled.
+transaction relay has been disabled.
+
+After this BIP is deployed, nodes could more easily implement inbound
+connection limiting that differentiates low-resource nodes (such as those
+sending disabletx) from full-relay peers, potentially allowing for an increase
+in the number of block-relay-only connections that can be made on the network.
 
 ==Specification==
 

From 332b9a4854963e8afa8ab89682b9686b79956b95 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar 
Date: Fri, 12 Feb 2021 08:20:07 -0500
Subject: [PATCH 47/50] Note that tx messages are never allowed on disabletx
 links

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

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index 98789aeb..12baf432 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -61,7 +61,7 @@ in the number of block-relay-only connections that can be made on the network.
 
 ==Specification==
 
-# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
+# A new disabletx message is added, which is defined as an empty message with message type set to "disabletx".
 # The protocol version of nodes implementing this BIP must be set to 70017 or higher.
 # If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
 # A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
@@ -70,6 +70,7 @@ in the number of block-relay-only connections that can be made on the network.
 ## getdata messages for merkleblock (BIP 37)
 ## filteradd/filterload/filterclear (BIP 37)
 ## mempool (BIP 35)
+## tx message
 # It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
 ## addr/getaddr
 ## addrv2 (BIP 155)

From 31f61e71759c8c205294b2065a8383a91c60b436 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar 
Date: Fri, 12 Feb 2021 08:46:49 -0500
Subject: [PATCH 48/50] Mention compatibility with bip 37

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

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index 12baf432..ace7da17 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -96,6 +96,8 @@ Note that all messages specified in BIP 152, including blocktxn and
 getblocktxn, are permitted between peers that have sent/received a disabletx
 message, subject to the feature negotiation of BIP 152.
 
+This proposal is compatible with, but independent of, BIP 37.
+
 ==Implementation==
 
 https://github.com/bitcoin/bitcoin/pull/20726

From d2853bcc511989d2ba96c0e3cffe51dd8b042879 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 12 Feb 2021 21:02:49 +0000
Subject: [PATCH 49/50] Assign BIP 338 for Disable transaction relay message

---
 README.mediawiki                               | 7 +++++++
 bip-disable-tx.mediawiki => bip-0338.mediawiki | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)
 rename bip-disable-tx.mediawiki => bip-0338.mediawiki (98%)

diff --git a/README.mediawiki b/README.mediawiki
index ca283394..374556cc 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -953,6 +953,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0338.mediawiki|338]]
+| Peer Services
+| Disable transaction relay message
+| Suhas Daftuar
+| Standard
+| Draft
+|-
 | [[bip-0339.mediawiki|339]]
 | Peer Services
 | WTXID-based transaction relay
diff --git a/bip-disable-tx.mediawiki b/bip-0338.mediawiki
similarity index 98%
rename from bip-disable-tx.mediawiki
rename to bip-0338.mediawiki
index ace7da17..4e2c2205 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-0338.mediawiki
@@ -1,10 +1,10 @@
 
-  BIP: XXX
+  BIP: 338
   Layer: Peer Services
   Title: Disable transaction relay message
   Author: Suhas Daftuar 
   Comments-Summary: No comments yet.
-  Comments-URI:
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338
   Status: Draft
   Type: Standards Track
   Created: 2020-09-03

From bb9af2ac042961ceb0b2c573bff23aeaa5ba56e8 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 12 Feb 2021 21:04:33 +0000
Subject: [PATCH 50/50] README: Fix colour for BIP 79

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

diff --git a/README.mediawiki b/README.mediawiki
index dd706530..366e1fa4 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -392,7 +392,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Nicolas Dorier
 | Standard
 | Draft
-|- style="background-color: #ffffcf"
+|- style="background-color: #ffcfcf"
 | [[bip-0079.mediawiki|79]]
 | Applications
 | Bustapay :: a practical coinjoin protocol