diff options
| -rw-r--r-- | README.mediawiki | 26 | ||||
| -rw-r--r-- | bip-0008.mediawiki | 30 | ||||
| -rw-r--r-- | bip-0034.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 9 | ||||
| -rw-r--r-- | bip-0039/bip-0039-wordlists.md | 17 | ||||
| -rw-r--r-- | bip-0039/portuguese.txt | 2048 | ||||
| -rw-r--r-- | bip-0079.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0085.mediawiki | 61 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0155.mediawiki | 5 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 748 | ||||
| -rw-r--r-- | bip-0175.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0322.mediawiki | 159 | ||||
| -rw-r--r-- | bip-0338.mediawiki | 112 | ||||
| -rw-r--r-- | bip-0340.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0350.mediawiki | 336 |
16 files changed, 3057 insertions, 506 deletions
diff --git a/README.mediawiki b/README.mediawiki index 83120ab..106c455 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 <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> 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. @@ -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 @@ -847,20 +847,20 @@ 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 | Andrew Chow | Standard -| Proposed -|- +| Final +|- style="background-color: #ffcfcf" | [[bip-0175.mediawiki|175]] | Applications | Pay to Contract Protocol | Omar Shibli, Nicholas Gregory | Informational -| Draft +| Rejected |- | [[bip-0176.mediawiki|176]] | @@ -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 @@ -980,6 +987,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 |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 7030a20..8800b43 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -79,12 +79,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, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid. ===State transitions=== @@ -176,16 +177,23 @@ 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 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"); - } - } - if (GetStateForBlock(block) == LOCKED_IN) { - if (((block.nVersion >> bit) & 1) != 1) { - return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-locked-in"); + int nonsignal = 0; + walk = block; + while (true) { + if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) { + ++nonsignal; + if (nonsignal > 2016 - threshold) { + return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); + } + } + if (walk.nHeight % 2016 == 0) { + // checked every block in this retarget period + break; + } + walk = walk.parent; } } @@ -226,7 +234,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. diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki index a993b7e..88073c5 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 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0). +# 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 2<sup>23</sup>-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0). # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100) diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index 8241da7..3e12d28 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== diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 589ceab..f2c173c 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 0000000..4a89105 --- /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 diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index c8f2104..797c8f1 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 == diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7c4cbca..cbd3a2a 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,42 @@ 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] +* JavaScript library implementation: [https://github.com/hoganri/bip85-js] ===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 <code>m/83696968/' + /app_no' + /index'</code> where ''app_no'' path for the application, and `index` in the index. +Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' path for the application, and ''{index}'' in the index. ===BIP39=== Application number: 39' @@ -231,6 +256,36 @@ INPUT: OUTPUT * DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c +===RSA=== + +Application number: 828365' + +The derivation path format is: <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code> + +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 <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code> + - Sub keys: <code>m/83696968'/828365'/{key_bits}'/{key_index}'/{sub_key}'</code> + + - key_index is the parent key for CERTIFY capability + - sub_key <code>0'</code> is used as the ENCRYPTION key + - sub_key <code>1'</code> is used as the AUTHENTICATION key + - sub_key <code>2'</code> 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 <code>'2009-01-03 18:05:05'</code> 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 <code>faketime</code>). + +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. diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 82f6abd..8528729 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 <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. 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 <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. 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 === diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 71fe3cc..19f92f2 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -44,8 +44,7 @@ interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RF The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>. It is serialized in the standard encoding for P2P messages. -Its format is similar to the current <code>addr</code> message format -<ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the +Its format is similar to the current <code>addr</code> 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 <code>std::vector</code> of the following structure: @@ -134,7 +133,7 @@ See the appendices for the address encodings to be used for the various networks Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". -<code>sendaddrv2</code> SHOULD be sent after receiving the <code>verack</code> message from the peer. +The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message. For older peers, that did not emit <code>sendaddrv2</code>, keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index c424c5d..9f6ad41 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -5,7 +5,7 @@ Author: Andrew Chow <achow101@gmail.com> 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 @@ -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. @@ -48,272 +51,337 @@ is the separator here <tt>0x00</tt> instead of <tt>0xff</tt>?''' 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.</ref>. -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: <tt><..></tt> indicates that the data is prefixed by a compact size unsigned integer representing -the length of that data. <tt>{..}</tt> indicates the raw data itself. - -<pre> -<key>|<value> -</pre> - -{| 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 -|} -The format of each key-value map is as follows: - -<pre> -{key-value pair}|{key-value pair}|...|{0x00} -</pre> -{| 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 -| <tt>0x00</tt> -| Must be <tt>0x00</tt> 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. + <psbt> := <magic> <global-map> <input-map>* <output-map>* + <magic> := 0x70 0x73 0x62 0x74 0xFF + <global-map> := <keypair>* 0x00 + <input-map> := <keypair>* 0x00 + <output-map> := <keypair>* 0x00 + <keypair> := <key> <value> + <key> := <keylen> <keytype> <keydata> + <value> := <valuelen> <valuedata> + +Where: + +;<tt><keytype></tt> +: 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 <tt><map></tt>. +;<tt><keylen></tt> +: The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt> +;<tt><valuelen></tt> +: The compact size unsigned integer containing the length of <tt><valuedata></tt>. +;<tt><magic></tt> +: Magic bytes which are ASCII for psbt <ref>'''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. </ref> followed by a separator of <tt>0xFF</tt> +<ref>'''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 <tt>0xff</tt> 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.</ref>. This integer must be serialized +in most significant byte order. The currently defined global types are as follows: -* Type: Unsigned Transaction <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x00}</tt> -** 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. -*** <tt>{transaction}</tt> -** Note: Every PSBT must have a field with this type. - -* Type: Extended Public Key <tt>PSBT_GLOBAL_XPUB = 0x01</tt> -** 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. -*** <tt>{0x01}|{xpub}</tt> -** 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. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Version Number <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0xFB}</tt> -** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. -*** <tt>{32-bit uint}</tt> - -* Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +! Parent BIP +|- +| Unsigned Transaction +| <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt> +| None +| No key data +| <tt><transaction></tt> +| 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 +| 174 +|- +| Extended Public Key +| <tt>PSBT_GLOBAL_XPUB = 0x01</tt> +| <tt><xpub></tt> +| 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. +| <tt><32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 +|- +| PSBT Version Number +| <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0. +| +| +| 0 +| 174 +|- +| Proprietary Use Type +| <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 +|} The currently defined per-input types are defined as follows: -* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -***<tt>{0x00}</tt> -** 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref> -*** <tt>{transaction}</tt> - -* Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x01}</tt> -** 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> -*** <tt>{serialized transaction output({output value}|<scriptPubKey>)}</tt> - -* Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> -** Key: The public key which corresponds to this signature. -*** <tt>{0x02}|{public key}</tt> -** Value: The signature as would be pushed to the stack from a scriptSig or witness. -*** <tt>{signature}</tt> - -* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x03}</tt> -** 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. -*** <tt>{sighash type}</tt> - -* Type: Redeem Script <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x04}</tt> -** Value: The redeemScript for this input if it has one. -*** <tt>{redeemScript}</tt> - -* Type: Witness Script <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x05}</tt> -** Value: The witnessScript for this input if it has one. -*** <tt>{witnessScript}</tt> - -* Type: BIP 32 Derivation Path <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> -** Key: The public key -*** <tt>{0x06}|{public key}</tt> -** 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. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Finalized scriptSig <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x07}</tt> -** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. -*** <tt>{scriptSig}</tt> - -* Type: Finalized scriptWitness <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x08}</tt> -** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. -*** <tt>{scriptWitness}</tt> - -* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x09}</tt> -** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. -*** <tt>{porCommitment}</tt> - -* Type: RIPEMD160 preimage <tt>PSBT_IN_RIPEMD160 = 0x0a</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0a}|{20-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm -*** <tt>{preimage}</tt> - -* Type: SHA256 preimage <tt>PSBT_IN_SHA256 = 0x0b</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0b}|{32-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm -*** <tt>{preimage}</tt> - -* Type: HASH160 preimage <tt>PSBT_IN_HASH160 = 0x0c</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0c}|{20-byte hash}</tt> -** 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 -*** <tt>{preimage}</tt> - -* Type: HASH256 preimage <tt>PSBT_IN_HASH256 = 0x0d</tt> -** Key: The resulting hash of the preimage -*** <tt>{0x0d}|{32-byte hash}</tt> -** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice -*** <tt>{preimage}</tt> - -* Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +! Parent BIP +|- +| Non-Witness UTXO +| <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> +| None +| No key data +| <tt><transaction></tt> +| 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref> +| +| +| 0 +| 174 +|- +| Witness UTXO +| <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt> +| None +| No key data +| <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt> +| 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt> +| +| +| 0 +| 174 +|- +| Partial Signature +| <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt> +| <tt><pubkey></tt> +| The public key which corresponds to this signature. +| <tt><signature></tt> +| The signature as would be pushed to the stack from a scriptSig or witness. +| +| +| 0 +| 174 +|- +| Sighash Type +| <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt> +| None +| No key data +| <tt><32-bit uint></tt> +| 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 +| 174 +|- +| Redeem Script +| <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt> +| None +| No key data +| <tt><redeemScript></tt> +| The redeemScript for this input if it has one. +| +| +| 0 +| 174 +|- +| Witness Script +| <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt> +| None +| No key data +| <tt><witnessScript></tt> +| The witnessScript for this input if it has one. +| +| +| 0 +| 174 +|- +| BIP 32 Derivation Path +| <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt> +| <tt><pubkey></tt> +| The public key +| <tt><32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 +|- +| Finalized scriptSig +| <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> +| None +| No key data +| <tt><scriptSig></tt> +| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation. +| +| +| 0 +| 174 +|- +| Finalized scriptWitness +| <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt> +| None +| No key data +| <tt><scriptWitness></tt> +| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation. +| +| +| 0 +| 174 +|- +| Proof-of-reserves commitment +| <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt> +| None +| No key data +| <tt><porCommitment></tt> +| The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. +| +| +| 0 +| [[bip-0127.mediawiki|127]] +|- +| RIPEMD160 preimage +| <tt>PSBT_IN_RIPEMD160 = 0x0a</tt> +| <tt><20-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm +| +| +| 0 +| 174 +|- +| SHA256 preimage +| <tt>PSBT_IN_SHA256 = 0x0b</tt> +| <tt><32-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm +| +| +| 0 +| 174 +|- +| HASH160 preimage +| <tt>PSBT_IN_HASH160 = 0x0c</tt> +| <tt><20-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm +| +| +| 0 +| 174 +|- +| HASH256 preimage +| <tt>PSBT_IN_HASH256 = 0x0d</tt> +| <tt><32-byte hash></tt> +| The resulting hash of the preimage +| <tt><preimage></tt> +| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice +| +| +| 0 +| 174 +|- +| Proprietary Use Type +| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 +|} The currently defined per-output <ref>'''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.</ref> types are defined as follows: -* Type: Redeem Script <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x00}</tt> -** Value: The redeemScript for this output if it has one. -*** <tt>{redeemScript}</tt> - -* Type: Witness Script <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> -** Key: None. The key must only contain the 1 byte type. -*** <tt>{0x01}</tt> -** Value: The witnessScript for this output if it has one. -*** <tt>{witnessScript}</tt> - -* Type: BIP 32 Derivation Path <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> -** Key: The public key -*** <tt>{0x02}|{public key}</tt> -** 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. -*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> - -* Type: Proprietary Use Type <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> -** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. -*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> -** Value: Any value data as defined by the proprietary type user. -*** <tt><data></tt> - -The transaction format is specified as follows: - - -<pre> - {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map}|{output key-value map}|...|{output key-value map}| -</pre> - -{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" -!Field Size -!Name -!Type -!Value -!Description -|- -| 4 -| Magic Bytes -| int32_t -| <tt>0x70736274</tt> -| Magic bytes which are ASCII for psbt. <ref>'''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. </ref> This integer should be serialized -in most significant byte order. -|- -| 1 -| separator -| char -| <tt>0xff</tt> -| Must be <tt>0xff</tt> <ref>'''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 <tt>0xff</tt> 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.</ref> -|- -| 1+ -| Global data -| Key-value Map -| varies -| The key-value pairs for all global data. -|- -| 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. +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><keydata></tt> Description +! <tt><valuedata></tt> +! <tt><valuedata></tt> Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +! Parent BIP +|- +| Redeem Script +| <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt> +| None +| No key data +| <tt><redeemScript></tt> +| The redeemScript for this output if it has one. +| +| +| 0 +| 174 +|- +| Witness Script +| <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt> +| None +| No key data +| <tt><witnessScript></tt> +| The witnessScript for this output if it has one. +| +| +| 0 +| 174 +|- +| BIP 32 Derivation Path +| <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> +| <tt><public key></tt> +| The public key +| <tt><{32-bit uint> <32-bit uint>*</tt> +| 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 +| 174 +|- +| Proprietary Use Type +| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> +| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt> +| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>. +| <tt><data></tt> +| Any value data as defined by the proprietary type user. +| +| +| 0 +| 174 |} -Each block of data between separators can be viewed as a scope, and all separators -are required<ref>'''Why are all separators required?''' The separators are required -so that the unserializer knows which input it is unserializing data for.</ref>. 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. @@ -336,10 +404,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 <tt>0xFC</tt> 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 <tt>0x00</tt> 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. @@ -350,6 +418,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. @@ -357,7 +431,7 @@ Using the transaction format involves many different roles. Multiple roles can b ===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. ===Updater=== @@ -509,6 +583,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 @@ -549,55 +635,55 @@ The following are invalid PSBTs: ** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000000</pre> ** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQA/AgAAAAH//////////////////////////////////////////wAAAAAA/////wEAAAAAAAAAAANqAQAAAAAAAAAA</pre> -* Case: PSBT With invalid global transaction typed key +* Case: PSBT with invalid global transaction typed key ** Bytes in Hex: <pre>70736274ff020001550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8CAAFVAgAAAAEnmiMjpd+1H8RfIg+liw/BPh4zQnkqhdfjbNYzO1y8OQAAAAAA/////wGgWuoLAAAAABl2qRT/6cAGEJfMO2NvLLBGD6T8Qn0rRYisAAAAAAABASCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> -* Case: PSBT With invalid input witness utxo typed key +* Case: PSBT with invalid input witness utxo typed key ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac000000000002010020955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAIBACCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> -* 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: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87210203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd46304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIQIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYwQwIgBCS1jv+qppThVZ6lyTu/1KiQZCJAVc3wcLZ3FGlELQcCH1yOsP6mUW1guKyzOtZO3mDoeFv7OqlLmb34YVHbmpoBAQQiACB3H9GK1FlmbdSfPVZOPbxC9MhHdONgraFoFqjtSI1WgQEFR1IhA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GIQPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvVKuIgYDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYQtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre> -* Case: PSBT With invalid redeemscript typed key +* Case: PSBT with invalid redeemscript typed key ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a01020400220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQIEACIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> -* Case: PSBT With invalid witnessscript typed key +* Case: PSBT with invalid witnessscript typed key ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre> -* Case: PSBT With invalid bip32 typed key +* Case: PSBT with invalid pubkey in input BIP 32 derivation paths typed key ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre> -* Case: PSBT With invalid non-witness utxo typed key +* Case: PSBT with invalid non-witness utxo typed key ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f0000000000020000bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> ** Base64 String: <pre>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=</pre> -* Case: PSBT With invalid final scriptsig typed key +* Case: PSBT with invalid final scriptsig typed key ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000020700da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> ** Base64 String: <pre>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=</pre> -* Case: PSBT With invalid final script witness typed key +* Case: PSBT with invalid final script witness typed key ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903020800da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> ** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAggA2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre> -* 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: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00210203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58710d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre> ** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIQIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1PtnuylhxDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre> -* Case: PSBT With invalid input sighash type typed key +* Case: PSBT with invalid input sighash type typed key ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0203000100000000010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre> ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wCAwABAAAAAAEAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> -* Case: PSBT With invalid output redeemScript typed key +* Case: PSBT with invalid output redeemScript typed key ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0002000016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre> ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> -* Case: PSBT With invalid output witnessScript typed key +* Case: PSBT with invalid output witnessScript typed key ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00</pre> ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A</pre> @@ -757,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 -|} diff --git a/bip-0175.mediawiki b/bip-0175.mediawiki index a3ffd1c..30c7985 100644 --- a/bip-0175.mediawiki +++ b/bip-0175.mediawiki @@ -6,7 +6,7 @@ Nicholas Gregory <nicholas@commerceblock.com> 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 diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index e515b56..5f4704d 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -17,19 +17,39 @@ 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.) -== Specification == +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. -This BIP follows the specification of BIP-325 challenges and solutions (see Signet comparison below). +== Types of Signatures == -Let there be two virtual transactions to_spend and to_sign. +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. -The "to_spend" transaction is: +=== 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 <code>to_spend</code> and <code>to_sign</code> as defined below, with default values for all fields except that + +* <code>message_hash</code> is a BIP340-tagged hash of the message, as specified below +* <code>message_challenge</code> in <code>to_spend</code> is set to the scriptPubKey being signed with +* <code>message_signature</code> in <code>to_sign</code> 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 <code>to_spend</code> and <code>to_sign</code>. + +The <code>to_spend</code> transaction is: nVersion = 0 nLockTime = 0 @@ -41,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 <code>message_hash</code> is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = <code>BIP0322-signed-message</code>, and <code>message_challenge</code> is the to be proven (public) key script. -The "to_sign" transaction is: +The <code>to_sign</code> transaction is: nVersion = 0 or as appropriate (e.g. 2, for time locks) nLockTime = 0 or as appropriate (for time locks) @@ -55,61 +74,69 @@ 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. +A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation. -* 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. +=== Full (Proof of Funds) === -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 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. -A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below. +* <code>message_challenge</code> is unused and shall be set to <code>OP_TRUE</code> +* Similarly, <code>message_signature</code> is then empty. +* All outputs that the signer wishes to demonstrate control of are included as additional inputs of <code>to_sign</code>, and their witness and scriptSig data should be set as though these outputs were actually being spent. -=== Validation === +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. -To validate a simple proof, the following steps must be taken: +== Detailed Specification == -# construct the to_spend and to_sign transactions, based on the specification above -# check the signature using consensus rules, then upgradable rules +For all signature types, except legacy, the <code>to_spend</code> and <code>to_sign</code> transactions must be valid transactions which pass all consensus checks, except of course that the output with prevout <code>000...000:FFFFFFFF</code> does not exist. -To validate a proof of funds, the following steps must be taken: +=== Verification === -# 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 +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 -== Legacy format == +==== Verification Process ==== -New proofs should use the new format for all invoice address formats, including P2PKH. +Validation consists of the following steps: -The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format. +# Basic validation +## Compute the transaction <code>to_spend</code> from ''m'' and ''A'' +## Decode ''s'' as the transaction <code>to_sign</code> +## If ''s'' was a full transaction, confirm all fields are set as specified above; in particular that +##* <code>to_sign</code> has at least one input and its first input spends the output of </code>to_spend</code> +##* <code>to_sign</code> has exactly one output, as specified above +## Confirm that the two transactions together satisfy all consensus rules, except for <code>to_spend</code>'s missing input, and except that ''nSequence'' of <code>to_sign</code>'s first input and ''nLockTime'' of <code>to_sign</code> 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 <code>CODESEPARATOR</code> or <code>FindAndDelete</code> is forbidden. +## <code>LOW_S</code>, <code>STRICTENC</code> and <code>NULLFAIL</code>: valid ECDSA signatures must be strictly DER-encoded and have a low-S value; invalid ECDSA signature must be the empty push +## <code>MINIMALDATA</code>: all pushes must be minimally encoded +## <code>CLEANSTACK</code>: require that only a single stack element remains after evaluation +## <code>MINIMALIF</code>: the argument of <code>IF</code>/<code>NOTIF</code> 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 <code>to_sign</code> 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. +# Let ''T'' by the nLockTime of <code>to_sign</code> and ''S'' be the nSequence of the first input of <code>to_sign</code>. Output the state ''valid at time T and age S''. === Signing === -Given the P2PKH invoice address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: - -# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code> -# let <code>x</code> be the private key associated with <code>P</code> so that <code>pkh(xG) = p</code> -# let <code>digest</code> be <code>SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m)</code> -# create a compact signature <code>sig</code> (aka "recoverable ECDSA signature") using <code>x</code> on <code>digest</code> - -The resulting proof is <code>sig</code>, serialized using the base64 encoding. +Signers who control an address ''A'' who wish to sign a message ''m'' act as follows: -=== Verifying === +# They construct <code>to_spend</code> and <code>to_sign</code> as specified above, using the scriptPubKey of ''A'' for <code>message_challenge</code> and tagged hash of ''m'' as <code>message_hash</code>. +# Optionally, they may set nLockTime of <code>to_sign</code> or nSequence of its first input. +# Optionally, they may add any additional outputs to <code>to_sign</code> that they wish to prove control of. +# They satisfy <code>to_sign</code> as they would any other transaction. -Given the P2PKH invoice address <code>a</code>, the message <code>m</code>, the compact signature <code>sig</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>: +They then encode their signature, choosing either ''simple'' or ''full'' as follows: -# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code> -# let <code>digest</code> be <code>SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m)</code> -# attempt pubkey recovery for <code>digest</code> using the signature <code>sig</code> and store the resulting pubkey into <code>Q</code> -## fail verification if pubkey recovery above fails -# let <code>q</code> be the pubkey-hash <code>pkh(Q)</code> for the pubkey <code>Q</code> -# if <code>p == q</code>, the proof is valid, otherwise it is invalid +* If they added no inputs to <code>to_sign</code>, left nSequence and nLockTime at 0, and ''A'' is a Segwit address (either pure or P2SH-wrapped), then they may base64-encode <code>message_signature</code> +* Otherwise they must base64-encode <code>to_sign</code>. == Compatibility == @@ -121,7 +148,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 == @@ -131,38 +158,6 @@ Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many oth 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 diff --git a/bip-0338.mediawiki b/bip-0338.mediawiki new file mode 100644 index 0000000..4e2c220 --- /dev/null +++ b/bip-0338.mediawiki @@ -0,0 +1,112 @@ +<pre> + BIP: 338 + Layer: Peer Services + Title: Disable transaction relay message + Author: Suhas Daftuar <sdaftuar@chaincode.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338 + Status: Draft + Type: Standards Track + Created: 2020-09-03 + License: BSD-2-Clause +</pre> + +==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== + +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 +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 +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== + +# 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: +## inv messages for transactions +## getdata messages for transactions +## 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) +# 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. + +This proposal is compatible with, but independent of, BIP 37. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/20726 + +==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. diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index f22194f..1de7faa 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 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. diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki new file mode 100644 index 0000000..9873d80 --- /dev/null +++ b/bip-0350.mediawiki @@ -0,0 +1,336 @@ +<pre> + BIP: 350 + Layer: Applications + Title: Bech32m format for v1+ witness addresses + Author: Pieter Wuille <pieter@wuille.net> + 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 +</pre> + +==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]): + +<pre> +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)] +</pre> + +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: + +<pre> +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 + elif check == BECH32M_CONST: + return Encoding.BECH32M + else: + return None +</pre> + +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<ref>'''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).</ref> 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<ref>'''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.</ref>, 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. + +<pre> +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) +</pre> + +'''Error locating''' + +Bech32m, like Bech32, does support locating<ref>'''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.</ref> 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/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/blob/master/ref/javascript Reference Javascript implementation] + +* Fancy decoder that localizes errors: +** [https://github.com/sipa/bech32/blob/master/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: +* <tt>A1LQFN3A</tt> +* <tt>a1lqfn3a</tt> +* <tt>an83characterlonghumanreadablepartthatcontainsthetheexcludedcharactersbioandnumber11sg7hg6</tt> +* <tt>abcdef1l7aum6echk45nj3s0wdvt2fg8x9yrzpqzd3ryx</tt> +* <tt>11llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllludsr8</tt> +* <tt>split1checkupstagehandshakeupstreamerranterredcaperredlc445v</tt> +* <tt>?1v759aa</tt> + +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 + <tt>1xj0phk</tt>: HRP character out of range +* 0x7F + <tt>1g6xzxy</tt>: HRP character out of range +* 0x80 + <tt>1vctc34</tt>: HRP character out of range +* <tt>an84characterslonghumanreadablepartthatcontainsthetheexcludedcharactersbioandnumber11d6pts4</tt>: overall max length exceeded +* <tt>qyrz8wqd2c9m</tt>: No separator character +* <tt>1qyrz8wqd2c9m</tt>: Empty HRP +* <tt>y1b0jsk6g</tt>: Invalid data character +* <tt>lt1igcx5c0</tt>: Invalid data character +* <tt>in1muywd</tt>: Too short checksum +* <tt>mm1crxm3i</tt>: Invalid character in checksum +* <tt>au1s5cgom</tt>: Invalid character in checksum +* <tt>M1VUXWEZ</tt>: checksum calculated with uppercase form of HRP +* <tt>16plkw9</tt>: empty HRP +* <tt>1p2gdwpf</tt>: 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. +* <tt>BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4</tt>: <tt>0014751e76e8199196d454941c45d1b3a323f1433bd6</tt> +* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</tt>: <tt>00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262</tt> +* <tt>bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kt5nd6y</tt>: <tt>5128751e76e8199196d454941c45d1b3a323f1433bd6751e76e8199196d454941c45d1b3a323f1433bd6</tt> +* <tt>BC1SW50QGDZ25J</tt>: <tt>6002751e</tt> +* <tt>bc1zw508d6qejxtdg4y5r3zarvaryvaxxpcs</tt>: <tt>5210751e76e8199196d454941c45d1b3a323</tt> +* <tt>tb1qqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesrxh6hy</tt>: <tt>0020000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433</tt> +* <tt>tb1pqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesf3hn0c</tt>: <tt>5120000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433</tt> +* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0</tt>: <tt>512079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798</tt> + +The following list gives invalid segwit addresses and the reason for +their invalidity. +* <tt>tc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq5zuyut</tt>: Invalid human-readable part +* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd</tt>: Invalid checksum (Bech32 instead of Bech32m) +* <tt>tb1z0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqglt7rf</tt>: Invalid checksum (Bech32 instead of Bech32m) +* <tt>BC1S0XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ54WELL</tt>: Invalid checksum (Bech32 instead of Bech32m) +* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kemeawh</tt>: Invalid checksum (Bech32m instead of Bech32) +* <tt>tb1q0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq24jc47</tt>: Invalid checksum (Bech32m instead of Bech32) +* <tt>bc1p38j9r5y49hruaue7wxjce0updqjuyyx0kh56v8s25huc6995vvpql3jow4</tt>: Invalid character in checksum +* <tt>BC130XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ7ZWS8R</tt>: Invalid witness version +* <tt>bc1pw5dgrnzv</tt>: Invalid program length (1 byte) +* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v8n0nx0muaewav253zgeav</tt>: Invalid program length (41 bytes) +* <tt>BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P</tt>: Invalid program length for witness version 0 (per BIP141) +* <tt>tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq47Zagq</tt>: Mixed case +* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v07qwwzcrf</tt>: zero padding of more than 4 bits +* <tt>tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vpggkg4j</tt>: Non-zero padding in 8-to-5 conversion +* <tt>bc1gmk9yu</tt>: 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 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<sup>-30</sup>'', 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<sup>-10</sup>'' 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<ref>'''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.</ref> +* '''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.<ref>'''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.</ref><ref>'''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.</ref> +* '''error patterns with failure probability''' For each probability (''0'', ''2<sup>-30</sup>'', ''2<sup>-25</sup>'', ''2<sup>-20</sup>'', ''2<sup>-15</sup>'', and ''2<sup>-10</sup>'') 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<ref>'''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.</ref>. + +{| 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<sup>-30</sup>'' !! ''2<sup>-25</sup>'' !! ''2<sup>-20</sup>'' !! ''2<sup>-15</sup>'' !! ''2<sup>-10</sup>'' +|- +! colspan="10" | Properties averaged over all HRPs +|- +| ≤ 4 || only subst. || any || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none<sup>(a)</sup> +|- +| any || any || ≤ 4 || 56.16%|| 43.84%|| colspan="4" | none<sup>(b)</sup> +|- +| ≤ 2 || any || ≤ 68 || 7.71%|| 92.28%|| colspan="4" | none<sup>(b)</sup> +|- +| ≤ 2 || any || any || 7.79%|| 92.20%|| 0.004%|| colspan="3" | none<sup>(b)</sup> +|- +| ≤ 3 || any || ≤ 69 || 7.73%|| 92.23%|| 0.033%<sup>(d)</sup> || colspan="3" | none<sup>(b)</sup> +|- +| ≤ 3 || any || any || 7.77%|| 92.19%|| 0.034%|| 0.000065% || colspan="2" | none<sup>(b)</sup> +|- +| ≤ 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% +|- +| 0 || - || - || rowspan="3" | Bech32m/Bech32 || 100.00%|| colspan="5" | none<sup>(a)</sup> +|- +| 1 || any || - || 46.53%|| 53.46%|| colspan="4" | none<sup>(b)</sup> +|- +| ≤ 2 || any || any || 22.18%|| 77.77%|| 0.048%|| colspan="3" | none<sup>(b)</sup> +|- +! colspan="10" | Properties for segregated witness addresses with HRP "bc" +|- +| ≤ 4 || only subst. || any || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none<sup>(a)</sup> +|- +| 1 || any || - || 24.34%|| 75.66%|| colspan="4" | none<sup>(c)</sup> +|- +| ≤ 2 || any || ≤ 28 || 16.85%|| 83.15%|| colspan="4" | none<sup>(c)</sup> +|- +| any || any || ≤ 4 || 74.74%|| 25.25%|| 0.0016%|| colspan="3" | none<sup>(c)</sup> +|- +| ≤ 2 || any || any || 15.72%|| 84.23%|| 0.039%|| 0.0053%|| colspan="2" | none<sup>(c)</sup> +|- +| ≤ 3 || any || any || 13.98%|| 85.94%|| 0.078%|| 0.00063%|| colspan="2" | none<sup>(c)</sup> +|- +| ≤ 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% +|- +| 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<sup>(c)</sup> +|- +| 1 || any || - || 70.89%|| 29.11%|| colspan="4" | none<sup>(c)</sup> +|- +| ≤ 2 || any || any || 36.12%|| 63.79%|| 0.092%|| 0.00049%|| colspan="2" | none<sup>(c)</sup> +|} + +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 ''2<sup>30</sup>-1'' constants different from Bech32's ''1''. All of these satisfy the properties marked <sup>(a)</sup> in the table above. +* Through exhaustive analysis, reject all constants that do not exhibit the properties<ref>'''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.</ref> marked <sup>(b)</sup> 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<sup>-20</sup>''). This selection leaves us with 12054 candidates. +* Reject all constants that do not exhibit the <sup>(c)</sup> properties in the table above<ref>'''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.</ref>. This leaves us with 79 candidates. +* Finally, select the candidate that minimizes the number of error classes matching <sup>(d)</sup> in the table above as a final tiebreaker. The result is the single constant ''0x2bc830a3''. + +==Footnotes== + +<references /> + +==Acknowledgements== + +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. |